有时 - 尽管我认为不像许多人想的那么频繁 - 应用程序的设计固有地需要二级索引，范围可查询性等.NoSQL方法通过 document store 如MongoDB . 像Membase一样，Mongo在关系数据库特别弱的一些领域非常好，比如 application-unaware scaling， auto-sharding 和 maintaining flat response times even as dataset size balloons . 它's significantly slower than Membase and a bit trickier to do pure horizontal scale, but the benefit is that it'高度可查询 . 您可以实时查询参数和范围，也可以使用Map / Reduce在真正庞大的数据集上执行复杂的批处理操作 .
6 回答
对"NoSQL"的礼貌解释已成为
Not Only SQL. 如果您的数据确实是真正的关系，或者您的功能取决于连接和ACIDity之类的东西，那么您应该以关系方式存储该数据 . 在这篇文章中，我将解释如何将MySQL与两个NoSQL数据存储一起使用 . 现代的网络规模数据存储就是要了解如何为工作选择最佳工具 .也就是说，NoSQL实际上是对这样一个事实的反应：关系方法和思维方式已经应用于实际上并不适合的问题（通常是具有数千万行或更多行的大表） . 一旦表变得那么大，典型的SQL "best practice"就是手动对数据进行分片 - 也就是说，在表A中放置1到10,000,000的记录，在表B中放置10,000,001到20,000,001，依此类推 . 然后，通常在应用程序模型层中，根据该方案执行查找 . 这就是所谓的
application-aware缩放 . 它_1139965_成为一个或多或少的标准MO . 对我来说，NoSQL代表了application-unaware替代方案 .Key-Value
当我有一个MySQL原型开始变得太大而不是为了自己的好处时，我亲自将尽可能多的数据移动到闪电般快速的Membase，它优于Memcached并增加了持久性 . Membase是一个分布式键值存储，可以或多或少线性扩展（例如，Zynga使用它来处理每秒50万个操作数），通过在群集中添加更多商品服务器 - 因此它非常适合 Cloud 时代Amazon EC2，Joyent等
众所周知，分布式键值存储是获得巨大线性规模的最佳方式 . 键值的弱点是可查询性和索引 . 但即使在关系世界中，可伸缩性的最佳实践是尽可能多地将更多精力卸载到应用程序服务器上，在商用应用程序服务器上进行内存连接，而不是要求中央RDB集群处理所有逻辑 . 由于
simple select加上application logic确实是即使在MySQL上实现大规模扩展的最佳方式，因此向Membase（或其竞争对手，如Riak）等过渡并不是太糟糕 .Document Stores
有时 - 尽管我认为不像许多人想的那么频繁 - 应用程序的设计固有地需要二级索引，范围可查询性等.NoSQL方法通过
document store如MongoDB . 像Membase一样，Mongo在关系数据库特别弱的一些领域非常好，比如application-unawarescaling，auto-sharding和maintaining flat response times even as dataset size balloons. 它's significantly slower than Membase and a bit trickier to do pure horizontal scale, but the benefit is that it'高度可查询 . 您可以实时查询参数和范围，也可以使用Map / Reduce在真正庞大的数据集上执行复杂的批处理操作 .在我上面提到的同一个项目中，我使用Membase来提供大量的实时播放器数据，我们使用MongoDB来存储分析/度量数据，这正是MongoDB所发挥的作用 .
Why to keep things in SQL
我简要地谈到了“真正的关系”信息应保留在关系数据库中的事实 . 正如评论员Dan K.指出的那样，我错过了讨论离开RDBMS的缺点的部分，或者至少完全抛弃它 .
First, there's SQL itself. SQL是众所周知的，并且长期以来一直是行业标准 . 一些"NoSQL"数据库，如Google的App Engine数据存储（基于Big Table构建）实现了他们自己的类似SQL的语言（谷歌的名字很可爱，GQL代表
Google Query Language） . MongoDB以令人愉快的JSON query objects采用了一种全新的查询问题 . 尽管如此，SQL本身也是一种从数据中获取信息的强大工具，这通常是数据库的重点 .保持RDBMS的最重要原因是ACID或
Atomicity, Consistency, Isolation, Durability. 我在this post上获得了很好的解决方案 . 我只想说，有一个理性的原因Oracle's RDBMS这样一个巨大的市场无处可去：一些数据需要纯ACID合规性 . 如果您的数据确实存在（如果确实如此，您可能很清楚这一事实），那么您的数据库也是如此 . 保持低pH！Edit: 查看Aaronaught的帖子here.他比我更好地代表了企业对企业的观点，部分原因是因为我的整个职业生涯都在消费领域 .
我认为这在很大程度上取决于你想要存储在数据库中的内容 . 我没有使用CouchDB或Cassandra的经验，所以我会让其他人代表他们，但我经常使用MongoDB和MySQL .
如果您正在开发需要交易的应用，例如一个计费应用程序，你肯定想要使用MySQL，因为它支持事务 . MySQL是ACIDic，它是Atomic，Consistent，Isolated和Durable . 这实际上意味着当你更新MySQL中的一行时 - 保证发生这种情况 . 然而，MySQL的问题在于它不能非常容易地水平扩展（通过添加越来越多的服务器） . MySQL服务器倾向于通过添加更多内存，硬盘空间等垂直扩展，但它们最终达到上限并且可能会花费巨大的成本 .
MongoDB是一个文档数据库 . 它将类似JSON的文档存储在集合中，并且是无模式的 - 因此每个文档可以是不同的 . 这非常适合您的应用程序的灵活性 . 许多开发人员说noSql解决方案是为程序员开发的，而且根据我的经验，它们往往更容易构建 . 此外，MongoDB通过将数据库分片为块来水平扩展 . 事实上，这甚至可以自动化 .
但是使用MongoDB有一些缺点 . 如果你在 生产环境 中使用它，你真的必须用它来放入一个复制从属 . 这是因为MongoDB没有完整的单服务器持久性 . 因此，如果您遇到电源故障，您可能需要修复整个MongoDB数据库，这可能需要数小时 . 如果您的资金充足，这可能不是一件大事，但如果您是一个资金很少的新组织，那么就很困难（使用 Cloud 计算？） . 此外，MongoDB不支持保证原子性和隔离所必需的事务 . 最后，MongoDB最终只是一致的（虽然我已经看到了这个论点的一些方面） - 这意味着当一个写入发生时，所有其他进程都不能保证直接看到信息 - 只是最终 .
在我看来，如果你存储艺术家信息和关于轨道的元数据，那么MongoDB将是一个很好的解决方案 . 如果您正在存储用户数据，计费数据等，则将其存储在MySQL中 .
这个问题只有一个正确的答案：只有在遇到性能问题或者预计流量大幅增加并且测量（通过压力测试）您的架构不适合时，才能更改当前的解决方案 .
否则 - 甚至不需要评估替代方案 .
对于's worth, I like Aaronaught'对一个非常相似的问题的答案here .
我发现NoSQL数据库很难用于原型设计，因为你必须根据你将如何获得数据来构建你的数据 . 使用NoSQL，架构可以满足您的查询需求 . 但是在原型中，您还不知道如何获取数据，并且每次要为原型添加新功能时，您会发现自己要么执行太多查询，要么重构模式 .
使用关系数据库，您只需标准化数据，就可以提出任何问题 . 如果模型与现实世界实体不匹配，则只需重构模式 .
每次我添加一种新的方式来查看Web应用程序中的数据时，我不得不多次重构我的MongoDB数据库 . 毫不奇怪，我正在融合一个关系模式，它很少利用文档数据库可能的嵌套数组和对象 .
如果你环顾四周，你会发现NoSQL最成功的用途是那些使用关系数据库开发应用程序的人，现在他们了解了他们的功能，可以切换到NoSQL，确切地知道要放入什么来满足他们的查询 . 如果您仍在探索您的应用以及您想要询问数据库的各种问题，我建议坚持关系 .
有几个人喜欢Aaronaught但答应相应的答案问题在此期间被删除了，我从Stackoverflow archive复制了他的答案：