为什么RDBM的集群不能像NoSQL那样？

#1 楼

分布式数据库系统101

或者，分布式数据库-FK的“网络规模”实际上是什么意思？

分布式数据库系统是复杂的生物，具有许多不同的风味。如果我在大学里深入研究那些对此记忆模糊的研究，我将尝试解释构建分布式数据库系统的一些关键工程问题。

首先，一些术语

ACID（原子性，一致性，隔离性和持久性）属性：这些是为可靠地执行事务而不会造成不良副作用所必须执行的关键不变式。

原子性要求事务完成或完全回滚。部分完成的事务永远都不可见，并且必须以防止这种情况发生的方式构建系统。

一致性要求事务绝不应该违反任何不变式（例如声明性参照完整性）由数据库模式保证。例如，如果存在一个外键，则不可能插入一个与不存在的父级相关的子级记录。

隔离要求事务不能相互干扰。如果并行或顺序执行事务，则系统应保证相同的结果。实际上，大多数RDBMS产品都允许在权衡隔离与性能之间进行选择的方式。

耐久性要求一旦提交，事务就以对硬件或软件故障稳定的方式保留在持久性存储中。

我将在下面解释分布式系统上存在的这些要求的一些技术障碍。

共享磁盘体系结构：一种体系结构，群集中的所有处理节点都可以访问所有存储。这可能会成为数据访问的中心瓶颈。共享磁盘系统的一个示例是Oracle RAC或Exadata。

无共享架构：一种架构，群集中的处理节点具有本地存储，其他群集节点不可见。无共享系统的示例包括Teradata和Netezza。

共享内存体系结构：一种架构，其中多个CPU（或节点）可以访问共享的内存池。大多数现代服务器都是共享内存类型。共享内存可促进某些操作，例如缓存或原子同步原语，这些操作在分布式系统上很难完成。

同步：一种通用术语，用于描述确保多个进程或多个进程一致访问共享资源的各种方法。线程。尽管某些网络体系结构（例如Teradata的BYNET）在网络协议中具有同步原语，但这在分布式系统上比在共享内存系统上要难得多。同步也可能会带来大量开销。

半联接：用于联接分布式系统的两个不同节点中保存的数据的原语。本质上，它包含有关要联接的行的足够信息，这些信息被捆绑并由一个节点传递给另一节点，以解决联接。在大型查询中，这可能会涉及大量网络流量。

最终一致性：用于描述事务语义的术语，该事务语义权衡了分布式系统所有节点上的即时更新（读取一致性）以提高性能（以及因此更高的事务吞吐量）。最终的一致性是使用Quorum Replication作为性能优化来加快分布式数据库中事务提交的副作用，该分布式数据库中多个数据副本保存在单独的节点上。

Lamport算法：一种用于在没有共享内存的系统之间实现互斥（同步）的算法。通常，系统内的互斥需要原子型的read-compare-write或类似的指令，这种指令通常仅在共享内存系统上才适用。还存在其他分布式同步算法，但是兰莫特算法是最早的算法之一，也是最著名的算法。与大多数分布式同步机制一样，Lamport的算法在很大程度上依赖于群集节点之间的准确时序和时钟同步。

两阶段提交（2PC）：这是一种协议家族，可确保提交涉及多个物理系统的数据库更新或始终回滚。无论是在系统中使用2PC还是通过事务管理器在多个系统中使用2PC，它都会产生大量开销。

在两阶段提交协议中，事务管理器要求参与节点将事务持久化到这样的环境中。他们可以保证提交的方式，然后发出此状态信号。当所有节点都返回“快乐”状态时，它会向节点发出信号以提交。直到所有节点都发送指示提交已完成的答复，该事务仍被视为已打开。如果节点在发出提交完成信号之前已关闭，则事务管理器将在备份后重新查询该节点，直到获得肯定的答复以表明该事务已提交。

