使用NoSQL数据库有什么好处？我最近读了很多关于它们的内容，但我仍然不确定为什么要实现它，在什么情况下我想要使用它。
答案 0 :(得分：74)
关系数据库强制执行ACID。因此，您将拥有基于模式的面向事务的数据存储。它已被证明适用于99％的实际应用。你几乎可以对关系数据库做任何事情。
但是，在大规模高可用性数据存储方面，速度和扩展方面存在限制。例如，谷歌和亚马逊在大数据中心存储了数TB的数据。由于RDBM的阻塞/架构/事务性质，在这些场景中查询和插入不具备性能。这就是他们实现自己的数据库（实际上是键值存储）以实现大规模性能提升和可扩展性的原因。
NoSQL数据库已经存在了很长时间 - 只是这个术语是新的。一些示例是图形，对象，列，XML和文档数据库。
关于你的第二个问题：可以在同一个网站上同时使用它们吗？
为什么不呢？两者都有不同的用途吗？
答案 1 :(得分：69)
NoSQL解决方案通常用于解决关系数据库不适合使用的问题，使用起来过于昂贵（如Oracle）或者要求您实现破坏数据库关系性质的东西。
优点通常特定于您的使用，但除非您在RDBMS中对数据进行建模时遇到某种问题，否则我认为没有理由选择NoSQL。
我自己使用MongoDB和Riak来解决RDBMS不可行的特定问题，对于我使用MySQL（或SQLite进行测试）的所有其他事情。
如果您需要您通常知道的NoSQL数据库，可能的原因是：
如果您不需要NoSQL解决方案请记住，这些解决方案并不是RDBMS的替代品，而是前者失败的替代方案，更重要的是它们相对较新，因此它们仍然有很多错误和缺失的功能。
哦，关于第二个问题，将任何技术与另一个技术结合使用是完全没问题的，所以只要他们不在同一台机器上就可以完成MongoDB和MySQL的完美工作
答案 2 :(得分：33)
Martin Fowler有一个很好的video，它很好地解释了NoSQL数据库。该链接直接告诉他使用它们的原因，但整个视频包含了很好的信息。
您拥有大量数据 - 特别是如果您无法将其全部放在一台物理服务器上，因为NoSQL的设计可以很好地扩展。
Object-relational impedance mismatch - 您的域对象不适合在关系数据库架构中使用。 NoSQL允许您将数据保存为文档（或图形），这些文档可能更贴近您的数据模型。
答案 3 :(得分：13)
NoSQL是数据库系统，其中数据被组织到文档（MongoDB），键值对（MemCache，Redis），图形结构形式（Neo4J）中。
也许这里有可能的问题和答案“什么时候去NoSQL”：
需要灵活的架构或处理树状数据？ 通常，在敏捷开发中，我们开始设计系统而不需要预先了解所有需求，后来在整个开发过程中，数据库系统可能需要适应频繁的设计更改，展示MVP（最小可行产品）。 或者您正在处理本质上是动态的数据模式。 例如系统日志，非常精确的示例是AWS cloudwatch日志。
数据集庞大/大？ 是NoSQL数据库是数据库需要管理数百万甚至数十亿条记录而不影响性能的应用程序的理想选择。
缩放一致性之间的权衡
与RDMS不同，NoSQL数据库可能会在这里和那里丢失小数据（注意：概率为.x％），但它在性能方面很容易扩展。
示例：这可能适用于存储即时消息应用程序中的联机人员，数据库中的令牌，记录网站流量统计信息。
执行地理定位操作： MongoDB hash支持GeoQuerying＆amp;地理位置操作。 我真的很喜欢MongoDB的这个功能。
简而言之，MongoDB非常适合可以大规模存储动态结构化数据的应用程序。
答案 4 :(得分：3)
缺少一些基本信息来回答这个问题：数据库必须涵盖哪些用例？是否必须从现有数据（OLAP）执行复杂分析，或者应用程序是否必须能够处理许多事务（OLTP）？什么是数据结构？这远非问题时间的结束。
在我看来，在粗略流行语的基础上做出技术决策是错误的，而不知道究竟是什么背后。 NoSQL因其可扩展性而受到称赞。但你也必须知道水平缩放（在几个节点上）也有它的价格并且不是免费的。然后，您必须处理eventual consistency等问题，并定义如果无法在数据库级别解析数据冲突，如何解决这些问题。但是，这适用于所有分布式数据库系统。
开发人员喜欢“＃34; schema less＆＃34;在NoSQL开始时也很大。这个流行语很快就会在技术分析后失去理智，因为它在编写时正确地不需要架构，但在阅读时会发挥作用。这就是为什么它应该正确地为＃34;架构在读＆＃34;。能够根据自己的判断编写数据可能很诱人。但是，如果存在现有数据但应用程序的新版本需要不同的架构，我该如何处理这种情况呢？
对于数据模型之间存在许多关系的数据模型，文档模型（例如，在MongoDB中）是not suitable。连接必须在应用程序级别完成，这是额外的工作，为什么我应该编写数据库应该做的事情。
如果您认为谷歌和亚马逊已经开发了自己的数据库，因为传统的RDBMS无法再处理大量数据，那么您只能说：您不是谷歌和亚马逊。这些公司是先锋，占传统数据库不再适用的场景的0.01％，但对于世界其他地区而言，它们都是适合的。
什么不是无关紧要的：SQL已经存在了40多年，数百万小时的开发已经进入大型系统，如Oracle或Microsoft SQL。这必须通过一些新的数据库来实现。有时，查找SQL管理员比使用MongoDB更容易。这带来了维护和管理的问题。一个不完全性感的主题，但这是技术决策的一部分。
答案 5 :(得分：2)
我在寻找偏离RDBMS设计的令人信服的理由时遇到了这个问题。
Julian Brown有一个很棒的post，它揭示了分布式系统的限制。这个概念被称为Brewer的CAP定理，总结如下：
分布式系统的三个要求是：一致性，可用性和分区容差（简称CAP）。但是你一次只能有两个。
这就是我自己总结的方式：
如果您正在牺牲一致性，那么最好选择NoSQL。
答案 6 :(得分：0)
我使用NoSQL数据库设计和实现了解决方案，这是我的检查点列表，以便决定使用 SQL 或面向文档的NoSQL 。
不要
SQL并不是过时的，并且在某些情况下仍然是更好的工具。
很难证明使用面向文档的NoSQL是合理的。待办事项
如果您没有这些条件或可以缓解这些条件，那么有2个理由可以使您从NoSQL中受益：
更多信息
在我的博客文章中，我详细解释了原因：
注意：以上内容仅适用于面向文档的NoSQL。有other types的NoSQL，需要其他注意事项。
答案 7 :(得分：0)
处理大量读写操作
需要快速扩展时，请查看NoSQL数据库。而且通常什么时候需要快速扩展？
当您的网站上有大量读写操作以及处理大量数据时，NoSQL数据库最适合这些情况。由于他们具有即时添加节点的能力，因此他们可以以最小的延迟处理更多的并发流量和大量数据。
数据建模的灵活性
第二个提示是在开发的初始阶段，当您不确定数据模型，数据库设计，事物会快速变化时。 NoSQL数据库为我们提供了更大的灵活性。
最终一致性比强一致性
当我们可以放弃强一致性并且不需要事务时，最好选择NoSQL数据库。
例如Twitter之类的社交网站就是一个很好的例子。当名人的推文爆炸时，每个人都喜欢从世界各地转发它。点赞次数短暂上升或下降有关系吗？
名人绝对不会在乎，如果系统在短时间内显示5百万个250，而不是实际的500万个喜欢。
将大型应用程序部署在遍布全球的数百台服务器上时，地理上分散的节点需要一些时间才能达成全球共识。
直到他们达成共识，实体的价值才是不一致的。不久之后，实体的价值最终将保持一致。这就是最终的一致性。
尽管不一致并不意味着存在任何类型的数据丢失。这只是意味着数据需要很短的时间才能通过海底互联网电缆在全球范围内传播，从而达成全球共识并变得一致。
我们一直都在经历这种行为。特别是在YouTube上。通常，您会看到一个视频，其中包含10次观看和15个顶。这怎么可能？
不是。实际的观点已经超过了喜欢的观点。只是观看次数不一致，需要很短的时间才能更新。
运行数据分析
NoSQL数据库也最适合数据分析用例，在这种情况下，我们必须处理大量数据的涌入。