在論證了大規(guī)模運(yùn)行Druid的挑戰(zhàn)之后，我想提出我對(duì)下一代開(kāi)源時(shí)間序列存儲(chǔ)的看法，這應(yīng)該不會(huì)出現(xiàn)Druid固有的問(wèn)題。
“開(kāi)源”是問(wèn)題陳述的重要組成部分，因?yàn)樘岢龅脑O(shè)計(jì)實(shí)質(zhì)上是專有Google BigQuery的簡(jiǎn)化版本。我主要從Dremel論文和帖子“ BigQuery under the hood”中獲取了有關(guān)BigQuery體系結(jié)構(gòu)的信息，還從許多其他來(lái)源中獲取了一些信息。
其他目標(biāo)和自我約束：
時(shí)間序列存儲(chǔ)可擴(kuò)展到單個(gè)群集中的PB級(jí)壓縮數(shù)據(jù)和100k處理核心。
云優(yōu)先：利用云的優(yōu)勢(shì)。
從數(shù)十兆兆字節(jié)的數(shù)據(jù)和一千個(gè)處理內(nèi)核開(kāi)始，具有成本效益。
在合理規(guī)模的群集中，處理少于5 TB數(shù)據(jù)的查詢應(yīng)在3秒以內(nèi)（p99延遲）運(yùn)行-涵蓋交互式廣告分析用例。
高度一致的查詢延遲：相似的查詢應(yīng)始終花費(fèi)相同的時(shí)間來(lái)完成，而不管集群中并行運(yùn)行的查詢是什么。
新攝取的數(shù)據(jù)應(yīng)立即可查詢。
仔細(xì)想想：提出的設(shè)計(jì)有望在3-5年內(nèi)變得越來(lái)越重要，而不是不那么重要。
非目標(biāo)：
本地部署。
小規(guī)模的成本效益。
隨機(jī)更新和刪除舊數(shù)據(jù)的效率，盡管這些事情應(yīng)該是可能的。
對(duì)于任何小的查詢，即使在沒(méi)有負(fù)載的系統(tǒng)中，p99的等待時(shí)間也不到半秒。
易于首次部署和軟件更新。
最后的介紹性說(shuō)明：這篇文章基于在Metamarkets大規(guī)模運(yùn)行Druid的經(jīng)驗(yàn)和理論研究，但是所描述的設(shè)計(jì)尚未在生產(chǎn)中實(shí)施和測(cè)試。這篇文章中的某些陳述是錯(cuò)誤的。如果您有任何意見(jiàn)或更正，請(qǐng)?jiān)诖颂酉掳l(fā)表評(píng)論！
設(shè)計(jì)概述
具有三個(gè)解耦子系統(tǒng)的時(shí)間序列存儲(chǔ)的設(shè)計(jì)。淺藍(lán)色線表示未壓縮的面向行的數(shù)據(jù)流；深藍(lán)線-壓縮的柱狀數(shù)據(jù)；紅線-查詢結(jié)果。
該系統(tǒng)由三部分組成，各部分之間有嚴(yán)格的職責(zé)分離：流處理系統(tǒng)，存儲(chǔ)和計(jì)算樹(shù)。
流處理系統(tǒng)攝取數(shù)據(jù)（接受“寫入”），對(duì)其進(jìn)行分區(qū)，將每個(gè)時(shí)間間隔內(nèi)的數(shù)據(jù)轉(zhuǎn)換為壓縮的列格式并將其寫入Storage。流處理系統(tǒng)的工作人員還負(fù)責(zé)計(jì)算最新數(shù)據(jù)的部分查詢結(jié)果。
計(jì)算樹(shù)具有多個(gè)級(jí)別的節(jié)點(diǎn)：最低級(jí)別的節(jié)點(diǎn)從Storage中下載特定分區(qū)和間隔的數(shù)據(jù)，并為其計(jì)算部分結(jié)果。如果查詢間隔包括最新數(shù)據(jù)，則第二層中的節(jié)點(diǎn)合并特定分區(qū)的所有分區(qū)的結(jié)果，并接受最低層中的節(jié)點(diǎn)和Stream處理系統(tǒng)的工作程序的接受。第三級(jí)中的節(jié)點(diǎn)合并或合并第二級(jí)中節(jié)點(diǎn)的每個(gè)時(shí)間間隔結(jié)果，并包含每個(gè)時(shí)間間隔查詢結(jié)果的緩存。這些節(jié)點(diǎn)還可能負(fù)責(zé)群集平衡和較低級(jí)別的計(jì)算樹(shù)的自動(dòng)縮放。
此設(shè)計(jì)的關(guān)鍵原則：
計(jì)算和存儲(chǔ)的分離。這個(gè)想法來(lái)自BigQuery。在我有關(guān)Druid問(wèn)題的文章中，我解釋了Druid中缺少這種分隔如何使查詢延遲不可預(yù)測(cè)，因?yàn)椴樵冎g會(huì)相互干擾。
使計(jì)算樹(shù)中的節(jié)點(diǎn)（幾乎）是無(wú)狀態(tài)的，這意味著它們是“一次性”的。它們可能是亞馬遜的EC2或Google的可搶占實(shí)例，它們比普通實(shí)例便宜幾倍。同樣，計(jì)算樹(shù)可以在數(shù)分鐘之內(nèi)放大和縮小，從而有可能e。G。在查詢負(fù)載較低時(shí)，每晚和周末將其按比例縮小。
數(shù)據(jù)攝?。ㄔ诹魈幚硐到y(tǒng)中）和存儲(chǔ)分開(kāi)。這個(gè)想法實(shí)際上已經(jīng)在Druid中實(shí)現(xiàn)，它具有實(shí)時(shí)節(jié)點(diǎn)。這樣的關(guān)注點(diǎn)分離可以使Storage保持非常簡(jiǎn)單，不需要分配資源來(lái)進(jìn)行提取，列壓縮，查詢處理等。它只專注于從磁盤讀取字節(jié)塊并將其通過(guò)網(wǎng)絡(luò)發(fā)送到計(jì)算中的節(jié)點(diǎn)和樹(shù)。
流處理系統(tǒng)也可能比支持寫操作的存儲(chǔ)更動(dòng)態(tài)。流處理系統(tǒng)可以根據(jù)數(shù)據(jù)攝取強(qiáng)度的變化而按比例放大或縮小，通常在晚上和周末較低。流處理系統(tǒng)可能具有在存儲(chǔ)中難以實(shí)現(xiàn)的功能，例如動(dòng)態(tài)重新分區(qū)。
網(wǎng)絡(luò)是瓶頸
如果查詢的下載量沒(méi)有使Storage的出站網(wǎng)絡(luò)帶寬飽和，則網(wǎng)絡(luò)對(duì)總查詢延遲的貢獻(xiàn)是恒定的，并且與查詢大小無(wú)關(guān)。如果將云對(duì)象存儲(chǔ)用作存儲(chǔ)（請(qǐng)參閱下面的“云對(duì)象存儲(chǔ)”部分），或者相對(duì)于存儲(chǔ)中的歷史數(shù)據(jù)量，系統(tǒng)中的查詢負(fù)載不成比例地較小，則可以授予此權(quán)限。
如果這兩個(gè)條件都不適用，則可以使用Storage托管一些非時(shí)間序列的，下載頻率較低的數(shù)據(jù)，以便人為地增加Storage群集的大小，從而增加其出站網(wǎng)絡(luò)帶寬。
否則，在存儲(chǔ)和計(jì)算樹(shù)之間的網(wǎng)絡(luò)吞吐量可能將成為限制所提出設(shè)計(jì)中查詢延遲的因素。有幾種方法可以減輕這種情況：
與僅生成一個(gè)表的典型SQL查詢不同，對(duì)該系統(tǒng)的查詢應(yīng)組成所有子查詢，而這些子查詢是在分析界面的單個(gè)屏幕上所需的。Analytics（分析）界面通常包括至少幾個(gè)，有時(shí)是幾十個(gè)表，圖表等，它們是同一時(shí)間序列數(shù)據(jù)的子查詢的結(jié)果。
在第三級(jí)計(jì)算樹(shù)中慷慨地緩存查詢結(jié)果，以減少重做相同計(jì)算的負(fù)載。
投影下推：僅從存儲(chǔ)區(qū)下載查詢處理所需的列子集。
按維度鍵分區(qū)（最常出現(xiàn)在查詢過(guò)濾器中）僅下載和處理所需的分區(qū)-謂詞下推式。由于許多實(shí)際數(shù)據(jù)維度中的密鑰頻率是Poisson-，Zipf-或其他不均勻分布的，因此理想情況下，Stream處理系統(tǒng)應(yīng)支持“部分”分區(qū)，請(qǐng)參見(jiàn)下圖。由于這種分區(qū)的基數(shù)較低，因此可以在各個(gè)分區(qū)變得太小而無(wú)法以列格式和處理進(jìn)行有效壓縮之前，將數(shù)據(jù)按多個(gè)維度進(jìn)行分區(qū)。
部分分區(qū)可實(shí)現(xiàn)密鑰分配不均。每個(gè)盒子都是一個(gè)分區(qū)。具有“其他值”的分區(qū)可能具有數(shù)千個(gè)“長(zhǎng)尾”值。
更一般而言，數(shù)據(jù)段（分區(qū)）的元數(shù)據(jù)應(yīng)包括有關(guān)所有維度的信息，該維度似乎在此分區(qū)中僅填充了一個(gè)（或很少）鍵，從而可以從“意外”分區(qū)中受益。
色譜柱壓縮應(yīng)強(qiáng)烈支持壓縮率，而不是減壓或處理速度。
列數(shù)據(jù)應(yīng)從存儲(chǔ)流式傳輸?shù)接?jì)算樹(shù)中的節(jié)點(diǎn)，并且一旦所有必需列的第一個(gè)塊到達(dá)計(jì)算節(jié)點(diǎn)，就開(kāi)始子查詢處理。這樣可以使網(wǎng)絡(luò)和CPU的貢獻(xiàn)在總查詢延遲中盡可能地重疊。要從中受益，將列從存儲(chǔ)發(fā)送到計(jì)算樹(shù)的順序應(yīng)該比僅在存儲(chǔ)中的磁盤上排列列的順序或列名稱按字母順序排列的順序更聰明。列也可以按小塊以交錯(cuò)順序發(fā)送，而不是逐列發(fā)送。
一旦部分結(jié)果準(zhǔn)備就緒，就遞增計(jì)算最終查詢結(jié)果，并將增量結(jié)果流式傳輸?shù)娇蛻舳?，以使客戶端感知查詢運(yùn)行得更快。
在本文的后面，我將詳細(xì)介紹系統(tǒng)的每個(gè)部分。
存儲(chǔ)
在本節(jié)中，我想討論一些存儲(chǔ)的可能實(shí)現(xiàn)。它們可以作為可互換的選項(xiàng)共存，就像在Druid中一樣。
云對(duì)象存儲(chǔ)
它是Amazon S3，Google云存儲(chǔ)（GCS），Azure Blob存儲(chǔ)以及其他云提供商的類似產(chǎn)品。
從概念上講，這正是設(shè)計(jì)的時(shí)間序列存儲(chǔ)中應(yīng)使用的存儲(chǔ)方式，因?yàn)镚CS由名為Colossus的系統(tǒng)提供支持，并且它也是BigQuery的存儲(chǔ)層。
云對(duì)象存儲(chǔ)比我將在下面討論的選項(xiàng)便宜得多，所需的管理工作少得多，并且吞吐量幾乎不受限制，因此上面的整個(gè)“網(wǎng)絡(luò)是瓶頸”一節(jié)在很大程度上是不相關(guān)的（理論上）。
云對(duì)象存儲(chǔ)API不夠完善，不足以在單個(gè)請(qǐng)求中支持多個(gè)字節(jié)范圍的下載（用于多列的投影下推），因此每列的每次下載應(yīng)是一個(gè)單獨(dú)的請(qǐng)求。我懷疑這不是BigQuery的工作方式，它與Colossus的集成更緊密，可以實(shí)現(xiàn)適當(dāng)?shù)亩嗔型队跋峦啤?/p>
在我看來(lái)，“云對(duì)象存儲(chǔ)”選項(xiàng)的主要缺點(diǎn)可能是其p99延遲和吞吐量。一些基準(zhǔn)測(cè)試表明，GCS和S3在100 ms的延遲中具有p99延遲（這是可以接受的），并且吞吐量?jī)H受下載端VM功能的限制，但是如果在并發(fā)100個(gè)負(fù)載的情況下仍然如此，我將感到非常驚訝一個(gè)節(jié)點(diǎn)的請(qǐng)求，以及整個(gè)集群中一百萬(wàn)個(gè)并發(fā)請(qǐng)求的規(guī)模。請(qǐng)注意，所有云提供商都沒(méi)有針對(duì)對(duì)象存儲(chǔ)延遲和吞吐量的SLA，對(duì)于GCS，公認(rèn)吞吐量是“相當(dāng)多的變量”。
（注意：之前，在上面的部分中，我提到了Cloud Object Storage API不支持范圍請(qǐng)求，這是不正確的，盡管它們?nèi)匀徊恢С郑ń刂?019年10月）單個(gè)請(qǐng)求中的多個(gè)范圍下載，因此并發(fā)查詢放大系數(shù)不會(huì)消失。）
HDFS中Parquet格式的數(shù)據(jù)分區(qū)
此選項(xiàng)的主要優(yōu)點(diǎn)是與Hadoop生態(tài)系統(tǒng)的其余部分很好地集成-計(jì)算樹(shù)甚至可以“附加”到某些已經(jīng)存在的數(shù)據(jù)倉(cāng)庫(kù)中。大型聯(lián)接或多步查詢等不適用于時(shí)間序列范式的復(fù)雜查詢可以由同一HDFS群集頂部的Spark，Impala，Hive或Presto之類的系統(tǒng)處理。
同樣重要的是，旨在部署設(shè)計(jì)的時(shí)間序列存儲(chǔ)的組織可能已經(jīng)具有非常大的HDFS集群，該集群具有較大的出站網(wǎng)絡(luò)帶寬，并且如果時(shí)間序列存儲(chǔ)使用此HDFS集群存儲(chǔ)其數(shù)據(jù)分區(qū)，則它可能會(huì)工作圍繞網(wǎng)絡(luò)的可擴(kuò)展性問(wèn)題。
但是，庫(kù)存HDFS通過(guò)單個(gè)NameNode路由所有讀取請(qǐng)求。100k并發(fā)讀取請(qǐng)求（假設(shè)只需要一個(gè)讀取請(qǐng)求就可以在計(jì)算樹(shù)中的一個(gè)節(jié)點(diǎn)上下載數(shù)據(jù)分區(qū)）接近NameNode的絕對(duì)可伸縮性限制，因此，如果HDFS集群實(shí)際上忙于處理某些內(nèi)容，則超出該限制與時(shí)間序列存儲(chǔ)無(wú)關(guān)的操作。
此外，當(dāng)HDFS用作“遠(yuǎn)程”分布式文件系統(tǒng)時(shí)，即使對(duì)于Parquet格式的文件，它也不支持投影下推，因此整個(gè)數(shù)據(jù)分區(qū)應(yīng)由計(jì)算樹(shù)中的節(jié)點(diǎn)下載。如果時(shí)間序列數(shù)據(jù)中有數(shù)百列，并且通常只使用一小部分進(jìn)行查詢，則效果將不佳。正如云對(duì)象存儲(chǔ)所建議的那樣，使每個(gè)數(shù)據(jù)分區(qū)的每一列都成為一個(gè)單獨(dú)的文件，由于擴(kuò)大了文件和讀取請(qǐng)求的數(shù)量，因此施加了更大的可擴(kuò)展性限制。NameNode將無(wú)法處理一百萬(wàn)個(gè)并發(fā)請(qǐng)求，并且HDFS并未針對(duì)小于10 MB的文件進(jìn)行優(yōu)化，假設(shè)最佳數(shù)據(jù)分區(qū)的大小約為一百萬(wàn)，則數(shù)據(jù)分區(qū)的各個(gè)列將具有的大小行。
但是，在某些情況下（例如，存在大量未充分利用的HDFS集群）并且在某些使用情況下，HDFS似乎是最經(jīng)濟(jì)高效的選擇，并且運(yùn)行良好。
Apache Kudu
Apache Kudu是一種列式數(shù)據(jù)存儲(chǔ)，旨在在許多情況下替換HDFS Parquet對(duì)。它結(jié)合了節(jié)省空間的列式存儲(chǔ)以及快速進(jìn)行單行讀寫的能力。設(shè)計(jì)的時(shí)間序列系統(tǒng)實(shí)際上不需要第二部分，因?yàn)閷懭胧怯蒘tream處理系統(tǒng)處理的，而我們希望使Storage更加便宜并且不浪費(fèi)CPU（例如用于后臺(tái)壓縮任務(wù)），每個(gè)Storage節(jié)點(diǎn)上的內(nèi)存和磁盤資源支持單行讀取和寫入。此外，在Kudu中對(duì)舊數(shù)據(jù)進(jìn)行單行寫入的方式要求在Kudu節(jié)點(diǎn)上進(jìn)行分區(qū)解壓縮，而在建議的時(shí)間序列存儲(chǔ)設(shè)計(jì)中，只有壓縮后的數(shù)據(jù)應(yīng)在存儲(chǔ)和計(jì)算樹(shù)之間傳輸。
另一方面，Kudu具有多種功能，這些功能吸引了時(shí)間序列系統(tǒng)，而HDFS沒(méi)有：
類似于RDBMS的語(yǔ)義。Kudu中的數(shù)據(jù)以表格的形式組織，而不僅僅是一堆文件。
Kudu中的平板電腦服務(wù)器（節(jié)點(diǎn)）比HDFS中的服務(wù)器更獨(dú)立，從而可以在進(jìn)行讀取時(shí)繞過(guò)查詢主節(jié)點(diǎn)（Kudu等效于NameNode），從而大大提高了讀取可擴(kuò)展性。
投影下推。
它是用C 編寫的，因此尾部延遲應(yīng)該比用Java編寫并且會(huì)出現(xiàn)GC暫停的HDFS更好。
Kudu論文提到，從理論上講，它可能支持可插拔的存儲(chǔ)布局。如果實(shí)施的存儲(chǔ)布局放棄了Kudu對(duì)提取單行寫入和舊數(shù)據(jù)寫入的支持，但更適合于時(shí)間序列存儲(chǔ)設(shè)計(jì)，則Kudu可能會(huì)成為比HDFS更好的存儲(chǔ)選項(xiàng)。
Cassandra或Scylla
每個(gè)數(shù)據(jù)分區(qū)可以存儲(chǔ)在類似Cassandra的系統(tǒng)中的單個(gè)條目中。從Cassandra的角度來(lái)看，列具有二進(jìn)制類型，并存儲(chǔ)數(shù)據(jù)分區(qū)的壓縮列。
該選項(xiàng)與Kudu共享許多優(yōu)點(diǎn)，甚至具有更好的優(yōu)點(diǎn)：出色的讀取可伸縮性，極低的延遲（尤其是如果使用ScyllaDB），表語(yǔ)義，僅下載所需列的能力（投影下推式）。
另一方面，類似Cassandra的系統(tǒng)并非設(shè)計(jì)用于多個(gè)MB的列值和大約100 MB的總行大小，并且在填充此類數(shù)據(jù)時(shí)可能開(kāi)始遇到操作問(wèn)題。而且，它們不支持在單行甚至單行中的單列級(jí)別上進(jìn)行流讀取，但可以在這些系統(tǒng)中相對(duì)容易地實(shí)現(xiàn)。
Cassandra旨在承受高寫入負(fù)載，因此使用類似LSM的存儲(chǔ)結(jié)構(gòu)和大量?jī)?nèi)存，在時(shí)間序列系統(tǒng)中用作存儲(chǔ)時(shí)將浪費(fèi)資源。
與我上面討論的其他選項(xiàng)相比，該選項(xiàng)最快，但成本效益最低。
將計(jì)算樹(shù)的節(jié)點(diǎn)重用為存儲(chǔ)（已在2019中添加）
請(qǐng)參閱此處的想法說(shuō)明。https://github.com/apache/druid/issues/8575
流處理系統(tǒng)
如上所述，Druid已經(jīng)將數(shù)據(jù)攝取與所謂的索引子系統(tǒng)或?qū)崟r(shí)節(jié)點(diǎn)中的存儲(chǔ)區(qū)分開(kāi)了。但是，盡管該索引子系統(tǒng)實(shí)現(xiàn)了完整的分布式流處理系統(tǒng)的功能的子集，但它并未利用其中的任何功能，甚至也沒(méi)有利用Mesos或YARN之類的資源管理器，并且一切都在Druid源代碼中完成。Druid的索引子系統(tǒng)的效率要比現(xiàn)代流處理系統(tǒng)低得多，因?yàn)閷?duì)其進(jìn)行的開(kāi)發(fā)工作少了數(shù)十倍。
同樣，時(shí)間序列數(shù)據(jù)通常在Druid之前的其他流處理系統(tǒng)中進(jìn)行組合或豐富。例如，沃爾瑪（Walmart）通過(guò)Storm來(lái)做到這一點(diǎn)，而Metamarkets將Samza用于類似目的。從本質(zhì)上講，這意味著兩個(gè)獨(dú)立的流處理系統(tǒng)正在數(shù)據(jù)管道中一個(gè)接一個(gè)地運(yùn)行，從而阻止了映射運(yùn)算符與Druid的提取終端運(yùn)算符的融合，這是流處理系統(tǒng)中的常見(jiàn)優(yōu)化。
這就是為什么我認(rèn)為在下一代時(shí)間序列中，數(shù)據(jù)提取應(yīng)充分利用某些現(xiàn)有的流處理系統(tǒng)。
流處理系統(tǒng)與其余時(shí)間序列存儲(chǔ)之間需要緊密集成，例如允許計(jì)算樹(shù)中的節(jié)點(diǎn)查詢流處理系統(tǒng)中的工作程序。這意味著與Storage的情況不同，它可能很難支持多個(gè)流處理系統(tǒng)。應(yīng)該只選擇一個(gè)，并將其與時(shí)間序列系統(tǒng)集成。
Flink，Storm和Heron都是可能的候選人。很難判斷當(dāng)前哪個(gè)技術(shù)更合適，或者說(shuō)在哪個(gè)技術(shù)上更合適，因?yàn)檫@些項(xiàng)目可以快速相互復(fù)制要素。如果設(shè)計(jì)的時(shí)間序列系統(tǒng)實(shí)際上是在某個(gè)組織中創(chuàng)建的，則選擇可能取決于該組織中已使用的流處理系統(tǒng)。
閱讀Druid Development郵件列表中的該線程，以獲取有關(guān)此主題的更多信息。
計(jì)算樹(shù)
對(duì)于系統(tǒng)的這一部分的外觀，我并不太費(fèi)勁。上面的“設(shè)計(jì)概述”部分介紹了一些可能的方法。
這種方法至少存在一個(gè)問(wèn)題：如果需要緩存太多查詢結(jié)果，則計(jì)算樹(shù)的第三（最高）級(jí)別的多個(gè)節(jié)點(diǎn)將無(wú)法有效地處理對(duì)特定時(shí)間序列（表）的查詢。為了始終將相似的子查詢（僅在總體查詢間隔上不同的子查詢）路由到相同的節(jié)點(diǎn)并捕獲緩存的結(jié)果，應(yīng)將具有多個(gè)子查詢的一個(gè)“復(fù)合”查詢分解為多個(gè)獨(dú)立的查詢，進(jìn)而使用網(wǎng)絡(luò)存儲(chǔ)和計(jì)算樹(shù)之間的效率較低：請(qǐng)參見(jiàn)上面的“網(wǎng)絡(luò)是瓶頸”部分，該列表中的第一項(xiàng)。
但是，可以在垂直方向上擴(kuò)展第三級(jí)計(jì)算樹(shù)中的節(jié)點(diǎn)，以使其足夠大，從而能夠處理所有查詢并容納任何單個(gè)時(shí)間序列（甚至最繁忙的時(shí)間序列）的整個(gè)緩存。
垂直擴(kuò)展意味著第三級(jí)計(jì)算樹(shù)中的一個(gè)節(jié)點(diǎn)應(yīng)處理大量并發(fā)查詢。這就是為什么我認(rèn)為如果從頭開(kāi)始構(gòu)建計(jì)算樹(shù)的原因之一，它應(yīng)該選擇異步服務(wù)器體系結(jié)構(gòu)而不是阻塞（Go風(fēng)格的綠色線程也可以）。其他兩個(gè)原因是：
第一層計(jì)算樹(shù)中的節(jié)點(diǎn)通過(guò)存儲(chǔ)執(zhí)行大量的網(wǎng)絡(luò)I / O。這些節(jié)點(diǎn)上的計(jì)算取決于來(lái)自Storage的數(shù)據(jù)到達(dá)，并具有不可預(yù)知的延遲：來(lái)自Storage的數(shù)據(jù)請(qǐng)求通常會(huì)得到重新排序的響應(yīng)。
計(jì)算樹(shù)所有級(jí)別的節(jié)點(diǎn)都應(yīng)支持增量查詢結(jié)果計(jì)算，并可能以很長(zhǎng)的間隔返回同一查詢的多個(gè)結(jié)果。如上文“網(wǎng)絡(luò)是瓶頸”一節(jié)所述，它使系統(tǒng)更具容錯(cuò)能力（在我的第一篇文章中討論了運(yùn)行Druid的挑戰(zhàn)），并使其變得更快。
平臺(tái)
理想情況下，構(gòu)建計(jì)算樹(shù)的編程平臺(tái)應(yīng)具有以下特征：
支持運(yùn)行時(shí)代碼生成，以使查詢更快地完成并提高CPU利用率。這篇有關(guān)Impala中運(yùn)行時(shí)代碼生成的博客文章對(duì)此進(jìn)行了很好的解釋。
出于相同的原因，生成的機(jī)器代碼應(yīng)該是“最佳”的，并在可能的情況下進(jìn)行矢量化處理。
較低的堆/對(duì)象內(nèi)存開(kāi)銷，因?yàn)閮?nèi)存昂貴，因此使計(jì)算樹(shù)中的節(jié)點(diǎn)更便宜。
始終較短的垃圾回收暫停（對(duì)于具有托管內(nèi)存的平臺(tái)），以支持設(shè)計(jì)的時(shí)間序列存儲(chǔ)的“一致查詢延遲”目標(biāo)。
從純技術(shù)角度來(lái)看，C 是贏家，它可以滿足所有這些要求。選擇C 與性能無(wú)關(guān)的缺點(diǎn)也是眾所周知的：開(kāi)發(fā)速度，可調(diào)試性，使用插件體系結(jié)構(gòu)擴(kuò)展系統(tǒng)都很困難等。
JVM仍然是一個(gè)不錯(cuò)的選擇，我相信該系統(tǒng)的效率可能比使用C 內(nèi)置的系統(tǒng)低不超過(guò)20％：
JVM允許搭載JIT編譯器以達(dá)到與運(yùn)行時(shí)代碼生成目標(biāo)相同的效果。
對(duì)于時(shí)間序列處理，主要在列解壓縮期間以及在數(shù)據(jù)上運(yùn)行特定聚合時(shí)需要代碼矢量化。兩者都可以在JNI函數(shù)中完成。當(dāng)為數(shù)十千字節(jié)的解壓縮數(shù)據(jù)支付一次時(shí)，JNI的開(kāi)銷相對(duì)較?。ㄎ覀兛赡芟Ｍ赃@種大小的塊進(jìn)行處理以適合L2緩存中的所有解壓縮數(shù)據(jù)）。巴拿馬項(xiàng)目將使此開(kāi)銷更小。如果將數(shù)據(jù)存儲(chǔ)在堆外內(nèi)存中并進(jìn)行處理，則垃圾回收的JNI含義也很小或根本不存在。
可以通過(guò)將所有網(wǎng)絡(luò)IO，數(shù)據(jù)存儲(chǔ)，緩沖和處理都放在堆外內(nèi)存中，從而使堆內(nèi)存很小，從而僅對(duì)每個(gè)查詢分配一些堆。
使用Shenandoah GC可以縮短垃圾收集的暫停時(shí)間。如果核心處理循環(huán)中使用的所有數(shù)據(jù)結(jié)構(gòu)都是非堆分配的，則堆內(nèi)存的讀取和寫入障礙不會(huì)對(duì)CPU利用率造成太大影響。
據(jù)我所知，盡管Go或Rust目前不支持運(yùn)行時(shí)代碼生成，盡管添加這種支持可能不需要太多的黑客操作：請(qǐng)參閱gojit項(xiàng)目以及有關(guān)Rust的StackOverflow問(wèn)題。對(duì)于其他條件，Go的運(yùn)行時(shí)和生成的代碼可能效率較低，但是出于某些非技術(shù)性原因，它比Rust更有效。
提議的時(shí)間序列系統(tǒng)的缺點(diǎn)
該系統(tǒng)感覺(jué)不像是一個(gè)單一的“數(shù)據(jù)庫(kù)”，它具有三個(gè)獨(dú)立的子系統(tǒng)，其中活動(dòng)部件的總數(shù)很高，這使其在小規(guī)模上效率不高，難以部署和更新。
將系統(tǒng)與現(xiàn)有的說(shuō)SQL的接口有效地集成可能是一個(gè)挑戰(zhàn)，因?yàn)橄到y(tǒng)需要對(duì)同一張表運(yùn)行帶有許多獨(dú)立子查詢的“復(fù)合”查詢。
該系統(tǒng)不適用于需要對(duì)查詢的響應(yīng)速度超過(guò)一秒的用例。
系統(tǒng)的性能高度依賴于部署它的數(shù)據(jù)中心中的網(wǎng)絡(luò)性能。
在某些用例中，無(wú)法在第三級(jí)計(jì)算樹(shù)中水平縮放節(jié)點(diǎn)可能是主要的可伸縮性瓶頸。
(本文由聞數(shù)起舞翻譯自828 Followers的文章《Design of a Cost Efficient Time Series Store for Big Data》，轉(zhuǎn)載請(qǐng)注明出處，原文鏈接：https://leventov./design-of-a-cost-efficient-time-series-store-for-big-data-88c5dc41af8e)
