時序數(shù)據(jù)及時序數(shù)據(jù)庫概述

1、時序數(shù)據(jù)及時序數(shù)據(jù)庫概述一、什么是時間序列？這類數(shù)據(jù)描述了某個被測量的主體在一個時間范圍內(nèi)的每個時間點上的測量值。對時序數(shù)據(jù)進(jìn)行建模的話，會包含三個重要部分，分別是:主體，時間點和測量值。時間系列數(shù)據(jù)的特性二、時序數(shù)據(jù)寫入的特點寫入平穩(wěn)、持續(xù)、高并發(fā)高吞吐：時序數(shù)據(jù)的寫入是比較平穩(wěn)的，這點與應(yīng)用數(shù)據(jù)不同，應(yīng)用數(shù)據(jù)通常與應(yīng)用的訪問量成正比，而應(yīng)用的訪問量通常存在波峰波谷。時序數(shù)據(jù)的產(chǎn)生通常是以一個固定的時間頻率產(chǎn)生，不會受其他因素的制約，其數(shù)據(jù)生成的速度是相對比較平穩(wěn)的。時序數(shù)據(jù)是由每個個體獨立生成，所以當(dāng)個體數(shù)量眾多時，通常寫入的并發(fā)和吞吐量都是比較高的，特別是在物聯(lián)網(wǎng)場景下。寫入并發(fā)和吞吐量

2、，可以簡單的通過個體數(shù)量和數(shù)據(jù)生成頻率來計算，例如若你有1000個個體以10秒的頻率產(chǎn)生數(shù)據(jù)，則你平均每秒產(chǎn)生的并發(fā)和寫入量就是100。2.寫多讀少：時序數(shù)據(jù)上95%-99%的操作都是寫操作，是典型的寫多讀少的數(shù)據(jù)。這與其數(shù)據(jù)特性相關(guān)，例如監(jiān)控數(shù)據(jù)，你的監(jiān)控項可能很多，但是你真正去讀的可能比較少，通常只會關(guān)心幾個特定的關(guān)鍵指標(biāo)或者在特定的場景下才會去讀數(shù)據(jù)。2.3.實時寫入最近生成的數(shù)據(jù)，無更新：時序數(shù)據(jù)的寫入是實時的，且每次寫入都是最近生成的數(shù)據(jù)，這與其數(shù)據(jù)生成的特點相關(guān)，因為其數(shù)據(jù)生成是隨著時間推進(jìn)的，而新生成的數(shù)據(jù)會實時的進(jìn)行寫入。數(shù)據(jù)寫入無更新，在時間這個維度上，隨著時間的推進(jìn)，每次數(shù)

3、據(jù)都是新數(shù)據(jù)，不會存在舊數(shù)據(jù)的更新，不過不排除人為的對數(shù)據(jù)做訂正。3.數(shù)據(jù)查詢和分析的特點1.按時間范圍讀?。和ǔ碚f，你不會去關(guān)心某個特定點的1.按時間范圍讀?。和ǔ碚f，你不會去關(guān)心某個特定點的數(shù)據(jù)，而是一段時間的數(shù)據(jù)。所以時序數(shù)據(jù)的讀取，基本數(shù)據(jù)，而是一段時間的數(shù)據(jù)。所以時序數(shù)據(jù)的讀取，基本都是按時間范圍的讀取。2.最近的數(shù)據(jù)被讀取的概率高:最近的數(shù)據(jù)越有可能被讀2.最近的數(shù)據(jù)被讀取的概率高:最近的數(shù)據(jù)越有可能被讀取，以監(jiān)控數(shù)據(jù)為例，你通常只會關(guān)心最近幾個小時或最近幾天的監(jiān)控數(shù)據(jù)，而極少關(guān)心一個月或一年前的數(shù)據(jù)。3.多精度查詢：按數(shù)據(jù)點的不同密集度來區(qū)分不同的精度，例如若相鄰數(shù)據(jù)點的間隔

