您什么时候选择在Oracle或MySQL之类的东西上使用MongoDB之类的东西？
根据我的理解，NoSQL类型数据库不是要替换RDBMS，但是它们到底是要做什么呢？
#1 楼
我以前在三个宠物项目中使用过CouchDB。一个微博客系统。目的集思广益的应用程序。
之所以选择它而不是诸如MSSQL或MySQL之类的主要原因是使用它时获得的灵活性。没有严格的架构。如果下线三个月，则需要一个特定的表来拥有一个额外的字段，而仅此而已，只需对其进行更改，就可以从那里不断地跳来跳去。
我使用Apress的Beginning CouchDB来学习如何使用它。
例如，CouchDB使用json与数据库进行通信。如果您的语言可以发布数据，则可以使用它与数据库进行通信。
也请阅读：
为什么我应该使用基于文档的数据库而不是关系数据库？在StackOverflow
评论
您的前两个示例听起来像传统的关系型DBMS的一个不错的领域。
–乔纳斯（Jonas）
2011年7月8日在10:57
@yati：这种应用程序听起来像StackOverflow.com，我发现它与传统的关系数据库一起使用非常好。
–乔纳斯（Jonas）
2011年9月19日下午14:08
@yatisagade：我不是在谈论动态社交网站。但是有一个小记笔记的应用程序和一个微博客系统。
–乔纳斯（Jonas）
2011-09-19 14:56
没有定义的架构怎么会加分？对于关系数据库，如果下线三个月需要一个额外的字段，则只需添加该字段。使用关系数据库，您不能动态添加字段，但是也不能动态更改应用程序代码以与动态添加的字段一起使用。
–恢复莫妮卡
16年6月6日在21:20
这个答案似乎表明关系数据库的架构不能更改。我无法理解会有多少误解可能导致某人相信这一点。在关系数据库中添加新列很简单。通常，会有一个不错的UI，或者如果您愿意编写脚本，则可以在单个SQL语句中完成。
–雅克B
16 Dec 12'在15:04
#2 楼
很抱歉添加另一个答案，但是这里没有一个答案令人满意。这个答案是针对MongoDB的（相对于其他大量的非关系数据库的数据存储选项而言）。更新（2020年7月）
这个答案每时每刻都会得到投票和我感到内，因为我已经有一段时间感到内answer了。一方面，MongoDB现在支持多文档事务，这使我提出的很多观点都受到质疑。自从他们添加了这些事务以来，我就没有将其用于深入的性能，因此我无法对此发表评论。
此外，我最近一直在使用非结构化数据，MongoDB的无模式特性比下面的答案可能表明。例如，我正在处理由测试和执行解决方案生成的测试结果数据。测试用例本身（以及不同的结果列）由最终用户创建。 MongoDB允许我以一种可搜索的方式存储自由格式的测试结果，而无需严格的架构。我将再次强调关于迁移的观点。每次用户更改测试用例时，用于分析结果的工具也必须更改。
作为替代，基于SQL的存储引擎增强了对自由格式列（如Postgres的JSONB）的支持。数据类型或MySQL的JSON数据类型。
带走：今天，mongodb和SQL数据库之间的差异越来越像Java＆C＃或Node＆Java之间的差异。两者都有他们的狂热者，他们会觉得这个决定很明显。他们显然在幕后做事有所不同。但是，最终还是很难宣布一个优越者，甚至很难确定有利于任何一个的广泛情况。
如果您正在努力做出这一选择，请选择最吸引您的选择。请记住，随着应用程序的扩展，任何数据解决方案都可能需要不断地重新访问和重写。届时，您将了解更多的存储需求，并可能会在寻找非常适合的关键部分/用例。
MongoDB每次查询的等待时间更短并且花费的CPU时间更少每个查询，因为它的工作量要少得多（例如，没有联接，事务）。结果，它可以处理每秒更高的查询负载，因此如果您有大量用户，就经常使用它。
MongoDB更易于分片（在集群中使用），因为它不会必须担心事务和一致性。
MongoDB具有更快的写入速度，因为它不必担心事务或回滚（因此不必担心锁定）。
MongoDB没有模式，以防您有一个特殊的用例可以利用它。
缺点：
MongoDB不支持事务。这就是它获得大部分收益的方式。
通常，MongoDB为客户端服务器创建更多的工作（例如，更多的CPU成本）。例如，要联接数据，必须发出多个查询并在客户端上进行联接。
即使在2017年，MongoDB的工具支持也比关系数据库少，这仅仅是因为它是更新的。 MongoDB专家的数量也少于关系专家。
经常被误解的要点：
MongoDB和关系数据库都支持索引。在执行大型查询方面，它们的查询性能相似。
MongoDB不会消除迁移的需求，更具体地说，不会随着架构的发展而更新现有数据。例如：如果您有一个依赖用户表来包含某些数据的应用程序，并且修改了该表以包含其他数据（例如，您添加了个人资料图片字段），那么您仍然需要：
编写应用程序以处理未定义此属性的对象，或者
编写一次性迁移以为此属性输入默认值，或者
编写代码以在以下位置提供默认值如果此字段不存在，则查询时间或
以其他方式处理丢失的字段
评论
我要添加一个巨大的东西，这在许多NoSQL与RDBMS讨论中都以某种方式丢失了：NoSQL数据库对于临时查询要困难得多（这是“无SQL部分”。无论您是否是开发人员，这都是事实。因此，使用它们创建报表也变得更加困难，这对于任何严肃的业务都是至关重要的。
–迈克尔
17年11月15日在11:36
嘿，我不赞成与MongoDB进行这种交互，因为我不愿与数据库进行这种交互。但是，Mongo确实具有即席查询语言和图形即席客户端（Compass）。它不像SQL那样具有丰富的功能，所以我同意这是一个潜在的缺点，但是对我个人而言，当我决定使用哪个数据库时，它永远不会有所作为。
–步伐
17年11月15日在16:16
您为什么不鼓励探索数据库中的数据？如果该数据库具有对企业有用的信息，则应尽可能地对其进行访问。显然，虽然没有将负载添加到生产中，但这就是您读取副本的目的。
–迈克尔
17年11月15日在20:24
最终，您将始终拥有对数据感兴趣的利益相关者。无论是通过SQL查询还是某种ipython笔记本脚本，还是通过re：dash。因此，当您更改数据库时，必须始终确保不破坏这些依赖性。 SQL（不是RDBMS）使数据更易于访问，这对企业来说是一件好事。
–迈克尔
17年11月16日在12:14
此评论现在已过时。 MongoDB从3.2开始支持外部联接，从4.0开始支持事务。
– dimiguel
19年6月8日在9:27
#3 楼
要无耻地从Renesis窃取（实际上我是在做这个答案CW）：使用RDBMS代替其他类型：
继续阅读“ NoSQL”和其他数据库类型的概念：
NoSQL：如果那么简单
（以上链接为链接）何时使用MongoDB或其他面向文档的数据库系统？目前已在SO上删除（更多）
https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql -going
何时使用CouchDB和RDBMS
RDBMS大量使用索引来提高性能。在非常大的数据库上，这可能会对性能产生不利影响，甚至会减少每个DB / Shard需要更多硬件的最佳行数。
如果要存储大量数据但读取频率较低，则不理想
/>如果您没有很多外部关系，则关系数据库可能不理想（文档存储）
评论
“ RDBMS大量使用索引来提高性能” MongoDB也不使用索引吗？
–罗塔雷蒂
16-10-19在15:41
何时使用MongoDB或其他面向文档的数据库系统？目前已在SO上删除...没有更多..已重新打开该问题并对其进行了保护。不知道删除背后的原因。
–拉胡尔
17 Mar 20 '17在14:07
如果您正在使用索引来提高性能，但会对性能产生不利影响，那么您就不会在使用索引来提高性能！
–史蒂夫·基德（Steve Kidd）
20年7月25日在14:50
#4 楼
当您的数据不相关时，使用NoSQL数据库可能会带来主要好处，例如性能和可伸缩性（当然取决于情况）。某些设计模式（例如CQRS）使在通常需要SQL数据库独占使用的领域中利用非关系数据变得容易得多。通常使用mongo这样的数据库来缓存数据。例如，如果您需要生成报告，则可以执行一个复杂的SQL查询，该查询可以动态地连接和聚合一堆数据，或者您可以仅从mongo数据库中获取一个已经拥有生成所需内容的json文档那个报告。这使得读取数据确实非常容易（而且速度很快！），但是却可能使写入数据变得非常复杂（这就是CQRS的用处）。
#5 楼
当您通常知道数据在哪里（而不是需要编写多个复杂的查询）时，像MongoDB这样的数据库非常有用。使用Mongo，“相关”数据要么嵌套在父数据中，要么具有主键/外键。例如，如果您有帖子和评论，那就太好了；通常，您不会在帖子的上下文之外显示评论，因此将评论包含在帖子中是很有意义的（这样，您无需查询单独的表即可获取帖子的所有评论）。MongoDB是无模式的。这意味着，在大多数情况下，它将采用任何数据结构。通过Mongo中的嵌入或简单关系无法实现的方法，那就是时候该使用像MySQL或PostgreSQL这样的RDBMS了。
MongoDB并不是要替换SQL。它仅满足不同的需求，并且MongoDB和RDBMS可以结合使用。我认为，如果您不需要数据灵活或嵌入到父文档中，MongoDB并不需要所有。使用MongoDB进行开发非常有趣，因为启动和运行项目（例如在Rails中）涉及的步骤要少得多。需要改变吗？没问题。只需在模型中添加一个属性即可。完成。
我不能代表许多其他NoSQL数据库，尽管我知道它们通常是为满足RDBMS无法满足的特定需求而设计的。有些完全驻留在内存中，或者可以很容易地分片或扩展。我非常确定，如果节点发生故障，Cassandra旨在继续运行而不会丢失数据。 Redis基本上是一个驻留在内存中的键值存储（具有用于持久性的定期磁盘写入功能），但是还具有存储数据类型（如集合）并对其进行排序的能力。
#6 楼
主要胜利是当您想分片数据或拥有多个主数据库时。您可以在MySQL中分片数据，但这会带来很大的麻烦。如果您要进行大量写操作，则将数据分片到多个服务器上通常很有用，问题是，如果要在执行此操作时具有强大的参照一致性，则很难（即使不是不可能）查找CAP定理。SQL数据库具有很好的一致性，但分区支持却很差，NoSQL数据库倾向于采用其他方法。易于分区，但通常称为最终一致性。如果您建立的消息站点还可以，那么对于银行来说可能就不行了。
优点是，现在有多个用于存储数据的模型，因此可以选择实现方式的方法，而以前只有SQL数据库。
SE Radio在这个问题上有一些不错的插曲。
评论
必须记住，分片在很大程度上取决于数据中心的体系结构。如果您有服务器机架，则其性能非常出色。在分布式DC上，不是很多。同意您所说的关于在NoSql数据库上进行分区的一般简便性的意见-但可靠性是一个关键问题。
– Apoorv
2012年11月16日在21:03
如果您进行大量写操作，则可能只有两个模型：非规范化的stronly索引读模型和未索引的写模型。自然地需要复制，这增加了复杂性。您必须评估对您不利的方面：应对NoSQL的局限性，即自己做更多的编程工作来匹配java域中的记录，或者让现有的数据库复制技术来完成工作，否则您将付出更多的代价配置和硬件。
–劳伦斯
17年5月15日在13:46
#7 楼
当您写入大量数据并且查询需求不太复杂时，MongoDB可以很好地工作。因此，当您在Command端通过事件源实现CQRS时，MongoDB非常合适-即您的事件存储是MongoDB数据库。在查询端，我们仍然使用SQL由于其灵活性，服务器db的视图和WCF数据服务位于顶部。我认为在大多数情况下，您确实需要关系数据库的功能来进行查询。
评论
如果您写入大量数据，全局写入锁定不会对您造成负面影响吗？
– Apoorv
2012年11月16日在21:01
请注意，Mongodb不再使用全局写锁（并且在发布以上注释时已被更新为不需要一个）。
–法律
2015年9月3日，下午1:26
#8 楼
MongoDB和RDBMS之间的直接和根本区别是基础数据模型。关系数据库将数据结构化为表格和行，而MongoDB将数据结构化为JSON文档的集合。 JSON是一种自我描述的，人类可读的数据格式。它最初是为浏览器和服务器之间的轻量级交换而设计的，现已被许多类型的应用程序广泛接受。JSON文档由于多种原因对数据管理特别有用。 JSON文档由一组字段组成，这些字段本身就是键值对。这意味着每个JSON文档随处携带其自己的可读模式设计，使文档可以轻松在数据库和客户端应用程序之间移动而不会失去其含义。
JSON也是一种自然的数据格式在应用程序层中使用。与由列和行组成的表相比，JSON支持更丰富，更灵活的数据结构。除了支持数字，字符串，布尔值等字段类型外，JSON字段还可以是数组或嵌套的子对象。这意味着我们可以表示一组复杂的关系，这些关系可以更紧密地表示我们的应用程序所使用的对象。在我们的数据库中使用JSON文档意味着我们在数据库与其服务的应用程序之间不需要对象关系映射器。我们可以以正确的形式保存数据
评论
你在看什么您可以为我们提供报价或链接或背景吗？我们不知道您知道多少-也不知道。除非/除非将它们移到此处，否则在StackOverflow上会有几个非常相似的问题，包括何时使用MongoDB或其他面向文档的数据库系统？
它是网络规模的mongodb-is-web-scale.com / s
讽刺的是：因为这是一个炒作，许多人喜欢听炒作。
@Pace：我认为很难击败这篇文章。