1.简介

作为软件开发人员，我们生活在令人兴奋的创新新时代，尤其是在数据存储和数据处理领域。 过去由关系数据库管理系统主导的可用解决方案的格局已被所谓的NoSQL和后来的NewSQL运动大大改变了。

这些新型的数据存储应运而生，以满足现代分布式应用程序体系结构的需求，这需要前所未有的（当时）可扩展性和可用性保证。 垂直可伸缩性达到了这样的水平：硬件或/和支持基础架构的成本变得不合理地高，因此不可避免地要转向水平可伸缩性 。

在本文中，我们将研究在分布式体系结构中管理数据的一般问题，简要讨论传统的关系数据库管理系统 ，然后将我们的设备切换到NoSQL / NewSQL解决方案。

本文决不是要定义获奖者或强调特定数据存储解决方案的优劣。 而不是概述可以帮助您构建复杂的分布式系统的更多选项，而是要选择合适的工具来完成工作，并且要事先知道没有通用的解决方案。

2.分布式系统：CAP定理

2000年，埃里克·布鲁尔（Eric Brewer）提出了定理，该定理如今称为CAP定理 。 它断言一个分布式系统不能同时提供以下所有三个理想特征：

• 一致性 ：读操作可查看所有先前完成的写操作。 在分布式系统的上下文中，这意味着所有节点都同时看到相同的数据。
• 可用性 ：读写操作始终成功。 在分布式系统的上下文中，这意味着每个请求都会收到有关成功还是失败的响应。
• 分区容限 ：尽管由于网络故障而导致任意分区，但系统仍继续运行，这会阻止某些节点与其他节点进行通信。

我们不打算详细讨论CAP定理 ，因为这是值得写的文章，而是强调它在分布式系统设计中的重要性。 尽管多年来引起了很多争论（最终导致Eric Brewer在2012年发表了后续文章《 CAP十二年后》 ），但大多数（如果不是全部） NoSQL / NewSQL解决方案都是基于CAP概述的权衡取舍的定理 。

在本文中，我们将重点介绍每当适当且相关细节可用时，每个数据存储如何解释CAP定理 。

3.关系数据存储

长期以来， 关系数据库管理系统一直是数据存储解决方案的事实上的标准。 不时有新的参与者试图挑战这一点（例如， 对象数据库 ），但是他们中没有一个能够真正破坏市场。 SQL （及其特定于供应商的方言）是用于查询关系数据存储的实际标准，对于任何软件开发人员来说， SQL本质上都是必知的语言。

但是，几年前，当数据量的增长呈指数级增长时，情况开始发生根本变化，从而达到了关系数据库管理系统设计的极限。

MySQL的/ MariaDB的

MySQL是最古老的开源关系数据库管理系统之一，也是目前使用最广泛的数据存储之一。 无论如何，由于它的稳定性和可靠性， MySQL曾经是并且现在是大多数现代应用程序的数据存储引擎的绝佳选择。

但是， MySQL的发展道路在2009年发生了急剧变化，当时Oracle Corporation达成了收购MySQL版权和商标所有者的Sun Microsystems的协议。 此次收购引起了人们对MySQL未来的担忧，因此，这与我们今天所称的MariaDB无关 。

为了满足现代分布式系统的可伸缩性和可用性需求， MySQL和MariaDB都提供了集群版本，分别为MySQL Cluster和MariaDB Galera Cluster 。 参考CAP定理描述，单个MySQL群集或MariaDB Galera群集是CP系统。

要结束MySQL ，值得一提的是一些案例研究：

• Twitter 上的MySQL，Twitter上的MySQL和Mysos的孵化
• Twitter如何使用MySQL每天存储2.5亿条推文
• WebScaleSQL：基于MySQL上游的协作 ，

PostgreSQL的

PostgreSQL与MySQL一样广泛地使用，并且基本上这些数据存储是最受欢迎的开源关系数据库管理系统 。 PostgreSQL与MySQL具有许多相似之处，从传统上讲 ，它在提供更好的可扩展性和许多高级功能方面仅领先几步。