4、周期是10秒，則該時序數(shù)據(jù)的精度就是10秒，若相鄰數(shù)據(jù)點的時間間隔周期是30秒，則該時序數(shù)據(jù)的精度就是30秒。時間間隔越短，精度越高。精度越高的數(shù)據(jù)，能夠還原的歷史狀態(tài)更細(xì)致更準(zhǔn)確，但其保存的數(shù)據(jù)點會越多。這個就好比相機(jī)的像素，像素越高，照片越清晰但是相片大小越大。時序數(shù)據(jù)的查詢，不需要都是高精度的，這是實際的需求，也是一種取舍，同樣也是成本的考慮。還是拿監(jiān)控數(shù)據(jù)舉例，通常監(jiān)控數(shù)據(jù)會以曲線圖的方式展現(xiàn)，由人的肉眼去識別。在這種情況下，單位長度下若展示的數(shù)據(jù)點過于密集，反而不利于觀察，這是實際的需求。而另外一種取舍是，若你查詢一個比較長的時間范圍，比如是一個月，若查詢10秒精度的數(shù)據(jù)需要返回25

5、9200個點，而若查詢60秒精度的數(shù)據(jù)則只要返回43200個點，這是查詢效率上的一種取舍。而成本方面的考慮，主要在存儲的數(shù)據(jù)量上，存儲高精度的數(shù)據(jù)需要的成本越高，通常對于歷史數(shù)據(jù)，可以不需要存儲很高精度的數(shù)據(jù)。總的來說，在查詢和處理方面，會根據(jù)不同長度的時間范圍，來獲取不同精度的數(shù)據(jù)，而在存儲方面，對于歷史的數(shù)據(jù)，會選擇降精度的數(shù)據(jù)存儲。3.多維分析：時序數(shù)據(jù)產(chǎn)生自不同的個體，這些個體擁有不同的屬性，可能是同一維度的，也可能是不同維度的。還是舉個監(jiān)控的例子，我有個對某個集群上每臺機(jī)器的網(wǎng)絡(luò)流量的監(jiān)控，此時可以查詢這個集群下某臺機(jī)器的網(wǎng)絡(luò)流量，這是一個維度的查詢，而同時還需要查詢這個集群總的網(wǎng)絡(luò)

6、流量，這是另外一個維度的查詢。5.數(shù)據(jù)挖掘：隨著大數(shù)據(jù)和人工智能技術(shù)的發(fā)展，在存儲、計算能力以及云計算發(fā)展的今天，數(shù)據(jù)的高附加值的挖掘已經(jīng)不再有一個很高門檻。而時序數(shù)據(jù)蘊(yùn)含著很高的價值，非常值得挖掘。5.四、數(shù)據(jù)存儲的特點1.數(shù)據(jù)量大：拿監(jiān)控數(shù)據(jù)來舉例，如果我們采集的監(jiān)控數(shù)據(jù)的時間間隔是1s，那一個監(jiān)控項每天會產(chǎn)生86400個數(shù)據(jù)點，若有10000個監(jiān)控項，則一天就會產(chǎn)生864000000個數(shù)據(jù)點。在物聯(lián)網(wǎng)場景下，這個數(shù)字會更大。整個數(shù)據(jù)的規(guī)模，是TB甚至是PB級的。1.2.冷熱分明：時序數(shù)據(jù)有非常典型的冷熱特征，越是歷史的數(shù)據(jù)，被查詢和分析的概率越低。2.3.具有時效性：時序數(shù)據(jù)具有時效性，

