快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

分布式SQL与NewSQL

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

我们在本系列的上一篇文章“什么是分布式SQL?”中 着重介绍了通用的体系结构原理以及分布式SQL数据库的商业利益。在本文中,我们将分布式SQL数据库与NewSQL数据库进行比较,以便我们更好地理解它们之间的差异。

在我们深入研究NewSQL之前,重要的是要理解为什么NoSQL数据库(例如MongoDB和Apache Cassandra)在2000年代中后期变得如此重要。它们最初也被定位为SQL数据库的替代品,但未达到其目标。当时的SQL数据库是单片的,NoSQL的分布式特性对于寻求可伸缩性和弹性的应用程序很有吸引力。

由于各种NoSQL语言都将重点放在单行(即键值)数据模型上,而放弃了SQL语言的关系/多行构造,因此这些数据库不再可以归类为“ SQL”数据库。因此,采用了“ NoSQL”这个名称。NoSQL最初被称为“不支持SQL”,但后来在用户意识到NoSQL数据库必须与SQL数据库并存而不是完全替换它们之后,演变为“不仅SQL”。

继续需要SQL数据库的主要原因是需要支持单行一致性以及多行ACID事务的关系数据建模。最终一致的NoSQL数据库遵循CAP定理的“可用”和“分区容忍”(AP)方面,因此在体系结构上不适合满足此类一致性优先需求。

您可能还会喜欢: Google Spanner:NewSQL之旅或NoSQL时代结束的开始。

考虑到NoSQL的上述局限性,即使在NoSQL出现之后,大规模的OLTP工作负载(数据的正确性和可伸缩性都很重要)仍继续受到损害。为解决此问题,NewSQL数据库于2010年初开始引入。451 Research的Matthew Aslett 于2011年创造了该术语,用于对这些新的“可扩展” SQL数据库进行分类。NewSQL数据库有两种不同的风格。

  1. 第一种方式只是在单片SQL数据库的多个独立实例之上提供了一个自动数据分片层。例如,Vitess在MySQL上下文中解决了这个问题,而Citus(又名PostgreSQL的Azure数据库– Hyperscale)对PostgreSQL也是一样。由于每个独立实例仍是相同的旧整体数据库,因此基本问题(例如,跨分片的本机故障转移/修复以及分布式ACID事务)仍然无法实现,或者在实际使用案例中表现不佳。最糟糕的是,开发人员失去了与单个逻辑SQL数据库进行交互所带来的敏捷性。
  2. 第二类包括NuoDB,VoltDB和Clustrix之类的东西,它们构建了新的分布式存储引擎,目的是保持单个逻辑SQL数据库概念的完整性。

使用分布式SQL标准评估NewSQL数据库

分布式SQL与NewSQL

维特斯

Vitess是MySQL的自动分片解决方案。每个MySQL实例都充当整个数据库的碎片。它使用etcd(一个单独的,高度一致的键值存储)来存储分片位置元数据,例如哪个分片位于哪个实例上。Vitess使用vtgate(一组特殊的协调器节点)来接受应用程序客户端查询,然后根据存储在etcd中的映射将它们路由到适当的分片。这些实例中的每一个都使用标准的MySQL主从复制来解决高可用性问题。

在Vitess中不建议使用访问分布在多个分片上的多行数据的SQL功能。此类功能的示例包括全局二级索引(需要分布式ACID事务)和交叉分片JOIN。请注意,甚至不支持真正的分布式ACID事务,因为无法为跨碎片事务提供隔离保证。这意味着在实践中,Vitess群集会丢失单个逻辑SQL数据库的概念。应用程序开发人员必须敏锐地意识到其分片机制,并在设计其架构以及执行查询时对此加以考虑。

希特斯

