VS-NoSQL对比SQL:选择数据管理解决方案

1.介绍

作为软件开发人员,我们正处于激动人心的创新时代,特别是在数据存储和数据处理领域。所谓的NoSQL和后来的NewSQL动作已经大大改变了历史上由关系数据库管理系统主导的可用解决方案的格局。

这些新类型的数据存储诞生了,以满足现代分布式应用架构的需求,这需要前所未有的(当时)可扩展性和可用性保证。该垂直可扩展性达到这样的硬件或/和配套设施的成本变得不合理高的水平,从而切换到横向扩展,而不是是不可避免的。

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

本文的目的决不是为了确定获胜者,还是强调特定数据存储解决方案的优劣。为了提出更多可以帮助您构建复杂的分布式系统的选项,为未来的工作选择正确的工具并不存在通用的解决方案。

2.分布式系统:CAP定理

2000年,埃里克布鲁尔提出了现在被称为CAP定理的定理。它断言分布式系统不能同时提供以下所有三种理想特性:

  • 一致性:读取操作会查看以前完成的所有写入操作。在分布式系统的情况下,它意味着所有节点同时看到相同的数据。
  • 可用性:读取和写入操作总是成功。在分布式系统的情况下,它意味着每个请求都会收到有关它是成功还是失败的响应。
  • 分区容错:尽管由于网络故障导致的任意分区,系统仍然可以继续运行,从而阻止某些节点与其他节点进行通信。

我们不会详细讨论CAP定理,因为它值得自己的文章,而是强调它在分布式系统设计中的重要性。尽管这些年来引起了很多争论(最终导致2012年Eric Brewer的后续文章题为CAP十二年后),但大多数(如果不是所有的话)NoSQL / NewSQL解决方案都建立在CAP概述的权衡之上定理。

在本文中,我们将重点介绍每个数据存储如何解释CAP定理,只要它是合适的并且有相关详细信息。

3.关系数据存储

相当长的一段时间,关系数据库管理系统是数据存储解决方案的事实标准。不时有新手试图挑战(例如,对象数据库),但是他们中没有一个能够真正打乱市场。SQL(及其特定于供应商的方言)是查询关系数据存储的事实标准,对于任何软件开发人员来说,本质上都是一个必须知道的语言。

但几年前,随着数据量的增长呈指数级增长,触及关系数据库管理系统设计的限制,情况开始发生根本性的变化。

3.1。MySQL / MariaDB

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

然而,2009年MySQL的道路发生了翻天覆地的变化,当时Oracle公司签署了购买MySQL版权和商标所有人Sun Microsystems的协议。这次收购引发了人们对MySQL未来的担忧,因此,它被分解为我们今天所知的MariaDB。

为了解决现代分布式系统的可扩展性和可用性需求,MySQL和MariaDB分别提供了集群版本,MySQL Cluster和MariaDB Galera Cluster。参考CAP定理描述,单个MySQL集群或MariaDB Galera集群是一个CP系统。

为了完成MySQL,值得一提的是不少案例研究:

  • MySQL在推特上,另一个在Twitter 上看MySQL并孵化Mysos
  • Twitter如何使用MySQL每天存储2.5亿条推文
  • WebScaleSQL:建立在MySQL上游的协作,

3.2。PostgreSQL

PostgreSQL与MySQL一样广泛使用,实质上这些数据存储是最流行的开源关系数据库管理系统。除了与MySQL有许多相似之外,PostgreSQL传统上几乎没有提供更好的可扩展性和许多高级功能。

PostgreSQL目前缺乏的功能之一是支持即用型集群支持,尽管有几个选项可用。

3.3。其他

尽管我们将在本文中讨论开源解决方案,但值得一提的是由Oracle数据库,Microsoft SQL Server和IBM DB2领导的商业关系数据库管理系统领域的巨头。根据您愿意支付的价格,这些数据存储提供了相当不错的性能,可扩展性和可靠性特性,能够满足大多数分布式系统的要求。

4.为什么选择NoSQL?

我认为可以公平地说,NoSQL / NewSQL运动是紧迫需求的产物,它弥补了处理海量数据量的现代高扩展性,响应性和可用分布式系统的架构空白。在某种程度上,由关系数据库管理系统支持的“一刀切”方法成为系统满足功能要求的限制因素(甚至是阻碍因素)。