7、數(shù)據(jù)通常會有一個保存周期，超過這個保存周期的數(shù)據(jù)可以認(rèn)為是失效的，可以被回收。一方面是因為越是歷史的數(shù)據(jù)，可利用的價值越低；另一方面是為了節(jié)省存儲成本，低價值的數(shù)據(jù)可以被清理。3.1.2.3.4.多精度數(shù)據(jù)存儲：在查詢的特點里提到時序數(shù)據(jù)出于存儲成本和查詢效率的考慮，會需要一個多精度的查詢，同樣也需要一個多精度數(shù)據(jù)的存儲。五、時序數(shù)據(jù)庫基本要求綜合以上對于時序數(shù)據(jù)寫入、查詢和存儲的特點的分析，我們可以歸納總結(jié)下對于時序數(shù)據(jù)庫的基本要求:能夠支撐高并發(fā)、高吞吐的寫入：如上所說，時序數(shù)據(jù)具有典型的寫多讀少特征，其中95%-99%的操作都是寫。在讀和寫上，首要權(quán)衡的是寫的能力。由于其場景的特點，對于

8、數(shù)據(jù)庫的高并發(fā)、高吞吐寫入能力有很高的要求。交互級的聚合查詢：交互級的查詢延遲，并且是在數(shù)據(jù)基數(shù)（TB1.2.3.4.多精度數(shù)據(jù)存儲：在查詢的特點里提到時序數(shù)據(jù)出于存儲成本和查詢效率的考慮，會需要一個多精度的查詢，同樣也需要一個多精度數(shù)據(jù)的存儲。五、時序數(shù)據(jù)庫基本要求綜合以上對于時序數(shù)據(jù)寫入、查詢和存儲的特點的分析，我們可以歸納總結(jié)下對于時序數(shù)據(jù)庫的基本要求:能夠支撐高并發(fā)、高吞吐的寫入：如上所說，時序數(shù)據(jù)具有典型的寫多讀少特征，其中95%-99%的操作都是寫。在讀和寫上，首要權(quán)衡的是寫的能力。由于其場景的特點，對于數(shù)據(jù)庫的高并發(fā)、高吞吐寫入能力有很高的要求。交互級的聚合查詢：交互級的查詢延遲

9、，并且是在數(shù)據(jù)基數(shù)（TB級）較大的情況下，也能夠達(dá)到很低的查詢延遲。能夠支撐海量數(shù)據(jù)存儲：場景的特點決定了數(shù)據(jù)的量級，至少是18的量級，甚至是PB級數(shù)據(jù)。高可用：在線服務(wù)的場景下，對可用性要求也會很高。5.分布式架構(gòu)：寫入和存儲量的要求，底層若不是分布式架構(gòu)基本達(dá)不到目標(biāo)。5.背景結(jié)合時序數(shù)據(jù)的特點和時序數(shù)據(jù)庫的基本要求的分析，使用基于LSM樹存儲引擎的NoSQL數(shù)據(jù)庫（例如HBase、Cassandra或阿里云表格存儲等）相比使用B+樹的RDBMS，具有顯著的優(yōu)勢。LSM樹的基本原理不在這里贅述，它是為優(yōu)化寫性能而設(shè)計的，寫性能相比B+樹能提高一個數(shù)量級。但是讀性能會比B+樹差很多，所以極其

10、適合寫多讀少的場景。目前開源的幾個比較著名的時序數(shù)據(jù)庫中，OpenTSDB底層使用HBase、BlueFlood和KairosDB底層使用Cassandra，InfluxDB底層是自研的與LSM類似的TSM存儲引擎，Prometheus是直接基于LevelDB存儲引擎。所以可以看到，主流的時序數(shù)據(jù)庫的實現(xiàn)，底層存儲基本都會采用1$乂樹加上分布式架構(gòu)，只不過有的是直接使用已有的成熟數(shù)據(jù)庫，有的是自研或者基于LevelDB自己實LSM樹加分布式架構(gòu)能夠很好的滿足時序數(shù)據(jù)寫入能力的要求，但是在查詢上有很大的弱勢。如果是少量數(shù)據(jù)的聚合和多維度查詢，勉強(qiáng)能夠應(yīng)付，但是若需要在海量數(shù)據(jù)上進(jìn)行多維和聚合查詢