PostgreSQL目前缺少的功能之一是开箱即用的集群支持，尽管有两个可用的选项 。

其他

尽管我们将在本文中讨论开放源代码解决方案，但值得一提的是由Oracle数据库 ， Microsoft SQL Server和IBM DB2领导的商业关系数据库管理系统领域的主要参与者。 根据您愿意支付的价格，这些数据存储可提供相当不错的性能，可伸缩性和可靠性，可以满足大多数分布式系统的要求。

4.为什么要使用NoSQL？

我认为可以说， NoSQL / NewSQL运动源于填补现代海量，可扩展性强，响应Swift且可用的分布式系统（处理海量数据）的体系结构中的空白的迫切需求。 在某个时候，由关系数据库管理系统支持的“一刀切” 模式成为系统满足其功能要求的限制因素（甚至是阻碍因素）。

尽管NoSQL / NewSQL解决方案彼此之间存在巨大差异，但它们还是有一些共同点：更简单的设计，对CAP定理折衷的理解以及对水平可伸缩性的支持。 从本质上讲，要付出代价或很难找到几乎完全适合您的应用程序所有需求的通用NoSQL / NewSQL数据存储。 选择取决于NoSQL / NewSQL数据存储必须解决的问题。 这就是为什么近来经常将关系数据库管理系统与一个或多个NoSQL / NewSQL数据存储结合在一起的原因。

在本文的其余部分中，我们将看一下许多最受欢迎的NoSQL / NewSQL解决方案，它们分为七个不同的类别： 键/值数据存储区 ， 列式数据存储区 ， 图数据存储区 ， 文档数据存储区 ， 时间序列数据存储 ， 混合数据存储和专业数据存储 。 这些数据存储中的每一个都至少值得一本专门的书，因此我们将关注关键的设计决策和用例。

5.键/值数据存储

键/值数据存储区旨在将数据作为关联数组（也称为字典或哈希）进行存储，查询和管理。 它们非常适合分布式（或复制）缓存解决方案，但是其中许多数据存储都超出了简单的键/值操作。

DynamoDB

本文的目的是仅涵盖NoSQL / NewSQL空间中的开源解决方案，但DynamoDB将是一个例外。 这样做的原因是其基本原理（如Dynamo：Amazon的高可用键值存储中所述 ）的巨大影响力，这为许多开源替代方案带来了灵感。

Amazon DynamoDB是一项完全托管的NoSQL数据存储服务，可提供无缝的可扩展性和快速可预测的性能。 尽管它最广为人知的是键/值数据存储 ，但它也能够以文档格式（JSON，XML和HTML）管理数据。 参考CAP定理 ， DynamoDB是AP系统。

关于何时使用的建议：

• 大量特别活动
• 社交媒体应用
• 批量处理
• 报告中
• 实时分析

为了完成DynamoDB的开发 ，值得一提的是一些案例研究：

• 在生产中使用DynamoDB

记忆快取

Memcached是内存中的键/值数据存储区，用于存储任意小数据块（字符串，对象），这些小块数据可以表示数据库调用，API调用或呈现的页面的结果。 在许多方面， Memcached是关键/值数据存储的先驱之一，非常广泛地主要用作缓存解决方案，旨在通过减轻数据库负载来加速动态Web应用程序。 Memcached没有任何现成的集群支持，并且由于这种简化的设计， Memcached非常快速，有效，但是却不是很可靠（这对于当今的许多分布式应用程序来说是不可接受的）。

关于何时使用的建议：

• 缓存层
• 内存会话存储

雷迪斯

与Memcached一起 ， Redis是最广泛使用的键/值数据存储之一 。 尽管将Redis视为键/值存储是一个正确的假设，但是Redis所做的更多，将复杂数据结构的强大功能释放给开发人员。 引用http://redis.io ：

“ Redis是开放源代码，BSD许可的高级键值存储，用作数据库，缓存和消息代理。 它通常被称为数据结构服务器，因为键可以包含字符串，哈希，列表，集合和排序集合。”

对于分布式部署， Redis支持集群（也称为Redis Cluster ）。 有趣的是，从CAP定理的角度来看， Redis Cluster既不是CP也不是AP系统，而是类似的东西。