多版本并发控制（MVCC）：通过将数据的新版本写入不同的位置并允许其他事务查看数据的旧版本，直到提交新版本，来管理争用。这样可以减少数据库争用，但要付出一些额外的写流量，以写入新版本，然后将旧版本标记为过时。

选择算法：涉及多个节点的分布式系统本质上不如单个系统可靠，因为存在更多的故障模式。在许多情况下，集群系统需要某种机制来处理节点的故障。选举算法是一类算法，用于在“领导者”节点不是100％确定或不可靠的情况下选择领导者来协调分布式计算。

水平分区：可以将表拆分为多个多个节点或存储卷通过其键。这样就可以将大数据量分割成较小的块，并分布在存储节点之间。

共享：在无共享架构中，数据集可以在多个物理节点之间进行水平分区。如果该分区不是透明的（即，客户端必须知道分区方案并确定要显式查询的节点），则称为分片。某些系统（例如Teradata）确实在节点之间拆分数据，但是位置对客户端是透明的；该术语通常不与此类系统结合使用。

一致性哈希：一种用于根据密钥将数据分配给分区的算法。它的特点是哈希键分布均匀，并且能够有效地弹性扩展或减少存储桶的数量。这些属性使它可用于在节点群集上进行数据分区或加载，其中大小可以随着添加或删除群集的节点而动态变化（可能由于故障）。

多主复制：一种技术，允许跨群集中多个节点的写操作复制到其他节点。该技术通过允许某些表在服务器之间进行分区或分片，而另一些表在整个集群之间进行同步，则有助于扩展。必须将写入复制到所有节点（而不是仲裁），因此在多主机复制体系结构上的事务提交比在仲裁复制系统上的事务提交更为昂贵。

非阻塞交换机：一种网络交换机使用内部硬件并行性来实现与没有内部瓶颈的端口数量成比例的吞吐量。天真的实现可以使用交叉开关机制，但这对于N个端口具有O（N ^ 2）复杂度，将其限制为较小的交换机。较大的交换机可以使用更复杂的内部拓扑结构（称为无阻塞最小跨度交换机）来实现线性吞吐量扩展，而无需O（N ^ 2）硬件。

制造分布式DBMS-这有多难？

多项技术挑战使得在实践中很难做到这一点。除了构建分布式系统的复杂性外，分布式DBMS的架构师还必须克服一些棘手的工程问题。

分布式系统上的原子性：如果事务更新的数据分布在多个节点上，必须协调节点的提交/回滚。这会在无共享系统上增加大量开销。在共享磁盘系统上，这不是问题，因为所有存储都可以被所有节点看到，因此单个节点可以协调提交。

分布式系统上的一致性：以上面引用的外键示例为例，系统必须能够评估一致状态。例如，如果外键关系的父级和子级可以驻留在不同的节点上，则需要某种分布式锁定机制以确保不使用过时的信息来验证交易。如果不强制执行此操作，则可能会出现（例如）竞争条件，即在允许父项存在之前，先验证父项的存在，然后再允许其插入子项，然后将其删除。

延迟执行约束（即等待直到提交以验证DRI）要求在事务期间保持该锁。这种分布式锁定会带来大量开销。

如果保存了多个数据副本（在无共享系统上可能有此必要，以避免来自半联接的不必要网络流量），则所有的副本分布式系统上的隔离：在事务上受影响的数据驻留在多个系统节点上的情况下，锁和版本（如果正在使用MVCC）必须在节点之间同步。要保证操作的可串行性，尤其是在可能存储数据冗余副本的无共享体系结构上，需要分布式同步机制（例如Lamport算法），这也会带来很大的网络流量开销。

分布式系统上的持久性：在共享磁盘系统上，持久性问题与共享内存系统基本相同，但跨节点仍然需要分布式同步协议。 DBMS必须将日志写入日志并一致地将数据写出。在无共享系统上，可能有多个数据副本或部分存储在不同节点上的数据。需要两阶段提交协议以确保跨节点正确进行提交。这也将导致相当大的开销。

