Update ch06.md

remove redundant * in ch06
This commit is contained in:
muniao 2023-01-08 15:59:27 +08:00 committed by GitHub
parent 9685c37508
commit 6c3a350bae
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -35,7 +35,7 @@
因此,接下来主要针对键值对集合的分区方式,则其他数据库在构建存储层时,可以首先转化为 KV 对,然后进行分区。
**分片Partition**的本质是对数据集合的划分。但在实践中,可以细分为两个步骤:
**分片Partition** 的本质是对数据集合的划分。但在实践中,可以细分为两个步骤:
1. 对数据集进行**逻辑**划分
2. 将逻辑分片调度到**物理**节点
@ -83,7 +83,7 @@
![partition by hash key](img/ch06-fig03.png)
还有一种常提的哈希方法叫做**[一致性哈希](https://zh.m.wikipedia.org/zh-hans/%E4%B8%80%E8%87%B4%E5%93%88%E5%B8%8C)**。其特点是,会考虑逻辑分片和物理拓扑,将数据和物理节点按同样的哈希函数进行哈希,来决定如何将哈希分片路由到不同机器上。它可以避免在内存中维护**逻辑分片到物理节点的映射**,而是每次计算出来。即用一套算法同时解决了我们在最初提出的逻辑分片和物理路由的两个问题。 比较经典的数据系统,[Amazon Dynamo](https://www.qtmuniao.com/2020/06/13/dynamo/) 就用了这种方式。
还有一种常提的哈希方法叫做[一致性哈希](https://zh.m.wikipedia.org/zh-hans/%E4%B8%80%E8%87%B4%E5%93%88%E5%B8%8C) 。其特点是,会考虑逻辑分片和物理拓扑,将数据和物理节点按同样的哈希函数进行哈希,来决定如何将哈希分片路由到不同机器上。它可以避免在内存中维护**逻辑分片到物理节点的映射**,而是每次计算出来。即用一套算法同时解决了我们在最初提出的逻辑分片和物理路由的两个问题。 比较经典的数据系统,[Amazon Dynamo](https://www.qtmuniao.com/2020/06/13/dynamo/) 就用了这种方式。
![dynamo partitioning and replication](img/ch06-dynamo.png)
@ -270,9 +270,9 @@
大部分 NoSQL 存储,所支持的查询都不太负载,如基于主键的查询、基于次级索引的 scatter/gather 查询。如前所述,都是针对单个键值非常简单的查询路由。
但对于关系型数据库产品,尤其是支持 **大规模并行处理MPP, Massively parallel processing**数仓,一个查询语句在执行层要复杂的多,可能会:
但对于关系型数据库产品,尤其是支持 **大规模并行处理MPP, Massively parallel processing** 数仓,一个查询语句在执行层要复杂的多,可能会:
1. Stage由多个阶段组成。
2. Partition每个阶段包含多个针对每个分区的并行的子查询计划。
数仓的大规模的快速并行执行是另一个需要专门讨论的话题,由于多用于支持 BI因此其优化具有重要意义本书后面第十章会专门讨论。
数仓的大规模的快速并行执行是另一个需要专门讨论的话题,由于多用于支持 BI因此其优化具有重要意义本书后面第十章会专门讨论。