时序数据库是近两年的热门话题,不断有新的时序数据库产品发布,但在我个人看来,目前还没有看到一个系统的、全面的时序数据库评测方案,帮助开发者认识各个产品的异同,为特定场景选择最适合的产品,各个数据库厂商基于自身优势和特点,设计发挥其产品最佳性能的场景,展示一份份傲人的性能测试报告。本篇博客就结合本人的一些看法,从不同维度来分析时序数据库产品的异同,同时也希望有更多的人关注时序数据库,在各自的行业应用需求上为时序数据库厂商建言献策,共同推动时序数据库的发展。由于个人能力有限,难免有不妥之处,还望大家提出宝贵意见,多多批评指正。
首先对本文提到的一些名词做相应的解释:
对象:本文所述对象是能够持续产生数据的实体,也是时序数据库数据建模的对象,例如:传感器、电梯、自行车等。
时间线:为了将同一个对象在不同时间点产生的数据组织在一起而提出的数据管理单元。各个时序数据库对时间线有不同的称呼,例如:松果时序数据库的“设备”、influxDB的“Measurement和Tags的组合”、TDEngine的“子表”以及实时数据库的“测点”。实际上他们表达的是同一个概念,命名不同而已。
其次通过以下几个维度来浅析时序数据库评测和选型:
(1)支持时间线的数量
时序数据库能够支持时间线的数量?每个时间线需要消耗的资源?
(2)对象是否确定?
场景一:公交公司将公交车运行的位置、营运状态等信息写入时序数据库。此时对象是公交车,对象是确定的,不会爆发式增长。
场景二:互联网公司将用户的访问记录写入时序数据库。如果将用户作为对象,此时对象是不确定的,可能爆发式增长,也有可能某用户访问后就不再访问。
对象是否确定这项指标在实际场景中影响非常大,应重点考量、对比各个时序数据库的差异,选择最适合实际场景的产品。
(3)数据产生的频率
场景一:智能电表每15分钟产生一条数据,900万个智能电表平均每秒产生一万条数据。
场景二