在无共享系统上，节点丢失可能意味着系统无法使用数据。为了减轻这种影响，可以在一个以上的节点上复制数据。这种情况下的一致性意味着必须将数据复制到通常驻留的所有节点。这会产生大量的写开销。

NoSQL系统中的一项常见优化是使用仲裁复制和最终一致性，以允许延迟复制数据，同时通过在报告报告之前写入仲裁来确保数据具有一定程度的弹性。交易已提交。然后将数据懒散地复制到数据副本所在的其他节点。

请注意，“最终一致性”是一致性的主要折衷方案，如果必须查看数据，则可能无法接受交易一经提交就保持一致。例如，在金融应用程序上，更新的余额应立即可用。

共享磁盘系统

共享磁盘系统是所有节点都可以访问的系统所有的存储空间。因此，计算与位置无关。许多DBMS平台也可以在此模式下工作-Oracle RAC是这种体系结构的一个示例。

共享磁盘系统可以扩展，因为它们可以支持存储节点和处理节点之间的M：M关系。一个SAN可以有多个控制器，并且多个服务器可以运行数据库。这些体系结构以交换机为中心瓶颈，但是交叉开关使该交换机具有很大的带宽。可以将一些处理工作转移到存储节点上（例如在Oracle Exadata中），这可以减少存储带宽上的流量。

尽管从理论上讲该交换机是瓶颈，但是可用带宽意味着共享-磁盘体系结构将非常有效地扩展到大事务量。大多数主流DBMS体系结构都采用这种方法，因为它提供了“足够好”的可伸缩性和高可靠性。使用冗余存储体系结构（例如光纤通道）时，不会出现单点故障，因为在任何处理节点和任何存储节点之间至少存在两条路径。

无共享系统

“无共享系统”是指其中至少一些数据保存在本地节点上，而其他节点无法直接看到的系统。这消除了中央交换机的瓶颈，从而使数据库（至少在理论上）可以根据节点数进行扩展。水平分区允许在节点之间拆分数据；这可能对客户端透明或不透明（请参阅上面的分片）。

由于数据是固有分布的，因此查询可能需要来自多个节点的数据。如果联接需要来自不同节点的数据，则使用半联接操作来传输足够的数据以支持从一个节点到另一个节点的联接。这会导致大量的网络流量，因此优化数据的分布会对查询性能产生很大的影响。

通常，数据跨无共享系统的节点之间复制，以减少半联接的必要性。这在数据仓库设备上效果很好，因为其维度通常比事实表小许多个数量级，并且可以轻松地在节点之间复制。它们通常还分批加载，因此复制开销比事务性应用程序要少。

无共享架构的固有并行性使其非常适合数据仓库特有的表扫描/聚合查询。这种操作几乎可以随处理节点的数量线性地扩展。由于半联接操作会产生大量网络流量，因此跨节点进行大联接往往会产生更多开销。

移动大数据量对于事务处理应用程序不太有用，因为多次更新的开销使得这这种类型的体系结构没有共享磁盘那么吸引人。因此，这种类型的体系结构往往不会在数据仓库应用程序中广泛使用。

共享，仲裁复制和最终一致性

仲裁复制是DBMS复制的工具数据以实现高可用性。这对于打算在没有内置高可用性功能（如SAN）的便宜商品硬件上运行的系统很有用。在这种类型的系统中，数据跨多个存储节点进行复制，以提高读取性能和冗余存储，从而使系统能够应对节点的硬件故障。

但是，对于M个节点和N次写入，对所有节点的写入复制为O（M x N）。如果必须在允许事务提交之前将写操作复制到所有节点，则写操作将变得昂贵。仲裁复制是一种折衷方案，它允许将写入立即复制到节点的一个子集，然后通过后台任务将其延迟写入其他节点。通过在将事务报告为已提交给客户端之前确保将其复制到最小的节点子集（仲裁），可以更快地落实写入，同时提供一定程度的冗余。

