document/ddia
2
0
Fork 0
mirror of https://github.com/Vonng/ddia.git synced 2024-12-06 15:20:12 +08:00
Code Issues Packages Projects Releases Wiki Activity

fix markdown and punctuations

Browse Source
This commit is contained in:
keming 2020-11-09 00:05:15 +08:00
parent 1bf5a38bdc
commit bdd492deb3
3 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
ch6.md
View File

@ -11,13 +11,13 @@
[TOC] [TOC]
​ 在[第5章](ch5.md)中，我们讨论了复制——即数据在不同节点上的副本,对于非常大的数据集,或非常高的吞吐量，仅仅进行复制是不够的：我们需要将数据进行**分区（partitions）**，也称为**分片（sharding）**[^i] ​ 在[第5章](ch5.md)中，我们讨论了复制——即数据在不同节点上的副本,对于非常大的数据集,或非常高的吞吐量，仅仅进行复制是不够的：我们需要将数据进行**分区（partitions）**，也称为**分片（sharding）**[^i]。
[^i]: 正如本章所讨论的，分区是一种有意将大型数据库分解成小型数据库的方式。它与 **网络分区（net splits）** 无关，这是节点之间网络中的一种故障类型。我们将在[第8章](ch8.md)讨论这些错误。 [^i]: 正如本章所讨论的，分区是一种有意将大型数据库分解成小型数据库的方式。它与 **网络分区（net splits）** 无关，这是节点之间网络中的一种故障类型。我们将在[第8章](ch8.md)讨论这些错误。
> ##### 术语澄清 > ##### 术语澄清
> >
> ​ 上文中的**分区(partition)**,在MongoDB,Elasticsearch和Solr Cloud中被称为**分片(shard)**,在HBase中称之为**区域(Region)**，Bigtable中则是 **表块（tablet）**，Cassandra和Riak中是**虚节点（vnode)**, Couchbase中叫做**虚桶(vBucket)**.但是**分区(partition)** 是约定俗成的叫法。 > ​ 上文中的**分区(partition)**，在MongoDB，Elasticsearch和Solr Cloud中被称为**分片(shard)**，在HBase中称之为**区域(Region)**，Bigtable中则是 **表块（tablet）**，Cassandra和Riak中是**虚节点（vnode)**，Couchbase中叫做**虚桶(vBucket)**。但是**分区(partition)** 是约定俗成的叫法。
> >
​ 通常情况下，每条数据（每条记录，每行或每个文档）属于且仅属于一个分区。有很多方法可以实现这一点，本章将进行深入讨论。实际上，每个分区都是自己的小型数据库，尽管数据库可能支持同时进行多个分区的操作。 ​ 通常情况下，每条数据（每条记录，每行或每个文档）属于且仅属于一个分区。有很多方法可以实现这一点，本章将进行深入讨论。实际上，每个分区都是自己的小型数据库，尽管数据库可能支持同时进行多个分区的操作。
@ -43,7 +43,7 @@
## 键值数据的分区 ## 键值数据的分区
​ 假设你有大量数据并且想要分区,如何决定在哪些节点上存储哪些记录呢？ ​ 假设你有大量数据并且想要分区，如何决定在哪些节点上存储哪些记录呢？
​ 分区目标是将数据和查询负载均匀分布在各个节点上。如果每个节点公平分享数据和负载，那么理论上10个节点应该能够处理10倍的数据量和10倍的单个节点的读写吞吐量（暂时忽略复制）。 ​ 分区目标是将数据和查询负载均匀分布在各个节点上。如果每个节点公平分享数据和负载，那么理论上10个节点应该能够处理10倍的数据量和10倍的单个节点的读写吞吐量（暂时忽略复制）。
@ -51,7 +51,7 @@
​ 避免热点最简单的方法是将记录随机分配给节点。这将在所有节点上平均分配数据，但是它有一个很大的缺点：当你试图读取一个特定的值时，你无法知道它在哪个节点上，所以你必须并行地查询所有的节点。 ​ 避免热点最简单的方法是将记录随机分配给节点。这将在所有节点上平均分配数据，但是它有一个很大的缺点：当你试图读取一个特定的值时，你无法知道它在哪个节点上，所以你必须并行地查询所有的节点。
​ 我们可以做得更好。现在假设您有一个简单的键值数据模型，其中您总是通过其主键访问记录。例如，在一本老式的纸质百科全书中，你可以通过标题来查找一个条目;由于所有条目按字母顺序排序，因此您可以快速找到您要查找的条目。 ​ 我们可以做得更好。现在假设您有一个简单的键值数据模型，其中您总是通过其主键访问记录。例如，在一本老式的纸质百科全书中，你可以通过标题来查找一个条目；由于所有条目按字母顺序排序，因此您可以快速找到您要查找的条目。
### 根据键的范围分区 ### 根据键的范围分区
@ -75,7 +75,7 @@
​ 由于偏斜和热点的风险，许多分布式数据存储使用散列函数来确定给定键的分区。 ​ 由于偏斜和热点的风险，许多分布式数据存储使用散列函数来确定给定键的分区。
​ 一个好的散列函数可以将将偏斜的数据均匀分布。假设你有一个32位散列函数,无论何时给定一个新的字符串输入，它将返回一个0到$2^{32}$ -1之间的"随机"数。即使输入的字符串非常相似，它们的散列也会均匀分布在这个数字范围内。 ​ 一个好的散列函数可以将将偏斜的数据均匀分布。假设你有一个32位散列函数,无论何时给定一个新的字符串输入，它将返回一个0到$2^{32}$ -1之间的“随机”数。即使输入的字符串非常相似，它们的散列也会均匀分布在这个数字范围内。
​ 出于分区的目的，散列函数不需要多么强壮的加密算法：例如，Cassandra和MongoDB使用MD5，Voldemort使用Fowler-Noll-Vo函数。许多编程语言都有内置的简单哈希函数（它们用于哈希表），但是它们可能不适合分区：例如，在Java的`Object.hashCode()`和Ruby的`Object#hash`，同一个键可能在不同的进程中有不同的哈希值【6】。 ​ 出于分区的目的，散列函数不需要多么强壮的加密算法：例如，Cassandra和MongoDB使用MD5，Voldemort使用Fowler-Noll-Vo函数。许多编程语言都有内置的简单哈希函数（它们用于哈希表），但是它们可能不适合分区：例如，在Java的`Object.hashCode()`和Ruby的`Object#hash`，同一个键可能在不同的进程中有不同的哈希值【6】。
@ -107,7 +107,7 @@
​ 如今，大多数数据系统无法自动补偿这种高度偏斜的负载，因此应用程序有责任减少偏斜。例如，如果一个主键被认为是非常火爆的，一个简单的方法是在主键的开始或结尾添加一个随机数。只要一个两位数的十进制随机数就可以将主键分散为100种不同的主键,从而存储在不同的分区中。 ​ 如今，大多数数据系统无法自动补偿这种高度偏斜的负载，因此应用程序有责任减少偏斜。例如，如果一个主键被认为是非常火爆的，一个简单的方法是在主键的开始或结尾添加一个随机数。只要一个两位数的十进制随机数就可以将主键分散为100种不同的主键,从而存储在不同的分区中。
​ 然而，将主键进行分割之后，任何读取都必须要做额外的工作，因为他们必须从所有100个主键分布中读取数据并将其合并。此技术还需要额外的记录：只需要对少量热点附加随机数;对于写入吞吐量低的绝大多数主键来说是不必要的开销。因此，您还需要一些方法来跟踪哪些键需要被分割。 ​ 然而，将主键进行分割之后，任何读取都必须要做额外的工作，因为他们必须从所有100个主键分布中读取数据并将其合并。此技术还需要额外的记录：只需要对少量热点附加随机数；对于写入吞吐量低的绝大多数主键来说是不必要的开销。因此，您还需要一些方法来跟踪哪些键需要被分割。
​ 也许在将来，数据系统将能够自动检测和补偿偏斜的工作负载；但现在，您需要自己来权衡。 ​ 也许在将来，数据系统将能够自动检测和补偿偏斜的工作负载；但现在，您需要自己来权衡。
@ -155,7 +155,7 @@
​ 我们将这种索引称为**关键词分区（term-partitioned）**，因为我们寻找的关键词决定了索引的分区方式。例如，一个关键词可能是：`颜色：红色`。**关键词(Term)** 来源于来自全文搜索索引（一种特殊的次级索引），指文档中出现的所有单词。 ​ 我们将这种索引称为**关键词分区（term-partitioned）**，因为我们寻找的关键词决定了索引的分区方式。例如，一个关键词可能是：`颜色：红色`。**关键词(Term)** 来源于来自全文搜索索引（一种特殊的次级索引），指文档中出现的所有单词。
​ 和之前一样，我们可以通过**关键词**本身或者它的散列进行索引分区。根据它本身分区对于范围扫描非常有用（例如对于数字,像汽车的报价），而对关键词的哈希分区提供了负载均衡的能力。 ​ 和之前一样，我们可以通过**关键词**本身或者它的散列进行索引分区。根据它本身分区对于范围扫描非常有用（例如对于数字，像汽车的报价），而对关键词的哈希分区提供了负载均衡的能力。
​ 关键词分区的全局索引优于文档分区索引的地方点是它可以使读取更有效率：不需要**分散/收集**所有分区，客户端只需要向包含关键词的分区发出请求。全局索引的缺点在于写入速度较慢且较为复杂，因为写入单个文档现在可能会影响索引的多个分区（文档中的每个关键词可能位于不同的分区或者不同的节点上） 。 ​ 关键词分区的全局索引优于文档分区索引的地方点是它可以使读取更有效率：不需要**分散/收集**所有分区，客户端只需要向包含关键词的分区发出请求。全局索引的缺点在于写入速度较慢且较为复杂，因为写入单个文档现在可能会影响索引的多个分区（文档中的每个关键词可能位于不同的分区或者不同的节点上） 。
@ -222,7 +222,7 @@
​ 每个分区分配给一个节点，每个节点可以处理多个分区，就像固定数量的分区一样。大型分区拆分后，可以将其中的一半转移到另一个节点，以平衡负载。在HBase中，分区文件的传输通过HDFS（底层分布式文件系统）来实现【3】。 ​ 每个分区分配给一个节点，每个节点可以处理多个分区，就像固定数量的分区一样。大型分区拆分后，可以将其中的一半转移到另一个节点，以平衡负载。在HBase中，分区文件的传输通过HDFS（底层分布式文件系统）来实现【3】。
​ 动态分区的一个优点是分区数量适应总数据量。如果只有少量的数据，少量的分区就足够了，所以开销很小;如果有大量的数据，每个分区的大小被限制在一个可配置的最大值【23】。 ​ 动态分区的一个优点是分区数量适应总数据量。如果只有少量的数据，少量的分区就足够了，所以开销很小；如果有大量的数据，每个分区的大小被限制在一个可配置的最大值【23】。
​ 需要注意的是，一个空的数据库从一个分区开始，因为没有关于在哪里绘制分区边界的先验信息。数据集开始时很小，直到达到第一个分区的分割点，所有写入操作都必须由单个节点处理，而其他节点则处于空闲状态。为了解决这个问题，HBase和MongoDB允许在一个空的数据库上配置一组初始分区（这被称为**预分割（pre-splitting）**）。在键范围分区的情况中，预分割需要提前知道键是如何进行分配的【4,26】。 ​ 需要注意的是，一个空的数据库从一个分区开始，因为没有关于在哪里绘制分区边界的先验信息。数据集开始时很小，直到达到第一个分区的分割点，所有写入操作都必须由单个节点处理，而其他节点则处于空闲状态。为了解决这个问题，HBase和MongoDB允许在一个空的数据库上配置一组初始分区（这被称为**预分割（pre-splitting）**）。在键范围分区的情况中，预分割需要提前知道键是如何进行分配的【4,26】。
@ -258,7 +258,7 @@
概括来说，这个问题有几种不同的方案（如图6-7所示）: 概括来说，这个问题有几种不同的方案（如图6-7所示）:
1. 允许客户联系任何节点（例如，通过**循环策略的负载均衡（Round-Robin Load Balancer）**）。如果该节点恰巧拥有请求的分区，则它可以直接处理该请求;否则，它将请求转发到适当的节点，接收回复并传递给客户端。 1. 允许客户联系任何节点（例如，通过**循环策略的负载均衡（Round-Robin Load Balancer）**）。如果该节点恰巧拥有请求的分区，则它可以直接处理该请求；否则，它将请求转发到适当的节点，接收回复并传递给客户端。
2. 首先将所有来自客户端的请求发送到路由层，它决定了应该处理请求的节点，并相应地转发。此路由层本身不处理任何请求；它仅负责分区的负载均衡。 2. 首先将所有来自客户端的请求发送到路由层，它决定了应该处理请求的节点，并相应地转发。此路由层本身不处理任何请求；它仅负责分区的负载均衡。
3. 要求客户端知道分区和节点的分配。在这种情况下，客户端可以直接连接到适当的节点，而不需要任何中介。 3. 要求客户端知道分区和节点的分配。在这种情况下，客户端可以直接连接到适当的节点，而不需要任何中介。