关于何时使用的建议（有关更多详细信息，请参阅如何仅将Redis添加到您的堆栈中以利用Redis ）：

• 缓存层
• 内存会话存储
• 分布式锁定
• 实时分析
• 发布/订阅和队列
• 专柜
• 排行榜

为了完成Redis ，值得一提的是一些案例研究：

• Craigslist的Redis分片
• Twitter如何使用Redis进行扩展

里亚克

Riak KV是一个分布式，可伸缩且容错的键/值数据存储 。 它支持高级的本地和多集群复制，即使在发生硬件故障或网络分区时，也可以保证读写。 Riak KV的显着特征之一是复杂的查询支持，它基于全文搜索，二级索引和map / reduce建立 。 从CAP定理的观点来看， Riak KV是支持可调一致性和可用性级别的AP系统。

有关何时使用的建议（有关更多详细信息，请参阅Riak：用例 ）：

• 内容管理
• 会话存储
• 投放广告
• 记录数据
• 传感器数据
• 用户资料/设置/首选项存储

气钉

Aerospike是经过闪存优化的内存中键/值数据存储 ，适用于需要超快速度，经济高效的扩展且无停机的关键任务应用。 Aerospike的集群体系结构旨在通过自动故障转移，复制，跨数据中心同步和线性可伸缩性可靠地存储TB级数据。 根据CAP定理 ， Aerospike基本上是一个AP系统，它另外还试图提供高一致性保证。

有关何时使用的建议（有关更多详细信息，请参阅Aerospike：用例 ）：

• 缓存层
• 用户资料存储
• 推荐引擎
• 欺诈检测和干预

为了完成Aerospike ，值得一提的是很多有趣的资源：

• 寻求数据库规模
• Aerospike规模的内存中计算

基础数据库

FoundationDB是NoSQL / NewSQL系列的成员， 该系列将键/值数据存储的传统可伸缩性与真正的多键ACID事务相结合。 SQL层可以访问存储的数据，这使得FoundationDB与到目前为止我们讨论过的所有其他键/值数据存储完全不同。 遗憾的是， FoundationDB曾经是一个开源项目，但据报道在2015年3月被Apple收购后，它突然停止提供下载并删除了其公共存储库。

6.列式数据存储

柱状数据存储区旨在存储，查询和管理结构化数据。 与关系数据库管理系统非常相似，它们使用表，行和列，但是同一表中行的名称和格式可能会因行而异。 许多列式数据存储都基于Google在Bigtable：结构化数据的分布式存储系统一书中描述的原理。

柱状数据存储确实具有广泛的适用性，因此很难提出准确的建议清单。 但是，本节中讨论的每个数据存储都有一些独特的条件，这使其成为某些情况下的不错选择。

Accumulo

Apache Accumulo是基于Google BigTable设计的高度可扩展的结构化NoSQL数据存储。 Apache Accumulo支持有效存储和检索结构化数据（包括范围查询），提供映射/减少处理功能，并具有自动负载平衡和分区，数据压缩和细粒度安全标签的功能。 值得一提的是， Apache Accumulo在Hadoop分布式文件系统 （HDFS）上运行。 参考CAP定理的权衡， Apache Accumulo是一个CP系统。

关于何时使用的建议：

• 数据访问需要细粒度的安全性
• Apache Hadoop集成需要快速的读/写访问权限
• 还有很多……

卡桑德拉

与大多数此类数据存储一样， Apache Cassandra建立在Google的BigTable （和Amazon的Dynamo ）的基础上，当您需要可扩展性和高可用性而不影响性能时，它是正确的选择。 它在商品硬件或云基础架构上提供了线性可扩展性和经过验证的容错能力，使其成为关键任务数据的理想平台。 它是完全分散的，没有单点故障。

Apache Cassandra的杀手级功能之一是支持多个数据中心复制，因此对降低延迟和灾难恢复的功能要求很高。 从CAP定理的角度来看， Apache Cassandra是具有可调一致性级别的AP系统。

有关何时使用的建议（有关更多详细信息，请参阅Apache Cassandra：用例 ）：