这意味着读取仲裁外的节点的数据可以看到过时的数据版本，直到后台进程完成将数据写入其余节点为止。语义被称为“最终一致性”，根据您的应用程序的要求可能会接受，也可能不会接受，但意味着在资源使用方面，事务提交比O（n）更接近O（1）。

共享要求客户端通常使用一种称为“一致性哈希”的算法来了解数据库中数据的分区。在分片数据库中，客户端通过散列键来确定要向集群中的哪个服务器发出查询。由于请求是在群集中的各个节点之间分布的，因此没有一个查询协调器节点的瓶颈。

这些技术允许通过向群集中添加节点来以接近线性的速率扩展数据库。从理论上讲，仅当底层存储介质被认为不可靠时才需要法定复制。如果要使用商用服务器，这将很有用，但是如果基础存储机制具有其自己的高可用性方案（例如，具有镜像控制器的SAN和与主机的多路径连接的SAN），则价值将较小。

例如，尽管Google的BigTable确实位于GFS（确实使用仲裁复制的群集文件系统）上，但它本身并没有实现仲裁复制。 BigTable（或任何无共享系统）可以使用具有多个控制器的可靠存储系统，并在各个控制器之间划分数据。然后，可以通过对数据进行分区来实现并行访问。

返回RDBMS平台

没有内在的原因这些技术不能与RDBMS一起使用。但是，在这样的系统上，锁定和版本管理会非常复杂，并且此类系统的任何市场都可能非常专业。没有一个主流的RDBMS平台使用仲裁复制，而且我还没有特别意识到可以使用仲裁复制的任何RDBMS产品（至少没有一个具有重要意义的产品）。

共享磁盘和无共享系统可以扩展到非常大的工作量。例如，Oracle RAC可以支持63个处理节点（本身可以是大型SMP计算机）和SAN上任意数量的存储控制器。 IBM Sysplex（zSeries大型机的集群）可以支持多个大型机（每个大型机具有自己的强大处理能力和I / O带宽）和多个SAN控制器。尽管它们确实假定了可靠的存储，但是它们可以使用ACID语义支持非常大的事务量。 Teradata，Netezza和其他供应商建立了基于无共享设计的高性能分析平台，这些设计可扩展到极大的数据量。

到目前为止，廉价但超高容量的全ACID RDBMS平台市场被MySQL支配，它支持分片和多主复制。 MySQL不使用仲裁复制来优化写入吞吐量，因此事务提交比NoSQL系统上的开销更大。分片允许很高的读取吞吐量（例如，Facebook广泛使用MySQL），因此，这种类型的体系结构可在读取大量工作负载上很好地扩展。

有趣的辩论

BigTable是一个下文的Michael Hausenblas指出的无共享架构（本质上是分布式键值对）。我最初对它的评估包括MapReduce引擎，它不是BigTable的一部分，但通常会在其最常见的实现中（例如Hadoop / HBase和Google的MapReduce框架）与它结合使用。

将此架构与Teradata进行比较，Teradata在存储和处理之间具有物理亲和力（即，节点具有本地存储，而不是共享的SAN），您可能会认为BigTable / MapReduce是通过全局可见的并行存储系统共享的磁盘体系结构。 >
诸如Hadoop之类的MapReduce样式系统的处理吞吐量受到非阻塞网络交换机带宽的限制。1非阻塞交换机由于设计中固有的并行性而可以处理大带宽集合，因此它们很少会对性能造成重大的实际限制。这意味着即使理论上网络交换机是一个中心瓶颈，共享磁盘体系结构（也许更好地称为共享存储系统）也可以扩展到大型工作负载。

最初要指出的是，尽管共享磁盘系统中存在此中心瓶颈，但具有多个存储节点（例如BigTable平板电脑服务器或SAN控制器）的分区存储子系统仍可以扩展到大型工作负载。无阻塞交换机体系结构（理论上）可以处理与端口一样多的当前连接。

