作者介紹黃杰，2015年加入餓了么，現(xiàn)任框架工具部高級開發(fā)經(jīng)理，主要負(fù)責(zé)餓了么的監(jiān)控系統(tǒng)及監(jiān)控系統(tǒng)周邊的工具。

一、背景

餓了么對時序數(shù)據(jù)庫的需求主要來自各監(jiān)控系統(tǒng)，主要用于存儲監(jiān)控指標(biāo)。原來使用的是graphite，后來慢慢對指標(biāo)有了多維的需求，主要體現(xiàn)在對一個指標(biāo)加多個Tag來組成Series，然后對Tag進(jìn)行Filter和Group進(jìn)行計算，這時graphite基本很難滿足需求。

業(yè)界現(xiàn)在用的比較多的主要有如下幾類TSDB：

• InfluxDB：很多公司都在用，包括餓了么有部分監(jiān)控系統(tǒng)也是用的InfluxDB。其優(yōu)點在于支持多維和多字段，存儲也根據(jù)TSDB的特點做了優(yōu)化，不過開源的部分并不支持。很多公司自己做集群化，但大多基于指標(biāo)名來，這樣就會有單指的熱點問題?，F(xiàn)在餓了么也是類似的做法，但熱點問題很嚴(yán)重，大的指標(biāo)已經(jīng)用了***的服務(wù)器，可查詢性能還是不夠理想，如果做成按Series Sharding，那成本還是有一點高；
• Graphite：根據(jù)指標(biāo)寫入及查詢，計算函數(shù)很多，但很難支持多維，包括機房或多集群的查詢。原來餓了么把業(yè)務(wù)層的監(jiān)控指標(biāo)存儲在Graphite中，并工作的很好，不過多活之后基本已經(jīng)很難滿足一些需求了，由于其存儲結(jié)構(gòu)的特點，很占IO，根據(jù)目前線上的數(shù)據(jù)寫放大差不多幾十倍以上；
• OpenTSDB：基于HBase，優(yōu)點在于存儲層不用自己考慮，做好查詢聚合就可以，也會存在HBase的熱點問題等。在以前公司也用基于HBase實現(xiàn)的TSDB來解決OpenTSDB的一些問題， 如熱點、部分查詢聚合下放到HBase等，目的是優(yōu)化其查詢性能，但依賴HBase/HDFS還是很重；
• HiTSDB：阿里提供的TSDB，存儲也是用HBase，在數(shù)據(jù)結(jié)構(gòu)及Index上面做了很多優(yōu)化，具體沒有研究，有興趣的同學(xué)可以在阿里云上試一下；
• Druid：Druid其實是一個OLAP系統(tǒng)，但也可以用來存儲時間序列數(shù)據(jù)，不過看到它的架構(gòu)圖時已經(jīng)放棄了；
• ElasticSearch（ES）：也有公司直接用ES來存儲，沒有實際測試，但總覺得ES不是一個真正的TSDB；
• atlas：Netflix出品，全內(nèi)存TSDB，最近幾小時數(shù)據(jù)全在內(nèi)存中，歷史數(shù)據(jù)需要外部存儲，具體沒有詳細(xì)研究；
• beringei：Facebook出品，同樣是全內(nèi)存TSDB，最近的數(shù)據(jù)也在內(nèi)存，目前應(yīng)該還在孵化期。

最終我們還是決定自己實現(xiàn)一套分布式時序數(shù)據(jù)庫，具體需要解決如下問題：

• 輕量，目前只依賴于Zookeeper；
• 基于Series進(jìn)行Sharding，解決熱點，可以真正水平擴(kuò)展；
• 實時寫入、實時查詢，由于大多用于監(jiān)控系統(tǒng)，所以查詢性能要好；
• 由于餓了么目前是多活，監(jiān)控系統(tǒng)也是多活，所以要支持單機房寫入，多機房聚合查詢等；
• 要有自動的Rollup功能，如用戶可以寫10s的精度，系統(tǒng)自動Rollup到分鐘、小時、天級別，以支持大時間范圍的查詢，如報表等；
• 支持類SQL的查詢方式；
• 支持多副本，以提高整個系統(tǒng)的可靠性，只要還有一個副本存活就可以正常提供服務(wù)，副本數(shù)指定。

二、整體設(shè)計

采用計算和存儲分離的架構(gòu)，分為計算層LinProxy和存儲層LinStorage。

說明：