• 大量写工作负载
• 产品目录/播放列表
• 推荐/个性化
• 欺诈识别
• 讯息传递
• 物联网/传感器数据
• 实时分析
• 还有很多……

为了完成Apache Cassandra的开发 ，值得一提的是一些案例研究：

• Cassandra投入生产：我们学到的东西
• 调整Cassandra @ Target
• Cassandra数据建模最佳实践， 第1 部分和第2部分

HBase的

当您需要对大量数据进行随机，实时读写访问时， Apache HBase是一个不错的选择。 与Accumulo一样，它在Google的BigTable的大力启发下构建于Hadoop分布式文件系统 （HDFS） 之上 。 线性可伸缩性，严格一致的读写，自动和可配置分片，自动故障转移以及与Apache Hadoop的集成只是关于Apache HBase设计的最重要功能的子集。 以CAP定理为基础， Apache HBase是一个CP系统。

关于何时使用的建议（有关更多详细信息，请参阅Apache HBase：用例 ）：

• 实时分析
• 批量处理
• 时间序列数据
• 还有很多……

为了完成Apache HBase ，值得一提的是一些案例研究：

• 为什么我们使用HBase， 第1 部分和第2部分
• Facebook的新实时消息系统

7.图形数据存储

图形数据存储家族基于图形理论 ，因此其数据模型围绕节点（顶点），边和属性构建，以表示和存储链接的数据。 这种数据存储在解决类似图形的问题时特别强大，例如查找两个节点之间的最短路径。

Neo4J

Neo4j是开放源代码NoSQL图形数据存储，自2007年以来已公开可用。Neo4j提供了全套可扩展且可靠的数据存储特征，包括ACID事务合规性，集群支持和运行时故障转移，使其适合用于管理图形实际生产场景中的数据。 Neo4j的商业产品还通过高可用性，实时备份和全面监视来补充功能集。 从CAP定理的观点来看， Neo4j是CA系统。

有关何时使用的建议（有关更多详细信息，请参阅Neoj4：用例 ）：

• 主数据管理
• 网络和IT运营
• 实时建议
• 欺诈识别
• 社交网络
• 身份和访问管理
• 基于图的搜索

泰坦

Titan是可扩展的图形数据存储，已优化用于存储和查询包含分布在多节点群集中的数千亿个顶点和边的图形。 Titan是一个事务数据库，可以实时支持数千个并发的复杂图形遍历执行。 此外， Titan还提供线性可扩展性，数据分发和复制，容错能力，多数据中心高可用性和热备份。 Titan没有实现自己的存储机制，而是可以由Apache HBase （使其成为CP系统）或由Apache Cassandra （使其成为AP系统）来支持。

关于何时使用的建议：

• 批处理和分析
• 网络和IT运营
• 欺诈识别
• 社交网络
• 基于图的搜索

若要完成了土卫六 ，这是值得一提的相当多的案例：

• 快速图的攻击分析

FlockDB

FlockDB是来自Twitter的分布式容错图数据库。 通过其设计， FlockDB比其他图形数据库要简单得多，因为它试图解决的问题更少。 它可以水平缩放，并设计用于实时，低延迟，高吞吐量的环境。 FlockDB建立在MySQL存储层之上，利用另一个名为Gizzard的 Twitter框架提供分片和复制支持。 可悲的是，似乎FlockDB的开发自2012年以来就被搁置了。

要完成FlockDB ，值得一提的是一些案例研究：

• 引入FlockDB

图库

GraphBase是一种商用的分布式NoSQL图形数据存储，旨在存储大量的高度结构化的数据并管理大型图形。 它声称提供很小的内存和存储空间，支持内置的遍历启发式和基于图的事务。 供应商提供的详细信息很少，不足以使GraphBase就CAP定理而言是可信的。

有关何时使用的建议（有关更多详细信息，请参考GraphBase：用例 ）：

• 主数据管理
• 大型人和/或物网络中的相互作用
• 社交网络
• 复杂的自然模型（生物，经济，环境……）
• 大规模情报收集

无限图

