时序数据库之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

相关推荐
枷锁—sha6 分钟前
【SRC】SQL注入快速判定与应对策略(一)
网络·数据库·sql·安全·网络安全·系统安全
惜分飞18 分钟前
ORA-600 kcratr_nab_less_than_odr和ORA-600 4193故障处理--惜分飞
数据库·oracle
chian-ocean18 分钟前
CANN 生态进阶:利用 `profiling-tools` 优化模型性能
数据库·mysql
m0_5500246322 分钟前
持续集成/持续部署(CI/CD) for Python
jvm·数据库·python
AC赳赳老秦23 分钟前
代码生成超越 GPT-4:DeepSeek-V4 编程任务实战与 2026 开发者效率提升指南
数据库·数据仓库·人工智能·科技·rabbitmq·memcache·deepseek
啦啦啦_999937 分钟前
Redis-2-queryFormat()方法
数据库·redis·缓存
玄同7651 小时前
SQLite + LLM:大模型应用落地的轻量级数据存储方案
jvm·数据库·人工智能·python·语言模型·sqlite·知识图谱
吾日三省吾码1 小时前
别只会“加索引”了!这 3 个 PostgreSQL 反常识优化,能把性能和成本一起打下来
数据库·postgresql
chian-ocean1 小时前
百万级图文检索实战:`ops-transformer` + 向量数据库构建语义搜索引擎
数据库·搜索引擎·transformer
小Tomkk2 小时前
数据库 变更和版本控制管理工具 --Bytebase 安装部署(linux 安装篇)
linux·运维·数据库·ci/cd·bytebase