11、，在缺乏索引的情況下會顯得比較無力。所以在開源界，也有其他的一些產(chǎn)品，會側(cè)重于解決查詢和分析的問題，例如Druid主要側(cè)重解決時序數(shù)據(jù)的OLAP需求，不需要預(yù)聚合也能夠提供在海量數(shù)據(jù)中的快速的查詢分析，以及支持任意維度的drilldown。同樣的側(cè)重分析的場景下，社區(qū)也有基于ElasticSearch的解決方案。總之，百花齊放的時序數(shù)據(jù)庫產(chǎn)品，各有優(yōu)劣，沒有最好的，只有最合適的，全憑你自己對業(yè)務(wù)需求的判斷來做出選擇。六、時間序列數(shù)據(jù)的模型時序數(shù)據(jù)的數(shù)據(jù)模型主要有這么幾個主要的部分組成：1.主體：被測量的主體，一個主體會擁有多個維度的屬性。以服務(wù)器狀態(tài)監(jiān)控場景舉例，測量的主體是服務(wù)器，其擁有的屬

12、性可能包括集群名、Hostname等。1.2.測量值：一個主體可能有一個或多個測量值，每個測量值對應(yīng)一個具體的指標(biāo)。還是拿服務(wù)器狀態(tài)監(jiān)控場景舉例，測量的指標(biāo)可能會有CPU使用率，IOPS等，CPU使用率對應(yīng)的值可能是一個百分比，而IOPS對應(yīng)的值是測量周期內(nèi)發(fā)生的IO次數(shù)。2.3.時間戳：每次測量值的匯報，都會有一個時間戳屬性來表示其時間。3.目前主流時序數(shù)據(jù)庫建模的方式會分為兩種，按數(shù)據(jù)源建模和按指標(biāo)建模，以兩個例子來說明這兩種方式的不同。按數(shù)據(jù)源建模如圖所示為按數(shù)據(jù)源建模的例子，同一個數(shù)據(jù)源在某個時間點的所有指標(biāo)的測量值會存儲在同一行。Druid和InfluxDB采用這種模式。按指標(biāo)建模m

13、etrictimestampclusterhostnamemetricvaluecpu2015-04-23717:50:002Cluster-Ahost-a10cpu2015-04-2&T17:50:10ZCluster-Ahost-b20cpu2015-04-28T17:50:202Cluster-Ahosba5iopS2015-04-23717:50:002Cluster-Ahost-a10iops2015-04-28T17:50:102Cluster-Aliost-b30iops2015-04-28T17:50:202Cluster-Ahosba8測量指標(biāo)時向戳主體“維度測星值如圖所示為

14、按指標(biāo)建模的例子，其中每行數(shù)據(jù)代表某個數(shù)據(jù)源的某個指標(biāo)在某個時間點的測量值。OpenTSDB和KairosDB采用這種模式。這兩種模型的選擇沒有明確的優(yōu)劣，如果底層是采用列式存儲且每個列上都有索引，則按數(shù)據(jù)源建模可能是一個比較干凈的方式。如果底層是類似HBase或Cassandra這種的，將多個指標(biāo)值存儲在同一行會影響對其中某個指標(biāo)的查詢或過濾的效率，所以通常會選擇按指標(biāo)建模。七、時間序列數(shù)據(jù)的處理這一小節(jié)會主要講解下對時序數(shù)據(jù)的處理操作，時序數(shù)據(jù)庫除了滿足基本的寫和存儲的需求外，最重要的就是查詢和分析的功能。對時序數(shù)據(jù)的處理可以簡單歸納為Filter（過濾），Aggregation（聚合）、

15、GroupBy和Downsampling（降精度）。為了更好的支持GroupBy查詢，某些時序數(shù)據(jù)庫會對數(shù)據(jù)做pre-aggregation（預(yù)聚合）。Downsampling對應(yīng)的操作是Rollup（匯總），而為了支持更快更實時的Rollup，通常時序數(shù)據(jù)庫都會提供auto-rollup（自動匯總）。Filter（過濾）metrictimestampclusterhostnamemetricvaluecpu2Q15-04-28T17:50:00ZCluster-Ahost-a10cpu2015-04-28T17:50:OOZCluster#host-b20cpu2O15-O4-28T17：5

