IT序号网

时序数据库入门

wyy 2021年06月14日 数据库 294 0

数据库的模型包含关系型、key-value 型、Document 型等很多种,那么为什么新型的时序数据库成为监控数据存储的新宠呢? 下面就会从

  • 为什么需要时序数据库?
  • 时序数据库的数据结构

两个方面来介绍一下时序数据库。

1. 为什么需要时序数据库

1.1 时序数据特点

时序数据有如下几个特点:

  • 基本上是插入操作较多且无更新的需求
  • 数据带有时间属性,且数据量随着时间递增
  • 插入数据多,每秒钟插入需要可到达千万甚至是上亿的数据量
  • 查询、聚合等操作主要针对近期插入的数据
  • 时序数据能够还原数据的变化状态
  • 可以通过分析过去时序数据的变化、检测现在的变化,以达到预测未来如何变化的目的

时序数据使用需求:

  • 能够按照指标筛选数据
  • 能够按照区间、时间范围、统计信息聚合展示数据

1.2 why

为什么不用一个「常规」 的数据库?

  • 事实上,你完全可以可以使用非时序序列的数据库,并且也确实有人是这样做的。
    在这里插入图片描述

        **注**: 数据源 Percona,2017 年 2 月. <https://www.percona.com/blog/2017/02/10/percona-blog-poll-database-engine-using-store-time-series-data/> 
    
         
          

为什么需要时序数据库?

  • 规模

    时间数据的特点是累计速度非常快,常规数据库在设计之初,并非是为了处理这种规模的数据,而且关系型数据库在处理大规模的数据集的效果非常差。

  • 使用特性

    时序数据库能够提供一些通用的对时间序列数据分析的功能和操作,比如数据保留策略、连续查询、灵活的时间聚合,此外时序数据库以时间为维度,也提供更快的大规模查询、更好的数据压缩等。

1.3 场景选择

是否所有的数据都适合用时序数据库来存储?

答案:是否定的,时序数据库提供了针对大量数据的插入操作,但同时数据的读取延迟也相对增加。而且时序数据库不支持 SQL 的数据查询。

主要适用时序数据库的场景

  • 监控软件系统: 虚拟机、容器、服务、应用

  • 监控物理系统: 水文监控、工厂的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等

  • 资产跟踪应用: 汽车、卡车、物理容器、运货托盘

  • 金融交易系统: 传统证券、新兴的加密数字货币

  • 事件应用程序: 跟踪用户、客户的交互数据

  • 商业智能工具: 跟踪关键指标和业务的总体健康情况

2. 时序数据库的数据结构

传统数据库存储采用的都是 B+ tree,原因是查询和顺序插入时有利于减少寻道次数的。然而对于 90% 以上场景都是写入的时序数据库,使用了 LSM tree 更合适。

2.1 LSM产生背景

LSM (Log Structured Merge Trees) 通过减少随机的本地更新操作来达到更好的写操作的吞吐量。

影响写操作吞吐量的主要原因还是磁盘的随机操作慢,顺序读写快,解决办法是将文件的随机存储改为顺序存储,因为完全是顺序的,提升写操作性能,比如日志文件就是顺序写入。

写数据的问题解决了,那如何快速的读出数据呢?

顺序写入的日志文件,在读取一些数据的时候需要全文扫描,但这一操作耗时取决于需要读取的数据在日志文件中的位置,所以其使用场景有限,适用于数据被整体的访问的情况下,像大部分数据的 WAL。

对于读操作,可以记录更多的内容比如 key、range 来提高性能,比较常用的方法有:

  • 二分查找:将文件数据有序保存,使用二分查找来完成特定 key 的查找。
  • 哈希:用哈希将数据分为不同的 bucket。
  • B+ 树:使用 B+ 树,减少外部文件的存取。

以上的方案都是将数据按照特定的方式存储,对于读操作友好,但写操作的性能必然下降,主要原因是这种存储数据产生的是磁盘的随机读写,不适用于时序数据库 90% 都是写入的场景。

2.2 LSM 算法

LSM 是将之前使用的一个大的查找结构(造成随机读写,影响写性能的结构,比如 B+ 树),变换为将写操作顺序的保存到有序文件中,且每个文件只保存短时间内的改动。文件是有序的,所以读取的时候,查找会非常快 。且文件不可修改,新的更新操作只会写入到新的文件中。读操作检查有序的文件。然后周期性的合并文件来减少文件的个数。
在这里插入图片描述

  • 写入操作

    数据先在内存中缓存(memtable) 中,memtable 使用树的结构来保持 key 是有序的,同时使用 WAL 的方式备份数据到磁盘。当 memtable 中数据达到一定规模后会刷新数据到磁盘生成文件。

  • 更新写入操作

    文件不允许被编辑,所以新的内容或修改只是简单的生成新的文件。当越多的数据存储到系统中,就会有越多的不可修改、顺序的有序文件被创建。但比较旧的文件不会被更新,重复的激流只会通过创建新的记录来达到覆盖的目的,但这这就产生了冗余的数据。

    系统会周期性的执行合并的操作,合并操作用于移除重复的更新或者删除记录,同时还能够减少文件个数的增加,保证读操作的性能。

  • 读取操作

    查询的时候首先检查内存数据(memtable),如果没有找到这个 key,就会逆序的一个个的检查磁盘上的文件,但读操作耗时会随着磁盘上文件个数的增加而增加。(O(K log N), K为文件个数, N 为文件平均大小)。可以使用如下策略减少耗时

    • 将文件按照 LRU 缓存到内存中
    • 周期性的合并文件,减少文件的个数
    • 使用布隆过滤器避免大量的读文件操作(如果bloom说一个key不存在,就一定不存在,而当bloom说一个文件存在是,可能是不存在的,只是通过概率来保证)

2.3 时序数据库的存储

  • 单机上的存储
    在这里插入图片描述

    核心就是通过内存写和后序磁盘的顺序写入获取更高的写入性能,避免随机写入,但同时也牺牲了读取性能

  • 分布式存储

    分布式存储需要考虑如何将数据分布到多台机器上面,即分片(sharding)的问题。分片问题包括分片方法的选择和分片的设计问题。

    分片方法

    • 哈希分片: 均衡性较好,但集群不易扩展
    • 执行哈希:均衡性好,集群扩展易,但实现复杂
    • 范围划分:复杂度在于合并和分裂,全局有序

    分片设计

    分片的会直接影响到写入的性能,结合时序数据库的特点,根据 metric + tags 分片是比较好的方式,查询大都是按照一个时间范围进行的,这样形同的 metric + tags 数据会被分配到一台机器上连续存放,顺序的磁盘读取是很快的。

    在时间范围很长的情况下,可以根据时间访问再进行分段,分别存储到不同的机器上,这样大范围的数据就可以支持并发查询,优化查询速度

    如下图,第一行和第三行都是同样的tag(sensor=95D8-7913;city=上海),所以分配到同样的分片,而第五行虽然也是同样的tag,但是根据时间范围再分段,被分到了不同的分片。第二、四、六行属于同样的tag(sensor=F3CC-20F3;city=北京)也是一样的道理。
    在这里插入图片描述

计划后面写一篇 关于InfluxDB 的文章,上文的大部分内容是 google + 个人理解,如果发现哪里有误,欢迎指出。

3. 参考资料

原文地址:https://blog.csdn.net/phantom_111/article/details/88920956

评论关闭
IT序号网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!