Skip to content

zhou-jered/RapidTSDB

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Apr 9, 2023
712c27f · Apr 9, 2023
Mar 4, 2022
Aug 13, 2022
Jul 15, 2021
Dec 25, 2021
Apr 9, 2023
Dec 23, 2021
Mar 27, 2022
Mar 27, 2022
Apr 9, 2023
Apr 9, 2023
Sep 9, 2020
Dec 19, 2021
Dec 26, 2021
Mar 6, 2022
Dec 19, 2021
Jul 22, 2021
Mar 4, 2022

Repository files navigation

简介

English Version: English Version

一个时序数据库,提供非常快速的时序数据插入和查询,同时提供丰富的数据聚合功能。 实现了论文 Gorilla: A Fast, Scalable, In-Memory Time Series DataBase

这个项目的目的是提供可以快速部署使用,适合从小规模部署到大规模集群的任意规模数据库的功能,高度灵活而且可自定义的的持久化实现功能。

什么是时序数据

顾名思义,时序数据就是时间序列数据,是按时间顺序记录的数据列。在物联网领域和监控领域有着广泛的应用。 例如某台服务器的cpu占用率,内存使用量,某个温度的温度监控数据。这些数据会随着时间的不同而输出不同的数据。

特点

  • 内存存储数据,读写非常高效快速。
  • 惊人的高压缩率的数据压缩,相比传统数据库,可节省20倍以上存储空间。
  • 稳定的,失败恢复机制
  • 灵活的自定义持久化存储
  • openTSDB http 接口兼容
  • 高效的 rpc 通信协议

RapidTSDB 的数据模型

某一个主体产出的数据称为一列数据,比如内存的使用率,memory.rate。 为了区分是哪台服务器的内存使用率,我们会给这列数据打上标签(Tag)。 这里的 memory.rate 我们叫做 metric。 同一个 metric 下面,不同Tag 下的数据是不同的列数据。 Metric 和 Tag 同时定义了一列数据。比如 memory.rate(host=192.168.0.1)。 某个时刻下数据称为数据点(DataPoint),一个数据点由时间戳(Timestamp)和值(Value)组成。

写入数据的时候,需要提供 metric name,tag 列表,时间戳和值。共四个参数。 读取数据的时候,需要提供 metric name,可选的 Tag 列表,开始时间和结束时间,如果没有提供 Tag 列表,或者 Tag 列表不能完整的覆盖 同一个 metric 下的所有 Tag 名称,服务器将会对所有的时间序列做横向聚合计算后返回,所以读取数据的时候,需要提供聚合函数(Aggregator)的名称。 可用的聚合函数名称在文档的后半部分提供。 由于监控数据写入精度通常较高,在需要查看跨度较大的时间数据(比如一天)的时间,服务器返回的时间点就会非常多,此时可以对数据进行降精度(down sample) 处理,比如将返回的数据由一秒一个数据点,降低精度到1分钟一个数据点,此时可以将数据量降低到原来的 60分之一。极大的节省传输量和提高查看效率。 降精度由时间区间和聚合函数组成,中间用字符 - 相连,比如 1m-sum 表示将一分钟以内的时间求和到一个时间点上。完整的降精度支持函数在文档的后半部分给出。 所以读取数据的时候,需要 metric name,Tag List(可选), startTimestamp,endTimestamp,Aggregator,downSampler(可选)

比较重要的内部数据模型

在数据库内部,每一列的数据点按照2个小时的长度被存储在一起,称为 Block。也就是说,一个 Block 存储了2个小时以内的数据点。 在正常的使用情况下,服务器会维护为每一列数据维护当前时间内(2小时)的Block,但是如果写入的数据点的时间戳不在当前的时间窗口, 服务器就会打开一个 Dirty Block,然后写入数据,Dirty block 也会保留在内存中,如果时间点非常的混乱,内存中驻留的Block就会非常多, 占用大量的内存,所以服务器提供了配置项 maxMemoryDirtyBlock 用来配置最大驻留内存的 Dirty Block 数量,当 Dirty Block 超出这一数量的时候, Dirty Block 会被持久化到外部存储以释放内存空间。

RapidTSDB 服务接口

RapidTSDB 提供了多个协议的服务接口,包括兼容 openTSDB 的 http 接口; Console 命令行服务接口,二进制的 Rpc 接口,方便在多种场合下的接入和使用。 不同的服务配置不同的监听端口即可。

数据的持久化

由于服务器内存并不能存下所有的数据,所以需要将数据持久化存储到外部,可以是文件,也可以是其他的第三方存储。 RapidTSDB 提供了存储插件,用户可以通过插件的方式来实现自定义的持久化存储方案。

数据的安全性

按照论文中描述,每条数据写入的时候,会同时写入一份日志文件,这个日志文件每 64K 刷新到磁盘一次,所以在非常极端的情况下,你会损失最多 64K 的数据。

部署模式

单机部署

在作者开发这一软件的时候,目标之一就是让降低小规模团队的使用成本,在数据量不大的场景下,不需要复杂的部署也能享受到高性能的时序数据服务。 所以开发两种部署模式,在数据量不大的情况下(metric 数量小于十万条),可以选择单机部署模式,并且将数据持久化到文件存储。这样无需额外的支持即可获得同样高性能的时序数据服务。

集群模式

如果数据量较大,可以选择集群部署模式,数据的持久化也可以选择功能更加强大的分布式存储,比如Hbase,Hadoop 或者其他地方。

扩展插件

系统扩展通过插件的形式来实现,目前提供了以下几个功能

  • 连接认证扩展插件,用以实现你自己的连接认证和权限管理功能
  • 文件存储扩展插件。 在系统内部会有一些需要持久化到文件的内部数据,用户可以自定义文件存储插件,可以将这部分数据存储到用户希望的文件系统中去。
  • 数据持久存储扩展。 存储系统的数据存储扩展,系统默认提供了文件,Hbase,HDFS 的实现,如果你想将数据存储到其他地方,也可以实现该插件。

注意,插件使用单例模式运行,扩展的自定义插件需要管理内部状态和线程安全

Thanks

openTSDB