Update NoSQL数据库中的分布式算法.md

20171017 第15期/NoSQL数据库中的分布式算法.md

@@ -4,9 +4,7 @@
 
 可扩展性是NoSQL运动的主要驱动因素之一。因此，它包括分布式系统协调，故障转移，资源管理以及许多其他功能。这听起来像一把大伞，然而确实如此。 虽然很难说NoSQL运动是否将根本性的新技术引入分布式数据处理，但它引发了大量的实际研究，以及关于协议和算法不同组合的实际试验。已被证明具有实用效率的关系型数据库管理系统在这期间逐渐崭露头角。在本文中，我试图或多或少地系统性描述与NoSQL数据库中的分布式操作相关的技术。
 
-接下来，我们将研究许多分布式策略，例如故障检测中的复制，这可能在数据库中发生。下面以粗体突出显示的这些活动分为三个主要部分
-
-接下来，我们将研究许多分布式策略，例如故障检测中的复制，这可能在数据库中发生。下面以粗体突出显示的这些活动分为三个主要部分：
+- 接下来，我们将研究许多分布式策略，例如故障检测中的复制，这可能在数据库中发生。下面以粗体突出显示的这些活动分为三个主要部分：
 
 - 数据一致性。 从历史上看，NoSQL为了为地理位置分散的系统，低延迟或高可用性应用程序提供服务,其非常注重在一致性，容错性和性能之间进行权衡。 从根本上说，这些权衡都是围绕数据一致性进行，因此本节主要是关于 **数据复制** 和 **数据修复**。
 - 数据分布。 数据库应适应不同的数据分布，集群拓扑和硬件配置。 在本节中，我们将讨论如何 **分发数据或再平衡数据** 才能快速处理故障，提供持久性保证，查询高效以及系统资源（如内存和硬盘空间）在整个群集中均匀使用。
@@ -37,7 +35,7 @@
 
 让我们对一致性保证技术从弱到强一一介绍：
 
-- （A，anti-entropy(反熵)）最弱的一致性保证，其策略是：Writer选择任意的节点副本更新，如果新数据还没有通过后台的反熵协议传递（更多关于下一节中的反熵协议）到读的那个节点，Reader查看到的依然是旧数据。这种方法的主要特性是：
+- （A）anti-entropy(反熵),最弱的一致性保证，其策略是：Writer选择任意的节点副本更新，如果新数据还没有通过后台的反熵协议传递（更多关于下一节中的反熵协议）到读的那个节点，Reader查看到的依然是旧数据。这种方法的主要特性是：
   - 高传播延迟使其对数据同步非常不切实际，因此它通常仅用作辅助后台进程，用于检测和修复的计划外出现的不一致。但是，像Cassandra这样的数据库在传播有关数据库拓扑和其他元数据的信息时，使用反熵作为主要方式。
   - 一致性保证很差：即使没有故障，写冲突和读写差异也很可能出现。
   - 针对网络分区有出色的可用性和鲁棒性。此模式提供了良好的性能，因为单个更新由异步批处理替换。
@@ -46,8 +44,8 @@
   - 与纯反熵相比，这大大提高了一致性并且性能损失相对较小。 但是，相比强一致性和持久性保证保还有一定差距。
   - 如果由于网络故障或节点故障/替换而使得一些副本变得暂时不可用，则副本最终应通过反熵过程传递更新。
 - （C）在前面的模式中，使用提示移交技术（hinted handoff technique）可以更好地处理故障[8]。 针对不可用节点的更新将记录在读/写协调器或任何其他节点上，并提示一旦原节点可用，就应将其传递回去。 这改善了持久性保证和副本收敛时间。