16、O：1OZCluster-Aho$t*a6cpu2015-04-28T17:50:10ZCluster-Ahost-b10cpu20l5-04-23T17:50:20ZCluster-A30cpu2015-04-28T17:50:20ZCluster-Ahost-b8selectcpufromtablewhereclustef=Cluster-A,andhostname二力口st田metrictimestampclusterhostnamemetricvaluecpu2015-04-28T17:50:00ZCluster-Ahost-a10cpu2015-04-28T17:50:10ZClus

17、ter-Ahost-a6cpu2015-04-28T1750:20ZCluster-Ahost-a30如圖所示就是一個簡單的Filter處理，簡單的說，就是根據(jù)給定的不同維度的條件，查找符合條件的所有數(shù)據(jù)。在時序數(shù)據(jù)分析的場景，通常先是從一個高維度入手，后通過提供更精細(xì)的維度條件，對數(shù)據(jù)做更細(xì)致的查詢和處理。Aggregation（聚合）聚合是時序數(shù)據(jù)查詢和分析的最基本的功能，時序數(shù)據(jù)記錄的是最原始的狀態(tài)變化信息，而查詢和分析通常需要的不是原始值，而是基于原始值的一些統(tǒng)計值。Aggregation就是提供了對數(shù)據(jù)做統(tǒng)計的一些基本的計算操作，比較常見的有SUM（總和）、AVG（平均值）、Max（

18、最大值）、TopN等等。例如對服務(wù)器網(wǎng)絡(luò)流量的分析，你通常會關(guān)心流量的平均值、流量的總和或者流量的峰值。GroupBy和Pre-aggregation(預(yù)聚合)metrictimestampclusterhostnamemetricvaluecpu2015-04-28T17：50：DOZCluster-Ahost-a10cpu2015-D4-?8T17:50:OOZCluster-Ahost-b20cpu201504-28T17：50：10ZCluster-Ahost-a6cpu2015-04-28T17：50：10ZCluster-Ahost-b10cpu2015-04-28117:50:2

19、02Cluster-Ahost-a30cpu2015-04-28T17:50:20ZCluster-Ariost-b8selectayg(cpu)fromEablegroupbyClustermetrictimestampclustermetricvalue(avg)cpu2CH5-O4-28T17;5O;OOZCluster-A15cpu2CH5-O48T17;5O:1OZCluster-A8cpu2015-04-28T17:50:207Cluster-A19GroupBy就是將一個低維度的時序數(shù)據(jù)轉(zhuǎn)換為一個高維度的統(tǒng)計值的過程，如圖就是一個簡單的GroupBy的例子。GroupBy一般發(fā)生

20、在查詢時，查詢到原始數(shù)據(jù)后做實時的計算來得到結(jié)果，這個過程有可能是很慢的，取決于其查詢的原始數(shù)據(jù)的基數(shù)。主流的時序數(shù)據(jù)庫提供preaggregation（預(yù)聚合）的功能來優(yōu)化這一過程，數(shù)據(jù)實時寫入后就會經(jīng)過預(yù)聚合的運(yùn)算，生成按指定規(guī)則GroupBy之后的結(jié)果，在查詢時就可以直接查詢結(jié)果而不需要再次計算。00小$111）8（降精度），Rollup（匯總）和Auto-rollup（自動匯總）Downsampling就是將一個高精度的時序數(shù)據(jù)轉(zhuǎn)換為一個低精度的時序數(shù)據(jù)的過程，這個過程被稱作Rollup。它與GroupBy的過程比較類似，核心區(qū)別是GroupBy是基于相同的時間粒度，把同一時間層面上的

