【萬字干貨】OpenMetric與時序數(shù)據(jù)庫存儲模型分析（下）
主流TSDB分析
InfluxDB
InfluxDB[9]是一個一站式的時序工具箱，包括了時序平臺所需的一切：多租戶時序數(shù)據(jù)庫、UI和儀表板工具、后臺處理和監(jiān)控數(shù)據(jù)采集器。如下圖9所示。
圖9
InfluxDB支持動態(tài)shcema，也就是在寫入數(shù)據(jù)之前，不需要做schema定義。因此，用戶可以隨意添加measurement、tag和field，可以是任意數(shù)量的列。
InfluxDB底層的存儲引擎經(jīng)歷了從LevelDB到BlotDB，再到自研TSM的歷程。從v1.3起，采用的是基于自研的WAL + TSMFile + TSIFile方案，即所謂的TSM（Time-Structured Merge Tree）引擎。其思想類似LSM，針對時序數(shù)據(jù)的特性做了一些特殊優(yōu)化。TSM的設計目標一是解決LevelDB的文件句柄過多問題，二是解決BoltDB的寫入性能問題。
Cache: TSM的Cache與LSM的MemoryTable類似，其內(nèi)部的數(shù)據(jù)為WAL中未持久化到TSM File的數(shù)據(jù)。若進程故障failover，則緩存中的數(shù)據(jù)會根據(jù)WAL中的數(shù)據(jù)進行重建。
WAL (Write Ahead Log) : 時序數(shù)據(jù)寫入內(nèi)存之后按照SeriesKey進行組織。數(shù)據(jù)會先寫入WAL，再寫入memory-index和cache，最后刷盤，以保證數(shù)據(jù)完整性和可用性。基本流程包括：根據(jù)Measurement和TagKV拼接出乎series key；檢查該series key是否存在；如果存在，就直接將時序數(shù)據(jù)寫入WAL、時序數(shù)據(jù)寫緩存；如果不存在，就會在Index WAL中寫入一組entry；依據(jù)series key所包含的要素在內(nèi)存中構建倒排索引、接著把時序數(shù)據(jù)寫入WAL和緩存。
TSM Files: TSM File與LSM的SSTable類似。在文件系統(tǒng)層面，每一個TSMFile對應了一個 Shard，單個最大2GB。一個TSM File中，有存放時序數(shù)據(jù)（i.e Timestamp + Field value）的數(shù)據(jù)區(qū)，有存放Serieskey和Field Name信息的索引區(qū)。基于 Serieskey + Fieldkey構建的形似B+tree的文件內(nèi)索引，通過它就能快速定位到時序數(shù)據(jù)所在的數(shù)據(jù)塊。在TSMFile中，索引塊是按照 Serieskey + Fieldkey 排序 后組織在一起的。
TSI Files：用戶如果沒有按預期根據(jù)Series key來指定查詢條件，比如指定了更加復雜的查詢條件，技術手段上通常是采用倒排索引來確保它的查詢性能的。由于用戶的時間線規(guī)模會變得很大，會造成倒排索引消耗過多的內(nèi)存。對此InfluxDB引入了TSIfiles。TSIFile的整體存儲機制與TSMFile相似，也是以 Shard 為單位生成一個TSIFile。
在InfluxDB中有一個對標傳統(tǒng)RDB的Database概念。邏輯上每個Database下面可以有多個measurement。在單機版中每個Database實際對應了一個文件系統(tǒng)的目錄。
InfluxDB作為時序數(shù)據(jù)庫，必然包括時序數(shù)據(jù)存儲和一個用于度量、標記和字段元數(shù)據(jù)的倒排索引，以提供更快速的多維查詢。InfluxDB在TSMFile上按照下面的步驟掃描數(shù)據(jù)，以獲得高性能查詢效果：
? 根據(jù)用戶指定的時間線（Serieskey）和FieldKey在索引區(qū)找到Serieskey+FieldKey所在的 索引數(shù)據(jù)塊。
? 根據(jù)用戶指定的時間戳范圍在索引數(shù)據(jù)塊中查找數(shù)據(jù)對應在哪個或哪幾個索引條目
? 把檢索出的索引條目所對應的時序數(shù)據(jù)塊加載到內(nèi)存中進一步掃描獲得結果
和 Prometheus 一樣，InfluxDB 數(shù)據(jù)模型有鍵值對作為標簽，稱為標簽。InfluxDB 支持分辨率高達納秒的時間戳，以及 float64、int64、bool 和 string 數(shù)據(jù)類型。相比之下，Prometheus 支持 float64 數(shù)據(jù)類型，但對字符串和毫秒分辨率時間戳的支持有限。InfluxDB 使用日志結構合并樹的變體來存儲帶有預寫日志，按時間分片。這比 Prometheus 的每個時間序列的僅附加文件方法更適合事件記錄。
Prometheus
下圖是Prometheus官方架構圖[10]，包括了一部分生態(tài)組件，它們大多是可選項。其中最核心的是Prometheus 服務器，它負責抓取和存儲時間序列數(shù)據(jù)，并對這些數(shù)據(jù)應用規(guī)則，從而聚合出新的時間序列或生成警報，并記錄存儲它們。
圖10
TSDB是Prometheus的關鍵內(nèi)核引擎。最新的V3引擎[7]相當于面向TSDB場景優(yōu)化后的LSM（Log Structured Merge Tree，結構化合并樹）。LSM樹核心思想的核心就是放棄部分讀能力，換取寫入的最大化能力；其假設前提就是內(nèi)存足夠大。通常LSM-tree適用于索引插入比檢索更頻繁的應用系統(tǒng)。V3存儲引擎也采用了Gorilla論文思想。它包括了下面幾個TSDB組件：塊頭（Head Block）、預寫日志W(wǎng)AL及檢查點、磁盤上Chunk頭的內(nèi)存映射、持久化block及其索引和查詢模塊。下圖11是Prometheus的磁盤目錄結構。
圖11
在V3引擎中一個chunk內(nèi)會包含很多的時間線（Time series）。Chunk目錄下的樣本數(shù)據(jù)分組為一個或者多個段（segment），每個缺省不超過512MB。index是這個block下的chunk目錄中的時間線按照指標名稱和標簽進行索引，從而支持根據(jù)某個label快速定位到時間線以及數(shù)據(jù)所在的chunk。meta.json是一個簡單的關于block數(shù)據(jù)和狀態(tài)的一個描述文件。Chunks_head負責對chunk索引，uint64索引值由文件內(nèi)偏移量（下4個字節(jié)）和段序列號（上4個字節(jié)）組成。
Prometheus將數(shù)據(jù)按時間維度切分為多個block。只有最近的一個block允許接收新數(shù)據(jù)。最新的block要寫入數(shù)據(jù)，會先寫到一個內(nèi)存結構中，為了保證數(shù)據(jù)不丟失，會先寫一份預寫日志文件WAL，按段（大小128MB ）存儲在目錄中。它們是未壓縮的原始數(shù)據(jù)，因此文件大小明顯大于常規(guī)塊文件。Prometheus 將保留三個或者多個WAL文件，以便保留至少兩個小時的原始數(shù)據(jù)。
V3引擎將2個小時作為塊（block）的默認塊持續(xù)時間；也就是塊按2h跨度來分割（這是個經(jīng)驗值）。V3也是采用了LSM一樣的compaction策略來做查詢優(yōu)化，把小的block合并為大的block。對于最新的還在寫數(shù)據(jù)的block，V3引擎則會把所有的索引全部hold在內(nèi)存，維護一個內(nèi)存結構，等到該block關閉再持久化到文件。針對內(nèi)存熱數(shù)據(jù)查詢，效率非常高。
Prometheus官方再三強調(diào)了它的本地存儲并不是為了持久的長期存儲；外部解決方案提供延長的保留時間和數(shù)據(jù)持久性。社區(qū)有多種集成方式嘗試解決這個問題。比如Cassandra、DynamoDB等。
通過指標實現(xiàn)應用的可觀察性（observability）是IT監(jiān)控運維系統(tǒng)的第一步。指標提供匯總視圖，再結合日志提供的有關每個請求或事件的明細信息。這樣更容易幫助問題的發(fā)現(xiàn)與診斷。
Prometheus 服務器彼此獨立運行，僅依賴其本地存儲來實現(xiàn)其核心功能：抓取、規(guī)則處理和警報。也就是說，它不是面向分布式集群的；或者說當前它的分布式集群能力是不夠強大的。社區(qū)的Cortex、Thanos等開源項目就是針對Prometheus的不足而涌現(xiàn)出來的成功解決方案。
Druid
Druid[11]是有名的實時OLAP分析引擎。Druid的架構設計比較簡潔（如下圖12）。集群中節(jié)點分3類：Master節(jié)點、Query節(jié)點和Data節(jié)點。
圖12
Druid數(shù)據(jù)存儲在datasource中，類似于傳統(tǒng)RDBMS中的表（table）。每個datasource都按時間（其他屬性也可以）分區(qū)（partition）。每個時間范圍稱為一個“塊（Chunk）”（例如，一天，如果您的數(shù)據(jù)源按天分區(qū)）。在一個Chunk內(nèi)，數(shù)據(jù)被分成一個或多個 “段（Segment）”。每個段都是一個文件，通常包含多達幾百萬行數(shù)據(jù)。如下圖13所示。
圖13
Segment的目的在于生成緊湊且支持快速查詢的數(shù)據(jù)文件。這些數(shù)據(jù)在實時節(jié)點MiddleManager上產(chǎn)生，而且可變的且未提交的。在這個階段，主要包括了列式存儲、bitmap索引、各種算法進行壓縮等。這些Segment（熱數(shù)據(jù)）會被定期提交和發(fā)布；然后被寫入到DeepStorage（可以是本地磁盤、AWS的S3，華為云的OBS等）中。Druid與HBase類似也采用了LSM結構，數(shù)據(jù)先寫入內(nèi)存再flush到數(shù)據(jù)文件。Druid編碼是局部編碼，是文件級別的。這樣可以有效減小大數(shù)據(jù)集合對內(nèi)存的巨大壓力。這些Segment數(shù)據(jù)一方面被MiddleManager節(jié)點刪除，一方面被歷史節(jié)點（Historical）加載。與此同時，這些Segment的條目也被寫入元數(shù)據(jù)（Metadata）存儲。Segment的自描述元數(shù)據(jù)包括了段的架構、其大小及其在深度存儲中的位置等內(nèi)容。這些元數(shù)據(jù)被協(xié)調(diào)器（Coordinator）用來進行查詢路由的。
Druid 將其索引存儲在按時間分區(qū)的Segment文件中。Segment文件大小推薦在 300MB-700MB 范圍內(nèi)。Segment文件的內(nèi)部結構，它本質(zhì)上是列存的：每一列的數(shù)據(jù)被布置在單獨的數(shù)據(jù)結構中。通過單獨存儲每一列，Druid 可以通過僅掃描查詢實際需要的那些列來減少查詢延遲。共有三種基本列類型：時間戳列、維度列和指標列，如下圖14所示：
圖14
維度（Dimension）列需要支持過濾和分組操作，所以每個維度都需要以下三種數(shù)據(jù)結構：
1) 將值（始終被視為字符串）映射到整數(shù) ID 的字典，
2) 列值的列表，使用 1 中的字典編碼。 【服務于group by和TopN查詢】
3) 對于列中的每個不同值，一個指示哪些行包含該值的位圖（本質(zhì)就是倒排索引，inverted index）。【服務于快速過濾，方便AND和OR運算】
Druid中每列存儲包括兩部分：Jackson 序列化的 ColumnDescriptor和該列的其余二進制文件。 Druid強烈推薦默認使用LZ4壓縮字符串、long、float 和 double 列的值塊，使用Roaring壓縮字符串列和數(shù)字空值的位圖。尤其在高基數(shù)列場景中匹配大量值的過濾器上Roaring?壓縮算法要快得多（對比CONCISE?壓縮算法）。
值得一提的是Druid支持Kafka Indexing Service插件（extension），實現(xiàn)實時攝入（ingestion）任務，那么此時可以立即查詢該segment，盡管該segment并沒有發(fā)布（publish）。這更能滿足對數(shù)據(jù)的產(chǎn)生到可查詢可聚合分析的實時性要求。
Druid另外一個重要特性就是在數(shù)據(jù)寫入的時候，可以開啟rollup功能，將選定的所有dimensions 按照你指定的最小時間間隔粒度（比如1分鐘，或者5分鐘等）進行聚合。這樣可以極大的減少需要存儲的數(shù)據(jù)大小，缺點是原始的每條數(shù)據(jù)就被丟棄了，不能進行明細查詢了。
Druid為了讓查詢更高效，有如下設計考慮。
? Broker修剪每個查詢訪問哪些Segment：它是 Druid 限制每個查詢必須掃描的數(shù)據(jù)量的重要方式。首先查詢先進入Broker，Broker 將識別哪些段具有可能與該查詢有關的數(shù)據(jù)。然后，Broker 將識別哪些Historian和 MiddleManager正在為這些段提供服務，并向這些進程中的每一個發(fā)送重寫的子查詢。Historical/MiddleManager 進程將接收查詢、處理它們并返回結果。Broker 接收結果并將它們合并在一起以獲得最終答案，并將其返回給原始調(diào)用者。
? Segment內(nèi)利用索引過濾：每個Segment內(nèi)的索引結構允許 Druid 在查看任何數(shù)據(jù)行之前確定哪些（如果有）行與過濾器集匹配。
? Segment內(nèi)只讀取特定關聯(lián)的行和列：一旦 Druid 知道哪些行與特定查詢匹配，它只會訪問該查詢所需的特定列。在這些列中，Druid可以從一行跳到另一行，避免讀取與查詢過濾器不匹配的數(shù)據(jù)。
時間戳也是Druid數(shù)據(jù)模型的必備項。盡管Druid不是時序數(shù)據(jù)庫，但它也是存儲時序數(shù)據(jù)的自然選擇。Druid數(shù)據(jù)模型可以支持在同一個datasource中，可以同時存放時序數(shù)據(jù)和非時序數(shù)據(jù)。因此，Druid不認為數(shù)據(jù)點是“時間序列”的一部分，而是將每個點單獨處理以進行攝入和聚合。比如正統(tǒng)的TSDB支持的時序數(shù)據(jù)插值計算，在Druid中就不復存在的必要了。這會給一些業(yè)務場景的處理帶來很大的便利性。
IoTDB
Apache IoTDB[12] 始于清華大學軟件學院，2020年9月為 Apache 孵化器項目。IoTDB 是一個用于管理大量時間序列數(shù)據(jù)的數(shù)據(jù)庫，它采用了列式存儲、數(shù)據(jù)編碼、預計算和索引技術，具有類 SQL 的接口，可支持每秒每節(jié)點寫入數(shù)百萬數(shù)據(jù)點，可以秒級獲得超過數(shù)萬億個數(shù)據(jù)點的查詢結果。主要面向工業(yè)界的IoT場景。
IoTDB 套件由若干個組件構成，共同形成數(shù)據(jù)收集、數(shù)據(jù)攝入、數(shù)據(jù)存儲、數(shù)據(jù)查詢、數(shù)據(jù)可視化、數(shù)據(jù)分析等一系列功能。如下圖15所示：
圖15
IoTDB 特指其中的時間序列數(shù)據(jù)庫引擎；其設計以設備、傳感器為核心，為了方便管理和使用時序數(shù)據(jù)，增加了存儲組（storage group的概念）。
存儲組(Storage Group): IoTDB提出的概念，類似于關系數(shù)據(jù)庫中的Database的概念。一個存儲組中的所有實體的數(shù)據(jù)會存儲在同一個文件夾下，不同存儲組的實體數(shù)據(jù)會存儲在磁盤的不同文件夾下，從而實現(xiàn)物理隔離。對IoTDB內(nèi)部實現(xiàn)而言，存儲組是一個并發(fā)控制和磁盤隔離的單位，多個存儲組可以并行讀寫。對用戶而言，方便了對設備數(shù)據(jù)的分組管理和方便使用。
設備 (Device)：對應現(xiàn)實世界中的具體物理設備，比如飛機發(fā)動機等。在IoTDB中, device是時序數(shù)據(jù)一次寫入的單位，一次寫入請求局限在一個設備中。
傳感器(Sensor): 對應現(xiàn)實世界中的具體物理設備自身攜帶的傳感器，例如：風力發(fā)電機設備上的風速、轉向角、發(fā)電量等信息采集的傳感器。在IoTDB中，Sensor也稱為測點（Measurement）。
測點/物理量（Measurement，也稱工況、字段 field）：一元或多元物理量，是在實際場景中傳感器采集的某時刻的測量數(shù)值，在IoTDB內(nèi)部采用
IoTDB的存儲由不同的存儲組構成。每個存儲組是一個并發(fā)控制和資源隔離單位。每個存儲組里面包括了多個Time Partition。其中，每個存儲組對應一個WAL預寫日志文件和TsFile時序數(shù)據(jù)存儲文件。每個Time Partition中的時序數(shù)據(jù)先寫入Memtable，同時記入WAL，定時異步刷盤到TsFile。這就是所謂的tLSM時序處理算法。
攝入性能方面：IoTDB 具有最小的寫入延遲。批處理大小越大，IoTDB 的寫入吞吐量就越高。這表明 IoTDB 最適合批處理數(shù)據(jù)寫入方案。在高并發(fā)方案中，IoTDB 也可以保持吞吐量的穩(wěn)定增長（受網(wǎng)卡、網(wǎng)絡帶寬約束）。
聚合查詢性能方面：在原始數(shù)據(jù)查詢中，隨著查詢范圍的擴大，IoTDB 的優(yōu)勢開始顯現(xiàn)。因為數(shù)據(jù)塊的粒度更大，列式存儲的優(yōu)勢體現(xiàn)出來，所以基于列的壓縮和列迭代器都將加速查詢。在聚合查詢中，IoTDB使用文件層的統(tǒng)計信息并緩存統(tǒng)計信息。多個查詢只需要執(zhí)行內(nèi)存計算，聚合性能優(yōu)勢明顯。
數(shù)據(jù)存儲對比
基于前面的分析，我們嘗試用下面的表格對比來說明這些時序數(shù)據(jù)處理系統(tǒng)的特點。
比較項
Prometheus
InfluxDB
Druid
IoTDB
OpenTSDB
數(shù)據(jù)模型
Labels
Labels
Labels
Tree schema
Labels
存儲引擎
優(yōu)化LSM
TSM
LSM
tLSM
Hbase
存算分離
基本支持
支持
支持
支持
支持
分區(qū)
支持
支持
支持
支持
支持
查詢引擎
PromQL
InfluxQL/Flux
Druid SQL
SQL/JDBC
OpenTSDB
降精度/rollup
X
支持
很強
支持
X
聚合速度
慢
慢
快
快
慢
分布式集群
Cortex等
商業(yè)版
很強
支持
支持
實時流計算
X
弱
支持
支持
X
表3
對于時序數(shù)據(jù)的處理，關鍵能力主要包括數(shù)據(jù)模型定義、存儲引擎、與存儲緊密協(xié)作的查詢引擎和支持分區(qū)擴展的架構設計。主流的TSDB基本都是基于LSM或者結合時序數(shù)據(jù)場景專門優(yōu)化的LSM tree來實現(xiàn)（包括InfluxDB號稱的TSM，IoTDB的tLSM，本質(zhì)上都還是LSM機制）。其中只有IoTDB獨創(chuàng)采用了tree schema來對時序數(shù)據(jù)建模。為了追求極致性能和極致成本，大家都在針對海量數(shù)據(jù)和使用場景，持續(xù)改進和優(yōu)化數(shù)據(jù)的存儲結構設計、各種高效索引機制、和查詢效率。從單點技術或者關鍵技術上來講，有趨同性和同質(zhì)化的大趨勢。
云廠商最新動態(tài)
除了開源社區(qū)推陳出新外，國內(nèi)外眾多云服務廠商也陸續(xù)發(fā)布了相關的時序數(shù)據(jù)庫產(chǎn)品或者服務。
華為云
華為云的GaussDB for Influx[13]云服務，基于InfluxDB進行深度優(yōu)化改造，在架構、性能和數(shù)據(jù)壓縮等方面進行了技術創(chuàng)新，取得了很好的效果。實現(xiàn)了存儲與計算分離架構，其中采用了華為云自研的高性能分布式存儲系統(tǒng)，顯著提升了時序數(shù)據(jù)庫的可靠性；同時方便計算節(jié)點分鐘級擴容和存儲空間的秒級擴容，同時大幅降低存儲成本。支持億級時間線（開源的能力在千萬時間線級別），寫入性能基本保持穩(wěn)定；能夠支持更高的高散列聚合查詢性能；在壓縮算法上，相比原生的InfluxDB，重點針對Float、String、Timestamp這三種數(shù)據(jù)類型進行了優(yōu)化和改進。。
華為云MRS云服務包含了IoTDB[14]，其中 IoTDB定位為面向工業(yè)設備、工業(yè)現(xiàn)場的時序數(shù)據(jù)庫庫。IoTDB優(yōu)化后性能更好，千萬級數(shù)據(jù)點秒級寫入，TB級數(shù)據(jù)毫秒級查詢；優(yōu)化后的數(shù)據(jù)壓縮比可達百倍，進一步節(jié)省存儲空間和成本；通過采用對等分布式架構，雙層多Raft協(xié)議，邊云節(jié)點同步雙活，做到7*24小時高可用。在工業(yè)化場景，真正做到一份時序數(shù)據(jù)兼容全場景、一套時序引擎打通云邊端和一套框架集成云邊端。
阿里云
據(jù)公開資料[15]，阿里云時序時空數(shù)據(jù)庫TSDB的發(fā)展演變經(jīng)歷了三個階段。在v1.0階段基于OpenTSDB，底層實現(xiàn)了雙引擎——HBase和HiStore。在v2.0階段中，把OpenTSDB引擎換成了自研的TSDB引擎，彌補了OpenTSDB不支持的倒排索引、面向時序場景的特殊編碼、分布式流計算聚合函數(shù)等特性。隨后實現(xiàn)了云和邊緣計算一體化，TSQL兼容Prometheus生態(tài)。其中TSDB for Spatial Temporal支持時空數(shù)據(jù)，它基于自研的S3時空索引和高性能電子圍欄。最新TSDB同樣基于 Gorilla, 將單個數(shù)據(jù)點的平均使用存儲空間降為1~2個字節(jié)，可以降低90%存儲使用空間，同時加快數(shù)據(jù)寫入的速度。對于百萬數(shù)據(jù)點的讀取，響應時間小于 5 秒，且最高可以支撐每秒千萬數(shù)據(jù)點的寫入。相較于開源的 OpenTSDB 和 InfluxDB，讀寫效率提升了數(shù)倍，同時兼容 OpenTSDB 數(shù)據(jù)訪問協(xié)議。
騰訊云
騰訊云也推出了TencentDB for CTSDB[16]云服務，它是一款分布式、可擴展、支持近實時數(shù)據(jù)搜索與分析的時序數(shù)據(jù)庫，兼容 Elasticsearch 常用的 API 接口和生態(tài)。它支撐了騰訊內(nèi)部20多個核心業(yè)務。性能方面可以做到每秒千萬級數(shù)據(jù)點寫入，億級數(shù)據(jù)秒級分析。CTSDB也是采用LSM機制，先寫內(nèi)存再周期性刷寫到存儲；然后通過倒排索引加速任意維度數(shù)據(jù)查詢，能實現(xiàn)數(shù)據(jù)秒級可查。也支持像histogram、percentile、cardinality這樣的通用聚合計算函數(shù)；也通過配置 Rollup 任務定時聚合歷史數(shù)據(jù)保存至新的數(shù)據(jù)表，實現(xiàn)降精度（Downsampling）特性。在集群中節(jié)點數(shù)量超過30個時，需要新購集群或者將通用集群架構優(yōu)化升級為混合節(jié)點集群架構，以保證多節(jié)點超大集群的性能穩(wěn)定。從這些特性推斷，CTSDB內(nèi)核應該是借鑒了ElasticSearch內(nèi)核深度優(yōu)化經(jīng)驗的基礎上構建的時序數(shù)據(jù)庫能力。
國內(nèi)其他廠商
除了云服務廠商提供的開箱即用的云服務外，還有一些創(chuàng)新型產(chǎn)品涌現(xiàn)出來，比較有名的包括TDengine[17]、字節(jié)跳動的TerarkDB[18]、DolphinDB[19]等等。他們也在快速演進發(fā)展中，值得大家持續(xù)跟蹤關注，尤其是國內(nèi)孵化出來的一些TSDB產(chǎn)品。
總結與展望
InfluxDB、IoTDB和OpenTSDB等除了社區(qū)版本外，也有云廠商提供原生InfluxDB（阿里云TSDB for InfluxDB）、IoTDB（華為云MRS IoTDB）或OpenTSDB（華為云MRS OpenTSDB）云化服務，方便使用。更主流的做法是各云廠商根據(jù)自身的技術沉淀和研發(fā)實力，借鑒、優(yōu)化甚至重新研發(fā)了時序數(shù)據(jù)庫內(nèi)核，能提供更強的集群能力，更高性能寫入，更快的查詢和聚合分析能力。國外廠商AWS有Timestream[20]，一種Serverless時序數(shù)據(jù)庫服務，國內(nèi)華為云的GaussDB for Influx，匯聚頂級數(shù)據(jù)庫專家團隊打造的新一代時空分析數(shù)據(jù)庫；騰訊云的TencentDB for CTSDB，兼容ES生態(tài)；阿里云的HiTSDB等等。這些開箱即用的、可擴展的、高可用的時序數(shù)據(jù)庫，為云原生應用的開發(fā)與部署帶來了福音，無需管理底層基礎設施，只需專注于業(yè)務構建。
Promeheus發(fā)展過程中，其需要長期保存的歷史數(shù)據(jù)（long-term）存儲是其短板之一。業(yè)界有一些折中的集成方案。比如采用Cassandra作為Prometheus的持久化存儲；還有采用InfluxDB作為Prometheus的持久化存儲，一方面充分利用Prometheus監(jiān)控相關能力和社區(qū)生態(tài)（包括支持分布式集群的Cortex）；另一方面利用好InfluxDB時序數(shù)據(jù)庫優(yōu)點，尤其是超PB級的分布式數(shù)據(jù)庫能力，以彌補Prometheus在海量歷史數(shù)據(jù)存儲上的短板。
Apache Druid在OLAP即時分析領域有著很強的競爭力，也為眾多大廠所采用。業(yè)界最大的集群擁有4000多個節(jié)點。不管是時序指標，還是業(yè)務數(shù)據(jù)，應用日志等，都可以利用Druid的Kafka Indexing Service和其強大的數(shù)據(jù)預處理能力，轉換為時序數(shù)據(jù)進入Druid。目前Druid SQL特性發(fā)展也很快，包括跨表join，subquery和眾多函數(shù)、算子的持續(xù)豐富。
不管是正統(tǒng)的時序數(shù)據(jù)庫，還是適合時序數(shù)據(jù)的OLAP分析系統(tǒng)；不管是開源社區(qū)的熱門項目，還是云廠商提供更強大的云原生時序數(shù)據(jù)庫，都為各種時序數(shù)據(jù)（包括指標、業(yè)務數(shù)據(jù)）的存儲、檢索和分析提供多樣化的選擇。用戶結合自己的業(yè)務場景，一定能找到相對適合的工具或服務，滿足業(yè)務訴求。
參考資料
[9]????https://www.influxdata.com/products/influxdb/
[10]????https://prometheus.io/docs/introduction/overview/
[11]????https://druid.apache.org/docs/latest/design/architecture.html
[12]????https://iotdb.apache.org/SystemDesign/Architecture/Architecture.html
[13]????https://bbs.huaweicloud.com/blogs/252115
[14]????https://bbs.huaweicloud.com/blogs/280948
[15]????https://developer.aliyun.com/article/692580
[16]????https://cloud.tencent.com/developer/article/1010045
[17]????https://www.taosdata.com/cn/
[18]????https://github.com/bytedance/terarkdb
[19]????https://www.dolphindb.cn/
[20]????https://aws.amazon.com/cn/timestream
【萬字干貨】OpenMetric與時序數(shù)據(jù)庫存儲模型分析（上）
云數(shù)據(jù)庫 GaussDB(for Influx) 數(shù)據(jù)庫 軟件開發(fā)
版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。
相關文章
