浅谈时序数据库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
内部的子查询会先将每个appid的host 10s内的connection求平均值，即downsampling，外部的查询将每个appid下的host的上述平均值求和，即aggregation
由于这类需求在时序查询中太常见了，使用上述SQL书写非常麻烦，有些系统就通过函数嵌套的方式来简化这类查询的书写
目前TDengine的聚合函数要么只能是downsampling要么只能是aggregation，也不支持子查询，那么是无法满足上述需求的
查询聚合架构
查询分2阶段：第一阶段请求管理节点，获取符合tag过滤的所有表的meta信息(包含每个表在哪个数据节点上)，假如满足条件的表有上百万个，这这个阶段的查询基本也吃不消，第二阶段向数据节点查询聚合每个表的数据，返回给客户端，客户端再做最终的聚合。
这种查询方案终究还是会面临客户端聚合瓶颈的，还是要上多机协调的分布式查询方案比如类似Presto、Impala等等