InfiniteGraph是商业图数据存储领域中的另一个参与者，它是来自分布式可伸缩图数据库，专门设计用于遍历复杂的关系并为制定实时业务决策提供基础。 InfiniteGraph自然支持分区和分布，从而保留跨节点边界查询数据的能力。 由于可用信息有限，因此很难根据CAP定理对InfiniteGraph进行分类，因此最好不要在此处进行任何猜测。

关于何时使用的建议：

• 欺诈识别
• 监视
• 处方分析
• 网络安全信息和事件管理（SIEM）
• 大规模情报收集

8.文档数据存储

NoSQL数据存储的另一类称为文档数据存储 ，用于存储，查询和管理文档（半结构化数据）。 数据记录不依赖于通常的键/值或表/列/行表示，而是存储为完整的文档，这些文档被组织为集合。 它非常自然且易于使用模型进行拨号，尤其是在现代Web应用程序中， JSON文档是主要的数据交换和表示格式。

Couchbase

Couchbase将自己定位为交互式Web应用程序的NoSQL 文档数据存储 。 它支持灵活的数据模式（与大多数文档数据存储一样） ，易于扩展，并提供一致的高性能和高可用性。 对于要求低延迟和高吞吐量的Web应用程序， Couchbase是一个不错的选择。 Couchbase提供的杰出功能是本机移动就绪性，它​​允许通过嵌入式数据库和自动同步在脱机支持下构建移动应用程序。 根据CAP定理的权衡， Couchbase是AP系统。

有关何时使用的建议（有关更多详细信息，请参阅Couchbase：用例 ）：

• 内容管理
• 欺诈识别
• 个人资料管理
• 数字通讯
• 个性化
• 产品数据管理
• 实时分析

CouchDB

CouchDB是为Web构建的文档数据存储 ：它以JSON文档的形式管理数据，具有内置的HTTP API，可直接从Web浏览器访问和查询文档，并使用JavaScript语言对文档进行索引，合并和转换。 CouchDB是可扩展的，高度可用的，分区容忍的，最终一致的系统，具有自动冲突检测功能。 遵循CAP定理设计约束， CouchDB是AP系统。

值得一提的是，尽管CouchDB和Couchbase是不同的产品，但它们确实有很多共同点，有时会使选择哪一个更加困难。 Couchbase与Apache CouchDB：两种开源NoSQL数据库技术的比较对这两种解决方案的历史以及它们之间的主要区别有一个公平的了解。

关于何时使用的建议：

• 内容管理
• 产品数据管理
• 个人资料管理
• 个性化

MongoDB

MongoDB是一个水平可伸缩且高度可用的文档数据存储 ，用于管理和存储归类为集合的JSON样式的文档。 除许多其他功能外，它还支持动态架构，高级监视，复杂查询，二级索引（包括全文搜索支持），复制，自动故障转移和分片。 MongoDB的显着特征之一是通过促进更快的开发过程而易于上手和使用。 从CAP定理来看， MongoDB是CP系统。

有关何时使用的建议（有关更多详细信息，请参阅MongoDB：用例 ）：

• 运营情报
• 产品数据管理
• 库存管理
• 内容管理
• 记录数据
• 报告中

为了完成MongoDB ，值得一提的是很多有趣的资源：

• 关于大规模运行MongoDB的十件事
• 我们如何扩展MongoDB

9.时间序列数据存储

时间序列数据存储区 （也称为TSDB ）是NoSQL解决方案的特殊类，它针对处理时间序列数据进行了高度优化：按时间排序的数据点阵列。 尽管通常可以使用其他类别的NoSQL / NewSQL数据存储区（例如Document数据存储区或Columnar数据存储区 ）来管理时间序列数据，但是由于要解决的问题的性质，在大多数情况下它不是适当的替代方法。

InfluxDB

InfluxDB是一个分布式时间序列，指标和分析数据存储。 尽管在撰写本文时，群集，复制和高可用性的支持被视为处于alpha状态，但是InfluxDB提供了许多其他强大的稳定功能：

• 强大的类似SQL的查询语言
• 用于数据提取和查询的本机HTTP（S）API
• 数据保留策略
• 即时聚合

