时序数据库之influxdb和倒排索引以及LSM-TREE

一、时序数据库的特点

1、时序数据库用作打点,用来做监控使用,属于写多读少 的场景,而且由于时间不可逆,几乎不可能出现更新 的操作。而且监控数据一般只会查询最近几分钟数据,冷热数据查询频率 非常明显。因此非常贴合ES LSM-TREE这种准实时的特点。

2、ES和LSM-TREE 写入的时候,都是顺序写入,相比于mysql B+树因为需要维持全局有序,随机写。效率有很大提升。

3、而且ES和LSM-TREE都是批量写入,都会先在内存攒一批数据(ES是段写满,或者达到兜底时间。LSM-TREE是内存里memoryTable写满后)落入磁盘。写入效率相比于mysql高很多。

4、LSM-TREE分层SSTable(类似多级缓存),刚写入的数据在上层,历史数据经过SSTable合并后会落入下一层级(查询难度加大)。也非常适合时序数据库这种冷热明显的场景

5、但是由于LSM-TREE顺序写入,SSTable内部局部有序,因此对于查询功能不如mysql(B+树全局有序)。

6、但是LSM-TREE为了加快查询效率,每个SSTable有一个布隆过滤器,能够快速发现数据在不在此SSTable。最坏的情况,需要把所有SSTable的filter都判断一遍。

7、正是因为LAM-TREE局部有序。对于范围查询支持的不好。需要遍历所有SSTable查看范围,(SSTable内部可以二分查找)。最终多个SSTable查询结果进行合并

因此市面上的时序数据库通常都是采用LSM-TREE或其变种

二、influxdb的原理 以及与LSM-TREE的结合

1、概念

database ------> 数据库

measurment -----> 表

tag -----> 索引

field -----> 数据内容

series -----> 是存储数据的基本单位。measurment,tag完全相同,只有时间戳不同的数据会存到同一个series(方便对于某种特定数据进行时间范围查询)。相对的influxdb对于 tag数据内容多变的查询 支持的不好。

以序列的方式管理数据是时序数据库和传统关系型数据库最不同的地方。

2、双索引设计 与高效查询思路(tag集合形成一个索引 时间戳是一个索引)

influxdb 查询先根据tag索引 查找到 某一条序列, 再根据时间索引进行 LSM-TREE查询

tag索引 是倒排索引 先根据倒排索引 查找序列(定位某一个LSM-TREE)

再根据时间 进行LSM-TREE查询

3、时序(序列)数据库致命问题:时间线膨胀

如果同一个measurment的tag集合变化太多,(tag1=x1,tag2=y1),(tag1=x2,tag2=y2)...等等。

就会造成序列太多,时序数据库的写入和读取性能通常都会有明显的下降。

因为序列太多,每次写数据,首先需要LSM-TREE查询写入哪条序列,SSTable局部有序,最坏情况需要遍历所有SSTable

相关推荐
先吃饱再说4 小时前
存储的进化:从 MySQL 到浏览器缓存,数据到底住在哪?
数据库
Nturmoils4 小时前
字段太多看不全,ksql 的展开模式和输出控制怎么用
数据库·后端
Databend6 小时前
Agent 轨迹分析与归因的数据工程实践
大数据·数据库·agent
这个DBA有点耶6 小时前
SQL改写进阶:标量子查询的“隐形代价”与消除实战
数据库·mysql·架构
smallyoung8 小时前
数据库乐观锁深度解析:MySQL、PostgreSQL 实战 + Spring Boot 集成指南
数据库·mysql·postgresql
parade岁月8 小时前
MySQL JOIN解析:朴实无华但食之有味
数据库·后端
用户3169353811838 小时前
MySQL服务无法启动问题解决全记录
数据库
vivo互联网技术12 小时前
从 10 分钟到 1 秒:ES 深度分页任意跳页的三轮优化实战
服务器·数据库·redis·elasticsearch·深度分页
倔强的石头_1 天前
《Kingbase护城河》——猎捕慢查询:执行计划的微观解析与索引调优实战
数据库
SelectDB1 天前
Apache Doris Python UDF:让 SQL 直接调用 Python 生态,支撑 Agent 时代复杂业务逻辑
大数据·数据库·python