-- （D，ReadOne-WriteOne）在延迟更新传播之前，提示移交（hinted handoff）的载体可能就会失效，因此必须通过所谓的读取修复来保障一致性。 每次读取（或随机选择的读取）都会触发异步进程，该异步进程向所有副本节点请求一份摘要（一种签名/哈希），并在检测到不一致性时，使之统一各个节点的数据摘要。 我们使用术语ReadOne-WriteOne来命名结合了A、B、C、D的技术，它们都不提供严格的一致性保证但足够有效，可以在实践中作为一种独立的方法使用。
-- （E，Read Quorum Write Quorum）上面的策略是可以减少副本的收敛时间的启发式增强功能（译者注：heuristic  enhancements,基于直观或经验构造的增强方法，如神经网络就是一种启发式的算法）。为了保障更强的一致性（甚至超越最终一致性），必须牺牲可用性来保证读写集之间的重叠。常见做法是同步写入W副本而不是一个，然后在读取过程中同时读取R个副本而不是一个。
+- （D）ReadOne-WriteOne,在延迟更新传播之前，提示移交（hinted handoff）的载体可能就会失效，因此必须通过所谓的读取修复来保障一致性。 每次读取（或随机选择的读取）都会触发异步进程，该异步进程向所有副本节点请求一份摘要（一种签名/哈希），并在检测到不一致性时，使之统一各个节点的数据摘要。 我们使用术语ReadOne-WriteOne来命名结合了A、B、C、D的技术，它们都不提供严格的一致性保证但足够有效，可以在实践中作为一种独立的方法使用。
+- （E）Read Quorum Write Quorum,上面的策略是可以减少副本的收敛时间的启发式增强功能（译者注：heuristic  enhancements,基于直观或经验构造的增强方法，如神经网络就是一种启发式的算法）。为了保障更强的一致性（甚至超越最终一致性），必须牺牲可用性来保证读写集之间的重叠。常见做法是同步写入W副本而不是一个，然后在读取过程中同时读取R个副本而不是一个。
   - 首先，通过配置W并保障其大于1来确定持久性。
   - 其次，由于R + W> N，同步写入的集合将与读取期间接触的集合重叠（在上图中W = 2，R = 3，N = 4），因此读者将至少读到一个新的副本并选择它作为结果。如果依次执行读写请求（例如，对单个用户的写完再读），则可以保证一致性，但不保证全局读后读取一致性。根据下图中的示例来理解为什么读取可能不一致，图中虽然R = 2，W = 2，N = 3（R + W >N），但写操作对两个副本的更新是非事务性的，因此客户端可以在写操作未完成时读取，可能读到一新一旧或两旧值：
 [![consistency-concurrent-quorum](https://highlyscalable.files.wordpress.com/2012/09/consistency-concurrent-quorum.png?w=805)](https://highlyscalable.files.wordpress.com/2012/09/consistency-concurrent-quorum.png)
@@ -56,11 +54,11 @@
   - 如果W <= N / 2，同时写入可以写到不相交的若干个节点（如，写操作A写前N/2个，B写后N/2个）。而设置W> N / 2则可确保使用回滚模型在原子级读改写时及时检测到冲突。
   - 严格来说，这种模式尽管它可以容忍单独节点的故障，但对网络分区容错性不好。 实际上，像sloppy quorum [8]这样的方法使用标准的Quorum机制通过牺牲一致性以提高在某些情况下的可用性。
 
-- （F，Read All Write Quorum）对于读一致性问题可以通过在读取期间联系所有副本（readers可以获取数据或检查摘要）得以减轻。在出现了新的版本数据时，它确保了马上就可以在至少一个节点上看到最新数据。但是在网络分区这种情况下，这种保证可能就不起作用了。
+- （F）Read All Write Quorum,对于读一致性问题可以通过在读取期间联系所有副本（readers可以获取数据或检查摘要）得以减轻。在出现了新的版本数据时，它确保了马上就可以在至少一个节点上看到最新数据。但是在网络分区这种情况下，这种保证可能就不起作用了。
 
-- （G，Master-Slave）上述的技术通常用于提供原子写入或冲突检测一致性的读改写的这类级别。要实现冲突预防级别，必须使用一种集中管理或用锁。最简单的策略是使用主从异步复制。所有需要写入的特定数据项都被路由到中央节点，然后在中心节点按顺序执行，但这会使得主节点成为瓶颈，因此必须将数据划分为独立的分片，从而实现可扩展性。
+- （G）Master-Slave,上述的技术通常用于提供原子写入或冲突检测一致性的读改写的这类级别。要实现冲突预防级别，必须使用一种集中管理或用锁。最简单的策略是使用主从异步复制。所有需要写入的特定数据项都被路由到中央节点，然后在中心节点按顺序执行，但这会使得主节点成为瓶颈，因此必须将数据划分为独立的分片，从而实现可扩展性。
 
-- （H，Transactional Read Quorum Write Quorum and Read One Write All）Quorum机制也可以通过事务控制技术来避免写冲突。众所周知的方法是使用两阶段提交协议。但两阶段提交并不完全可靠，因为协调器（coordinator）发生故障会导致资源阻塞。 PAXOS提交协议[20,21]是一种更可靠的替代方案，但会损失一点性能。在此基础上，我们最终得到了Read One Write All的方法，即把所有副本的更新放在一个事务中，这种方法提供了强容错一致性但会损失掉一些性能和可用性。
+- （H）Transactional Read Quorum Write Quorum and Read One Write All,Quorum机制也可以通过事务控制技术来避免写冲突。众所周知的方法是使用两阶段提交协议。但两阶段提交并不完全可靠，因为协调器（coordinator）发生故障会导致资源阻塞。 PAXOS提交协议[20,21]是一种更可靠的替代方案，但会损失一点性能。在此基础上，我们最终得到了Read One Write All的方法，即把所有副本的更新放在一个事务中，这种方法提供了强容错一致性但会损失掉一些性能和可用性。
 
 上面分析中的一些权衡有必要再强调一下：