TimescaleDB 性能测试

TimescaleDB是一个基于 PostgreSQL 的时序数据库 , 时序数据库的主要用途通常是 监控 及 历史数据分析。

世界上 久负盛名/快/贵/小 的时序数据库 kdb+ 可能有不少人听说过。 这个数据库由 K 语言 编写并且内置了 Q 语言。

提示
可以从 Kx System 的 Github 上下载免费版本。
可以从 https://ondemand.kx.com/ 获取免费版的授权文件。
AWS kdb+ 价格信息 便宜的授权费用是 $1.5/小时, 每个月需要 $1080（每个月按照30天计算）。
警告
Kdb 的免费版本不允许商业使用
注解
本公司并没有使用过 kdb+ 数据库, 跟 Kx Systems 4 公司也没有任何关系。

时序数据库的特性

写入特点

• 写入量大 峰值小

时序数据库通常用于机器(例如:工业、物联网设备 等)状态的监控.

例如当监控服务器运行的状态时:

假如每个机器每秒上报 100 个指标(metric), 如果监控 100 台机器(一个不算特别大的集群) 则每秒需要上报 10_000 个指标数据。

• 数据具有 实时性

数据实时性越高，越能提前发现问题。

注解
甚至有些工业设备监控的会有确定的实时性要求(比如说: 每个数据的处理需要在 1ms 之内)， 否则会导致严重的事故。

• 数据具有 不变性

数据写入之后通常不允许更改(更改历史的监控指标数据有什么实际意义吗?)。

注解
更改历史数据我能想到的用处就是: 用于欺骗别人。

查询特点

• 聚合查询

查询通常是 多种维度、多种时间精度 组合 进行聚合查询，并不关注某一个点的具体值。

注解
例如服务监控中的: p50, p95, p99 等

• 新的数据查询概率高

数据的重要性通常是随着时间的流逝在逐渐变低, 做聚合分析的时候，通常都是使用新的数据。

存储特点

• 数据量大

监控 100 台机器，每秒 100 个指标，每天的数据量也达到了惊人的 8.64 亿。

• 数据具有周期性

历史数据一般会定期清除。

注解
当用于监控服务器的时候，由于机器有生命周期(一般商用服务器的保质期为: 2~3年), 当一个机器已经下线，保留它历史所有的监控数据并没有什么价值。
当然，通过下采样获取这个机器的指标还是有一些实际价值的。

测试环境

注解
虚拟机实际是 Linode 的 10$ 每个月的机器。

• t 表示的是线程数量
• b 表示的是每个事务写入多少条数据
• n 表示每个线程执行多少次写入事务

测试写入的总数据 = t∗b∗n

注解
图像表示的是写入 1000 条数据所需要的时间。
待处理
测试内存 & 磁盘占用量

InfluxDB 的问题

曾经使用过 InfluxDB 的数据库，主要遇到两个比较严重的问题:

• 丢失数据

我曾经遇到过: 使用 API 写入时返回成功，实际上数据并没有落盘, 导致部分数据丢失。

• 在高基(high cardinality)数据下内存管理有问题

这也是一个老问题了，印象中后来他们做了一个优化, TSI 会落到磁盘上。

提示
InfluxDB 的集群版本早已不再开源(在1.0 版本之前)。
注解
InfluxDB 近又要更换架构(InfluxDB IOx) 9, 底层存储切换成 Rust 10 语言, 给我的感觉是: InfluxDB 从来就没有稳定过!

原文链接：奇遇淘客 Android 版本现已开源