CockroachDB架构——分布层

CockroachDB架构的分布层提供了集群数据的统一视图。
--注意:
1)如果您还没有准备好,我们建议先阅读架构概览部分。 
一.概览
为了从任何节点访问集群中的所有数据,CockroachDB按照整体排序映射来存储键值对。该键空间描述集群中数据的所有信息及其位置,并将其分为我们称为的"范围",其为连续的键空间块,以便每个键值总是能在单个范围内找到。
CockroachDB实施排序映射以开启:
1)简化查找(Simple lookups):因为我们要鉴别哪个节点复制某部分数据,查询能快速定位其需要的数据的位置。
2)高效扫描(Efficient scans):通过定义数据的顺序,扫描期间发现特定范围内的数据变的容易。
1.整体排序的映射结构
整体排序的映射包括连个基本元素:
1)系统数据,其包括描述集群中数据位置的元范围(在很多其他集群范围和本地数据元素中)。
2)用户数据,其存储集群的表数据。
1)元范围
集群中所有范围的位置存储于键空间开始部分的一个两级索引中,称为元范围,其一级(meta1)寻址二级,二级(meta2)寻址集群中的数据。重要的是,每个节点有定位meta1范围(称为其范围描述符,下面详述)位置的信息,且该范围从不会被拆分。
该元范围结构默认可以对4EiB的用户数据进行寻址:我们可以寻址2^(18+18)=2^36个范围;每个范围寻址2^26B,这样,我们可以对2^(36+26)B=2^62B=4EiB的数据进行寻址。但是,如果范围更大,这个容量可能得到进一步扩展。
元范围几乎像常规范围一样处理,且就像集群中KV数据的其他元素一样进行访问和复制。
每个节点缓冲之前访问的meta2范围数值,这会将来对这些数据的访问。无论何时节点发现其缓冲的某个meta2特定键值无效,就会通过该meta2范围的常规读取对该缓冲进行更新。
2)表数据
节点元范围之后是集群存储的KV数据。
每张表及其二级索引最初映射到单个范围,该范围内的每个键值对表示该表(因为该表按照主键排序,因此,也称为主键)或二级索引中的一个数据行。一旦范围达到512MiB,其将拆分为两个范围。当表及其索引持续增长时,该过程也会继续下去。一旦一张表拆分为多个范围,表和二级索引将可能分别存储到单独的范围内。但是,一个范围还是可能包含表和二级索引的数据。
默认的512MiB范围大小对我们来说是一个合适的点,其足够小,以便其在节点间进行快速移动,但又足够大,以便存储一套更可能被一起访问的有意义的连续数据集。这些范围在集群内调动以确保数据在意外事件中的生存性。
这些表的范围被复制(在适当命名的复制层中),并有存储于meta2范围内的每个副本的地址。
2.使用整体排序的映射
当某个节点接收到一个请求时,其将查看元范围并对请求中的键值与meta2范围内的键值进行对比以发现需要将该请求路由到哪个节点。
这些元数据会被大量缓冲,因此,这通常会被本地处理而无需发送RPC到实际包含该meta2范围的节点。
该节点接着将那些KV操作发送到前面meta2范围内识别到的租约持有者。但是,这些数据可能已发生移动,因此,不再存储这些数据的节点将向请求节点返回数据目前的存储位置。这种情况下,我们必须回到meta2范围获取最新信息并进行重试。
3.与其他层的交互
CockroachDB中,分布层与其他层的关系为:
1)从同一节点的事务层接收请求。
2)鉴别哪些节点应该接收该请求,并将该请求发送到相应节点的复制层。

