分布式时序数据库QTSDB的设计

xdb架构层次***是database，database下边根据数据保留时长不同分成了不同的retension policy，形成了database下面的多个存储容器，因为时序数据库与时间维度关联，所以将相同保留时长的内容存放到一起，便于到期删除。除此之外，在retension policy之下，将retension policy的保留时长继续细分，每个时间段的数据存储在一个shard group中，这样当某个分段的shard group到期之后，会将其整个删掉，避免从存储引擎内部抠出部分数据。例如，在database之下的数据，可能是30天保留时长，可能是7天保留时长，他们将存放在不同的retension policy之下。假设将7天的数据继续按1天进行划分，就将他们分别存放到7个shard group中，当第8天的数据生成时，会新建一个shard group写入，并将第 1天的shard group整个删除。

到此为止，同一个retension policy下，发来的当下时序数据只会落在当下的时间段，也就是只有***的shard group有数据写入，为了提高并发量，一个shard group又分成了多个shard，这些shard全局唯一，分布于所有物理节点上，每个shard对应一个tsm存储引擎，负责存储数据。

在请求访问数据时，通过请求的信息可以锁定某个database和retension policy，然后根据请求中的时间段信息，锁定某个(些)shard group。对于写入的情况，每条写入的数据都对应一个serieskey(这个概念后面会介绍)，通过对serieskey进行哈希取模就能锁定一个shard，进行写入。而shard是有副本的，在写入的时候会采用无主多写的策略同时写入到每个副本中。查询时，由于查询请求中没有serieskey的信息，所以只能将shard group内的shard都查询一遍，针对一个shard，会在其副本中选择一个可用的物理节点进行访问。

那么一个shard group要有多少shard呢，为了达到***并发量，又不过分干扰数据整体的有序性，在物理节点数和副本数确定后，一个shard group内的shard数量是机器数除以副本数，保障了当下的数据可以均匀写入到所有的物理节点之上，也不至于因为shard过多影响查询效率。例如，图上data集群有6个物理节点，用户指定双副本，那个部分：proxy、meta集群、data集群。proxy负责接收请求，无状态，其前可接lvs支持水平扩展。meta集群保存上面提到的逻辑存储层次及其与物理节点的对应关系，通过raft协议保障元数据的强一致，这里meta信息保存在内存中，日志和快照会持久化到磁盘。data集群是真正的数据存储节点，数据以shard为单位存储于其上，每个shard都对应一个tsm存储引擎。

请求到来的时候，经过lvs锁定一台proxy，proxy先根据database、retension policy和时间段到meta集群查找meta信息，最终得到一个shard到物理节点的映射，然后将这个映射关系转换为物理节点到shard的映射返回给proxy，***根据这个映射

（编辑：葫芦岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!