• LinProxy主要做一些SQL的解析及一些中間結(jié)合的再聚合計算，如果不是跨集群，LinProxy可以不需要，對于單集群的每個節(jié)點都內(nèi)嵌了一個LinProxy來提供查詢服務(wù)；
• LinDB Client主要用于數(shù)據(jù)的寫入，也有一些查詢的API；
• LinStorage的每個節(jié)點組成一個集群，節(jié)點之間進(jìn)行復(fù)制，并有副本的Leader節(jié)點提供讀寫服務(wù)，這點設(shè)計主要是參考Kafka的設(shè)計，可以把LinDB理解成類Kafka的數(shù)據(jù)寫入復(fù)制+底層時間序列的存儲層；
• LinMaster主要負(fù)責(zé)database、shard、replica的分配，所以LinStorage存儲的調(diào)度及MetaData（目前存儲Zookeeper中）的管理；由于LinStorage Node都是對等的，所以我們基于Zookeeper在集群的節(jié)點選一個成為Master，每個Node把自身的狀態(tài)以心跳的方式上報到Master上，Master根據(jù)這些狀態(tài)進(jìn)行調(diào)度，如果Master掛了，自動再選一個Master出來，這個過程基本對整個服務(wù)是無損的，所以用戶基本無感知。

1、寫入

整個寫過程分為如下2部分組成：

• WAL復(fù)制，這部分設(shè)計上參考了Kafka，用戶的寫入只要寫入WAL成功，就認(rèn)為成功（由于主要用于監(jiān)控系統(tǒng)，所以對數(shù)據(jù)的一致性沒有做太多的保證），這樣就可以提供系統(tǒng)的寫入吞吐；
• 本地寫入，這個過程是把WAL的數(shù)據(jù)解析寫入到自己的存儲結(jié)構(gòu)中，只有寫入本地存儲的數(shù)據(jù)才可以查到。

整個過程不像一些系統(tǒng)在每次寫的過程中完成，我們是把這個過程分2步，并異步化了。

WAL復(fù)制

目前LinDB的replica復(fù)制協(xié)議采用多通道復(fù)制協(xié)議，主要基于WAL在多節(jié)點之間的復(fù)制，WAL在每個節(jié)點上的寫入有獨立的寫操作完成，所以對于Client寫入對應(yīng)Leader的WAL成功就認(rèn)為本次寫操作是成功的，Leader所在的節(jié)點負(fù)責(zé)把相應(yīng)的WAL復(fù)制到對應(yīng)的Follower，同理寫WAL成功認(rèn)為復(fù)制成功，如下所示：

多通道復(fù)制協(xié)議

寫入Leader副本成功就算成功，提高了寫入速率，也帶來了以下問題：

• 數(shù)據(jù)一致性的問題；
• 數(shù)據(jù)的丟失問題。

以上圖Server1為Leader，3個Replication來復(fù)制1-WAL為例來說：

當(dāng)前Server1是該shard的Leader接受Client的寫入，Server2和Server3都是Follower接受Server1的復(fù)制請求，此時1-WAL通道作為當(dāng)前的數(shù)據(jù)寫入通道，Server2和Server3可能落后于Server1。

說明：

整個過程需要注意以下幾個Index：

• Client寫入時的Append Index，表示當(dāng)前Client寫入到哪里；
• 對應(yīng)每個Follower都會有一個Replica Index，表示對應(yīng)Follower消費Leader上面同步到哪里；
• Follower的Ack Index，表示Follower已經(jīng)成功復(fù)制到本地的WAL；
• 對于Follower的復(fù)制請求，其實相當(dāng)于一個特殊Client的寫入，所以也有一個對應(yīng)的Append Index。

只有被Ack過的Index，才標(biāo)示為已經(jīng)處理完成，對于Leader來說，小于最小的Ack Index的WAL數(shù)據(jù)是可以被刪除。在這個過程中，如果Server2或者Server3中有一臺出問題，這時對應(yīng)的Consume Index不會移動，只有等到相應(yīng)服務(wù)恢復(fù)之后才會繼續(xù)處理。

在整個過程中可能出現(xiàn)如下情況：

• Leader Replica Index > Follower Append Index，這時需要根據(jù)Follower Append Index重置Leader Replica Index，可能存在2種情況，具體情況在復(fù)制順序性中描述；
• Leader Replica Index <>

假如此時Server1掛了，從Server2和Server3中選出新的Leader，如此時選為Server2為Leader：

