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

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

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

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

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

我們使用4個(gè)worker達(dá)到最大的攝取性能，而其他系統(tǒng)需要更多的CPU資源來(lái)達(dá)到最大的吞吐量。QuestDB用4個(gè)線程達(dá)到了95.9萬(wàn)行/秒。我們發(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)測(cè)試結(jié)果：QuestDB、InfluxDB、ClickHouse和TimescaleDB每秒獲取的行數(shù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

能夠快速?gòu)?fù)制數(shù)據(jù)是一個(gè)不錯(cuò)的選擇，但我們認(rèn)為在大多數(shù)時(shí)間序列獲取場(chǎng)景中可以避免大量的數(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ù)庫(kù)的性能

我們已經(jīng)在TimescaleDB的TSBS GitHub倉(cāng)庫(kù)中開(kāi)啟了一個(gè)合并請(qǐng)求(Questdb基準(zhǔn)支持 https://github.com/timescale/tsbs/issues/157)，增加了針對(duì)QuestDB運(yùn)行基準(zhǔn)測(cè)試的能力。同時(shí)，用戶可以克隆我們的基準(zhǔn)測(cè)試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)許可的開(kāi)源數(shù)據(jù)庫(kù)

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

? 2021年QuestDB。由Slab提供

songjy