21、不同維度的數(shù)據(jù)做聚合，轉(zhuǎn)換后的結(jié)果還是相同時間粒度的數(shù)據(jù)，只不過是更高的一個維度。而Downsampling是不同時間層面上把相同維度的數(shù)據(jù)做聚合，抓換為更粗時間粒度的數(shù)據(jù)，但是還是擁有相同的維度。metrictimestampclusterhostnamemetricvaluecpu2015-04-28T17:50:307Cluster-Anost-a10cpu2015-04-28T17:50：10ZCluster-Anost-a20cpu2015-04-28T17:50:20ZCluster-Ahost-a6cpu2015-04-28T17:50：30ZCluster-Ahost-a10c

22、pu2015-04-28T17:50：40ZCllister-Ahost-a30cpu201504-28T17:50：50ZCluster-Anost-a8downsamplingfromintferval(IO)tointerval(30),metrictimestampclusterhostnamemetricvalue(avg)cpu2015-04-28T17:5000ZCluster-Ahost-a12cpu2015-04-28T17；5030ZCluster-Ahost-a16如圖就是一個簡單的Downsampling的例子，將一個10秒精度的數(shù)據(jù)聚合成30秒精度的數(shù)據(jù)，統(tǒng)計平均值。

23、Downsampling分為存儲降精度和查詢降精度，存儲降精度的意義在于降低存儲成本，特別是針對歷史數(shù)據(jù)。查詢降精度主要是針對較大時間范圍的查詢，來減少返回的數(shù)據(jù)點。不管是存儲降精度還是查詢降精度，都需要auto-rollup。auto-rollup就是自動的對數(shù)據(jù)做rollup，而不是等待查詢時做rollup，過程與pre-aggregation類似，能有效的提高查詢效率，這也是目前主流時序數(shù)據(jù)庫已經(jīng)提供或者正在規(guī)劃的功能。目前Druid、InfluxDB和KairosDB都提供auto-rollup，OpenTSDB不提供autorollup但是暴露了接口支持在外部做auto-rollup

24、后的結(jié)果導(dǎo)入。八、總結(jié)本篇文章主要分析了時序數(shù)據(jù)的特性、模型和基本的查詢和處理操作，以及對時序數(shù)據(jù)庫的基本要求。在下一篇文章中，會對當(dāng)前比較流行的幾個開源的時序數(shù)據(jù)庫的實現(xiàn)做分析。你會發(fā)現(xiàn)，雖然目前存在那么多的時序數(shù)據(jù)庫，但是在基本功能上都是大同小異的。各個時序數(shù)據(jù)庫各有特色，實現(xiàn)方式也各不同，但是都是圍繞在對時序數(shù)據(jù)的寫入、存儲、查詢和分析這幾個維度的設(shè)計方案的權(quán)衡和取舍。沒有一個萬能的時序數(shù)據(jù)庫解決了所有的問題，在你選擇用何種時序數(shù)據(jù)庫的時候，需要從業(yè)務(wù)角度出發(fā)，選擇一款最合適的時序數(shù)據(jù)庫。數(shù)據(jù)的存儲數(shù)據(jù)的存儲可以分為兩個問題，單機(jī)上存儲和分布式存儲。單機(jī)存儲如果只是存儲起來，直接寫成日志

25、就行。但因為后續(xù)還要快速的查詢，所以需要考慮存儲的結(jié)構(gòu)。傳統(tǒng)數(shù)據(jù)庫存儲采用的都是Btree，這是由于其在查詢和順序插入時有利于減少尋道次數(shù)的組織形式。我們知道磁盤尋道時間是非常慢的，一般在10ms左右。磁盤的隨機(jī)讀寫慢就慢在尋道上面。對于隨機(jī)寫入8tree會消耗大量的時間在磁盤尋道上，導(dǎo)致速度很慢。我們知道SSD具有更快的尋道時間，但并沒有從根本上解決這個問題。對于90%以上場景都是寫入的時序數(shù)據(jù)庫，Btree很明顯是不合適的。業(yè)界主流都是采用LSMtree替換Btree，比如Hbase,Cassandra等nosql中。這里我們詳細(xì)介紹一下。LSMtree包括內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)和磁盤上的文件兩

