时序数据库是近两年的热门话题，不断有新的时序数据库产品发布，但在我个人看来，目前还没有看到一个系统的、全面的时序数据库评测方案，帮助开发者认识各个产品的异同，为特定场景选择最适合的产品，各个数据库厂商基于自身优势和特点，设计发挥其产品最佳性能的场景，展示一份份傲人的性能测试报告。本篇博客就结合本人的一些看法，从不同维度来分析时序数据库产品的异同，同时也希望有更多的人关注时序数据库，在各自的行业应用需求上为时序数据库厂商建言献策，共同推动时序数据库的发展。由于个人能力有限，难免有不妥之处，还望大家提出宝贵意见，多多批评指正。
首先对本文提到的一些名词做相应的解释：
对象：本文所述对象是能够持续产生数据的实体，也是时序数据库数据建模的对象，例如：传感器、电梯、自行车等。
时间线：为了将同一个对象在不同时间点产生的数据组织在一起而提出的数据管理单元。各个时序数据库对时间线有不同的称呼，例如：松果时序数据库的“设备”、influxDB的“Measurement和Tags的组合”、TDEngine的“子表”以及实时数据库的“测点”。实际上他们表达的是同一个概念，命名不同而已。
其次通过以下几个维度来浅析时序数据库评测和选型：
（1）支持时间线的数量
时序数据库能够支持时间线的数量？每个时间线需要消耗的资源？
（2）对象是否确定？
场景一：公交公司将公交车运行的位置、营运状态等信息写入时序数据库。此时对象是公交车，对象是确定的，不会爆发式增长。
场景二：互联网公司将用户的访问记录写入时序数据库。如果将用户作为对象，此时对象是不确定的，可能爆发式增长，也有可能某用户访问后就不再访问。
对象是否确定这项指标在实际场景中影响非常大，应重点考量、对比各个时序数据库的差异，选择最适合实际场景的产品。
（3）数据产生的频率
场景一：智能电表每15分钟产生一条数据，900万个智能电表平均每秒产生一万条数据。
场景二：某智能设备（欢迎补充）每秒钟产生一千条数据，10个设备合计每秒产生一万条数据。
上述两个场景每秒都产生一万条数据，因此在选择数据库时应充分考虑数据产生的频率并做相应的测试以满足需求。
（4）不要把沙子装在金库里
不同的时序数据的价值密度差异巨大，例如：股票产生的时序数据和环境监测产生的时序数据价值密度相差巨大。他们对数据安全性和分析处理有着截然不同的要求。没有人愿意为处理环境监测的数据支付金融级解决方案的成本。因此需要针对不同的场景选择适宜的时序数据库产品。
（5）分析性功能
时序数据库是否支持复杂查询（排序、聚合、子查询、多表连接等），典型的代表是TimescaleDB，他基于PostgreSQL实现能够支持各种复杂的SQL查询，另外一些时序数据库不支持或支持受限的复杂查询。并不是支持复杂查询就比不支持好！例如：在关系库中时常发生由于一个复杂的SQL导致数据库服务hang住了。在时序数据库中亦是如此，很多时序数据库系统每天都会写入几亿条、几十亿条甚至更多的数据，对上亿条的数据进行排序、聚合是一个灾难，松果时序数据库不支持复杂查询，因而能够轻易做到只要数据库支持的查询都不会因为某一个任务占用过多的内存或磁盘资源导致其他的任务无法执行或执行失败，也不会出现任何死锁的情况，其稳定性强于支持复杂查询的时序数据库。不支持分析性功能的时序数据库可以引入额外的计算服务来达到复杂计算的功能，但是对比能支持复杂查询的数据库来讲更麻烦、灵活性更低。因此，是否选择支持分析性功能的产品需要根据实际情况权衡。
（6）单机&分布式
单机和分布式产品的对比：
|
单机时序数据库 |
分布式时序数据库 |
|
|
产品实现难度 |
简单 |
复杂 |
|
实施难度 |
简单 |
复杂 |
|
运维难度 |
简单 |
复杂 |
|
问题排查 |
简单 |
复杂 |
|
大规模扩容 |
难 |
简单 |
|
管理的时间线 |
少 |
多 |
从产品实现难度、实施难度、运维难度和问题排查来看，单机时序数据库比分布式时序数据库简单很多，也即一个单机数据库产品更容易研发并发布稳定版本、更易于维护。实际应用中应该以解决业务问题为导向，结合场景特点，预留一定的扩容需求，不应盲目选择分布式时序数据库。若一个业务场景不需要考虑大规模扩容的情况下，应当优先考虑单机时序数据库产品。
（7）对实时数据库的看法
业内存在些许实时数据库难以使用、价格昂贵的观点，萌发使用时序数据库替代实时数据库的想法，我个人认为：在某些应用场景中（欢迎大家补充），会因实时性无法得到保障而埋下隐患。另外，趁着时序数据库的热度，一些实时数据库厂商也发布了时序数据库的产品，虽然国内的实时数据库产品做得非常好了，但在一些核心指标上（如稳定性，欢迎大家补充）与国外一流产品存在一定的差距。实时数据库和时序数据库虽然在数据模型和使用上有一些相似性，实际上他们解决的是不同的问题，实时数据库厂商应更多的聚焦在如何超越PI等国外先进产品上。
最后，任何一个产品都有其适用性和局限性，完善时序数据库的评价体系才能客观、公正的对比各个产品的优势和特点及其适用场景，让时序数据库厂商充分发挥自身优势定位产品方向，研发出针对特定场景最适合的时序数据库产品，为客户提供更好的服务，这符合时序数据库厂商和客户的利益诉求。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/186098.html原文链接：https://javaforall.net
![One Piece1-541(ed2k)[通俗易懂]](https://javaforall.net/wp-content/uploads/2020/11/2020110817443450-480x300.jpg)
