时序数据库 QuestDB 特性解析

2022-03-22 15:46:25

QuestDB 是一款针对时序数据实时处理优化的关系型列存数据库。

存储模型

QuestDB 采用列存（column-based）存储模型，表里的数据按列存储到不同的文件，每次新的写入数据追加到文件末尾，保持跟写入顺序一致。

追加模型

QuestDB 采用列存模型，每个列存储到不同的文件，文件通过 mmap 方式映射到内存，每次写入直接在映射内存大末尾追加数据，非常高效，对于定长类型列，通过行号就能固定定位到数据位置；针对变长类型列，每个列除了对应一个数据文件，还要对应一个索引文件，索引文件的记录为定长，指向各个记录在数据文件的位置。

CREATE TABLE IF NOT EXISTS trades(name STRING, value INT);
INSERT INTO trades VALUES('abc', 123456);

$tree trades
.
├── default
│   ├── name.d
│   ├── name.i
│   └── value.d
├── _meta
└── _txn

一致性和持久性

QuestDB 能保证每次写入的表级别的原子性，每张表会单独维护 last_committed_record_count（txn_count）, 读取时 QuestDB 确保不会读到行号超过 txn_count 的记录，确保与正在写入事务的隔离性，当新记录的各个列都更新成功时，QuestDB commit 事务更新 last_committed_record_coun提交事务。数据的持久性级别可以在 commit 时指定不同的参数，是每次提交持久化还是周期性做持久化。

存储模型总结

列存模型，不同的列存储到不同的文件，所有的写入追加到列文件末尾，不支持更新
通过 commit point 来保证读写访问隔离性，避免读到中间状态的数据

特定时间戳

QuestDB 支持一种 designated timestamp 的特殊时间戳列，存储时可以根据该时间戳来进行分区，从而针对时间范围的查询做优化。

只有时间戳类型的列能被指定为 designated timestamp 列
每张表只有一个列可以是 designated timestamp 列
可以针对 designated timestamp 列指定 partition 策略，加速时序查询
designated timestamp 列不支持乱序写入（这个极大的限制了使用场景）

SQL 扩展

QuestDB 为简化时序查询的表达，对 SQL 进行了扩展。

LATEST BY

查询新时间点数据

# 查询传感器新的温度指标
SELECT sensorName, tempC
FROM sensors
LATEST BY sensorName;

SAMPLE BY

对时序数据范围进行降采样聚合计算

# 查询传感器每5分钟的温度平均值
SELECT timestamp, avg(tempC)
FROM sensors
SAMPLE BY 5m;

Timestamp Search

# 按时间点/时间范围检索

SELECT timestamp, tempC
FROM sensors
WHERE timestamp = '2020-06-14;1M';

数据分区

QuestDB 支持自动对数据按时间进行分区存储，分区规则只能在 designated timestamp 列上指定，例如按天、按周、按月分区等规则，分区后，每个分区的数据存储到单独的目录。数据按时间分区存储后，根据时间范围的查询能快速的过滤数据，同时也能方便的实现 TTL 机制。

SYMBOL 类型及索引

QuestDB 支持 SYMBOL 类型，对于取值重复度高的字符串列，为了避免重复的存储相同的内容，QuestDB 通过字典映射，将 String 映射为整数存储，极大的提升存储效率；SYMBOL 列类似时序数据库里的 Tag。QuestDB 支持对 SYMBOL 列建索引，索引的方式类似于 InfluxDB 等时序数据库里实现的倒排索引; 通过索引能极大的极速查询。