做者：Vlad Ilyushchenko，QuestDB的CTO git
在QuestDB (https://questdb.io/， https://github.com/questdb/questdb)，咱们已经创建了一个专一于性能的开源时间序列数据库。咱们建立QuestDB初衷是为了将咱们在超低延迟交易方面的经验以及咱们在该领域开发的技术方法带到各类实时数据处理用途中。github
QuestDB的旅程始于2013年的原型设计，咱们在去年HackerNews发布会期间（https://news.ycombinator.com/item?id=23975807）发表的一篇文章中描述了2013年以后所发生的变化。咱们的用户在金融服务、物联网、应用监控和机器学习领域都部署了QuestDB，使时间序列分析变得快速、高效和便捷。 数据库
什么是存储时间序列数据的最佳方式？
在项目的早期阶段，咱们受到了基于矢量的append-only系统（如kdb+）的启发，由于这种模型带来了速度和简洁代码路径的优点。QuestDB的数据模型使用了咱们称之为基于时间的数组，这是一种线性数据结构。这容许QuestDB在数据获取过程当中把数据切成小块，并以并行方式处理全部数据。以错误的时间顺序到达的数据在被持久化到磁盘以前会在内存中进行处理和从新排序。所以，数据在到达数据库中以前已经按时间排序。所以，QuestDB不依赖计算密集的索引来为任什么时候间序列的查询从新排序数据。数组
这种liner模型与其余开源数据库（如InfluxDB或TimescaleDB）中的LSM树或基于B树的存储引擎不一样。数据结构
除了更好的数据获取能力，QuestDB的数据布局使CPU可以更快地访问数据。咱们的代码库利用最新CPU架构的SIMD指令，对多个数据元素并行处理同类操做。咱们将数据存储在列中，并按时间进行分区，以在查询时从磁盘中提取最小的数据量。架构
数据被存储在列中，并按时间进行分区app
QuestDB与ClickHouse、InfluxDB和TimescaleDB相好比何？
咱们看到时间序列基准测试套件（TSBS https://github.com/timescale/tsbs）常常出如今关于数据库性能的讨论，所以咱们决定提供对QuestDB和其余系统进行基准测试的能力。TSBS是一个Go程序集，用于生成数据集，而后对读写性能进行基准测试。该套件是可扩展的，所以能够包括不一样的用例和查询类型，并在不一样系统之间进行比较。机器学习
如下是咱们在AWS EC2 m5.8xlarge实例上使用多达14个worker的纯cpu用例的基准测试结果，该实例有16个内核。布局
TSBS结果比较了QuestDB、InfluxDB、ClickHouse和TimescaleDB的最大获取吞吐量。性能
咱们使用4个worker达到最大的摄取性能，而其余系统须要更多的CPU资源来达到最大的吞吐量。QuestDB用4个线程达到了959k行/秒。咱们发现InfluxDB须要14个线程才能达到最大的摄取率（334k行/秒），而TimescaleDB用4个线程达到145k行/秒。ClickHouse以两倍于QuestDB的线程达到914k行/秒。
当在4个线程上运行时，QuestDB比ClickHouse快1.7倍，比InfluxDB快6.5倍，比TimescaleDB快6.6倍。
使用4个线程的TSBS基准测试结果：QuestDB、InfluxDB、ClickHouse和TimescaleDB每秒获取的行数。
当咱们使用AMD Ryzen5处理器再次运行该套件时，咱们发现，咱们可以使用5个线程达到每秒143万行的最大吞吐量。与咱们在AWS上的参考基准m5.8xlarge实例所使用的英特尔至强Platinum相比：
比较QuestDB TSBS在AWS EC2与AMD Ryzen5上的负载结果
你应该如何存储乱序的时间序列数据？
事实证实，在摄取过程当中对 "乱序"（O3）的数据进行从新排序特别具备挑战性。这是一个新的方法，咱们想在这篇文章中详细介绍一下。咱们对如何处理失序摄取的想法是增长一个三阶段的方法。
- 保持追加模式，直到记录不按顺序到达为止
- 在内存中对暂存区的未提交的记录进行排序
- 在提交时对分类的无序数据和持久化的数据进行核对和合并
前两个步骤很直接，也很容易实现，依然只是处理追加的数据，这一点没变。只有在暂存区有数据的时候，昂贵的失序提交才会启动。这种设计的好处是，输出是向量，这意味着咱们基于向量的阅读器仍然是兼容的。
这种预提交的排序和合并方式给数据获取增长了一个额外的处理阶段，同时也带来了性能上的损失。不过，咱们仍是决定探索这种方法，看看咱们能在多大程度上经过优化失序提交来减小性能损耗。
咱们如何分类、合并和提交无序的时间序列数据
处理一个暂存区给了咱们一个独特的机会来全面分析数据，在这里咱们能够彻底避免物理合并，并经过快速和直接的memcpy或相似的数据移动方法来替代。因为咱们的基于列的存储，这种方法能够被并行化。咱们能够采用SIMD和非时序数据访问，这对咱们来讲是很重要的。
咱们经过优化版本的radix排序对来自暂存区的时间戳列进行排序，所产生的索引被用于并行对暂存区的其他列进行排序。
并行得将列进行排序
如今排序的暂存区是相对于现有分区数据进行映射的。从一开始可能并不明显，但咱们正试图为如下三种类型的每一种创建所需的操做和维度。
失序（O3）排序和合并方案
当以这种方式合并数据集时，前缀和后缀组能够是持续的数据、失序的数据，或者没有数据。合并组(Merge Group)是最繁忙的，由于它能够被持久化的数据、失序的数据、失序的数据和持久化的数据占据，或者没有数据。
当明确了如何分组和处理暂存区的数据时，一个工人池就会执行所需的操做，在少许的状况下调用memcpy，其余都转向SIMD优化的代码。经过前缀、合并和后缀拆分，提交的最大活度（增长CPU容量的易感性）能够经过partition_affected x number_of_columns x 3获得。
时间序列数据应该多久进行一次排序和合并？
可以快速复制数据是一个不错的选择，但咱们认为在大多数时间序列获取场景中能够避免大量的数据复制。假设大多数实时失序的状况是由传递机制和硬件抖动形成的，咱们能够推断出时间戳分布将在必定区间范围。
例如，若是任何新的时间戳值有很大几率落在先前收到的值的10秒内，那么边界就是10秒，咱们称这个为滞后边界。
当时间戳值遵循这种模式时，推迟提交可使失序提交成为正常的追加操做。失序系统能够处理任何种类的延迟，但若是延迟的数据在指定的滞后边界内到达，它将被优先快速处理。
如何比较时间序列数据库的性能
咱们已经在TimescaleDB的TSBS GitHub仓库中开启了一个合并请求(Questdb基准支持 https://github.com/timescale/tsbs/issues/157)，增长了针对QuestDB运行基准测试的能力。同时，用户能够克隆咱们的基准测试fork(https://github.com/questdb/tsbs)，并运行该套件以查看本身的结果。
tsbs_generate_data --use-case="cpu-only" --seed=123 --scale=4000 `。
--timestamp-start="2016-01-01T00:00:00Z" --timestamp-end="2016-01-02T00:00:00Z" \
--log-interval="10s" --format="influx" > /tmp/bigcpu
tsbs_load_questdb --file /tmp/bigcpu --workers 4
构建具备受权许可的开源数据库
在进一步推进数据库性能的同时，使开发人员可以轻松地开始使用咱们的产品，这一点天天都激励着咱们。这就是为何咱们专一于创建一个坚实的开发者社区，他们能够经过咱们的开源分销模式参与并改进产品。
除了使QuestDB易于使用以外，咱们还但愿使其易于审计、审查，提交代码或其余的项目贡献。QuestDB的全部源代码都在GitHub（https://github.com/questdb/questdb）上以Apache 2.0许可证提供，咱们欢迎对此产品的各类贡献，包括在GitHub上建立issue或者提交代码。
© 2021年QuestDB。由Slab提供