ReSQL的？

大约在2009年创造出来的NoSQL名字标志着从“传统”关系模型的转变。在2009年之前，有相当多的非关系数据库，但是在最近几年中，我们看到了许多新产品（例如，我在上一篇文章中可以看到“ NoSQL格局” ）。一般而言，这里的一切都是疯狂的概括，因为并非所有解决方案都是平等创建的，并且存在多种类型的解决方案-NoSQL解决方案主要意味着放宽了ACID约束，并且顾名思义，删除了“结构化查询”语言（SQL）既作为数据定义语言，更重要的是作为数据操作语言，尤其是SQL的查询功能。

ACID和SQL损失很多，而NoSQL解决方案主要提供一些好处：

可伸缩性–作为相对可伸缩性，意味着在相同的规模上，其规模要比同类RDBMS便宜；或绝对–在规模上比RDBMS更好。可伸缩性通常是通过在Eric Brewer的CAP定理中偏重分区容忍性而不是一致性并依靠“最终一致性”来实现的（稍后会详细介绍）
更简单的模型-即将编程结构映射到存储结构是直接的，因此避免了整个“对象/关系映射的泥潭”（或被Ted Neward称为“ 计算机科学的越南” ）。我不得不说，根据我的经验，这仅是一个事实，因为它只适用于一点，当您需要扩展和/或具有高性能要求时，您需要仔细设计架构，但它并不总是“简单” ”。
后期绑定模式–这是真正的灵活性，因为您可以将数据存储在与原始表单接近的表单中，并在读取时应用这些模式，因此您可以交付多结构数据并轻松处理半结构化数据。

最终的一致性和简单的查询机制可以在一段时间和某些用例中起作用，但是随着NoSQL解决方案的采用变得越来越普遍，我们可以看到市场需要更多。

最终一致性

最终的一致性意味着，如果新读取在一段时间后停止流入，则所有读取将返回最后的更新值-由于新更新很少停止，并且“一段时间后”的定义不明确-这是一个相当微弱的保证，我们将付出一些努力做出更强有力的保证。彼得·贝利斯（Peter Bailis）和阿里·戈德西（Ali Ghodsi）发表了一篇很好的论文，名为“ 今天的最终一致性：局限性，扩展性和超越性 ”，他们在其中讨论了一些选项。 NoSQL领域太宽泛，无法说到处都是这种情况，但是有些解决方案朝这个方向发展，例如，在HBase（我过去几年中使用最多的NoSQL）中，我们看到了“多版本” “并发控制” ，它为单行操作提供ACID保证（可以调低性能）

但是，在真实条件下提供真实保证可能会非常棘手。我强烈建议阅读Jepsen上的Kyle Kingsbury系列精彩文章，他将探讨Postgres，MongoDB，Redis和Riak如何处理网络分区下的写入。

查询

当我们看NoSQL空间时，我们发现很多技术都变得更好，更高级的查询语言，例如mongoDB找到了一些不错的功能； cassandra的查询语言是第三版，但是Hadoop是Hadoop的一种技术，该技术在一般情况下引入查询，特别是SQL，这已成为踩踏的一种趋势。 Hadoop具有一个多供应商，多发行版的生态系统（与Linux不同），似乎每个人都想引入自己SQL解决方案：Cloudera提供了Impala ，Hortonworks正在进行Stinger计划，以增强Hive，Pivotal（nee EMC） greenplum）有Hawq ，IBM正在开发BigSQL ，甚至SalesForce.com（不提供发行版）也为HBase提供了一个名为PhoenixSQL皮肤。上届Hadoop峰会设有一个小组，其中一些参与者讨论了各自平台的优点，值得一听。

我上面给出的示例主要是关于hadoop的-自然，因为这是我一直在使用的环境，因此我对此更加熟悉，但是更重要的是，似乎Hadoop已成功地将自己定位为主要的NoSQL（大规模）（又名大数据）解决方案，因此这种reSQL趋势在该处更加明显，它将（并且确实）也影响其他NoSQL产品。

事实是NoSQL为了简化而放弃了SQL功能-广泛采用会降低所有功能和复杂性，我想主要的问题是，当我们还要处理大数据及其含义（例如后期绑定）时，情况甚至更加复杂。模式与（结构化）查询语言的模式需求；固定或难以移动的数据与联接等）

参考： ReSQL？从我们的JCG合作伙伴 Arnon Rotem Gal Oz在Cirrus Minor博客上获得。