• Server2就會開啟2-WAL復(fù)制通道，向Server1和Server3復(fù)制，由于當(dāng)前Server1掛了，所以暫時只往Server3復(fù)制，此時數(shù)據(jù)的寫入通道為2-WAL；
• Server1啟動恢復(fù)后，Server2會開啟向Server1的2-WAL復(fù)制通道，同時Server1會將1-WAL中剩余的還未向Server2和Server3復(fù)制的數(shù)據(jù)復(fù)制給它們。

對于異常情況，WAL中的數(shù)據(jù)不能正常，由于ACK之后刪除導(dǎo)致WAL占用過多磁盤，所以對WAL需要有一個SIZE和TTL的清理過程，一旦WAL因為SIZE和TTL清理之后，會導(dǎo)致幾個Index錯亂，具體錯亂情況如上所述。

多通道復(fù)制協(xié)議帶來的問題：

每個通道都有對應(yīng)的Index序列，保存每個通道的Last Index。而單通道復(fù)制只需要保存1個Last Index即可。這個代價其實還好。

本地寫入

背景

做到Shard級別的寫入隔離，即每個Shard都會有獨立的線程來負(fù)責(zé)寫入，不會因為某個數(shù)據(jù)庫或者某個Shard寫入量劇增而導(dǎo)致別的數(shù)據(jù)庫的寫入，但可能會因為單機承載的Shard數(shù)過多導(dǎo)致線程數(shù)過多。如果遇到這種情況，應(yīng)該通過擴(kuò)機器來解決，或者在新建數(shù)據(jù)庫的時候合理分配Shard數(shù)。

由于是單線程的寫操作，所以在很多情況下，不需要考慮多線程寫帶來的鎖競爭問題。

數(shù)據(jù)存儲結(jié)構(gòu)

說明，以單個數(shù)據(jù)庫在單節(jié)點上的數(shù)據(jù)結(jié)構(gòu)為例：

• 一個數(shù)據(jù)庫在單節(jié)點上會存在多個Shard，所有Shard共享一個索引數(shù)據(jù)；
• 所有的數(shù)據(jù)根據(jù)數(shù)據(jù)庫的Interval來計算按時間片，存儲具體的數(shù)據(jù)，包括數(shù)據(jù)文件和索引文件。

這樣的設(shè)計主要為了方便處理TTL，數(shù)據(jù)如果過期，直接刪除相應(yīng)的目錄就可以。每個Shard下面會存在segment，segment根據(jù)Interval來存儲相應(yīng)時間片的數(shù)據(jù)。

那么為什么每個segment下面又按Interval存儲很多個data family？

這個主要由于LinDB主要解決的問題是存儲海量的監(jiān)控數(shù)據(jù)，一般的監(jiān)控數(shù)據(jù)基本是***時間寫入，不會寫歷史數(shù)據(jù)，而整個LinDB的數(shù)據(jù)存儲類似LSM方式，所以為了減少數(shù)據(jù)文件之間的合并操作導(dǎo)致寫放大，最終衡量下來，再對segment時間片進(jìn)行分片。

下面以Interval為10s為例說明：

• segment按天來存儲；
• 每個segment按小時來分data family，每個小時一個family，每個family中的文件再按列存儲具體的數(shù)據(jù)。

寫入流程

說明：

• 系統(tǒng)會為每一個Shard啟一個寫線程，該線程負(fù)責(zé)這個Shard的所有寫操作。
• 首先把measurement，tags，fields對應(yīng)的數(shù)據(jù)寫入數(shù)據(jù)庫的索引文件，并生成相應(yīng)的Measurement ID，Time Series ID及Field ID，主要完成string->int的轉(zhuǎn)換。這樣的好處是所有的數(shù)據(jù)存儲都以數(shù)據(jù)類型來存儲，從而可以減少整個存儲大小。因為對于每個數(shù)據(jù)點，Measurement，Tags，F(xiàn)ield這樣元數(shù)據(jù)占用，如cpu{host=1.1.1.1} load=1 1514214168614，其實轉(zhuǎn)換成ID之后，cpu => 1(measurement id)，host=1.1.1.1 => 1(time series id)，load => 1(field id)，所以最終的數(shù)據(jù)存儲為1 1 1514214168614=>1，這個考慮OpenTSDB的設(shè)計。
• 如果寫索引失敗，認(rèn)為本次寫入失敗。失敗分為2種，一種是數(shù)據(jù)寫入格式有問題，這類失敗直接標(biāo)示失?。涣硗庖环N由于內(nèi)部問題，這時寫入失敗需要重試。
• 使用根據(jù)索引得到的ID，再結(jié)合寫入時間和數(shù)據(jù)庫Interval計算，得到需要寫入到哪個segment下的哪個family，寫family的過程，直接寫內(nèi)存以達(dá)到高吞吐量的要求，內(nèi)存數(shù)據(jù)到達(dá)內(nèi)存限制之后，會觸發(fā)Flush操作。
• 整個寫過程先寫內(nèi)存，再由Flusher線程把內(nèi)存中的數(shù)據(jù)dump到相應(yīng)的文件中，這樣就做到了對一批數(shù)據(jù)順序?qū)懭?，同時對于最近的數(shù)據(jù)根據(jù)Field Type進(jìn)行Rollup操作，從而進(jìn)一步減少磁盤IO操作。