与其他时间序列数据存储区相比， InfluxDB最明显的特点可能是没有外部依赖项：只需下载，解压缩和运行即可。 尽管InfluxDB被设计为高度可用并最终保持一致的数据存储，但从CAP定理的角度来看，它既不是CP也不是AP系统。

关于何时使用的建议：

• 指标/事件数据
• 传感器数据
• 实时分析

为了完成InfluxDB ，值得一提的是一些案例研究：

• Go的实时指标：在生产中运行InfluxDB

OpenTSDB

OpenTSDB是一个可伸缩的时间序列数据存储 ，从头开始设计用于存储和提供大量的时间序列数据，而不会丢失粒度。 OpenTSDB建立在Apache HBase的基础上 （有关更多详细信息，请参见HBase ），因此它继承了其大多数特征：线性可伸缩性，自动复制，有效的扫描和高写入吞吐量。

关于何时使用的建议：

• 指标数据
• 传感器数据
• 实时分析

德鲁伊

Druid是为交互式分析而构建的分布式，可伸缩，高性能，面向列的实时分析数据存储。 其最重要的功能包括高可用性，低延迟数据提取，灵活的数据浏览和快速的数据聚合。 从许多方面来看， Druid是OLAP数据存储，它的重点更多是在存储聚合数据（但是目前不支持联接）。 Druid的本机查询语言是JSON，而Druid在后台使用不同的存储元数据和实际数据。

关于何时使用的建议：

• 实时分析
• 指标/事件数据

为了结束Druid的学习 ，值得一提的是一些案例研究：

• 建立实时处理数十亿事件的数据管道
• 宣布Suro：Netflix数据管道的骨干

普罗米修斯

Prometheus是一种服务监控系统和时间序列数据存储，旨在确保可靠性。 它非常适合收集任何纯数字时间序列，并且它对多维数据收集和查询的支持特别有用。 也许，最重要的Prometheus功能是它不是严格分布的系统：每个服务器都彼此独立运行，并且仅依靠其本地存储来实现核心功能。

关于何时使用的建议：

• 指标数据

最后要完成Prometheus ，值得一提的是一些案例研究：

• Prometheus：在SoundCloud进行监听

10.混合数据存储

到目前为止，有一组特定的解决方案属于多个类别的NoSQL / NewSQL数据存储。 那些可以归类为混合数据存储，通常它们提供多种存储和管理数据的方式（例如，相同的NoSQL数据存储可以用作键/值数据存储以进行缓存，以及用作文档数据存储以进行内容管理） 。

从操作的角度来看，单个混合数据存储可以替换两个或多个专用数据存储，从而降低了分布式系统部署，监视和维护的复杂性。 类似地，从用例来看，预期的混合数据存储可能非常适合并且相对于要替换的数据存储同样有效。

有趣的是，根据CAP定理 ，在大多数情况下，混合数据存储会根据应用程序利用方式的不同而进行取舍。

ArangoDB

ArangoDB是具有高性能数据模型的分布式高性能NoSQL数据存储，用于管理文档，图形和键/值。 本质上，它通过提供现代Web应用程序通常所需的大多数功能而被设计为通用数据存储。 这些包括（但不限于）无模式数据模型，通用HTTP REST API，支持复杂过滤条件和联接的类似SQL的查询语言（AQL）， ACID多集合/单文档事务。 ArangoDB还为称为Foxx的以数据为中心的微服务提供了专用JavaScript框架，其中提供了各种微服务（例如，用户服务或会话服务）。 从可扩展性的角度来看， ArangoDB支持异步主从复制和分片群集。

关于何时使用的建议：当需要不同的数据模型投影（文档，图形，键/值）时，作为专用数据存储的就地替代。

东方数据库

OrientDB是线性可扩展的高性能可操作NoSQL数据存储，它将图形的功能和文档的灵活性结合在一起。 OrientDB的强项是完全支持ACID事务，多主复制，分片以及使用SQL（带有某些扩展）来操纵树和图。 HTTP REST API的存在也值得一提。