1当然，可用的处理和I / O吞吐量也限制了性能，但是网络交换机是所有流量通过的中心点。

#2 楼

关系数据库可以像NoSQL解决方案一样集群。维护ACID属性可能会使情况变得更加复杂，因此必须意识到为维护这些属性而进行的权衡。不幸的是，确切的权衡取决于工作量，当然还取决于设计数据库软件时所做出的决定。

例如，即使集群的吞吐量很好地扩展，主要是OLTP的工作负载也可能具有额外的单个查询延迟。额外的延迟可能不会引起注意，或者成为真正的交易破坏者，这一切都取决于应用程序。总的来说，群集将提高吞吐量并缩短延迟时间，但是如果应用程序的查询特别适合并行处理，即使是“规则”也值得怀疑。

我为Clustrix工作的公司提供的服务是通过相对高速的网络连接的一系列同类计算和存储节点。关系数据是散列式分布在每个索引上的节点上的散列，我们称之为“切片”。每个切片将有两个或多个副本散布在整个群集中，以在节点或磁盘发生故障时保持持久性。客户端可以使用MySQL Wire协议连接到集群中的任何节点以发出查询。

独立地考虑ACID数据库的组成部分有点不自然，因为它的很多部分是紧密结合在一起的，但这里有：

原子性-Clustrix使用两个阶段提交来确保原子性。 UPDATE和DELETE操作还将通过我们的分布式锁管理器锁定行，因为我们在内部将这些操作转换为SELECT，然后再执行精确的UPDATE / DELETE操作。

原子性显然会增加参与事务的节点之间的消息传递量，并增加那些节点上处理提交协议的负载。这是具有分布式系统的开销的一部分，如果每个节点都参与每个事务，则将限制可伸缩性，但是如果节点具有要写入的副本之一，则它们仅参与事务。

一致性-外键被实现为触发器，在提交时进行评估。大范围的UPDATE和DELETE操作会由于锁定而影响我们的性能，但幸运的是，我们很少经常看到这些内容。看到事务更新/删除几行然后提交，这种情况要普遍得多。

一致性的另一部分是通过PAXOS共识协议维护仲裁，该协议可确保只有大多数集群具有已知节点能够进行写操作。群集当然有可能达到法定人数，但仍然缺少数据（切片的所有副本都脱机），这将导致访问其中一个切片的事务失败。

隔离-Clustrix提供MVCC容器级别的隔离。我们的原子性保证了在报告已提交的事务之前，所有适用的副本都将收到特定的写入操作，这主要将隔离问题减少到非群集情况下的隔离问题。存储在两个或多个节点上以在节点或磁盘发生故障时提供弹性。在这里可能还值得注意的是，出于性能原因，我们产品的设备版本具有NVAL卡，其中存储了WAL。许多单实例数据库将通过间隔检查点而不是每次提交来提高其WAL的性能。这种方法在分布式系统中是有问题的，因为它使得“重放到哪里？”一个复杂的问题。我们通过提供坚硬的耐用性保证来避免在产品中使用此功能。

#3 楼

基本答案是一致性模型是不同的。我写这篇文章是为了扩展ConcernedOfTunbridge的答案，而这实际上应该是它的参考点。

ACID一致性模型的基本要点是，它对状态的变化做出了一系列基本保证。系统内的全局数据。这些保证受CAP定理的限制，这基本上意味着要使它们起作用，您需要在告诉应用程序您已提交事务之前在同一页面上拥有所有权威来源。因此，如果不遇到这些限制，很难进行多原版复制。当然，一旦您开始在多主机环境中进行异步复制，这些保证就无从谈起了。 ACID一致性模型是用于重要或关键信息的强一致性模型。

BASE一致性模型是用于非关键信息的弱一致性模型。由于担保明显较弱，因此，由于担保非常弱，因此在多主系统中提供此类弱担保的能力更容易实现。