2、查詢引擎

LinDB查詢需要解決如下問題：

• 解決多個機房之間的查詢；
• 高效的流式查詢計算。

說明：

• 由于需要支持多機房或者多集群的查詢，所以引入了LinProxy，LinProxy主要負(fù)責(zé)面向用戶的查詢請求；
• SQL Plan負(fù)責(zé)具體SQL的解析，生成最終的執(zhí)行計劃及需要計算的中間結(jié)果的函數(shù)；
• 通過Zookeeper中的Metadata，把請求路由給具體的LinDB集群中對應(yīng)的服務(wù)；
• 每個LinConnect負(fù)責(zé)與一個LinDB集群之間的通信，每個LinConnect內(nèi)部保存了一份對應(yīng)集群的Metadata，該Metadata信息在每個Metadata變更的時候由Server端推送給LinConnect，這樣LinConnect基本做到近實時的更新Metadata；
• Aggregator Stream主要負(fù)責(zé)把各個LinConnect的中間結(jié)果進(jìn)行最終的合并計算操作；
• 整個LinProxy處理過程都是異步化，這樣可以利用線程在IO等待的時候做計算。

每個Node接收LinConnect過來的請求，在內(nèi)部查詢計算成中間結(jié)果返回給LinConnect，詳細(xì)的過程后面要介紹。

Node查詢

說明：

• 如圖所示，Client過來的一個查詢請求，會產(chǎn)生很多小的查詢?nèi)蝿?wù)，每個任務(wù)所承擔(dān)的職責(zé)很單一，只做它所自己的任務(wù)，然后把結(jié)果給下一個任務(wù)，所以需要所有的查詢計算任務(wù)都是異常無阻塞處理，IO/CPU任務(wù)分離；
• 整個服務(wù)端查詢使用Actor模式來簡化整個Pipeline的處理；
• 任何一個任務(wù)執(zhí)行完成，如果沒有結(jié)果產(chǎn)生，則不會生產(chǎn)下游的任務(wù)，所有下游的任務(wù)都是根據(jù)上游任務(wù)是否有結(jié)果來決定；
• 最終把底層結(jié)果通過Reduce Aggregate聚合成最終的結(jié)果。

3、存儲結(jié)構(gòu)

倒排索引

倒排索引分兩部分，目前索引相關(guān)的數(shù)據(jù)還是存儲在RocksDB中。

• 根據(jù)Time Series的Measurement+Tags生成對應(yīng)的唯一ID（類似Luence里面的doc ID）；
• 根據(jù)Tags倒排索引，指向一個ID列表。TSID列表以BitMap的方式存儲，以方便查詢的時候通過BitMap操作來過濾出想要的數(shù)據(jù)。BitMap使用RoaringBitMap；
• 每一類數(shù)據(jù)都存儲在獨立的RocksDB Family中。

內(nèi)存結(jié)構(gòu)

為了提高寫入性能，把當(dāng)前一段時間的數(shù)據(jù)寫入到內(nèi)存中，內(nèi)存到達(dá)一定限制或者時間后把內(nèi)存中的數(shù)據(jù)Dump到文件中。

內(nèi)存存儲分為當(dāng)前可寫和不可寫，當(dāng)前可寫用于接收正常的數(shù)據(jù)寫入，不可寫用于Dump到文件中，如果Dump成功，則清空不可寫部分。

如果可寫的Memory Table也到達(dá)了內(nèi)存容量的限制，但不可寫部分還沒有完成Dump，這時寫入會被Block住，直到有可用的內(nèi)存供數(shù)據(jù)寫入，目的是為了不會因為占用過多內(nèi)存而導(dǎo)致OOM。

