浅谈时序数据库TDengine

浅谈时序数据库TDengine

近TDengine很火，本人也一直很早就有关注，其官方给出的测试性能结果很喜人，所以一开源，本人就进行了相关调研，终发现还是存在着一定的问题，期待后续的完善吧

写入问题

必须为每个Tag组合起一个表名

付出的代价：

• 用户必须要保证每个Tag组合起的表名，并且一旦Tag组合数过多用户很难记住每个Tag组合对应的表名，在查询时基本都是靠超级表STable来查询。所以对用户来说这个表名几乎没用到却让用户来花代价来起名

这样设计的终目的是为了将相同Tag组合的数据放到一起，但是系统设计时完全可以自己内部针对这个Tag组合记录一个id或者字符串来作为内部隐藏的表名，来替换让用户自己起表名的操作，对用户只需要呈现一个超级表STable即可，减轻用户负担。

其实可以看到上述其实是将系统内部判断的负担转交给用户，麻烦了用户。假如系统内部自动判断Tag组合是否，则在数据写入过程中一直需要判断当前Tag组合是否存在以及查找对应的底层id或者字符串，而让用户起表名则省去了上述代价，因为用户起的表名就是一个的字符串，所以写入性能自然好一些

Tag支撑与管理

• 多支持6个Tag，如果想要支持更多就要重新源码编译
• 超级表STable对Tag组合的索引是全内存的，终将会遇到瓶颈的，InfluxDB已经走过这条路了，从之前的全内存到后面的tsi
• 超级表STable对Tag组合的索引仅仅是对个Tag作为key来构建一个skiplist,也就是说当你的查询用到个tag时可以利用下上述索引，当你的查询没用到个tag时，那就是暴力全扫，所以这种在Tag组合数过多的时候过滤查询能力还是很有限的。而像其他时序数据库InfluxDB、Druid都在写入过程中针对Tag组合构建了倒排索引来应对任意维度的过滤，写入性能比TDengine自然就会差一些
• 对于不再使用的Tag组合的过期目前也是个麻烦的事情

不支持乱序写入

• 每张表会记录该表目前写入的大时间，一旦后续的写入时间小于该时间则不允许写入。假如你不小心向某张表写入2021-07-24 00:00:00时间的数据，那么该时间之前的数据都无法写入了

这样做带来的好处，简化了写入过程，写入过程永远是append操作。举个简单例子，比如用数组来存放内存数据，数组中的数据是按时间排序的，如果后来的数据的时间不是递增，那么就需要将数据插入到数组中间的某个位置，并且需要将该位置之后的数据全部后移。假如后来的数据的时间都是递增的，那么直接往数组的后面放即可，所以不支持乱序写入即以牺牲用户使用为代价来简化写入过程提高写入性能

不支持乱序写入还省去的一个麻烦就是：LSM中常见的compact。如果允许乱序写入，那么就会存在2个文件中时间范围是有重叠的，那么就需要像RocksDB那样来进行compact来消灭重叠，进而减少查询时要查询的文件个数，所以你就会发现HBase、RocksDB、InfluxDB等等辛辛苦苦设计的compact在TDengine中基本不存在

总结一下就是：不支持乱序写入是以牺牲用户的使用为代价来提高写入性能以及简化设计

查询问题

求topN的group

• order by只能对时间、以及tag进行排序。top或者bottom只能对某个field求topN

时序领域非常常见的topN的group，比如求CPU利用率大的3台机器，目前也无法满足

downsampling和aggregation

• downsampling:将同一根时间线上1s粒度的数据聚合成10s粒度的数据
• aggregation:将同一时刻多根时间线聚合成1根时间线

比如每个appId有多台机器，每台机器每秒都会记录该机器的连接数，目前想画出每个appId的总连接数的曲线

假如使用标准SQL则可能表示如下：

select sum(avg_host_conn),appid,new_time from (
        select avg(connection) as avg_host_conn,
                appid,host,time/10 as new_time 
        from t1 group by appid,host,time/10
) as t2 group by appid, new_time