关于何时使用的建议：当需要不同的数据模型投影（文档，图形）时，作为专业数据存储的就地替代。 但是， OrientDB可以超越此范围（如OrientDB：用例要点），并且可以用于：

• 时间序列
• 聊天室
• 排队系统

HyperDex

HyperDex是下一代分布式键值和文档NoSQL数据存储，从头开始设计时就考虑了可靠性，健壮性和性能。 它重视强大的一致性，容错性，可伸缩性，丰富的API和易用性。 尽管HyperDex声称具有完整的ACID交易支持，但是此功能不是标准HyperDex发行版的一部分，并且似乎构成了商业产品。

关于何时使用的建议：当需要不同的数据模型预测（文档，键/值）时，作为专业数据存储的就地替代。

11.专门的数据存储

在本文的最后部分，我们将介绍一些NoSQL / NewSQL解决方案，它们不属于特定的明确定义的类或类别。 它们旨在响应和响应式设计原则的驱动下，解决现代Web应用程序所面临的特定用例。

重新思考数据库

RethinkDB是从头开始为实时Web构建的可伸缩，分布式，高可用性的NoSQL数据存储。 当应用程序从数据存储中轮询数据（和更改）时，它将颠覆传统的轮询体系结构。 相反，当将更新的查询结果实时连续地推送到应用程序时，它提供了推送架构。

为了与仅推送原始数据更改的数据存储区分开来， RethinkDB允许使用支持联接，子查询和大规模并行分布式计算的高级查询语言来订阅更改。 从CAP定理来看， RethinkDB是CP系统。

关于何时使用的建议（请参阅RethinkDB：​​用例 ）：

• 协作式Web和移动应用程序
• 流分析应用
• 多人游戏
• 实时市场
• 连接的设备

箱

箱子是一个分布式的NewSQL数据存储。 基于熟悉的SQL语法，它具有高可用性，弹性和可伸缩性，并允许实时查询大量数据。 它提供动态的集群大小调整，自动重新平衡/自动分片和复制，多索引查询，分布式聚合和排序，全文本搜索以及简单的集群管理。 尽管Crate的核心位于分布式查询分析器，计划程序和执行引擎中，但是其大量功能在很大程度上依赖于其他出色解决方案（ Apache Lucene和Elasticsearch）的内置功能。

Recommendations on when to use (see please Crate: Use Cases ):

• Aggregation Across Large Data Sets
• 数据分析
• 全文搜索
• Geospatial queries

12.结论

NoSQL / NewSQL revolution brought to the world a lot of new fresh ideas and huge variety of excellent non-relation data stores to satisfy the needs of modern software systems in managing massive volumes of data. Although with time NoSQL / NewSQL data stores mature and are gaining more and more popularity, the relational database management systems are not going anywhere, they are here to stay, adapting to new challenges. Despite their constraints and endless alternatives, these days MySQL or PostgreSQL are still often a primary choice, successfully managing enormous volumes of data never seen before.

The goal of this article is not to identify the winners and losers but introduce a lot more options available. Picking the right relational database management system or NoSQL / NewSQL data store may significantly speed up development process, helps to reduce time to market, and addresses short or long term scalability requirements. It is very common these days to have many heterogeneous data stores working side by side to serve different application workloads and data access patterns.

But, be warned: to get most out of your data store it is worth to invest time understanding its design, constraints, tradeoffs, limitations, and most importantly, data access and durability guarantee. Discovering corrupted data or even complete data loss in production because of bugs, edge cases or pure misunderstanding of the key guarantees of shiny new data store of your choice is not worth following the hottest industry trends. Always do a conscious choice by learning and experimenting, particularly paying attentions to different failure conditions and heavy workloads.

Do you have any other NoSQL or NewSQL systems you would like to suggest? Let us know in the comments!

Don't forget to Retweet this, share it with your social media followers!

#NoSQL vs. #SQL : Choosing a Data Management Solution https://t.co/lRJ9e1IDnn pic.twitter.com/3IcZd7kn3C

— Java Code Geeks (@javacodegeeks) October 28, 2015

翻译自: https://www.javacodegeeks.com/2015/10/nosql-vs-sql.html