简单来说,Citus是PostgreSQL的Vitess。打包为  扩展对于整体式PostgreSQL数据库,Citus通过透明分片实质上为PostgreSQL部署增加了水平写入可扩展性。安装从例如PostgreSQL的n个节点开始,每个节点也具有Citus扩展名。此后,这n个节点中只有1个成为Citus协调器节点,其余n-1个节点成为Citus工作器节点。应用程序仅与协调器节点进行交互,并且不知道辅助节点的存在。用于确保发生故障时具有高可用性的复制体系结构仍然是主从结构(基于Postgres标准流复制)。单个协调器节点体系结构会带来明显的性能和可用性瓶颈。即使工作节点本身可能都正常运行,协调节点上的减速也会减慢整个群集的速度。协调器节点上的中断使整个群集不可用。工作程序节点无法直接与客户端应用程序交互的事实意味着,无法通过缓存当前分片元数据来使客户端驱动程序变得智能。

Citus在2019年被Microsoft收购,现在也可以作为PostgreSQL的Microsoft Azure数据库的Hyperscale选项提供。尽管这样的托管服务可以自动执行一些繁琐的复制配置任务,但它不能从根本上改变数据库的核心体系结构。

伏特数据库

VoltDB是具有专有SQL且不支持外键的自动分片式分布式数据库。集群内复制基于K安全算法,其中K表示为每个分片存储的数据的其他副本数。这意味着K = 2配置映射到分布式SQL数据库(例如Google Spanner和YugabyteDB)的默认“复制因子3”方法。

在VoltDB中,给定碎片的所有副本都由客户端应用程序同步更新。与Raft / Paxos支持的分布式SQL数据库相比,VoltDB在这方面要付出显着的性能损失。

像Raft和Paxos这样的分布式共识协议要求将写操作发送到所有副本,但是一旦大多数副本确认了该请求,便会提交。由于可以建立多数共识,因此不必等待所有副本都响应。此外,VoltDB默认情况下不检测网络分区,并且需要配置特殊的网络故障保护模式。

当群集的节点进行分区时,网络故障保护模式开始起作用。它增加了群集恢复时间,不仅会接受对副本丢失在节点分区中的分片的写入,而且还会在分区节点重新加入群集时重新填充分区节点上的数据,从而对群集性能产生负面影响。

在VoltDB体系结构中甚至不可能建立全球统一的多数据中心集群。最后,开放源代码版本不提供使用多主控体系结构的跨数据中心复制,因为它仅保留给专有商业版本。

o数据库

NuoDB是专有的NewSQL数据库,建立在包含多个移动部件(例如代理,事务引擎和存储管理器)的复杂体系结构上。它声称是一个弹性的,符合ANSI-SQL的数据库,完全不需要任何形式的分片或高度一致的复制。

这实质上意味着数据库集群的每个节点都存储所有数据,从而导致大量资源浪费。此外,必须在存储层(在没有共享的公共云中是不可能的)或在应用程序层(通过确保同一数据库的多个副本在多个主机上运行)来处理容错保证。

在我们今天生活的云原生时代,这些选择都不可行。另外,缺少可序列化的隔离意味着事务处理的ACID保证比现代分布式SQL数据库要弱得多。由于核心架构保持不变,因此自2013年以来对NuoDB 的Jepsen分析仍然有效。它表明,在出现故障的情况下,NuoDB容易丢失数据,还会遇到竞争状况并延长停机时间。

Clustrix数据库

Clustrix始于2006年,是建立横向扩展SQL数据库的最早尝试之一。不幸的是,它有一段曲折的历史,直到在2018年被MariaDB收购为止。第一个交付的产品是2010年的数据库硬件设备,只能部署在单个私有数据中心中。该设备使用了专门的硬件,无法在十几个部署中得到采用。

随着公共云和商品硬件的兴起,Clustrix在2013年转向了MySQL兼容的仅软件解决方案。但是,它仍然依赖于非常可靠的网络进行分片,复制和故障转移操作。这意味着在公共云时代的采用尤其落后于多区域和多区域部署。

摘要

NewSQL数据库最早是在2010年代初创建的,旨在解决与整体SQL数据库相关的写可伸缩性挑战。它们允许在SQL数据库的上下文中使用多个节点,而无需对复制体系结构进行任何重大改进。当时云还处于起步阶段,因此该策略已经运行了几年。

但是,随着多区域,多区域和多云的云部署成为现代应用程序的标准,这些数据库在开发人员采用方面已经落后。另一方面,分布式SQL数据库是完全建立起来的,以利用云的全部弹性,还可以在固有的不可靠基础架构上工作。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1922638