尽管NoSQL / NewSQL解决方案存在巨大差异,但它们有一些共同点:更简单的设计,对CAP定理权衡的理解以及对横向可伸缩性的支持。从本质上讲,它的价格很难或几乎不可能找到一个完全适合您的应用程序需求的通用NoSQL / NewSQL数据存储。选择取决于NoSQL / NewSQL数据存储必须解决的问题。这就是关系数据库管理系统和一个或多个NoSQL / NewSQL的结合原因 数据存储这些日子很常见。

在本文的其余部分中,我们将看看许多最流行的NoSQL / NewSQL解决方案,分为七个不同的类别:键/值数据存储,列式数据存储,图形数据存储,文档数据存储,时间序列数据存储,混合数据存储和专用数据存储。每个数据存储都至少有一本专用书,因此我们将关注关键设计决策和用例。

5.键/值数据存储

键/值数据存储设计用于将数据存储,查询和管理为关联数组(也称为字典或散列)。它们非常适合分布式(或复制)缓存解决方案,然而,这些数据存储中的很多不仅仅是简单的键/值操作。

5.1。DynamoDB

本文的目的是仅涵盖NoSQL / NewSQL空间中的开源解决方案,但DynamoDB将成为例外。其原因在于其基本原理(在Dynamo:亚马逊的高可用性关键值存储中描述)的巨大影响力,这是许多开源替代品的灵感来源。

Amazon DynamoDB是完全托管的NoSQL数据存储服务,可提供快速,可预测的性能和无缝可扩展性。尽管它被广泛称为关键/值数据存储,但它也能够以文档格式(JSON,XML和HTML)管理数据。参考CAP定理,DynamoDB是一个AP系统。

关于何时使用的建议:

  • 高容量特别活动
  • 社交媒体应用
  • 面向批处理
  • 报告
  • 实时分析

为了完成DynamoDB,值得一提的是不少案例研究:

  • 在生产环境中使用DynamoDB

5.2。Memcached

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

关于何时使用的建议:

  • 缓存层
  • 内存中会话存储

5.3。Redis

与Memcached一起,Redis是最广为人知和使用的关键/值数据存储之一。虽然把Redis看作是一个关键/价值存储是一个有效的假设,但Redis做得更多,它向开发人员提供了复杂数据结构的能力。引用http://redis.io:

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

对于分布式部署,Redis支持群集(也称为Redis群集)。有趣的是,从CAP定理的角度来看,Redis集群既不是CP也不是AP系统,而是沿着这些路线。

有关何时使用的建议(有关更多详细信息,请参阅如何利用Redis将其添加到堆栈中):

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

为了完成Redis,值得一提的是不少案例研究:

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

5.4。Riak KV

Riak KV是一个分布式,可扩展和容错的密钥/值数据存储。它支持高级本地和多群集复制,即使在发生硬件故障或网络分区时也能保证读取和写入。Riak KV的一个显着特点是复杂的查询支持,它建立在全文搜索,二级索引和map / reduce之上。从CAP定理的角度来看,Riak KV是支持可调一致性和可用性级别的AP系统。

有关何时使用的建议(更多详细信息,请参阅Riak:使用案例):

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

5.5。Aerospike

Aerospike是闪存优化的内存键/值数据存储器,用于关键任务应用,需要速度超快,成本效益高的缩放和无停机时间。Aerospike的集群体系结构旨在通过自动故障转移,复制,跨数据中心同步和线性可扩展性可靠地存储千兆字节的数据。就CAP定理而言,Aerospike基本上是一个AP系统,它另外还试图提供高一致性保证。

有关何时使用的建议(更多详细信息,请参阅Aerospike:使用案例):

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

为了完成Aerospike,值得一提的是一些有趣的资源:

  • 追求数据库规模
  • 在Aerospike规模的内存计算

5.6。FoundationDB

FoundationDB是NoSQL / NewSQL家族的成员,它将传统的关键/值数据存储的可扩展性与真正的多关键ACID事务相结合。用于访问存储数据的SQL层的存在使得FoundationDB与我们迄今为止所涉及的所有其他键/值数据存储区大不相同。不幸的是,FoundationDB曾经是一个开源项目,但据报道在2015年3月被苹果收购后,它突然停止提供下载并删除了它的公共库。

6.列式数据存储

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

该柱状数据存储有一个非常广泛的适用性,因此它是很难拿出建议的详细列表。但是,本节中讨论的每个数据存储都有一些独特的标准,因此对于某些情况很适合。

6.1。Accumulo

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

关于何时使用的建议:

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

