作者：Vlad Ilyushchenko，QuestDB的CTO

在QuestDB (https://questdb.io/， https://github.com/questdb/questdb)，我們已經(jīng)建立了一個專注于性能的開源時間序列數(shù)據(jù)庫。我們創(chuàng)建QuestDB初衷是為了將我們在超低延遲交易方面的經(jīng)驗以及我們在該領域開發(fā)的技術方法帶到各種實時數(shù)據(jù)處理用途中。

QuestDB的旅程始于2013年的原型設計，我們在去年HackerNews發(fā)布會期間（https://news.ycombinator.com/item?id=23975807）發(fā)表的一篇文章中描述了2013年之后所發(fā)生的變化。我們的用戶在金融服務、物聯(lián)網(wǎng)、應用監(jiān)控和機器學習領域都部署了QuestDB，使時間序列分析變得快速、高效和便捷。

什么是存儲時間序列數(shù)據(jù)的最佳方式？

在項目的早期階段，我們受到了基于矢量的append-only系統(tǒng)（如kdb+）的啟發(fā)，因為這種模型帶來了速度和簡潔代碼路徑的優(yōu)勢。QuestDB的數(shù)據(jù)模型使用了我們稱之為基于時間的數(shù)組，這是一種線性數(shù)據(jù)結構。這允許QuestDB在數(shù)據(jù)獲取過程中把數(shù)據(jù)切成小塊，并以并行方式處理所有數(shù)據(jù)。以錯誤的時間順序到達的數(shù)據(jù)在被持久化到磁盤之前會在內存中進行處理和重新排序。因此，數(shù)據(jù)在到達數(shù)據(jù)庫中之前已經(jīng)按時間排序。因此，QuestDB不依賴計算密集的索引來為任何時間序列的查詢重新排序數(shù)據(jù)。

這種liner模型與其他開源數(shù)據(jù)庫（如InfluxDB或TimescaleDB）中的LSM樹或基于B樹的存儲引擎不同。

除了更好的數(shù)據(jù)獲取能力，QuestDB的數(shù)據(jù)布局使CPU能夠更快地訪問數(shù)據(jù)。我們的代碼庫利用最新CPU架構的SIMD指令，對多個數(shù)據(jù)元素并行處理同類操作。我們將數(shù)據(jù)存儲在列中，并按時間進行分區(qū)，以在查詢時從磁盤中提取最小的數(shù)據(jù)量。

數(shù)據(jù)被存儲在列中，并按時間進行分區(qū)

QuestDB與ClickHouse、InfluxDB和TimescaleDB相比如何？

我們看到時間序列基準測試套件（TSBS https://github.com/timescale/tsbs）經(jīng)常出現(xiàn)在關于數(shù)據(jù)庫性能的討論，因此我們決定提供對QuestDB和其他系統(tǒng)進行基準測試的能力。TSBS是一個Go程序集，用于生成數(shù)據(jù)集，然后對讀寫性能進行基準測試。該套件是可擴展的，因此可以包括不同的用例和查詢類型，并在不同系統(tǒng)之間進行比較。

以下是我們在AWS EC2 m5.8xlarge實例上使用多達14個worker的純cpu用例的基準測試結果，該實例有16個內核。

TSBS結果比較了QuestDB、InfluxDB、ClickHouse和TimescaleDB的最大獲取吞吐量。

我們使用4個worker達到最大的攝取性能，而其他系統(tǒng)需要更多的CPU資源來達到最大的吞吐量。QuestDB用4個線程達到了95.9萬行/秒。我們發(fā)現(xiàn)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每秒獲取的行數(shù)。

當我們使用AMD Ryzen5處理器再次運行該套件時，我們發(fā)現(xiàn)，我們能夠使用5個線程達到每秒143萬行的最大吞吐量。與我們在AWS上的參考基準m5.8xlarge實例所使用的英特爾至強Platinum相比：

比較QuestDB TSBS在AWS EC2與AMD Ryzen5上的負載結果

你應該如何存儲亂序的時間序列數(shù)據(jù)？

事實證明，在攝取過程中對 "亂序"（O3）的數(shù)據(jù)進行重新排序特別具有挑戰(zhàn)性。這是一個新的方法，我們想在這篇文章中詳細介紹一下。我們對如何處理失序攝取的想法是增加一個三階段的方法。

1.保持追加模式，直到記錄不按順序到達為止

2.在內存中對暫存區(qū)的未提交的記錄進行排序

3.在提交時對分類的無序數(shù)據(jù)和持久化的數(shù)據(jù)進行核對和合并

前兩個步驟很直接，也很容易實現(xiàn)，依然只是處理追加的數(shù)據(jù)，這一點沒變。只有在暫存區(qū)有數(shù)據(jù)的時候，昂貴的失序提交才會啟動。這種設計的好處是，輸出是向量，這意味著我們基于向量的閱讀器仍然是兼容的。

這種預提交的排序和合并方式給數(shù)據(jù)獲取增加了一個額外的處理階段，同時也帶來了性能上的損失。不過，我們還是決定探索這種方法，看看我們能在多大程度上通過優(yōu)化失序提交來減少性能損耗。

我們如何分類、合并和提交無序的時間序列數(shù)據(jù)

處理一個暫存區(qū)給了我們一個獨特的機會來全面分析數(shù)據(jù)，在這里我們可以完全避免物理合并，并通過快速和直接的memcpy或類似的數(shù)據(jù)移動方法來替代。由于我們的基于列的存儲，這種方法可以被并行化。我們可以采用SIMD和非時序數(shù)據(jù)訪問，這對我們來說是很重要的。

我們通過優(yōu)化版本的radix排序對來自暫存區(qū)的時間戳列進行排序，所產(chǎn)生的索引被用于并行對暫存區(qū)的其余列進行排序。

并行得將列進行排序

現(xiàn)在排序的暫存區(qū)是相對于現(xiàn)有分區(qū)數(shù)據(jù)進行映射的。從一開始可能并不明顯，但我們正試圖為以下三種類型的每一種建立所需的操作和維度。

失序（O3）排序和合并方案

當以這種方式合并數(shù)據(jù)集時，前綴和后綴組可以是持續(xù)的數(shù)據(jù)、失序的數(shù)據(jù)，或者沒有數(shù)據(jù)。合并組(Merge Group)是最繁忙的，因為它可以被持久化的數(shù)據(jù)、失序的數(shù)據(jù)、失序的數(shù)據(jù)和持久化的數(shù)據(jù)占據(jù)，或者沒有數(shù)據(jù)。

當明確了如何分組和處理暫存區(qū)的數(shù)據(jù)時，一個工人池就會執(zhí)行所需的操作，在少量的情況下調用memcpy，其他都轉向SIMD優(yōu)化的代碼。通過前綴、合并和后綴拆分，提交的最大活度（增加CPU容量的易感性）可以通過partition_affected x number_of_columns x 3得到。

時間序列數(shù)據(jù)應該多久進行一次排序和合并？

能夠快速復制數(shù)據(jù)是一個不錯的選擇，但我們認為在大多數(shù)時間序列獲取場景中可以避免大量的數(shù)據(jù)復制。假設大多數(shù)實時失序的情況是由傳遞機制和硬件抖動造成的，我們可以推斷出時間戳分布將在一定區(qū)間范圍。

例如，如果任何新的時間戳值有很大概率落在先前收到的值的10秒內，那么邊界就是10秒，我們稱這個為滯后邊界。

當時間戳值遵循這種模式時，推遲提交可以使失序提交成為正常的追加操作。失序系統(tǒng)可以處理任何種類的延遲，但如果延遲的數(shù)據(jù)在指定的滯后邊界內到達，它將被優(yōu)先快速處理。

如何比較時間序列數(shù)據(jù)庫的性能

我們已經(jīng)在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

構建具有授權許可的開源數(shù)據(jù)庫

在進一步推動數(shù)據(jù)庫性能的同時，使開發(fā)人員能夠輕松地開始使用我們的產(chǎn)品，這一點每天都激勵著我們。這就是為什么我們專注于建立一個堅實的開發(fā)者社區(qū)，他們可以通過我們的開源分銷模式參與并改進產(chǎn)品。

除了使QuestDB易于使用之外，我們還希望使其易于審計、審查，提交代碼或其他的項目貢獻。QuestDB的所有源代碼都在GitHub（https://github.com/questdb/questdb）上以Apache 2.0許可證提供，我們歡迎對此產(chǎn)品的各種貢獻，包括在GitHub上創(chuàng)建issue或者提交代碼。