对“ NoSQL”的客气解释已经成为
Not OnlySQL。如果您确实具有真正的关系数据，或者您的功能取决于联接和ACIDity之类的数据，则应以关系方式存储该数据。在本文中，我将解释如何与 两个
NoSQL数据存储区一起使用MySQL 。现代的Web规模的数据存储都是关于了解如何为工作选择最佳工具的。
就是说，NoSQL确实是对以下事实的一种反应：关系方法和思维方式已应用于实际上并不十分适合的问题（通常是具有数千万行或更多行的大型表）。一旦表拿到大，典型的SQL“最佳实践”一直是手工
分片 数据-
即在表B中把记录1至10,000,000表A，10000001通过20000001，等等。然后，通常在应用程序模型层中，根据此方案执行查找。这就是所谓的
application-aware缩放。这是耗时且容易出错的方法，但是在为长表存储维护MySQL的同时扩大规模时，它已成为或多或少的标准MO。对我来说，NoSQL代表了
application-unaware替代方案。
核心价值
当我的MySQL原型开始变得太大而无法满足自己的需要时，我个人将尽可能多的数据转移到了快如闪电的Membase上，该性能优于Memcached并增加了持久性。Membase是一个分布式键值存储，可通过向集群中添加更多商品服务器来线性地扩展（或多或少进行线性扩展（例如，Zynga使用它来每秒处理50万次操作）），因此
非常
适合云时代的亚马逊EC2，Joyent的等
众所周知，分布式键值存储是获得巨大的线性规模的最佳方法。键值的弱点是可查询性和索引编制。但是，即使在关系世界中，可伸缩性的最佳实践是将尽可能多的精力转移到应用程序服务器上，在商品应用程序服务器上的内存中进行联接，而不是要求中央RDB集群处理所有这些逻辑。由于
simpleselectplus
application logic确实是 即使在 MySQL上 也
可以实现大规模扩展的最佳方法，因此向类似Membase（或其竞争对手Riak）的过渡并不是很糟糕。
文件存储
有时-尽管我的争论不如很多人想像的那样-应用程序的设计固有地需要二级索引，范围可查询性等。NoSQL的方法是通过
documentstore类似MongoDB的方法。与Membase一样，Mongo在关系数据库特别薄弱的某些领域（例如
application-unaware扩展
auto-sharding和）非常好
maintaining flat response times even as datasetsizeballoons。它比Membase慢得多，并且在进行纯水平缩放时会比较棘手，但是好处是它具有很高的可查询性。您可以实时查询参数和范围，也可以使用Map
/ Reduce对真正庞大的数据集执行复杂的批处理操作。
在我上面提到的同一项目中，该项目使用Membase提供大量实时播放器数据，我们使用MongoDB存储分析/指标数据，这正是MongoDB的亮点。
为什么要在SQL中保留内容
我简短地谈到了“真正的关系”信息应保留在关系数据库中的事实。正如评论员Dan
K.指出的那样，我错过了讨论离开RDBMS或至少完全离开RDBMS的缺点的部分。
首先，有SQL本身。 SQL是众所周知的，并且长期以来一直是行业标准。诸如Google的App
Engine数据存储区（在Big Table上构建）之类的某些“
NoSQL”数据库实现了它们自己的类似SQL的语言（Google的名字叫GQL，简称GQL
Google QueryLanguage）。MongoDB通过其令人愉悦的JSON查询对象对查询问题采取了一种全新的方法。尽管如此，SQL本身还是从数据中获取信息的强大工具，而数据通常是数据库的出发点。
保留RDBMS的最重要原因是ACID或
Atomicity,Consistency, Isolation, Durability。我不会重新哈希Acid-
NoSQL的状态，因为在SO上的这篇文章中已经很好地解决了它的问题。可以这么说，Oracle的RDBMS拥有如此庞大的市场，这是无可厚非的，这是有道理的：
某些数据需要纯ACID合规性
。如果您的数据可以（如果可以，那么您可能很清楚这一事实），那么数据库也可以。保持低pH值！