6.2。Apache Cassandra

由于大部分数据存储都属于这一类,所以Apache Cassandra建立在Google BigTable(和Amazon的Dynamo)的基础上,并且在需要可扩展性和高可用性而不影响性能的情况下是正确的选择。它在商用硬件或云基础架构上提供线性可扩展性和经过验证的容错性,从而使其成为关键任务数据的完美平台。它完全分散,没有单点故障。

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

有关何时使用的建议(有关更多详细信息,请参阅Apache Cassandra:用例):

  • 写入繁重的工作量
  • 产品目录/播放列表
  • 推荐/个性化
  • 欺诈识别
  • 消息
  • 物联网/传感器数据
  • 实时分析
  • 还有很多,还有更多……

为了完成Apache Cassandra,值得一提的是不少案例研究:

  • Apache Cassandra生产中:我们学到的东西
  • 调整Cassandra @ Target
  • Cassandra数据建模最佳实践,第1 部分和第2部分

6.3。HBase

当你需要对大量数据进行随机,实时的读写访问时,Apache HBase是最好的选择。Google的BigTable受到了很大的启发,它建立在Hadoop分布式文件系统(HDFS)之上,就像Accumulo一样。线性可伸缩性,严格一致的读取和写入,自动和可配置的分片,自动故障转移,与Apache Hadoop的集成只是Apache HBase设计中最重要的特性的一个子集。到达CAP定理的基础上,Apache HBase是一个CP系统。

有关何时使用的建议(有关更多详细信息,请参阅Apache HBase:用例):

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

为了完成Apache HBase,值得一提的是不少案例研究:

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

7.图形数据存储

图数据存储系列基于图论,因此其数据模型是围绕节点(顶点),边和属性构建的,以表示和存储链接的数据。这种数据存储在解决类似图形的问题方面特别强大,例如找到两个节点之间的最短路径。

7.1。Neo4j

Neo4j是自2007年以来公开发布的开源NoSQL图形数据存储。Neo4j提供了全套可扩展和可靠的数据存储特性,包括ACID事务合规性,集群支持和运行时故障转移,使其适用于管理图形数据在实际生产情况下。Neo4j的商业产品还补充了具有高可用性,实时备份和全面监控的一系列功能。从CAP定理的角度来看,Neo4j是CA系统。

关于何时使用的建议(更多详情请参阅Neoj4:使用案例):

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

7.2。Titan

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

关于何时使用的建议:

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

为了完成泰坦,值得一提的是不少案例研究:

  • 用快速图形进行攻击分析

7.3。FlockDB

FlockDB是一个分布式的,容错的图形数据库,它来自Twitter。通过它的设计,FlockDB比其他图形数据库简单得多,因为它试图解决更少的问题。它横向扩展,专为实时,低延迟,高吞吐量环境而设计。FlockDB建立在MySQL存储层之上,利用另一个叫做Gizzard的 Twitter框架来支持分片和复制。可悲的是,似乎FlockDB的发展自2012年以来一直处于暂停状态。

为了完成FlockDB,值得一提的是不少案例研究:

  • 介绍FlockDB

7.4。GraphBase

GraphBase是商业化的分布式NoSQL图形数据存储,用于存储大量高度结构化的数据并管理大型图形。它声称提供微小的内存和存储空间,支持内置的遍历启发式和基于图形的事务。供应商没有很多细节可以用来作出可信假设,GraphBase就CAP定理而言。

有关何时使用的建议(更多详细信息,请参阅GraphBase:用例):

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

7.5。InfiniteGraph

InfiniteGraph是商业图形数据存储领域的另一个参与者,它是分布式和可扩展的图形数据库,专门用于遍历复杂关系,为实时业务决策提供基础。InfiniteGraph自然支持分区和分布,保持跨节点边界查询数据的能力。由于信息有限,很难根据CAP定理对InfiniteGraph进行分类,所以最好不要在这里进行猜测。

关于何时使用的建议:

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

8.文件数据存储

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

8.1。Couchbase

Couchbase将自己定位为用于交互式Web应用程序的NoSQL 文档数据存储。它支持灵活的数据模式(如大多数文档数据存储),易于扩展,并提供一致的高性能和高可用性。对于低延迟和高吞吐量是关键要求的Web应用程序,Couchbase是一个很好的选择。Couchbase提供的出色功能是原生移动就绪,可通过嵌入式数据库和自动同步技术构建离线支持的移动应用程序。按照CAP定理的权衡,Couchbase是一个AP系统。