MemoryTable內(nèi)部通過一個Map來存儲Measurement ID→Measurement Store關(guān)系，即每個Measurement都存儲在一個獨立的Store中。

在Measurement Store內(nèi)存儲對應(yīng)Measurement下面每個TSID的數(shù)據(jù)，每個TSID對應(yīng)的數(shù)據(jù)用一個Memory Block來存儲，每個Memory Block按TSID的順序存儲在Array List中，把TSID存儲在一個BitMap中，通過TSID在Bitmap中位置來定位Memory Block在Array List中的具體位置。

這里說明一下為什么不直接使用Map來存儲，因為整個系統(tǒng)是用Java實現(xiàn)的，Java中的Map結(jié)構(gòu)不適合存儲小對象的數(shù)據(jù)，存在內(nèi)存放多倍的存儲。

由于每個TSID都會對應(yīng)一個時間線，每個時間線可能會存在多個數(shù)據(jù)點的情況，如count時只有一個count值，timer時會有count、sum、min、max等多個值。

每個數(shù)據(jù)類型以Chunk的方式存儲。Chunk內(nèi)部又以堆內(nèi)和堆外2部分內(nèi)存來存儲，最近一段時間的數(shù)據(jù)放在堆內(nèi)，歷史數(shù)據(jù)壓縮之后放在堆外，在內(nèi)存中盡量多放一些最近的數(shù)據(jù)，因為LinDB的目的主要是存儲一些監(jiān)控類的數(shù)據(jù)，而監(jiān)控類的數(shù)據(jù)主要關(guān)心最近一段時間的數(shù)據(jù)。

文件存儲結(jié)構(gòu)

文件存儲跟內(nèi)存存儲類似，同一個Measurement的數(shù)據(jù)以Block的方式存儲在一起，查詢時通過Measurement ID定位出該Measurement的數(shù)據(jù)存儲在哪個Block中。

• Measurement Block后存儲一個Offset Block，即存儲每個Measurement Block所在的Offset，每個Offset以4 bytes存儲。
• Offset Block存儲一個Measurement Index Block，按順序存儲每個Measurement ID，以Bitmap的方式存儲。
• 文件的尾存儲一個Footer Block，主要存儲Version(2 bytes) + Measurement Index Offset(4 bytes) + Measurement Index Length(4 bytes)。
• Data數(shù)據(jù)塊都是數(shù)值，所以使用xor壓縮，參考facebook的gorilla論文；

Measurement Block：

• 每個Measurement Block類似Measurement的方式存儲，只是把Measurement ID換成Measurement內(nèi)的TSID。
• TS Entry存儲該TSID對應(yīng)每一列的數(shù)據(jù)，一列數(shù)據(jù)對應(yīng)存儲一段時間的數(shù)據(jù)點。

查詢邏輯：

• DataFile在***次加載的時候會把Measurement Index放在內(nèi)存中，查詢輸入Measurement ID通過Measurement Index中的第幾個位置，然后通過這個位置N，在Offset Block查詢具體的Measurement Block的Offset，由于每個Offset都是4 bytes，所以offset position = (N-1) * 4，再讀取4 bytes得到真正的Offset。
• 同樣的道理可以通過TSID，找到具體的TS Entry，再根據(jù)條件過濾具體的列數(shù)據(jù)，最終得到需要讀取的數(shù)據(jù)。

三、發(fā)展歷程

LinDB從2年前正式慢慢服務(wù)于公司的監(jiān)控系統(tǒng)起，從1.0發(fā)展到2.0，已經(jīng)穩(wěn)定運行2年多，除了一次RocksDB的問題，幾乎沒出過什么問題。到現(xiàn)在，3.0性能大幅提升，我們基本都是站在業(yè)界一些成熟方案的基礎(chǔ)上，慢慢演進(jìn)而來。

也有人問，LinDB為什么這么快，其實我們是參考了很多TSDB的作法，然后取其好的設(shè)計，再結(jié)合時序的特征做一些優(yōu)化。

