分布式数据库系统101
还是分布式数据库-FK的“ 网络规模 ”实际上是什么意思？
分布式数据库系统是复杂的生物，具有多种不同的风格。如果我在大学里深入学习有关此方面的内容，我会很想念，我将尝试解释构建分布式数据库系统的一些关键工程问题。
首先，一些术语
ACID（原子性，一致性，隔离性和耐用性）属性：这些是必须强制执行的关键不变式，以便可靠地执行事务而不会引起不良副作用。
原子性要求事务完成或完全回滚。部分完成的交易永远都不可见，并且必须以防止这种情况发生的方式来构建系统。
一致性要求事务绝不能违反数据库架构所保证的任何不变式（例如声明性参照完整性）。例如，如果存在外键，则应该不可能插入与父代不相关的子记录。
隔离要求事务不应相互干扰。如果并行或顺序执行事务，则系统应保证相同的结果。实际上，大多数RDBMS产品都允许在权衡隔离与性能之间进行权衡的模式。
持久性要求一旦提交，事务就必须以对硬件或软件故障稳定的方式保留在持久性存储中。
我将在下面解释这些要求在分布式系统上存在的一些技术障碍。
共享磁盘体系结构：一种体系结构，群集中的所有处理节点都可以访问所有存储。这可能会成为数据访问的中心瓶颈。共享磁盘系统的一个示例是 Oracle RAC或 Exadata。
无共享架构：一种架构，其中集群中的处理节点具有本地存储，而其他集群节点看不到该本地存储。无共享系统的示例是 Teradata和 Netezza。
共享内存体系结构：多个CPU（或节点）可以访问共享内存池的体系结构。大多数现代服务器都是共享内存类型。共享内存有助于某些操作，例如缓存或原子同步原语，而这些操作在分布式系统上很难完成。
同步：通用术语，描述了确保多个进程或线程对共享资源进行一致访问的各种方法。尽管某些网络体系结构（例如Teradata的BYNET）在网络协议中具有同步原语，但在分布式系统上比在共享内存系统上做起来要困难得多。同步还可能带来大量开销。
半联接：用于联接分布式系统的两个不同节点中保存的数据的原语。本质上，它包含有关要联接的行的足够信息，这些信息被捆绑并由一个节点传递给另一节点，以解决联接。在大型查询中，这可能涉及大量的网络流量。
最终一致性：用于描述事务语义的术语，该事务权衡权衡分布式系统所有节点上的即时更新（读取一致性）以提高写入性能（并因此提高事务吞吐量）。最终一致性是使用仲裁复制作为性能优化来加快分布式数据库中事务提交的副作用，分布式数据库中多个数据副本保存在单独的节点上。
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和与主机的多路径连接），则价值将较小。
例如，尽管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（在存储和处理之间具有物理亲和力）（即，节点具有本地存储而不是共享的SAN）进行比较，您可能会争辩说BigTable / MapReduce是通过全局可见的并行存储系统共享的磁盘体系结构。
诸如Hadoop之类的MapReduce样式系统的处理吞吐量受到非阻塞网络交换机带宽的限制。1 但是，由于设计固有的并行性，无阻塞交换机可以处理大带宽集合，因此它们很少会对性能造成重大的实际限制。这意味着即使理论上网络交换机是一个中心瓶颈，共享磁盘体系结构（也许更好地称为共享存储系统）也可以扩展到较大的工作负载。
最初要指出的是，尽管共享磁盘系统中存在此中心瓶颈，但是具有多个存储节点（例如BigTable平板电脑服务器或SAN控制器）的分区存储子系统仍可以扩展到大型工作负载。无阻塞交换机体系结构（理论上）可以处理与端口一样多的当前连接。
1当然，可用的处理和I / O吞吐量也限制了性能，但是网络交换机是所有流量通过的中心点。