关于何时使用的建议(更多详情请参阅Couchbase:使用案例):

  • 内容管理
  • 欺诈识别
  • 档案管理
  • 数字通信
  • 个性化
  • 产品数据管理
  • 实时分析

8.2。CouchDB

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

值得一提的是,CouchDB和Couchbase虽然是不同的产品,但它们有许多共同之处,有时会让选择哪一个更难。文章Couchbase与Apache CouchDB:两种开源NoSQL数据库技术的比较对这两种解决方案的历史以及它们之间的主要差异进行了公正的审视。

关于何时使用的建议:

  • 内容管理
  • 产品数据管理
  • 档案管理
  • 个性化

8.3。MongoDB

MongoDB是一个可水平扩展且高度可用的文档数据存储,用于管理和存储分组为集合的JSON风格文档。在许多其他的功能,它支持动态架构,先进的监控,复杂的查询,二级指标(包括全文检索的支持),复制,自动故障转移和分片。MongoDB的一个显着特点是易于入门和使用,通过推动更快的开发流程。从CAP定理的角度来看,MongoDB是CP系统。

有关何时使用的建议(有关更多详细信息,请参阅MongoDB:用例):

  • 操作智能
  • 产品数据管理
  • 库存管理
  • 内容管理
  • 记录数据
  • 报告

为了完成MongoDB,值得一提的是一些有趣的资源:

  • 大规模运行MongoDB应该了解的10件事
  • 我们如何扩展MongoDB

9.时间系列数据存储

时间序列数据存储(也称为TSDB)是NoSQL解决方案的一个特殊类别,它针对处理时间序列数据进行了高度优化:按时间排序的数据点数组。尽管通常可以使用其他类的NoSQL / NewSQL数据存储(例如文档数据存储或列数据存储)来管理时间序列数据,但由于问题的性质正在得到解决,因此在大多数情况下它不是一个适当的替换。

9.1。InfluxDB

InfluxDB是一个分布式时间序列,度量标准和分析数据存储。虽然在撰写本文时,集群,复制和高可用性的支持被认为是处于alpha状态,但InfluxDB提供了很多其他非常稳定的功能:

  • 强大的SQL式查询语言
  • 原生HTTP(S)API用于数据摄取和查询
  • 数据保留政策
  • 在飞行聚合

与其他时间序列数据存储相比,InfluxDB最显着的特点是缺少外部依赖性:只需下载,解压缩并运行即可。虽然InfluxDB被设计为高度可用且最终一致的数据存储,但从CAP定理的角度来看,它既不是CP也不是AP系统。

关于何时使用的建议:

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

为了完成InfluxDB,值得一提的是不少案例研究:

  • Go的实时指标:在生产环境中运行InfluxDB

9.2。OpenTSDB

OpenTSDB是一个可扩展的时间序列数据存储,从头设计用于存储和服务海量时间序列数据而不会损失粒度。OpenTSDB建立在Apache HBase之上(请参阅HBase以获取更多详细信息),因此它继承了其大部分特性:线性可伸缩性,自动复制,高效扫描和高写入吞吐量。

关于何时使用的建议:

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

9.3。Druid

Druid是一个分布式,可扩展,高性能,面向列的实时分析数据存储,专为交互式分析而构建。其中最重要的特性包括高可用性,低延迟数据采集,灵活的数据探索和快速数据聚合。在许多方面,Druid是OLAP数据存储,其重点更多地放在存储汇总数据(但目前不支持联接)。Druid的原生查询语言是JSON,并且Druid使用不同的存储来存储元数据和实际数据。

关于何时使用的建议:

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

为了完成,值得一提的是不少案例研究:

  • 构建一个实时处理数十亿事件的数据管道
  • 宣布Suro:Netflix数据管道的骨干

9.4。Prometheus

Prometheus是一款专为可靠性而设计的服务监控系统和时间序列数据存储。它非常适合收集任何纯数字时间序列,并且它支持多维数据收集和查询是一个特别的优势。也许,最重要的Prometheus功能是它不是一个严格分布式的系统:每个服务器都独立运行,只依靠其本地存储实现核心功能。

关于何时使用的建议:在SoundCloud进行监控

10.混合数据存储

有一组特定的解决方案属于我们目前看到的多个NoSQL / NewSQL数据存储类。这些可以被归类为混合数据存储,并且通常它们提供多种方式来存储和管理数据(例如,相同的NoSQL数据存储可以用作缓存的键/值数据存储和用作内容管理的文档数据存储) 。