26、部分。分別對應(yīng)Hbase里的MemStore和HLog；對應(yīng)Cassandra里的MemTable和sstable。LSMtree操作流程如下：數(shù)據(jù)寫入和更新時首先寫入位于內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)。為了避免數(shù)據(jù)丟失也會先寫到WAL文件中。內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)會定時或者達(dá)到固定大小會刷到磁盤。這些磁盤上的文件不會被修改。隨著磁盤上積累的文件越來越多，會定時的進(jìn)行合并操作，消除冗余數(shù)據(jù)，減少文件數(shù)量。HbaseLSMtree結(jié)構(gòu)介紹（注1）可以看到LSMtree核心思想就是通過內(nèi)存寫和后續(xù)磁盤的順序?qū)懭氆@得更高的寫入性能，避免了隨機(jī)寫入。但同時也犧牲了讀取性能，因為同一個key的值可能存在于多個HFile中。

27、為了獲取更好的讀取性能，可以通過bloomfilter和compaction得到，這里限于篇幅就不詳細(xì)展開。分布式存儲時序數(shù)據(jù)庫面向的是海量數(shù)據(jù)的寫入存儲讀取，單機(jī)是無法解決問題的。所以需要采用多機(jī)存儲，也就是分布式存儲。分布式存儲首先要考慮的是如何將數(shù)據(jù)分布到多臺機(jī)器上面，也就是分片（sharding）問題。下面我們就時序數(shù)據(jù)庫分片問題展開介紹。分片問題由分片方法的選擇和分片的設(shè)計組成。分片方法時序數(shù)據(jù)庫的分片方法和其他分布式系統(tǒng)是相通的。哈希分片：這種方法實現(xiàn)簡單，均衡性較好，但是集群不易擴(kuò)展。一致性哈希：這種方案均衡性好，集群擴(kuò)展容易，只是實現(xiàn)復(fù)雜。代表有Amazon的DynamoDB和

28、開源的Cassandra。范圍劃分：通常配合全局有序，復(fù)雜度在于合并和分裂。代表有Hbase。分片設(shè)計分片設(shè)計簡單來說就是以什么做分片，這是非常有技巧的，會直接影響寫入讀取的性能。結(jié)合時序數(shù)據(jù)庫的特點，根據(jù)metric+tags分片是比較好的一種方式，因為往往會按照一個時間范圍查詢，這樣相同metric和tags的數(shù)據(jù)會分配到一臺機(jī)器上連續(xù)存放，順序的磁盤讀取是很快的。再結(jié)合上面講到的單機(jī)存儲內(nèi)容，可以做到快速查詢。進(jìn)一步我們考慮時序數(shù)據(jù)時間范圍很長的情況，需要根據(jù)時間范圍再將分成幾段，分別存儲到不同的機(jī)器上，這樣對于大范圍時序數(shù)據(jù)就可以支持并發(fā)查詢，優(yōu)化查詢速度。如下圖，第一行和第三行都是同

29、樣的tag（sensor=95D8-7913；city二上海），所以分配到同樣的分片，而第五行雖然也是同樣的tag,但是根據(jù)時間范圍再分段，被分到了不同的分片。第二、四、六行屬于同樣的tag（sensor=F3CC-20F3;city=北京）也是一樣的道理。時序數(shù)據(jù)分片說明真實案例下面我以一批開源時序數(shù)據(jù)庫作為說明。InfluxDB非常優(yōu)秀的時序數(shù)據(jù)庫，但只有單機(jī)版是免費開源的，集群版本是要收費的。從單機(jī)版本中可以一窺其存儲方案：在單機(jī)上InfluxDB采取類似于LSMtree的存儲結(jié)構(gòu)TSM；而分片的方案InfluxDB先通過+（事實上還要加上retentionPolicy）確定ShardGroup，再通過+的hashcode確定到具體的Shard。這里timestamp默認(rèn)情況下