RDBMS的规模和能力以及NoSQL解决方案但是，

在某些情况下，RDBMS可以并且确实可以扩展到NoSQL甚至无法匹配的程度。只是做的不同。我将以Postgres-XC为例，说明如何在不牺牲强大一致性保证的情况下进行横向扩展。

这些特定RDBMS的工作方式是使用以下方法实现某种分片解决方案：代理，有点像共享磁盘体系结构，但是比任何一种都复杂得多。它们的扩展方式与NoSQL解决方案不同，因此权衡是不同的。

据我了解，Postgres-XC模型是受Teradata启发的。它由具有两种不同角色的节点组成，分别是存储节点或协调器。协调器是多主服务器（不涉及任何实际复制），它们连接到存储节点以处理实际的数据处理。存储节点以主从设置复制。每个存储节点本质上都包含数据库的分片，但是协调者维护数据的一致图片。

这里涉及重大的职责分离。存储节点管理数据，检查约束，本地可执行的外键约束并至少处理一些数据聚合。协调器处理无法在本地强制执行的那些外键，以及可能从多个数据节点提取的窗口和其他数据注意事项。从本质上讲，协调器使ACID在多主设置中的分布式事务中成为可能，用户甚至不知道事务是分布式的。

在这方面，Postgres-XC提供了类似于NoSQL的功能。缩放选项，但是由于额外的一致性保证，因此增加了一些复杂性。我知道有商业的RDBMS可以提供​​这种可伸缩性。 Teradata会这样做。另外，共享磁盘系统可以以类似的方式扩展，并且DB2和Oracle都提供了这样的解决方案。因此，说RDBMS无法做到这一点是完全不公平的。他们能。但是，过去的需求如此之小，以至于规模经济不足以使大多数参与者都可以负担得起专有解决方案。

最后是有关VoltDB的说明。像NoSQL解决方案一样，我将VoltDB视为非常专业的工具。它的速度非常快，但要以多次往返事务和磁盘的持久性为代价。这意味着您有完全不同的关注点。当RDBMS先锋构建NoSQL解决方案时，您将获得VoltDB ;-)。 VoltDB之所以快速，部分原因是它从等式中定义了并发性和持久性。持久性成为网络属性，而不是主机内部属性，并发性是通过一次运行一个查询来管理的，并以内部顺序并行地内部并行化。它不是传统的RDBMS（这是一件好事，因为它可以代替传统的RDBMS，但是相反也很正确）。

编辑：考虑这一点也很重要连接的含义。在集群系统中，联接成为一个非常不同的性能问题。如果所有内容都在同一节点上，则它们可以提高性能，但是如果您必须往返于其他节点，这将带来很高的成本。因此，数据模型的确会产生差异，并且群集方法会对性能产生影响。诸如Postgres-XC和Postgres-XL之类的方法假定您可以花大量时间思考问题，以便可以适当地分拆数据并将合并的数据保持在一起。但这增加了设计开销。另一方面，它的伸缩性比许多NoSQL解决方案好得多，并且可以适当调整。例如，我们（在Adjust处）对PostgreSQL中的3.5PB数据使用类似于NoSQL的群集策略，这基本上是日志分析。而且我们的许多设计都受到NoSQL群集策略的深刻启发。因此有时数据模型也确实会约束聚类模型。

#4 楼

我的答案不会像上一个那样写得很好，但是请按以下步骤进行。无新的SQL数据库（VoltDB），它在群集中的不同节点之间分配数据并维护ACID。此后，Vertica被HP收购。

我相信其他新的SQL数据库也可以维护ACID，尽管我不确定它们中有多少在整个群集中分配行等。

这里是Stonebraker发表有关NoSQL和“ Old SQL”的新SQL的演讲。 http://www.youtube.com/watch?v=uhDM4fcI2aI

#5 楼

MySQL集群可以在集群中使用多重母带复制和哈希分片进行分片。