二.技术细节与组件
1.gRPC
gRPC是节点间用于通信的软件。因为分布层是与其他节点通信的第一层,所以,CockroachDB将gRPC实施在该层。
gRPC需要将输入和输出格式化为协议缓冲(protobufs)。为了利用gRPC,CockroachDB实施了定义在api.proto中的基于协议缓冲的API。
有关gRPC更多的信息,可以参考官方gRPC文档。
2.BatchRequest
所有的KV操作请求都被绑定到一个protobuf,称为BatchRequest。这些批处理的目的地通过BatchRequest头部标识,以及指向该请求事务记录的指针。(另一方面,当一个节点响应一个BatchRequest时,其使用一个protobuf--BatchRequest。)
该BatchRequest也被用于在节点间用gRPC发送请求,gRPC接收和发送协议缓冲(protocol buffers)。
3.DistSender
网关/协调节点的DistSender从其自己的TxnCoorSender接收BatchRequests。DistSender接着负责分解BatchRequests并将一套新BatchRequests路由到其通过meta2范围识别出包含这些数据的节点。其使用缓冲将请求发送到相应的租约持有者,但也准备试验其他副本,按照"proximity"顺序。仅将缓冲说是租约持有者的副本移到副本的前面进行试验,接着,按顺序给它们发送一个RPC。
非租约持有者接收的请求失败,并报出指向副本最后已知租约持有者的错误。这些请求通过网关节点更改的租约进行透明重试,且从来不会到达客户端。
当节点开始相应这些命令时,DiskSender也对这些结果进行汇聚并准备将其返回客户端。
4.元范围KV结构
就像集群中所有其他数据一样,元范围作为KV对被构造。元范围有类似结构:
metaX/successorKey -> LeaseholderAddress, [list of other nodes containing data]
其中,元素及描述如下:
1)metaX:元范围的级别。这里,我们使用简化的meta1和meta2,但这些在cockroach中实际分别表示为x02和\x03。
2)successorKey:比您扫描的键值更大的第一个键值。这使得CockroachDB的扫描效率更高;其仅仅扫描键值直到发现一个比要找的键值大的数值,且那是其发现相关数据的位置。
键值空间末端的successorKey被标识为maxKey。
3)LeaseholderAddress:主要负责读写的副本,称为租约持有者。复制层包含有关租约的更多信息。
下面是一个例子:
meta2/M -> node1:26257, node2:26257, node3:26257
这种情况下,节点1上的副本为租约持有者,节点2和节点3也包含副本。
例子:
我们想象有一个按字母顺序排序的列,我们用它来进行查找。这里是元范围近似的样子:
meta1包含meta2副本所在节点的地址。
#指向键值[A-M)的meta2范围
meta1/M -> node1:26257, node2:26257, node3:26257

#指向键值[M-Z]的meta2范围 
meta1/maxKey -> node4:26257, node5:26257, node6:26257
meta2包含集群中每个范围的副本所在节点的地址,其中,第一个为租约持有者。

#包含[A-G)
meta2/G -> node1:26257, node2:26257, node3:26257

#包含[G-M)
meta2/M -> node1:26257, node2:26257, node3:26257

#包含[M-Z)
meta2/Z -> node4:26257, node5:26257, node6:26257

#包含[Z-maxKey)
meta2/maxKey->  node4:26257, node5:26257, node6:26257
5.表数据KV结构
键-值数据,其用下面的结构表示表中的数据:
/

// ->
表本身以主键列上的index_id为1的索引存储,表中其他列被认作存储/覆盖列。
6.范围描述符
CockroachDB中的每个范围包含元数据,称为范围描述符。一个范围描述符包含下列内容:
1)一个连续RangeID
2)该范围包含的键值空间(即,包含的键值);例如:在上述表数据KV结构中的第一个和最后一个<索引列值>。这决定了meta2范围的键值。
3)包含该范围副本节点的地址,及第一个位置的租约持有者(其负责读写)。这决定了meta2范围的键值。
因为范围描述符包含meta2范围的键值数据,所以,每个节点的meta2缓冲也存储范围描述符。
当发生如下事件时,范围描述符被更新:
1)更改范围的Raft组成员(更多细节将在复制层讨论)。
2)租约持有者发生改变。
3)范围拆分。
所有这些对范围描述符的更新发生在本地该范围上,接着,传播到meta2范围。
7.范围拆分
默认地,CockroachDB试图保持范围/副本的大小为512MiB。一旦范围达到该限制,将被拆分成两个更小的范围(由连续的键值空间组成)。
范围拆分期间,节点创建一个新的Raft组,其包含与被拆分的范围的所有相同成员。现在有两个范围的事实也意味着有一个用新键值空间边界更新meta2的事务,也包括用范围描述符的节点的地址。

三.与其他层的技术交互
1.分布和事务层
分布层的DistSender接收来自本身节点TxnCoordSender的BatchRequests,其驻留在事务层。
2.分布和复制层
分布层将BatchRequests路由到包含数据范围的节点,其最终被路由到Raft组领导者或租约持有者,其在复制层被处理。

四.个人观点
1.分布层的作用真的是承上启下,上面接收来自事务层的请求,下面将这些请求分解后再发给复制层进行处理。
1.分布层在每款NewSQL产品中都会存在,虽然叫法可能不同,但类似的功能层应该都是存在的,这是数据分布式存储的基础和关键,所以,也没什么好说的。
 

你可能感兴趣的:(Newsql,cock,roach,cockroach,Distribution,架构)