用TiKV存储时序数据与InfluxDB比照

TiDB是现在当红的NewSQL数据库,在供给高功用读写的一起又兼容传统的RDBMS,其底层的存储是TiKV。这儿咱们看一下假定用TiKV存储时序数据,其底层数据安排方法是怎样样的,与InfluxDB的数据存储方法比较有何优缺点。

时序数据库与传统数据库比照

首要从上层运用的视点比照一下时序数据库与通用型数据库所面临的需求。关于时序数据的细节,数据模型,以及InfluxDB的结束,可以参看自己前面有一篇文章InfluxDB的存储引擎演化进程

  1. 写入/读取操作份额:关于通用的场景,这个份额是比较低的,就算是在高并发的互联网运用中,均匀份额或许不会跨越3:7。可是关于时序数据来说,这个份额很或许会跨越5:5。并且时序数据一旦丢掉,就找不回来了,由于时序数据都是一次性生成的。所以时序数据库对写入功用的要求更高。
  2. 数据删去:时序数据接见会晤临着许多时刻长远、价值低的数据需求铲除,需求删去的数据量大致等于新生成的数据量。传统数据库是不会大规模删去数据的。
  3. 数据更新:TiDB中存在许多的数据更新,比方产品的库存数据、账户余额数据等。可是时序数据都是一次性生成的,不需求更新。并且时序中单点数据是没有意义的,就算过失也没必要修正。关于这个特征,假定将数据依据时刻进行range sharding,就会导致冷热数据相对别离,方便于数据管理。可是也构成在数据写入时会构成抢手,简略构成单点压力。
  4. 数据模型:就现在面临的场景来说,时序数据的模型是相对固定的,首要包括timestamp,tags和fields三个部分,并且序列值可以究竟靠timestamp进行安排。相关于RDBMS,这带来一个优势便是对业务的支撑需求更小。这儿需求业务支撑只需一点:数据写入和删去时同一timestamp对应的各个field要一起。
  5. 数据运算:时序数据的运用更倾向于在时刻轴上进行聚合,或许核算,很少对原始数据直接取出来运用。从这一个视点来说,时序数据库的需求有点倾向OLAP。关于TSDB和OLAP的比照,也有博文进行了胪陈Time series databases vs OLAP。

所以,时序数据库需求供给高吞吐量、高可用性,可是对业务支撑的需求较小。所以是不是可以说时序数据库是OLTP和OLAP各自的部分结合,也算是HTAP?

用TiKV存储时序数据

假定直接用TiKV存储时序数据,底层存储结构是怎样呢?这儿咱们只议论数据在单个TiKV节点的安排方法,暂时先不论分布式架构。

TiKV底层运用的是RocksDB来存储数据,RocksDB是依据LSM Tree,是一个Key-Value存储引擎。TiKV的数据存储原理细节主张参看以下博文,里边做了很具体的描绘,包括底层的组件,以及怎样从传统的RDBMS的数据存储映射到TiKV:

  1. TiKV 是怎样存取数据的(上)
  2. TiKV 是怎样存储数据的(下)

用TiKV存储时序数据与InfluxDB比照

所以,这儿需求供认的便是怎样规划RocksDB中数据条目的key和value。如前文InfluxDB的存储引擎演化进程所说,关于时序数据,需求存储的内容包括timestamp,tags和fields,还需求在tags上做索引,行进经过tags的检索的功率。首要是存储每一个point的数据,每一个point可以究竟靠measurement,所触及的悉数tags,和timestamp来定位,这三个信息的组合等价于MySQL中的primary key,可以仅有供认一个point。存储的value便是point的fields。假定咱们写入的数据是:

Labs,location=SH,host=server1 CUP=73,Mem=16.067 1574179200s
Labs,location=SH,host=server2 CUP=31,Mem=32.087 1574179200s
Labs,location=SZ,host=server1 CUP=11,Mem=8.021 1574179200s
Labs,location=SZ,host=server2 CUP=43,Mem=16.779 1574179200s

在RocksDB里存储的数据条目便是:

# Primary Key, 前缀t标明table, 数据条目
t_Labs_location=SH,host=server1_1574179200s ==> (73, 16.067)
t_Labs_location=SH,host=server2_1574179200s ==> (31, 32.087)
t_Labs_location=SZ,host=server1_1574179200s ==> (11, 8.021)
t_Labs_location=SZ,host=server2_1574179200s ==> (43, 16.779)

经过primary key定位数据分外的简略,直接在RocksDB做查询。

接着,还需求存储依据tags的索引。TiKV中索引的安排结构跟InfluxDB的原理是相同的,也是反向索引。也便是说,给定一组tag nametag value对,记载哪些point与它相关。所以,索引的key既要包括触及到的tag,还要包括对应的point的primary key。而索引条目的value是无关紧要的,只需求判别key是不是真的存在。

# Tags Index, 前缀i标明index, 索引条目
i_location=SH___t_Labs_location=SH,host=server1_1574179200s ==> nil
i_host=server1___t_Labs_location=SH,host=server1_1574179200s ==> nil
i_location=SH___t_Labs_location=SH,host=server2_1574179200s ==> nil
i_host=server2___t_Labs_location=SH,host=server2_1574179200s ==> nil
i_location=SZ___t_Labs_location=SZ,host=server1_1574179200s ==> nil
i_host=server1___t_Labs_location=SZ,host=server1_1574179200s ==> nil
i_location=SZ___t_Labs_location=SZ,host=server2_1574179200s ==> nil
i_host=server2___t_Labs_location=SZ,host=server2_1574179200s ==> nil

当咱们该经过索引查找时,比方location=SH,首要构建key前缀i_location_SH___,找到以这个前缀开端的数据,这样的一个进程在TiKV里边是很高效的,由于它运用了依据key的range sharding。这些查找出来的索引条目的key的后半部分,便是跟给定tag相关的悉数数据条目primary key,然后经过这些primary key来检索对应的数据条目。

可以正常的看到TiKV的索引和数据混合在一起进行存储,但它们的key-value条目是分隔的,所以当把MySQL的innodb表转到TiKV后边应该会占用更大的空间。

与InfluxDB存储的比照

  1. 索引的构建,InfluxDB是运用一个超大的map结束的,这一点我觉得TiKV的构建方法愈加直观简略,也充沛的利用了kay-value存储引擎的优势,特别是适合巨量的tags。
  2. 时序数据惯例操作的功用:

    • 写入:二者差不多。首要会写入数据条目,然后会对每一个触及的tag创立一个索引条目。
    • 读取:时序数据最多的是依据tag和timestamp区间进行检索。在TiDB里边,第一步需求回来悉数的primary key,第二步取出每一个primary key的数据条目。InfluxDB的安排方法是依据entry进行存储,第一步是找到相关的series,这一步回来数据量更少,第二步依据series找出给定timestamp范围内的数据条目,只需求依据少数series轮询在数据库中检索。
    • 铲除:运用TiKV,数据的过期删去战略功率很差,需求遍历悉数数据和索引条目,判别所对应的timestamp是否到期。再三删去会影响到数据写入功用。InfluxDB依据timestamp进行sharding,旧的数据会存储在附近的shard里边,很简略就可以删去。
  3. 存储空间紧缩功率,InfluxDB的同field的内容会按列存储,同一数据类型,有利于紧缩。
  4. 分布式处理方案。由于InfluxDB Cluster是闭源的,而TiDB又开源支撑,所以TiDB胜。

依据上面的比照,关于时序数据的存储,InfluxDB更专业。可是假定需求其分布式处理方案,要么得买,要么得自己结束处理。