作者:乔峰
1. 背景
时间序列数据出现在越来越多的场景,监控和运维,传感器数据和物联网,金融数据,物流数据,应用程序使用数据等等。通常这些数据有着体积大,复杂性高的特性(如:多个测量量和标签关联一个时间点 )。这就意味着,存储时间序列数据满足规模和复杂查询两方面的要求。然而,很难同时实现这两个属性。用户通常面临着水平可伸缩的NoSQL数据库与拥有强大查询能力的关系型数据库之间的权衡。
TSDB是一个时序数据库,被设计使时序数据SQL可扩展。在一个通常被分为RDBMS和NoSQL数据库的世界里,Fastdata for TSDB提供了第三种选择,结合了两者优点:一个集群扩展架构和对复杂查询的支持。通过透明的自动执行时空分区和查询优化,TSDB支持高提取率的水平扩展,同时允许用户和数据互动,就好像这些数据在一个单独且连续的表中。通过执行高效的索引和优化来选择和聚合非主键,它支持快速查询。数据可以实时查询,避免了批量加载数据的写入延时。此外,因为TSDB是基于PostgreSQL开发,它提供了完整的SQL接口(包括对二级索引和连接的支持),同时继承了PostgreSQL的可靠性,成熟的生态系统和操作易用性。随着数据被测量,时间变成了一个更重要的维度。TSDB允许开发人员和组织利用时间的力量:分析过去,认识现在和预测未来。在查询水平统一时序数据和关系数据可以排除数据仓库,使延时和原型更容易取得进展。可扩展性和完整的SQL接口的结合使得一个组织里各种各样的人员直接向数据提问。换句话说,通过支持已经广泛使用的查询语言,TSDB确保了你的问题只受限于你的想象力,而不是数据库。
关键的挑战:时序数据库的一个中心目标就是支持 高写入率,许多这样的典型应用都是跨行业的。例如:在物联网场景中,不管是工业、农业、城市还是消费者领域,由于有大量的设备,再加上每个设备适度的高写入率,造成的整体的高写入率。在物流场景中,计划数据和真实数据都包含了可以和每个追踪对象有关的时间序列。应用监视场景下,如:DevOps,会追踪每个系统组件的许多指标。
在多种形式的金融应用中,例如那些基于标记的数据,也依赖于时间序列数据。所有这些都需要一个高容纳率的扩展。此外,除了简单地获取或聚合一个特定时期的单个指标,这些应用程序通常还要使用复杂和任意的方式查询数据。这样的查询模式可能包含丰富的谓语(如:WHERE字句中复杂的连词)、聚合、统计、窗口操作、连接等依赖于关系数据的操作。相比与创建一门新的查询语言(这需要开发人员和分析师提供新的培训,以及新的客户接口或者连接器用来和其他系统整合,一个理想的时序数据库应该支持标准的SQL,并且暴露一个全局的抽象表,即使底层存储可能被分区或分片在多个服务器或磁盘之间),这样的设计允许人们操作数据,就好像数据存在于一个标准的表中,隐藏了数据分区和用户查询优化的复杂性。
我们如何扩展SQL?乍一看,水平扩展且高效的SQL数据库的说法似乎值得怀疑;毕竟整个NoSQL运动有没有摆脱SQL数据库的局限性?这一运动应对SQL数据库在传统事务性的工作负载上的使用。在联机事务处理(OLTP)中,一般的事务更新会涉及多行已存在的数据,如从一个银行账户借钱的同时向另一个授信,以一种原子的方式;在两个关键的方面,时序的工作负载是不同的。
(1)时序数据是不可变的。新数据的不断到来,通常对应着新的时间周期。换句好说,写操作的发生伴随着新的插入,而不是更新已存在的行。 此外,数据库需要同时支持回填延时数据,写操作主要有最近的时间间隔产生。
(2)工作负载本质的区分时间和空间。写操作通常产生在最近的时间间隔,穿过空间维度的“分区键”(如:数据来源,设备,用户等等)。查询通常是一个指定时间序列或数据来源或许多数据源在一定时间间隔内的问题。然而查询可能不嫌疑一个特定的指标,但是可能定期的一次选择多个指标(或在多个指标上使用谓词)。这样的工作打开了数据库架构可能性新的空间,这正是TSDB的优势所在。值得注意的是,不仅是这些不同于传统联机事务处理工作的特性,也包括联机分析处理(OLAP)聚焦于读的负荷和单个指标的汇总和聚合。
2. 现有方案的局限性
现有方案需要使用者在可扩展性和丰富的查询支持之间选择。常见的的RDBMS(如:PostgreSQL、MySQL)。传统SQL数据库在处理高容量数据时有两个关键问题,对大量表格的写操作性能太差,这个问题会随着时间的推移,数据体积的线性增长而变得更加糟糕。表索引无法装入内容时,这些问题就会出现,每个插入将会转换为许多磁盘读写用来交换B-Tree索引的部分。此外,删除任何数据(为了节省空间或实现数据保留策略)都将需要昂贵的vacuuming(清理)操作以整理和这些表相关的磁盘存储。此外,依然缺少扩展RDBMS的开箱即用的解决方案。
NoSQL和时序数据库。作为回应,开发人员