作者：Vlad Ilyushchenko，QuestDB的CTO

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

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

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

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

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

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

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

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

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

以下是我們在AWS EC2 m5.8xlarge實(shí)例上使用多達(dá)14個(gè)worker的純cpu用例的基準(zhǔn)測試結(jié)果，該實(shí)例有16個(gè)內(nèi)核。

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

我們使用4個(gè)worker達(dá)到最大的攝取性能，而其他系統(tǒng)需要更多的CPU資源來達(dá)到最大的吞吐量。QuestDB用4個(gè)線程達(dá)到了95.9萬行/秒。我們發(fā)現(xiàn)InfluxDB需要14個(gè)線程才能達(dá)到最大的攝取率（334k行/秒），而TimescaleDB用4個(gè)線程達(dá)到145k行/秒。ClickHouse以兩倍于QuestDB的線程達(dá)到914k行/秒。

當(dāng)在4個(gè)線程上運(yùn)行時(shí)，QuestDB比ClickHouse快1.7倍，比InfluxDB快6.5倍，比TimescaleDB快6.6倍。

使用4個(gè)線程的TSBS基準(zhǔn)測試結(jié)果：QuestDB、InfluxDB、ClickHouse和TimescaleDB每秒獲取的行數(shù)。

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

比較QuestDB TSBS在AWS EC2與AMD Ryzen5上的負(fù)載結(jié)果

你應(yīng)該如何存儲(chǔ)亂序的時(shí)間序列數(shù)據(jù)？

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

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

2.在內(nèi)存中對(duì)暫存區(qū)的未提交的記錄進(jìn)行排序

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

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

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

我們?nèi)绾畏诸?、合并和提交無序的時(shí)間序列數(shù)據(jù)

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

我們通過優(yōu)化版本的radix排序?qū)碜詴捍鎱^(qū)的時(shí)間戳列進(jìn)行排序，所產(chǎn)生的索引被用于并行對(duì)暫存區(qū)的其余列進(jìn)行排序。

并行得將列進(jìn)行排序

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

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

當(dāng)以這種方式合并數(shù)據(jù)集時(shí)，前綴和后綴組可以是持續(xù)的數(shù)據(jù)、失序的數(shù)據(jù)，或者沒有數(shù)據(jù)。合并組(Merge Group)是最繁忙的，因?yàn)樗梢员怀志没臄?shù)據(jù)、失序的數(shù)據(jù)、失序的數(shù)據(jù)和持久化的數(shù)據(jù)占據(jù)，或者沒有數(shù)據(jù)。

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

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

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

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

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

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

我們已經(jīng)在TimescaleDB的TSBS GitHub倉庫中開啟了一個(gè)合并請(qǐng)求(Questdb基準(zhǔn)支持 https://github.com/timescale/tsbs/issues/157)，增加了針對(duì)QuestDB運(yùn)行基準(zhǔn)測試的能力。同時(shí)，用戶可以克隆我們的基準(zhǔn)測試fork(https://github.com/questdb/tsbs)，并運(yùn)行該套件以查看自己的結(jié)果。

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

構(gòu)建具有授權(quán)許可的開源數(shù)據(jù)庫

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

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