从运营角度看,单个混合数据存储可以替代两个或更多专用数据存储,因此可以降低分布式系统部署,监视和维护的复杂性。同样,从使用情况来看,预期的混合数据存储可能非常适合,并且在被替换的数据存储方面同样适用。

有趣的是,从CAP定理的角度来看,在大多数情况下,混合数据存储会根据应用程序的利用方式进行不同的权衡。

10.1。ArangoDB

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

关于何时使用的建议:作为在需要不同数据模型预测(文档,图表,键/值)时对专用数据存储进行就地替换的建议。

10.2。OrientDB

OrientDB是一个可线性扩展的高性能操作NoSQL数据存储,集合了图形的强大功能和文档的灵活性。OrientDB的最强点是完全支持ACID事务,多主复制,分片和使用SQL(有一些扩展)来操纵树和图。存在HTTP REST API也值得一提。

关于何时使用的建议:当需要不同的数据模型预测(文档,图表)时,作为专门数据存储的就地替换。然而,OrientDB可以超越(OrientDB:Use Cases亮点)并可用于:

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

10.3。HyperDex

HyperDex是下一代分布式键值和文档NoSQL数据存储,从头到尾以可靠性,稳健性和性能为基础进行设计。它看重强大的一致性,容错性,可扩展性,丰富的API和易用性。虽然HyperDex声称拥有完整的ACID事务支持,但此功能不是标准HyperDex分配的一部分,似乎构成了商业产品。

关于何时使用的建议:当需要不同的数据模型预测(文档,键/值)时,作为专门数据存储的就地替换。

11.专门的数据存储

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

11.1。RethinkDB

RethinkDB是一个可扩展的,分布式的,高度可用的NoSQL数据存储库,专为实时Web构建。当数据(和更改)由数据存储的应用程序轮询时,它反转了传统的轮询体系结构。相反,当更新的查询结果不断推送到应用程序时,它提供了一种推送体系结构。

为了区别于刚推入原始数据更改的数据存储区,RethinkDB允许使用支持连接,子查询和大规模并行分布式计算的高级查询语言订阅更改。从CAP定理的角度来看,RethinkDB是CP系统。

有关何时使用的建议(请参阅RethinkDB:​​用例):

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

11.2。Crate

Crate是一个分布式的NewSQL数据存储。基于熟悉的SQL语法,它具有高可用性,弹性和可伸缩性,并允许实时查询大量数据。它提供动态群集调整大小,自动重新平衡/自动分片和复制,多索引查询,分布式聚合和排序,全文搜索以及简单的群集管理。虽然Crate的核心是分布式查询分析器,规划器和执行引擎,但其大量功能主要依赖于其他优秀解决方案(Apache Lucene和Elasticsearch)的内置功能。

有关何时使用的建议(请参阅Crate:Use Cases):

  • 跨大型数据集的聚合
  • 数据分析
  • 全文搜索
  • 地理空间查询

12.结论

NoSQL / NewSQL革命为世界带来了许多全新的创意和各种优秀的非关系数据存储,以满足现代软件系统管理海量数据的需求。尽管随着NoSQL / NewSQL数据存储时间的日渐成熟并且越来越受欢迎,关系数据库管理系统并没有随处可见,他们仍然在这里待命,以适应新的挑战。尽管他们受到限制和无尽的选择,但现在MySQL或PostgreSQL仍然是首选,成功地管理了以前从未见过的大量数据。

本文的目标不是确定赢家和输家,而是介绍更多可用选项。选择正确的关系数据库管理系统或NoSQL / NewSQL数据存储可能显着加速开发过程,有助于缩短上市时间并解决短期或长期可扩展性要求。现在有许多异构数据存储并行工作以服务于不同的应用程序工作负载和数据访问模式是非常普遍的。

但是,需要注意的是:为了充分利用数据存储,有必要花时间了解其设计,约束,折衷,限制以及最重要的数据访问和持久性保证。发现由于错误,边缘情况或纯粹误解您所选择的闪亮新数据存储的关键保证而导致数据损坏或甚至数据完全丢失的现象不值得遵循最热门的行业趋势。始终通过学习和实验做出有意识的选择,特别是关注不同的失败情况和繁重的工作量。

你有没有其他的NoSQL或NewSQL系统你想建议?让我们在评论中知道!

原创于 【模棱博客】