• 時序一般都是***寫入，但也是一種隨機寫，我們會先在內(nèi)存中把隨寫變成循序?qū)?，最終到寫文件都是順序?qū)懀袛?shù)據(jù)都是有序，這樣查詢的時候也是順序讀，這一點很關(guān)鍵；
• 把寫入的measurement/tags/fields都轉(zhuǎn)化成Int，再生成倒排索引，最終生成一個TSID（類似Luence的doc ID），這樣就大大減少了最終的數(shù)據(jù)量，畢竟指標(biāo)這樣字符串是占絕對的大頭，這點很像OpenTSDB，雖然InfluxDB已經(jīng)把一段時間的按Block來存儲，但還是在Block的頭放這些數(shù)據(jù)，這些都是成本，特別是在compact的時候；
• 不像別的TSDB會把timestamp直接存下來，一般timestamp到毫秒級別占8個節(jié)點，雖然根據(jù)時間有序的優(yōu)勢再用delta-encoded壓縮也是很好，但我們想做到***，我們是用一個bit來表示時間，具體的做法就是根據(jù)上面的描述，把時間的高位和存儲Interval，把高位的時間放在目錄上，再結(jié)合高位算一個delta，把delta以1bit的格式存儲，來表示有沒有數(shù)據(jù)，因為監(jiān)控數(shù)據(jù)絕大部分都是連續(xù)的數(shù)據(jù)， 所以這樣做也是合理的，因此在時間這個數(shù)據(jù)上的存儲也大大減少了空間；
• 我們發(fā)現(xiàn)對一個指標(biāo)的多個Field的數(shù)據(jù)，每個Field的數(shù)據(jù)相鄰的一些點基本是很相近的，LinDB 2.0存儲直接是用RocksDB，多個Field放在一起存儲，再把相鄰的點進(jìn)行壓縮，這樣其實壓縮率不會很高， 而且每取查詢?nèi)ield的時候都要把所有的數(shù)據(jù)讀出來，這也是LinDB 3.0我們考慮自己實現(xiàn)列式存儲的原因。我們把相同列存在一塊，以提高壓縮率，查詢的時候只讀需要的數(shù)據(jù)。整個壓縮我們也沒有用gzip、snappy、zlib，因為這些不大適合用于數(shù)值類型，我們是直接參考了facebook的gorilla論文的xor的方式來的，這個現(xiàn)在已經(jīng)被很多TSDB采用；
• 基于上面這些基本的順序讀已經(jīng)不成問題，基于TSID查詢的更不是問題，因為整個設(shè)計都是基于TSID→data來設(shè)計的，所以還要解決一個根據(jù)倒排查出一組TSID對數(shù)據(jù)的隨機讀，如上我們是把TSID放在Bitmap，然后通過Bitmap計算出Offset，直接找到數(shù)據(jù)，通過存儲時的優(yōu)化，做到TSID查詢精準(zhǔn)查找，而不是通過二分查找；
• 還有一點就是LinDB在新建數(shù)據(jù)庫時指定完Interval之后，系統(tǒng)會自己Rollup，不像InfluxDB要寫很多Continue Query，LinDB所有的這一切都是自動化的；
• 查詢計算并行流式處理。

所以用一句話來總結(jié)就是——一個高效的索引外加一堆數(shù)值，然后怎么玩好這堆數(shù)值。

自身監(jiān)控

LinDB也自帶了自身的一些監(jiān)控功能：

Overview

Dashboard

未來的展望

• 豐富查詢函數(shù)；
• 優(yōu)化內(nèi)存使用率；
• 自身監(jiān)控的提升；
• 如果有可能，計劃開源。

對比測試

下面是與InfluxDB和LinDB2.0的一些查詢性能對比。由于InfluxDB集群化要商業(yè)版，所以都是單機默認(rèn)配置下，無Cache的測試。服務(wù)器配置阿里云機器：8 Core 16G Memory

大維度

Tags：host(40000),disk(4),partition(20)，模擬服務(wù)器磁盤的監(jiān)控，總的Series數(shù)為320W，每個Series寫一個數(shù)據(jù)點：

小維度的1天內(nèi)的聚合測試

Tags：host(400),disk(2),partition(10)，模擬服務(wù)器磁盤的監(jiān)控，總的Series數(shù)為8K，每個Series寫一天的數(shù)據(jù) 每個維度每2s寫入1個點，每個維度一天內(nèi)總共43200個點，所有維度總共43200 * 8000個點，共345600000即3億多數(shù)據(jù)：

小維度的7天內(nèi)的聚合測試

Tags：host(400),disk(2),partition(10)，模擬服務(wù)器磁盤的監(jiān)控，總的Series數(shù)為8K，每個Series寫7天的數(shù)據(jù)，每個維度每5s寫入1個點，每個維度一天內(nèi)總共17280個點，所有天數(shù)所有維度總共172808000 7 個點，即967680000，9億多個點。

這個測試要說明一下，得利于LinDB自動的Rollup，如果InfluxDB開Continue Query的話相信應(yīng)該也還好。