43 KiB
6. 分片
我们必须跳出电脑指令序列的窠臼。 叙述定义、描述元数据、梳理关系，而不是编写过程。
—— Grace Murray Hopper，未来的计算机及其管理（1962）
[TOC]
在第5章中，我们讨论了复制 - 即在不同节点上有相同数据的多个副本。对于非常大的数据集，或非常高的查询吞吐量是不够的：我们需要将数据拆分成分区（partitions），也称为分片（sharding）1
术语澄清
这里称之为分区（partition）的东西，在MongoDB，Elasticsearch和Solr Cloud中被称为分片（shard）；在HBase中称之为区域（Region），Bigtable中的 表块（tablet），Cassandra和Riak中虚节点（vnode）以及Couchbase中的虚桶（vBucket）。但是**分区（partition）**是最重要的术语，所以这里坚持使用它。
通常情况下，分区是这样定义的，即每条数据（每条记录，每行或每个文档）属于且仅属于一个分区。有很多方法可以实现这一点，本章将深入讨论。实际上，每个分区都是自己的小型数据库，尽管数据库可能支持同时触及多个分区的操作。
需要分区数据的主要原因是可扩展性。不同的分区可以放在不共享的集群中的不同节点上（参阅第二部分关于无共享架构的定义）。因此，大数据集可以分布在多个磁盘上，并且查询负载可以分布在多个处理器上。
对于在单个分区上运行的查询，每个节点可以独立执行对其自己的分区的查询，因此可以通过添加更多的节点来缩放查询吞吐量。大型，复杂的查询可能会跨越多个节点进行并行处理，尽管这会变得非常困难。
分区数据库在20世纪80年代由Teradata和NonStop SQL【1】等产品率先推出，最近又被NoSQL数据库和基于Hadoop的数据仓库重新发明。有些系统是为事务性工作负载设计的，其他系统则用于分析（参阅“事务处理或分析？”）：这种差异会影响系统的调整方式，但是分区的基本原理适用于这两种工作负载。
在本章中，我们将首先介绍分割大型数据集的不同方法，并观察索引如何与分区配合。然后，我们将讨论再平衡，如果想要添加或删除群集中的节点，则必须进行再平衡。最后，我们将概述数据库如何将请求路由到正确的分区并执行查询。
分片与复制
分区通常与复制结合使用，以便每个分区的副本都存储在多个节点上。 这意味着，即使每条记录属于一个分区，它仍然可以存储在多个不同的节点上以获得容错能力。
一个节点可能存储多个分区。 如果使用主从复制模型，则分区和复制的组合如图6-1所示。 每个分区的主被分配给一个节点，从被分配给其他节点。 每个节点可能是某些分区的领导者，同时是其他分区的追随者。 我们在第5章讨论的关于数据库复制的所有内容同样适用于分区的复制。 大多数情况下，分区方案的选择与复制方案的选择是独立的，为简单起见，本章中将忽略复制复制。
图6-1 组合使用复制和分区：每个节点充当某些分区的领导者，其他分区充当追随者。
键值数据的分片
假设你有很多的数据，想要分片？那么，如何决定在哪些节点上存储哪些记录呢？
分区目标是将数据和查询负载均匀分布在各个节点上。如果每个节点公平分享数据和负载，那么理论上10个节点应该能够处理10倍的数据量和10倍的单个节点的读写吞吐量（目前忽略复制）。
如果分区是不公平的，那么一些分区比其他分区有更多的数据或查询，我们称之为偏斜（skew）。数据倾斜的存在使分区效率下降很多。在极端的情况下，所有的负载都可能在一个分区上，所以10个节点中有9个是空闲的，你的瓶颈就是单个的繁忙节点。一个负载不均衡的分区被称为热点（hot spot）。
避免热点的最简单方法是将记录随机分配给节点。这将在整个节点上平均分配数据，但是它有一个很大的缺点：当你试图读取一个特定的项目时，你无法知道它在哪个节点上，所以你必须并行地查询所有的节点。
我们可以做得更好。现在让我们假设您有一个简单的键值数据模型，其中您总是通过其主键访问记录。例如，在一篇老式的纸质百科全书中，你可以通过标题来查找一个条目;由于所有条目按字母顺序排序，因此您可以快速找到您要查找的条目。
根据键的范围分片
一种分区的方法是为每个分区指定一块连续的键范围（从最小值到最大值），如纸百科全书的卷（图6-2）。如果知道范围之间的界限，则可以轻松确定哪个分区包含给定的键。如果您还知道哪个分区分配给哪个节点，那么您可以直接向相应的节点发出请求（或者对于百科全书而言，从书架上选取正确的书籍）。
图6-2 印刷版百科全书按照关键字范围进行分区
键的范围不一定均匀分布，因为您的数据可能不均匀分布。例如，在图6-2中，第1卷包含以A和B开头的单词，但第12卷则包含以T，U，V，X，Y和Z开头的单词。每个字母的两个字母只有一个音量导致一些卷比其他卷更大。为了均匀分配数据，分区边界需要适应数据。
分区边界可以由管理员手动选择，也可以由数据库自动选择（将在“重新平衡分区”中更详细地讨论分区边界的选择）。 Bigtable使用了这种分区策略，以及其开源等价物HBase 【2, 3】，RethinkDB和2.4版本之前的MongoDB 【4】。
在每个分区中，我们可以按照排序的顺序保存键（参见“SSTables和LSM-树”）。这具有范围扫描非常简单的优点，您可以将键作为连接索引来处理，以便在一个查询中获取多个相关记录（参阅“多列索引”）。例如，考虑存储来自传感器网络的数据的应用程序，其中关键是测量的时间戳（年月日时分秒）。范围扫描在这种情况下非常有用，因为它们让您轻松获取某个月份的所有读数。
然而，Key Range分区的缺点是某些访问模式会导致热点。 如果Key是时间戳，则分区对应于时间范围，例如，每天一个分区。 不幸的是，由于我们在测量发生时将数据从传感器写入数据库，因此所有写入操作都会转到同一个分区（即今天的分区），这样分区可能会因写入而过载，而其他分区则处于空闲状态【5】。
为了避免传感器数据库中的这个问题，需要使用除了时间戳以外的其他东西作为Key的第一个部分。 例如，可以在每个时间戳前添加传感器名称，以便分区首先按传感器名称，然后按时间。 假设同时有许多传感器处于活动状态，则写入负载将最终均匀分布在分区上。 现在，当您想要在一个时间范围内获取多个传感器的值时，您需要为每个传感器名称执行一个单独的范围查询。
根据键的散列分片
由于这种倾斜和热点的风险，许多分布式数据存储使用散列函数来确定给定键的分区。
一个好的散列函数可以将接受偏斜的数据并使其均匀分布。假设你有一个带有字符串的32位散列函数。无论何时给它一个新的字符串，它将返回一个0到$2^{32}-1$之间的"随机"数。即使输入的字符串非常相似，它们的散列也会均匀分布在这个数字范围内。
出于分区的目的，散列函数不需要多么强壮的密码学安全性：例如，Cassandra和MongoDB使用MD5，Voldemort使用Fowler-Noll-Vo函数。许多编程语言都有内置的简单哈希函数（因为它们用于哈希表），但是它们可能不适合分区：例如，在Java的Object.hashCode()和Ruby的Object#hash，同一个键可能有不同的进程中不同的哈希值【6】。
一旦你有一个合适的键散列函数，你可以为每个分区分配一个散列范围（而不是键的范围），每个散列落在分区范围内的键将被存储在该分区中。如图6-3所示。
图6-3 按哈希键分区
这种技术擅长在分区之间分配键。分区边界可以是均匀间隔的，也可以是伪随机选择的（在这种情况下，该技术有时被称为一致性哈希（consistent hashing））。
一致性哈希
一致性哈希由Karger等人定义。【7】 用于跨互联网级别的缓存系统，例如CDN中，是一种能均匀分配负载的方法。它使用随机选择的**分区边界（partition boundaries）**来避免中央控制或分布式共识的需要。 请注意，这里的一致性与复制一致性（请参阅第5章）或ACID一致性（参阅第7章）无关，而是描述了重新平衡的特定方法。
正如我们将在“重新平衡分区”中所看到的，这种特殊的方法对于数据库实际上并不是很好，所以在实际中很少使用（某些数据库的文档仍然指的是一致性哈希，但是它 往往是不准确的）。 因为这太混乱了，所以最好避免使用一致性哈希这个术语，而只是把它称为散列分区（hash partitioning）。
不幸的是，通过使用Key散列进行分区，我们失去了键范围分区的一个很好的属性：高效执行范围查询的能力。曾经相邻的密钥现在分散在所有分区中，所以它们之间的顺序就丢失了。在MongoDB中，如果您使用了基于散列的分片模式，则任何范围查询都必须发送到所有分区【4】。主键上的范围查询不受Riak 【9】，Couchbase 【10】或Voldemort的支持。
Cassandra在两种分区策略之间达成了一个折衷【11, 12, 13】。 Cassandra中的表可以使用由多个列组成的复合主键来声明。键中只有第一列会作为散列的依据，而其他列则被用作Casssandra的SSTables中排序数据的连接索引。尽管查询无法在复合主键的第一列中按范围扫表，但如果第一列已经指定了固定值，则可以对该键的其他列执行有效的范围扫描。
串联索引方法为一对多关系提供了一个优雅的数据模型。例如，在社交媒体网站上，一个用户可能会发布很多更新。如果更新的主键被选择为(user_id, update_timestamp)，那么您可以有效地检索特定用户在某个时间间隔内按时间戳排序的所有更新。不同的用户可以存储在不同的分区上，但是在每个用户中，更新按时间戳顺序存储在单个分区上。
负载倾斜与消除热点
如前所述，哈希键确定其分区可以帮助减少热点。但是，它不能完全避免它们：在极端情况下，所有的读写操作都是针对同一个键的，所有的请求都会被路由到同一个分区。
这种工作量也许并不常见，但并非闻所未闻：例如，在社交媒体网站上，一个拥有数百万追随者的名人用户在做某事时可能会引发一场风暴【14】。这个事件可能导致大量写入同一个键（键可能是名人的用户ID，或者人们正在评论的动作的ID）。哈希键不起作用，因为两个相同ID的哈希值仍然是相同的。
如今，大多数数据系统无法自动补偿这种高度偏斜的工作负载，因此应用程序有责任减少偏斜。例如，如果一个密钥被认为是非常热的，一个简单的方法是在密钥的开始或结尾添加一个随机数。只要一个两位数的十进制随机数就可以将写入密钥分散到100个不同的密钥中，从而允许这些密钥分配到不同的分区。
然而，在不同的密钥之间进行分割，任何读取都必须要做额外的工作，因为他们必须从所有100个密钥中读取数据并将其合并。此技术还需要额外的簿记：只为少量热键附加随机数是有意义的;对于写入吞吐量低的绝大多数密钥，这将是不必要的开销。因此，您还需要一些方法来跟踪哪些键被分割。
也许在将来，数据系统将能够自动检测和补偿偏斜的工作负载；但现在，您需要自己来权衡。
分片与次级索引
到目前为止，我们讨论的分区方案依赖于键值数据模型。如果只通过主键访问记录，我们可以从该键确定分区，并使用它来将读写请求路由到负责该键的分区。
如果涉及次级索引，情况会变得更加复杂（参考“其他索引结构”）。辅助索引通常并不能唯一地标识记录，而是一种搜索记录中出现特定值的方式：查找用户123的所有操作，查找包含词语hogwash的所有文章，查找所有颜色为红色的车辆等等。
次级索引是关系型数据库的吃饭家伙，在文档数据库中也是很普遍的。许多键值存储（如HBase和Volde-mort）由于实现的复杂性而避免次级索引，但是一些（如Riak）已经开始添加它们，因为它们对于数据建模实在是太有用了。最后，次级索引是Solr和Elasticsearch等搜索服务器的存在意义。
次级索引的问题是它们不能整齐地映射到分区。有两种主要的方法可以用二级索引分区数据库：基于文档的分区（document-based）和基于关键词（term-based）的分区。
按文档的二级索引
例如，假设您正在经营一个销售二手车的网站（如图6-4所示）。 每个列表都有一个唯一的ID——称之为文档ID——并且用文档ID对数据库进行分区（例如，分区0中的ID 0到499，分区1中的ID 500到999等）。
你想让用户搜索汽车，允许他们通过颜色和厂商过滤，所以需要一个在颜色和厂商上的次级索引（文档数据库中这些是字段（field），关系数据库中这些是列（column） ）。 如果您声明了索引，则数据库可以自动执行索引2。例如，无论何时将红色汽车添加到数据库，数据库分区都会自动将其添加到索引条目color：red的文档ID列表中。
图6-4 按文档分区二级索引
在这种索引方法中，每个分区是完全独立的：每个分区维护自己的二级索引，仅覆盖该分区中的文档。它不关心哪些数据存储在其他分区中。无论何时您需要写入数据库（添加，删除或更新文档），只需处理包含您正在编写的文档ID的分区即可。出于这个原因，文档分区索引也被称为本地索引（local index）（而不是将在下一节中描述的全局索引（global index））。
但是，从文档分区索引中读取需要注意：除非您对文档ID做了特别的处理，否则没有理由将所有具有特定颜色或特定品牌的汽车放在同一个分区中。在图6-4中，红色汽车出现在分区0和分区1中。因此，如果要搜索红色汽车，则需要将查询发送到所有分区，并合并所有返回的结果。
这种查询分区数据库的方法有时被称为分散/聚集（scatter/gather），并且可能会使二级索引上的读取查询相当昂贵。即使您并行查询分区，分散/聚集也容易导致尾部延迟放大（请参阅第16页的“实践中的百分比”）。然而，它被广泛使用：MonDBDB，Riak 【15】，Cassandra 【16】，Elasticsearch 【17】，SolrCloud 【18】和VoltDB 【19】都使用文档分区二级索引。大多数数据库供应商建议您构建一个能从单个分区提供二级索引查询的分区方案，但这并不总是可行，尤其是当在单个查询中使用多个二级索引时（例如同时需要按颜色和制造商查询）。
根据Term的二级索引
我们可以构建一个覆盖所有分区数据的全局索引，而不是每个分区都有自己的次级索引（本地索引）。但是，我们不能只把这个索引存储在一个节点上，因为它可能会成为一个瓶颈，打破了分区的目的。全局索引也必须进行分区，但索引可以采用与主键不同的分区方式。
图6-5说明了这可能是什么情况：来自所有分区的红色汽车在索引中显示为红色：索引中的红色，但索引是分区的，以便从字母a到r开始的颜色出现在分区0中，颜色以s开始z出现在第1部分。汽车制造商的指数也是相似的（分区边界在f和h之间）。
图6-5 按术语对二级索引进行分区
我们将这种索引称为关键词分片（term-partitioned），因为我们寻找的关键词决定了索引的分片。在这里，例如，一个关键词可能是：颜色：红色。**关键词（Term）**这个术语来源于来自全文搜索索引（一种特定的次级索引），其中术语是文档中出现的所有单词。
和以前一样，我们可以通过关键词本身来将索引分片，或者使用关键词的散列。对关键词本身进行划分，对于范围扫描是有用的（例如，数字特性，例如汽车的要价），而对术语的哈希进行划分给出了负载的更均匀的分布。
全局（关键词分区）索引优于文档分区索引的优点是它可以使读取更有效率：而不是分散/收集所有分区，客户端只需要向包含关键词的分区发出请求它想要的。但是，全局索引的缺点在于写入速度较慢且较为复杂，因为写入单个文档现在可能会影响索引的多个分区（文档中的每个术语可能位于不同的分区上，位于不同的节点上） 。
在理想的世界里，索引总是最新的，写入数据库的每个文档都会立即反映在索引中。但是，在分区索引中，这会需要跨库分布式事务，跨越所有被写入影响的分片，这在所有数据库中都不受支持（请参阅第7章和第9章）。
在实践中，对全局二级索引的更新通常是异步的（也就是说，如果在写入之后不久读取索引，刚才所做的更改可能尚未反映在索引中）。例如，Amazon DynamoDB指出，在正常情况下，其全局次级索引会在不到一秒的时间内更新，但在基础架构出现故障的情况下可能会经历更长的传播延迟【20】。
全局术语分区索引的其他用途包括Riak的搜索功能【21】和Oracle数据仓库，它允许您在本地索引和全局索引之间进行选择【22】。我们将回到第12章中回到实现关键字二级索引的主题。
重平衡分区
在数据库中，随着时间的推移，事情也在起变化。
- 查询吞吐量增加，所以您想要添加更多的CPU来处理负载。
- 数据集大小增加，所以您想添加更多的磁盘和RAM来存储它。
- 机器出现故障，其他机器需要接管故障机器的责任。
所有这些更改都要求数据和请求从一个节点移动到另一个节点。 从集群中的一个节点向另一个节点移动负载的过程称为再平衡（reblancing）。
无论使用哪种分区方案，再平衡通常都会满足一些最低要求：
- 再平衡之后，负载（数据存储，读取和写入请求）应该在集群中的节点之间公平地共享。
- 再平衡正在发生时，数据库应该继续接受读取和写入。
- 节点之间不应移动超过所需的数据，以便快速再平衡，并尽量减少网络和磁盘I/O负载。
平衡策略
有几种不同的分区分配方式【23】。让我们依次简要讨论一下。
反面教材：hash mod N
我们在前面说过（图6-3），最好将可能的散列分成不同的范围，并将每个范围分配给一个分区（例如，如果$0≤hash(key)<b_0$，则将键分配给分区0，如果$b_0 ≤ hash(key) <b_1$，则分配给分区1）
也许你想知道为什么我们不使用mod（许多编程语言中的％运算符）。例如，hash(key) mod 10会返回一个介于0和9之间的数字（如果我们将散列写为十进制数，散列模10将是最后一个数字）。如果我们有10个节点，编号为0到9，这似乎是将每个键分配给一个节点的简单方法。
模N方法的问题是，如果节点数量N发生变化，大多数密钥将需要从一个节点移动到另一个节点。例如，假设$hash(key)=123456$。如果最初有10个节点，那么这个键一开始放在节点6上（因为$123456\ mod\ 10 = 6$）。当您增长到11个节点时，密钥需要移动到节点3（$123456\ mod\ 11 = 3$），当您增长到12个节点时，需要移动到节点0（$123456\ mod\ 12 = 0$）。这种频繁的举动使得再平衡过于昂贵。
我们需要一种不需要移动数据的方法。
固定数量的分区
幸运的是，有一个相当简单的解决方案：创建比节点更多的分区，并为每个节点分配多个分区。例如，运行在10个节点的集群上的数据库可能会从一开始就被拆分为1,000个分区，因此大约有100个分区被分配给每个节点。
现在，如果一个节点被添加到集群中，新节点可以从每个现有节点中窃取几个分区，直到分区再次公平分配。这个过程如图6-6所示。如果从集群中删除一个节点，则会发生相反的情况。
只有整个分区在节点之间移动。分区的数量不会改变，键所指定的分区也不会改变。唯一改变的是分区所指派的节点。这种指派变更并不是即时的——在网络上传输大量的数据需要一些时间——所以在传输过程中，旧的分区会接受传输过程中发生的读写操作。
图6-6 将新节点添加到每个节点具有多个分区的数据库群集。
原则上，您甚至可以解决集群中的硬件不匹配问题：通过为更强大的节点分配更多的分区，可以强制这些节点分担更多的负载。在Riak 【15】，Elasticsearch 【24】，Couchbase 【10】和Voldemort 【25】中使用了这种重新平衡的方法。
在这种配置中，分区的数量通常在数据库第一次建立时是固定的，之后不会改变。虽然原则上可以分割和合并分区（请参阅下一节），但固定数量的分区在操作上更简单，因此许多固定分区数据库选择不实施分区分割。因此，一开始配置的分区数就是您可以拥有的最大节点数量，所以您需要选择足够高的分区以适应未来的增长。但是，每个分区也有管理开销，所以选择太高的数字是适得其反的。
如果数据集的总大小是高度可变的（例如，如果它开始很小，但随着时间的推移可能会变得更大），选择正确的分区数是困难的。由于每个分区包含总数据的固定部分，因此每个分区的大小与集群中的数据总量成比例增长。如果分区非常大，重新平衡和从节点故障恢复变得昂贵。但是，如果份额太小，则会产生太多的开销。当分区大小“恰到好处”，既不会太大，也不会太小，如果分区数量固定，但数据集大小变化不定，则难以达到最佳性能。
动态分区
对于使用键范围分区的数据库（参阅“按键范围分区”），具有固定边界的固定数量的分区将非常不方便：如果出现边界错误，则可能会导致所有一个分区中的数据和所有其他分区中的数据为空。手动重新配置分区边界将非常繁琐。
出于这个原因，按键的范围进行分区的数据库（如HBase和RethinkDB）会动态创建分区。当分区增长到超过配置的大小时（在HBase上，默认值是10GB），它被分成两个分区，大约每个分区各占一半的数据【26】。相反，如果大量数据被删除并且分区缩小到某个阈值以下，则可以将其与相邻分区合并。此过程与B树顶层发生的过程类似（参阅“B树”）。
每个分区指派给一个节点，每个节点可以处理多个分区，就像固定数量的分区一样。大型分区拆分后，可以将其中的一半转移到另一个节点，以平衡负载。在HBase的情况下，分区文件的传输通过HDFS（底层分布式文件系统）来实现【3】。
动态分区的一个优点是分区数量适应总数据量。如果只有少量的数据，少量的分区就足够了，所以开销很小;如果有大量的数据，每个分区的大小被限制在一个可配置的最大值【23】。
但是，需要注意的是，一个空的数据库从一个分区开始，因为没有关于在哪里绘制分区边界的先验信息。虽然数据集很小，直到达到第一个分区的分割点时，所有写入操作都必须由单个节点处理，而其他节点则处于空闲状态。为了解决这个问题，HBase和MongoDB允许在一个空的数据库上配置一组初始分区（这被称为预分割（pre-splitting））。在键范围分区的情况下，预分割要求已经知道键分布的样子【4,26】。
动态分区不仅适用于关键的范围分区数据，而且也适用于散列分区数据。从版本2.4开始，MongoDB同时支持键范围和哈希分区，并且在任何情况下动态分割分区。
按节点比例分区
通过动态分区，分区的数量与数据集的大小成正比，因为拆分和合并过程将每个分区的大小保持在固定的最小值和最大值之间。另一方面，对于固定数量的分区，每个分区的大小与数据集的大小成正比。在这两种情况下，分区的数量都与节点的数量无关。
Cassandra和Ketama使用的第三种方法是使分区数与节点数成比例 - 换句话说，每个节点具有固定数量的分区【23, 27, 28】。在这种情况下，每个分区的大小与数据集大小成比例地增长，而节点数量保持不变，但是当增加节点数时，分区将再次变小。由于较大的数据量通常需要较大数量的节点进行存储，因此这种方法也使每个分区的大小相当稳定。
当一个新节点加入集群时，它随机选择固定数量的现有分区进行拆分，然后占有这些拆分分区中每个分区的一半，同时将每个分区的另一半留在原地。随机化可能会产生不公平的分裂，但是当在更大数量的分区上进行平均时（在Cassandra中，默认情况下，每个节点有256个分区），新节点最终从现有节点获得公平的负载份额。 Cassandra 3.0引入了另一种可重用的算法来避免不公平的分裂【29】。
随机选择分区边界要求使用基于散列的分区（所以可以从散列函数产生的数字范围中挑选边界）。实际上，这种方法最符合一致性散列的原始定义【7】（参阅“一致性散列”）。较新的哈希函数可以在降低元数据开销的情况下达到类似的效果【8】。
运维：手动还是自动平衡
关于我们已经掩盖的重新平衡问题有一个重要问题：重新平衡是自动还是手动进行？
在全自动重新平衡（系统自动决定何时将分区从一个节点移动到另一个节点，而没有任何管理员交互）和完全手动（分区指派给节点由管理员明确配置）之间有一个梯度，仅在管理员明确重新配置时才会更改）。例如，Couchbase，Riak和Voldemort会自动生成建议的分区分配，但需要管理员在生效之前提交它。
全自动重新平衡可以很方便，因为正常维护的操作工作较少。但是，这可能是不可预测的。再平衡是一个昂贵的操作，因为它需要重新路由请求并将大量数据从一个节点移动到另一个节点。如果没有做好，这个过程可能会使网络或节点负载过重，并在重新平衡过程中损害其他请求的性能。
这种自动化与自动故障检测相结合可能是危险的。例如，假设一个节点过载，并且对请求的响应暂时很慢。其他节点得出结论：过载的节点已经死亡，并自动重新平衡集群，使负载离开它。这会对超载节点，其他节点和网络造成额外的负载，从而使情况变得更糟，并可能导致级联失败。
出于这个原因，再平衡的循环中有一个人参与是一件好事。这比完全自动的过程慢，但可以帮助防止意外操作。
请求路由
现在我们已经将数据集分割到多个机器上运行的多个节点上。但是仍然存在一个悬而未决的问题：当客户想要提出请求时，如何知道要连接哪个节点？随着分区重新平衡，分区对节点的分配也发生变化。为了回答这个问题，有人需要停留在这些变化之上：如果我想读或写键“foo”，需要连接哪个IP地址和端口号？
这是一个称为**服务发现（service discovery）**的更普遍问题的实例，它不仅限于数据库。任何可通过网络访问的软件都有这个问题，特别是如果它的目标是实现高可用性（在多台机器上运行冗余配置）。许多公司已经编写了自己的内部服务发现工具，其中许多已经作为开源发布【30】。
在很高的层面上，这个问题有几种不同的方法（如图6-7所示）：
- 允许客户联系任何节点（例如，通过循环策略的负载均衡（Round-Robin Load Balancer））。如果该节点巧合地拥有请求所适用的分区，则它可以直接处理该请求;否则，它将请求转发到适当的节点，接收答复并传递给客户端。
- 首先将所有来自客户端的请求发送到路由选择层，它决定了应该处理请求的节点，并相应地转发。此路由层本身不处理任何请求；它仅充当分区感知负载平衡器。
- 要求客户端知道分区和节点分配。在这种情况下，客户端可以直接连接到适当的节点，而不需要任何中介。
在所有情况下，关键问题是：作出路由决策的组件（可能是节点之一，还是路由层或客户端）如何了解分区-节点之间的分配关系变化？
图6-7 将请求路由到正确节点的三种不同方式。
这是一个具有挑战性的问题，因为重要的是所有参与者都同意 - 否则请求将被发送到错误的节点，而不是正确处理。 在分布式系统中有达成共识的协议，但很难正确地实现（见第9章）。
许多分布式数据系统都依赖于一个独立的协调服务，比如ZooKeeper来跟踪集群元数据，如图6-8所示。 每个节点在ZooKeeper中注册自己，ZooKeeper维护分区到节点的权威映射。 其他参与者（如路由层或分区感知客户端）可以在ZooKeeper中订阅此信息。 只要分区改变了所有权，或者添加或删除了一个节点，ZooKeeper就会通知路由层，以使路由信息保持最新状态。
图6-8 使用ZooKeeper跟踪分区分配给节点。
例如，LinkedIn的Espresso使用Helix 【31】进行集群管理（依靠ZooKeeper），实现了一个路由层，如图6-8所示。 HBase，SolrCloud和Kafka也使用ZooKeeper来跟踪分区分配。 MongoDB具有类似的体系结构，但它依赖于自己的**配置服务器（config server）**实现和mongos守护进程作为路由层。
Cassandra和Riak采取不同的方法：他们在节点之间使用**八卦协议（gossip protocal）**来传播群集状态的变化。请求可以发送到任意节点，该节点会转发到包含所请求的分区的适当节点（图6-7中的方法1）。这个模型在数据库节点中增加了更多的复杂性，但是避免了对像ZooKeeper这样的外部协调服务的依赖。
Couchbase不会自动重新平衡，这简化了设计。通常情况下，它配置了一个名为moxi的路由选择层，它会从集群节点了解路由变化【32】。
当使用路由层或向随机节点发送请求时，客户端仍然需要找到要连接的IP地址。这些分区并不像分配给节点那么快，所以为此使用DNS通常就足够了。
执行并行查询
到目前为止，我们只关注读取或写入单个键的非常简单的查询（对于文档分区的二级索引，另外还有分散/聚集查询）。这与大多数NoSQL分布式数据存储所支持的访问级别有关。
然而，通常用于分析的**大规模并行处理（MPP, Massively parallel processing）**关系数据库产品在其支持的查询类型方面要复杂得多。一个典型的数据仓库查询包含多个连接，过滤，分组和聚合操作。 MPP查询优化器将这个复杂的查询分解成许多执行阶段和分区，其中许多可以在数据库集群的不同节点上并行执行。涉及扫描大部分数据集的查询尤其受益于这种并行执行。
数据仓库查询的快速并行执行是一个专门的话题，由于分析有很强的商业重要性，它收到了很多商业利益。我们将在第10章讨论并行查询执行的一些技巧。有关并行数据库中使用的技术的更详细的概述，请参阅参考文献【1,33】。
本章小结
在本章中，我们探讨了将大数据集划分成更小的子集的不同方法。如果您有太多的数据，在单台机器上存储和处理不再可行，则分区是必要的。分区的目标是在多台机器上均匀分布数据和查询负载，避免出现热点（负载不成比例的节点）。这需要选择适合于您的数据的分区方案，并在将节点添加到集群或从集群删除时进行再分区。
我们讨论了两种主要的分区方法：
键范围分区
其中键是有序的，并且分区拥有从某个最小值到某个最大值的所有键。排序的优势在于可以进行有效的范围查询，但是如果应用程序经常按照排序顺序访问密切相关的键，则存在热点的风险。
在这种方法中，当分区变得太大时，通常将分区分成两个子分区，动态地再平衡分区。
散列分区
散列函数应用于每个键，分区拥有一定范围的散列。这种方法破坏了键的排序，使得范围查询效率低下，但可以更均匀地分配负载。
通过散列进行分区时，通常先提前创建固定数量的分区，为每个节点分配多个分区，并在添加或删除节点时将整个分区从一个节点移动到另一个节点。也可以使用动态分区。
混合方法也是可行的，例如使用复合主键：使用键的一部分来标识分区，而使用另一部分作为排序顺序。还讨论了分区和二级索引之间的相互作用。次级索引也需要分片，有两种方法：
- 按文档分区（本地索引），其中辅助索引存储在与主键和值相同的分区中。这意味着只有一个分区需要在写入时更新，但是读取辅助索引需要在所有分区之间进行分散/收集。
- 按关键词分区（全局索引），其中二级索引是分开分开的。辅助索引中的条目可以包括来自主键的所有分区的记录。当文档写入时，需要更新二级索引的多个分区；但是，可以从单个分区提供读取。
最后，我们讨论了将查询路由到适当的分区的技术，从简单的分区感知负载平衡到复杂的并行查询执行引擎。
按照设计，每个分区大部分是独立运行的——这就是允许分区数据库扩展到多台机器的原因。但是，需要写入多个分区的操作难以推理：例如，如果写入一个分区成功，但另一个分区失败，会发生什么情况？我们将在下面的章节中讨论这个问题。
参考文献
-
David J. DeWitt and Jim N. Gray: “Parallel Database Systems: The Future of High Performance Database Systems,” Communications of the ACM, volume 35, number 6, pages 85–98, June 1992. doi:10.1145/129888.129894
-
Lars George: “HBase vs. BigTable Comparison,” larsgeorge.com, November 2009.
-
“The Apache HBase Reference Guide,” Apache Software Foundation, hbase.apache.org, 2014.
-
MongoDB, Inc.: “New Hash-Based Sharding Feature in MongoDB 2.4,” blog.mongodb.org, April 10, 2013.
-
Ikai Lan: “App Engine Datastore Tip: Monotonically Increasing Values Are Bad,” ikaisays.com, January 25, 2011.
-
Martin Kleppmann: “Java's hashCode Is Not Safe for Distributed Systems,” martin.kleppmann.com, June 18, 2012.
-
David Karger, Eric Lehman, Tom Leighton, et al.: “Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web,” at 29th Annual ACM Symposium on Theory of Computing (STOC), pages 654–663, 1997. doi:10.1145/258533.258660
-
John Lamping and Eric Veach: “A Fast, Minimal Memory, Consistent Hash Algorithm,” arxiv.org, June 2014.
-
Eric Redmond: “A Little Riak Book,” Version 1.4.0, Basho Technologies, September 2013.
-
“Couchbase 2.5 Administrator Guide,” Couchbase, Inc., 2014.
-
Avinash Lakshman and Prashant Malik: “Cassandra – A Decentralized Structured Storage System,” at 3rd ACM SIGOPS International Workshop on Large Scale Distributed Systems and Middleware (LADIS), October 2009.
-
Jonathan Ellis: “Facebook’s Cassandra Paper, Annotated and Compared to Apache Cassandra 2.0,” datastax.com, September 12, 2013.
-
“Introduction to Cassandra Query Language,” DataStax, Inc., 2014.
-
Samuel Axon: “3% of Twitter's Servers Dedicated to Justin Bieber,” mashable.com, September 7, 2010.
-
“Riak 1.4.8 Docs,” Basho Technologies, Inc., 2014.
-
Richard Low: “The Sweet Spot for Cassandra Secondary Indexing,” wentnet.com, October 21, 2013.
-
Zachary Tong: “Customizing Your Document Routing,” elasticsearch.org, June 3, 2013.
-
“Apache Solr Reference Guide,” Apache Software Foundation, 2014.
-
Andrew Pavlo: “H-Store Frequently Asked Questions,” hstore.cs.brown.edu, October 2013.
-
“Amazon DynamoDB Developer Guide,” Amazon Web Services, Inc., 2014.
-
Rusty Klophaus: “Difference Between 2I and Search,” email to riak-users mailing list, lists.basho.com, October 25, 2011.
-
Donald K. Burleson: “Object Partitioning in Oracle,”dba-oracle.com, November 8, 2000.
-
Eric Evans: “Rethinking Topology in Cassandra,” at ApacheCon Europe, November 2012.
-
Rafał Kuć: “Reroute API Explained,” elasticsearchserverbook.com, September 30, 2013.
-
“Project Voldemort Documentation,” project-voldemort.com.
-
Enis Soztutar: “Apache HBase Region Splitting and Merging,” hortonworks.com, February 1, 2013.
-
Brandon Williams: “Virtual Nodes in Cassandra 1.2,” datastax.com, December 4, 2012.
-
Richard Jones: “libketama: Consistent Hashing Library for Memcached Clients,” metabrew.com, April 10, 2007.
-
Branimir Lambov: “New Token Allocation Algorithm in Cassandra 3.0,” datastax.com, January 28, 2016.
-
Jason Wilder: “Open-Source Service Discovery,” jasonwilder.com, February 2014.
-
Kishore Gopalakrishna, Shi Lu, Zhen Zhang, et al.: “Untangling Cluster Management with Helix,” at ACM Symposium on Cloud Computing (SoCC), October 2012. doi:10.1145/2391229.2391248
-
“Moxi 1.8 Manual,” Couchbase, Inc., 2014.
-
Shivnath Babu and Herodotos Herodotou: “Massively Parallel Databases and MapReduce Systems,” Foundations and Trends in Databases, volume 5, number 1, pages 1–104, November 2013.doi:10.1561/1900000036
| 上一章 | 目录 | 下一章 |
|---|---|---|
| 第五章：复制 | 设计数据密集型应用 | 第七章：事务 |