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

時(shí)序數(shù)據(jù)及時(shí)序數(shù)據(jù)庫(kù)概述什么是時(shí)間序列？這類數(shù)據(jù)描述了某個(gè)被測(cè)量的主體在一個(gè)時(shí)間范圍內(nèi)的每個(gè)時(shí)間點(diǎn)上的測(cè)量值。對(duì)時(shí)序數(shù)據(jù)進(jìn)行建模的話，會(huì)包含三個(gè)重要部分，分別是：主體，時(shí)間點(diǎn)和測(cè)量值。時(shí)間系列數(shù)據(jù)的特性時(shí)序數(shù)據(jù)寫入的特點(diǎn)寫入平穩(wěn)、持續(xù)、高并發(fā)高吞吐：時(shí)序數(shù)據(jù)的寫入是比較平穩(wěn)的，這點(diǎn)與應(yīng)用數(shù)據(jù)不同，應(yīng)用數(shù)據(jù)通常與應(yīng)用的訪問(wèn)量成正比，而應(yīng)用的訪問(wèn)量通常存在波峰波谷。時(shí)序數(shù)據(jù)的產(chǎn)生通常是以一個(gè)固定的時(shí)間頻率產(chǎn)生，不會(huì)受其他因素的制約，其數(shù)據(jù)生成的速度是相對(duì)比較平穩(wěn)的。時(shí)序數(shù)據(jù)是由每個(gè)個(gè)體獨(dú)立生成，所以當(dāng)個(gè)體數(shù)量眾多時(shí)，通常寫入的并發(fā)和吞吐量都是比較高的，特別是在物聯(lián)網(wǎng)場(chǎng)景下。寫入并發(fā)和吞吐量，可以簡(jiǎn)單的通過(guò)個(gè)體數(shù)量和數(shù)據(jù)生成頻率來(lái)計(jì)算，例如若你有1000個(gè)個(gè)體以10秒的頻率產(chǎn)生數(shù)據(jù)，則你平均每秒產(chǎn)生的并發(fā)和寫入量就是100。寫多讀少：時(shí)序數(shù)據(jù)上95%-99%的操作都是寫操作，是典型的寫多讀少的數(shù)據(jù)。這與其數(shù)據(jù)特性相關(guān)，例如監(jiān)控?cái)?shù)據(jù)，你的監(jiān)控項(xiàng)可能很多，但是你真正去讀的可能比較少，通常只會(huì)關(guān)心幾個(gè)特定的關(guān)鍵指標(biāo)或者在特定的場(chǎng)景下才會(huì)去讀數(shù)據(jù)。實(shí)時(shí)寫入最近生成的數(shù)據(jù)，無(wú)更新：時(shí)序數(shù)據(jù)的寫入是實(shí)時(shí)的，且每次寫入都是最近生成的數(shù)據(jù)，這與其數(shù)據(jù)生成的特點(diǎn)相關(guān)，因?yàn)槠鋽?shù)據(jù)生成是隨著時(shí)間推進(jìn)的，而新生成的數(shù)據(jù)會(huì)實(shí)時(shí)的進(jìn)行寫入。數(shù)據(jù)寫入無(wú)更新，在時(shí)間這個(gè)維度上，隨著時(shí)間的推進(jìn)，每次數(shù)據(jù)都是新數(shù)據(jù)，不會(huì)存在舊數(shù)據(jù)的更新，不過(guò)不排除人為的對(duì)數(shù)據(jù)做訂正。數(shù)據(jù)查詢和分析的特點(diǎn)按時(shí)間范圍讀?。和ǔ?lái)說(shuō)，你不會(huì)去關(guān)心某個(gè)特定點(diǎn)的數(shù)據(jù)，而是一段時(shí)間的數(shù)據(jù)。所以時(shí)序數(shù)據(jù)的讀取，基本都是按時(shí)間范圍的讀取。最近的數(shù)據(jù)被讀取的概率高：最近的數(shù)據(jù)越有可能被讀取，以監(jiān)控?cái)?shù)據(jù)為例，你通常只會(huì)關(guān)心最近幾個(gè)小時(shí)或最近幾天的監(jiān)控?cái)?shù)據(jù)，而極少關(guān)心一個(gè)月或一年前的數(shù)據(jù)。多精度查詢：按數(shù)據(jù)點(diǎn)的不同密集度來(lái)區(qū)分不同的精度，例如若相鄰數(shù)據(jù)點(diǎn)的間隔周期是10秒，則該時(shí)序數(shù)據(jù)的精度就是10秒，若相鄰數(shù)據(jù)點(diǎn)的時(shí)間間隔周期是30秒，則該時(shí)序數(shù)據(jù)的精度就是30秒。時(shí)間間隔越短，精度越高。精度越高的數(shù)據(jù)，能夠還原的歷史狀態(tài)更細(xì)致更準(zhǔn)確，但其保存的數(shù)據(jù)點(diǎn)會(huì)越多。這個(gè)就好比相機(jī)的像素，像素越高，照片越清晰但是相片大小越大。時(shí)序數(shù)據(jù)的查詢，不需要都是高精度的，這是實(shí)際的需求，也是一種取舍，同樣也是成本的考慮。還是拿監(jiān)控?cái)?shù)據(jù)舉例，通常監(jiān)控?cái)?shù)據(jù)會(huì)以曲線圖的方式展現(xiàn)，由人的肉眼去識(shí)別。在這種情況下，單位長(zhǎng)度下若展示的數(shù)據(jù)點(diǎn)過(guò)于密集，反而不利于觀察，這是實(shí)際的需求。而另外一種取舍是，若你查詢一個(gè)比較長(zhǎng)的時(shí)間范圍，比如是一個(gè)月，若查詢10秒精度的數(shù)據(jù)需要返回259200個(gè)點(diǎn)，而若查詢60秒精度的數(shù)據(jù)則只要返回43200個(gè)點(diǎn)，這是查詢效率上的一種取舍。而成本方面的考慮，主要在存儲(chǔ)的數(shù)據(jù)量上，存儲(chǔ)高精度的數(shù)據(jù)需要的成本越高，通常對(duì)于歷史數(shù)據(jù)，可以不需要存儲(chǔ)很高精度的數(shù)據(jù)?？偟膩?lái)說(shuō)，在查詢和處理方面，會(huì)根據(jù)不同長(zhǎng)度的時(shí)間范圍，來(lái)獲取不同精度的數(shù)據(jù)，而在存儲(chǔ)方面，對(duì)于歷史的數(shù)據(jù)，會(huì)選擇降精度的數(shù)據(jù)存儲(chǔ)。多維分析：時(shí)序數(shù)據(jù)產(chǎn)生自不同的個(gè)體，這些個(gè)體擁有不同的屬性，可能是同一維度的，也可能是不同維度的。還是舉個(gè)監(jiān)控的例子，我有個(gè)對(duì)某個(gè)集群上每臺(tái)機(jī)器的網(wǎng)絡(luò)流量的監(jiān)控，此時(shí)可以查詢這個(gè)集群下某臺(tái)機(jī)器的網(wǎng)絡(luò)流量，這是一個(gè)維度的查詢，而同時(shí)還需要查詢這個(gè)集群總的網(wǎng)絡(luò)流量，這是另外一個(gè)維度的查詢。數(shù)據(jù)挖掘：隨著大數(shù)據(jù)和人工智能技術(shù)的發(fā)展，在存儲(chǔ)、計(jì)算能力以及云計(jì)算發(fā)展的今天，數(shù)據(jù)的高附加值的挖掘已經(jīng)不再有一個(gè)很高門檻。而時(shí)序數(shù)據(jù)蘊(yùn)含著很高的價(jià)值，非常值得挖掘。數(shù)據(jù)存儲(chǔ)的特點(diǎn)數(shù)據(jù)量大：拿監(jiān)控?cái)?shù)據(jù)來(lái)舉例，如果我們采集的監(jiān)控?cái)?shù)據(jù)的時(shí)間間隔是1s，那一個(gè)監(jiān)控項(xiàng)每天會(huì)產(chǎn)生86400個(gè)數(shù)據(jù)點(diǎn)，若有10000個(gè)監(jiān)控項(xiàng)，則一天就會(huì)產(chǎn)生864000000個(gè)數(shù)據(jù)點(diǎn)。在物聯(lián)網(wǎng)場(chǎng)景下，這個(gè)數(shù)字會(huì)更大。整個(gè)數(shù)據(jù)的規(guī)模，是TB甚至是PB級(jí)的。冷熱分明：時(shí)序數(shù)據(jù)有非常典型的冷熱特征，越是歷史的數(shù)據(jù)，被查詢和分析的概率越低。具有時(shí)效性：時(shí)序數(shù)據(jù)具有時(shí)效性，數(shù)據(jù)通常會(huì)有一個(gè)保存周期，超過(guò)這個(gè)保存周期的數(shù)據(jù)可以認(rèn)為是失效的，可以被回收。一方面是因?yàn)樵绞菤v史的數(shù)據(jù)，可利用的價(jià)值越低；另一方面是為了節(jié)省存儲(chǔ)成本，低價(jià)值的數(shù)據(jù)可以被清理。多精度數(shù)據(jù)存儲(chǔ)：在查詢的特點(diǎn)里提到時(shí)序數(shù)據(jù)出于存儲(chǔ)成本和查詢效率的考慮，會(huì)需要一個(gè)多精度的查詢，同樣也需要一個(gè)多精度數(shù)據(jù)的存儲(chǔ)。時(shí)序數(shù)據(jù)庫(kù)基本要求??綜合以上對(duì)于時(shí)序數(shù)據(jù)寫入、查詢和存儲(chǔ)的特點(diǎn)的分析，我們可以歸納總結(jié)下對(duì)于時(shí)序數(shù)據(jù)庫(kù)的基本要求：能夠支撐高并發(fā)、高吞吐的寫入：如上所說(shuō)，時(shí)序數(shù)據(jù)具有典型的寫多讀少特征，其中95%-99%的操作都是寫。在讀和寫上，首要權(quán)衡的是寫的能力。由于其場(chǎng)景的特點(diǎn)，對(duì)于數(shù)據(jù)庫(kù)的高并發(fā)、高吞吐寫入能力有很高的要求。交互級(jí)的聚合查詢：交互級(jí)的查詢延遲，并且是在數(shù)據(jù)基數(shù)（TB級(jí)）較大的情況下，也能夠達(dá)到很低的查詢延遲。能夠支撐海量數(shù)據(jù)存儲(chǔ)：場(chǎng)景的特點(diǎn)決定了數(shù)據(jù)的量級(jí)，至少是TB的量級(jí)，甚至是PB級(jí)數(shù)據(jù)。高可用：在線服務(wù)的場(chǎng)景下，對(duì)可用性要求也會(huì)很高。分布式架構(gòu)：寫入和存儲(chǔ)量的要求，底層若不是分布式架構(gòu)基本達(dá)不到目標(biāo)。背景?結(jié)合時(shí)序數(shù)據(jù)的特點(diǎn)和時(shí)序數(shù)據(jù)庫(kù)的基本要求的分析，使用基于LSM樹存儲(chǔ)引擎的NoSQL數(shù)據(jù)庫(kù)（例如HBase、Cassandra或阿里云表格存儲(chǔ)等）相比使用B+樹的RDBMS，具有顯著的優(yōu)勢(shì)。LSM樹的基本原理不在這里贅述，它是為優(yōu)化寫性能而設(shè)計(jì)的，寫性能相比B+樹能提高一個(gè)數(shù)量級(jí)。但是讀性能會(huì)比B+樹差很多，所以極其適合寫多讀少的場(chǎng)景。目前開源的幾個(gè)比較著名的時(shí)序數(shù)據(jù)庫(kù)中，OpenTSDB底層使用HBase、BlueFlood和KairosDB底層使用Cassandra，InfluxDB底層是自研的與LSM類似的TSM存儲(chǔ)引擎，Prometheus是直接基于LevelDB存儲(chǔ)引擎。所以可以看到，主流的時(shí)序數(shù)據(jù)庫(kù)的實(shí)現(xiàn)，底層存儲(chǔ)基本都會(huì)采用LSM樹加上分布式架構(gòu)，只不過(guò)有的是直接使用已有的成熟數(shù)據(jù)庫(kù)，有的是自研或者基于LevelDB自己實(shí)現(xiàn)。

??LSM樹加分布式架構(gòu)能夠很好的滿足時(shí)序數(shù)據(jù)寫入能力的要求，但是在查詢上有很大的弱勢(shì)。如果是少量數(shù)據(jù)的聚合和多維度查詢，勉強(qiáng)能夠應(yīng)付，但是若需要在海量數(shù)據(jù)上進(jìn)行多維和聚合查詢，在缺乏索引的情況下會(huì)顯得比較無(wú)力。所以在開源界，也有其他的一些產(chǎn)品，會(huì)側(cè)重于解決查詢和分析的問(wèn)題，例如Druid主要側(cè)重解決時(shí)序數(shù)據(jù)的OLAP需求，不需要預(yù)聚合也能夠提供在海量數(shù)據(jù)中的快速的查詢分析，以及支持任意維度的drilldown。同樣的側(cè)重分析的場(chǎng)景下，社區(qū)也有基于ElasticSearch的解決方案。??總之，百花齊放的時(shí)序數(shù)據(jù)庫(kù)產(chǎn)品，各有優(yōu)劣，沒(méi)有最好的，只有最合適的，全憑你自己對(duì)業(yè)務(wù)需求的判斷來(lái)做出選擇。時(shí)間序列數(shù)據(jù)的模型??時(shí)序數(shù)據(jù)的數(shù)據(jù)模型主要有這么幾個(gè)主要的部分組成：主體:被測(cè)量的主體，一個(gè)主體會(huì)擁有多個(gè)維度的屬性。以服務(wù)器狀態(tài)監(jiān)控場(chǎng)景舉例，測(cè)量的主體是服務(wù)器，其擁有的屬性可能包括集群名、Hostname等。測(cè)量值:一個(gè)主體可能有一個(gè)或多個(gè)測(cè)量值，每個(gè)測(cè)量值對(duì)應(yīng)一個(gè)具體的指標(biāo)。還是拿服務(wù)器狀態(tài)監(jiān)控場(chǎng)景舉例，測(cè)量的指標(biāo)可能會(huì)有CPU使用率，IOPS等，CPU使用率對(duì)應(yīng)的值可能是一個(gè)百分比，而IOPS對(duì)應(yīng)的值是測(cè)量周期內(nèi)發(fā)生的IO次數(shù)。時(shí)間戳:每次測(cè)量值的匯報(bào)，都會(huì)有一個(gè)時(shí)間戳屬性來(lái)表示其時(shí)間。目前主流時(shí)序數(shù)據(jù)庫(kù)建模的方式會(huì)分為兩種，按數(shù)據(jù)源建模和按指標(biāo)建模，以兩個(gè)例子來(lái)說(shuō)明這兩種方式的不同。按數(shù)據(jù)源建模??如圖所示為按數(shù)據(jù)源建模的例子，同一個(gè)數(shù)據(jù)源在某個(gè)時(shí)間點(diǎn)的所有指標(biāo)的測(cè)量值會(huì)存儲(chǔ)在同一行。Druid和InfluxDB采用這種模式。按指標(biāo)建模

??如圖所示為按指標(biāo)建模的例子，其中每行數(shù)據(jù)代表某個(gè)數(shù)據(jù)源的某個(gè)指標(biāo)在某個(gè)時(shí)間點(diǎn)的測(cè)量值。OpenTSDB和KairosDB采用這種模式。??這兩種模型的選擇沒(méi)有明確的優(yōu)劣，如果底層是采用列式存儲(chǔ)且每個(gè)列上都有索引，則按數(shù)據(jù)源建?？赡苁且粋€(gè)比較干凈的方式。如果底層是類似HBase或Cassandra這種的，將多個(gè)指標(biāo)值存儲(chǔ)在同一行會(huì)影響對(duì)其中某個(gè)指標(biāo)的查詢或過(guò)濾的效率，所以通常會(huì)選擇按指標(biāo)建模。時(shí)間序列數(shù)據(jù)的處理??這一小節(jié)會(huì)主要講解下對(duì)時(shí)序數(shù)據(jù)的處理操作，時(shí)序數(shù)據(jù)庫(kù)除了滿足基本的寫和存儲(chǔ)的需求外，最重要的就是查詢和分析的功能。對(duì)時(shí)序數(shù)據(jù)的處理可以簡(jiǎn)單歸納為Filter(過(guò)濾),Aggregation(聚合)、GroupBy和Downsampling(降精度)。為了更好的支持GroupBy查詢，某些時(shí)序數(shù)據(jù)庫(kù)會(huì)對(duì)數(shù)據(jù)做pre-aggregation(預(yù)聚合)。Downsampling對(duì)應(yīng)的操作是Rollup(匯總)，而為了支持更快更實(shí)時(shí)的Rollup，通常時(shí)序數(shù)據(jù)庫(kù)都會(huì)提供auto-rollup(自動(dòng)匯總)。Filter(過(guò)濾)??如圖所示就是一個(gè)簡(jiǎn)單的Filter處理，簡(jiǎn)單的說(shuō)，就是根據(jù)給定的不同維度的條件，查找符合條件的所有數(shù)據(jù)。在時(shí)序數(shù)據(jù)分析的場(chǎng)景，通常先是從一個(gè)高維度入手，后通過(guò)提供更精細(xì)的維度條件，對(duì)數(shù)據(jù)做更細(xì)致的查詢和處理。Aggregation(聚合)??聚合是時(shí)序數(shù)據(jù)查詢和分析的最基本的功能，時(shí)序數(shù)據(jù)記錄的是最原始的狀態(tài)變化信息，而查詢和分析通常需要的不是原始值，而是基于原始值的一些統(tǒng)計(jì)值。Aggregation就是提供了對(duì)數(shù)據(jù)做統(tǒng)計(jì)的一些基本的計(jì)算操作，比較常見(jiàn)的有SUM（總和）、AVG（平均值）、Max（最大值）、TopN等等。例如對(duì)服務(wù)器網(wǎng)絡(luò)流量的分析，你通常會(huì)關(guān)心流量的平均值、流量的總和或者流量的峰值。GroupBy和Pre-aggregation(預(yù)聚合)??GroupBy就是將一個(gè)低維度的時(shí)序數(shù)據(jù)轉(zhuǎn)換為一個(gè)高維度的統(tǒng)計(jì)值的過(guò)程，如圖就是一個(gè)簡(jiǎn)單的GroupBy的例子。GroupBy一般發(fā)生在查詢時(shí)，查詢到原始數(shù)據(jù)后做實(shí)時(shí)的計(jì)算來(lái)得到結(jié)果，這個(gè)過(guò)程有可能是很慢的，取決于其查詢的原始數(shù)據(jù)的基數(shù)。主流的時(shí)序數(shù)據(jù)庫(kù)提供pre-aggregation(預(yù)聚合)的功能來(lái)優(yōu)化這一過(guò)程，數(shù)據(jù)實(shí)時(shí)寫入后就會(huì)經(jīng)過(guò)預(yù)聚合的運(yùn)算，生成按指定規(guī)則GroupBy之后的結(jié)果，在查詢時(shí)就可以直接查詢結(jié)果而不需要再次計(jì)算。Downsampling(降精度)，Rollup(匯總)和Auto-rollup(自動(dòng)匯總)??Downsampling就是將一個(gè)高精度的時(shí)序數(shù)據(jù)轉(zhuǎn)換為一個(gè)低精度的時(shí)序數(shù)據(jù)的過(guò)程，這個(gè)過(guò)程被稱作Rollup。它與GroupBy的過(guò)程比較類似，核心區(qū)別是GroupBy是基于相同的時(shí)間粒度，把同一時(shí)間層面上的不同維度的數(shù)據(jù)做聚合，轉(zhuǎn)換后的結(jié)果還是相同時(shí)間粒度的數(shù)據(jù)，只不過(guò)是更高的一個(gè)維度。而Downsampling是不同時(shí)間層面上把相同維度的數(shù)據(jù)做聚合，抓換為更粗時(shí)間粒度的數(shù)據(jù)，但是還是擁有相同的維度。

??如圖就是一個(gè)簡(jiǎn)單的Downsampling的例子，將一個(gè)10秒精度的數(shù)據(jù)聚合成30秒精度的數(shù)據(jù)，統(tǒng)計(jì)平均值。??Downsampling分為存儲(chǔ)降精度和查詢降精度，存儲(chǔ)降精度的意義在于降低存儲(chǔ)成本，特別是針對(duì)歷史數(shù)據(jù)。查詢降精度主要是針對(duì)較大時(shí)間范圍的查詢，來(lái)減少返回的數(shù)據(jù)點(diǎn)。不管是存儲(chǔ)降精度還是查詢降精度，都需要auto-rollup。auto-rollup就是自動(dòng)的對(duì)數(shù)據(jù)做rollup，而不是等待查詢時(shí)做rollup，過(guò)程與pre-aggregation類似，能有效的提高查詢效率，這也是目前主流時(shí)序數(shù)據(jù)庫(kù)已經(jīng)提供或者正在規(guī)劃的功能。目前Druid、InfluxDB和KairosDB都提供auto-rollup，OpenTSDB不提供auto-rollup但是暴露了接口支持在外部做auto-rollup后的結(jié)果導(dǎo)入?？偨Y(jié)??本篇文章主要分析了時(shí)序數(shù)據(jù)的特性、模型和基本的查詢和處理操作，以及對(duì)時(shí)序數(shù)據(jù)庫(kù)的基本要求。在下一篇文章中，會(huì)對(duì)當(dāng)前比較流行的幾個(gè)開源的時(shí)序數(shù)據(jù)庫(kù)的實(shí)現(xiàn)做分析。你會(huì)發(fā)現(xiàn)，雖然目前存在那么多的時(shí)序數(shù)據(jù)庫(kù)，但是在基本功能上都是大同小異的。各個(gè)時(shí)序數(shù)據(jù)庫(kù)各有特色，實(shí)現(xiàn)方式也各不同，但是都是圍繞在對(duì)時(shí)序數(shù)據(jù)的寫入、存儲(chǔ)、查詢和分析這幾個(gè)維度的設(shè)計(jì)方案的權(quán)衡和取舍。沒(méi)有一個(gè)萬(wàn)能的時(shí)序數(shù)據(jù)庫(kù)解決了所有的問(wèn)題，在你選擇用何種時(shí)序數(shù)據(jù)庫(kù)的時(shí)候，需要從業(yè)務(wù)角度出發(fā)，選擇一款最合適的時(shí)序數(shù)據(jù)庫(kù)。數(shù)據(jù)的存儲(chǔ)數(shù)據(jù)的存儲(chǔ)可以分為兩個(gè)問(wèn)題，單機(jī)上存儲(chǔ)和分布式存儲(chǔ)。單機(jī)存儲(chǔ)如果只是存儲(chǔ)起來(lái)，直接寫成日志就行。但因?yàn)楹罄m(xù)還要快速的查詢，所以需要考慮存儲(chǔ)的結(jié)構(gòu)。傳統(tǒng)數(shù)據(jù)庫(kù)存儲(chǔ)采用的都是Btree，這是由于其在查詢和順序插入時(shí)有利于減少尋道次數(shù)的組織形式。我們知道磁盤尋道時(shí)間是非常慢的，一般在10ms左右。磁盤的隨機(jī)讀寫慢就慢在尋道上面。對(duì)于隨機(jī)寫入Btree會(huì)消耗大量的時(shí)間在磁盤尋道上，導(dǎo)致速度很慢。我們知道SSD具有更快的尋道時(shí)間，但并沒(méi)有從根本上解決這個(gè)問(wèn)題。對(duì)于90%以上場(chǎng)景都是寫入的時(shí)序數(shù)據(jù)庫(kù)，Btree很明顯是不合適的。業(yè)界主流都是采用LSMtree替換Btree，比如Hbase,Cassandra等nosql中。這里我們?cè)敿?xì)介紹一下。LSMtree包括內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)和磁盤上的文件兩部分。分別對(duì)應(yīng)Hbase里的MemStore和HLog；對(duì)應(yīng)Cassandra里的MemTable和sstable。LSMtree操作流程如下：數(shù)據(jù)寫入和更新時(shí)首先寫入位于內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)。為了避免數(shù)據(jù)丟失也會(huì)先寫到WAL文件中。內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)會(huì)定時(shí)或者達(dá)到固定大小會(huì)刷到磁盤。這些磁盤上的文件不會(huì)被修改。隨著磁盤上積累的文件越來(lái)越多，會(huì)定時(shí)的進(jìn)行合并操作，消除冗余數(shù)據(jù)，減少文件數(shù)量。HbaseLSMtree結(jié)構(gòu)介紹（注1）可以看到LSMtree核心思想就是通過(guò)內(nèi)存寫和后續(xù)磁盤的順序?qū)懭氆@得更高的寫入性能，避免了隨機(jī)寫入。但同時(shí)也犧牲了讀取性能，因?yàn)橥粋€(gè)key的值可能存在于多個(gè)HFile中。為了獲取更好的讀取性能，可以通過(guò)bloomfilter和compaction得到，這里限于篇幅就不詳細(xì)展開。分布式存儲(chǔ)時(shí)序數(shù)據(jù)庫(kù)面向的是海量數(shù)據(jù)的寫入存儲(chǔ)讀取，單機(jī)是無(wú)法解決問(wèn)題的。所以需要采用多機(jī)存儲(chǔ)，也就是分布式存儲(chǔ)。分布式存儲(chǔ)首先要考慮的是如何將數(shù)據(jù)分布到多臺(tái)機(jī)器上面，也就是

分片（sharding）問(wèn)題。下面我們就時(shí)序數(shù)據(jù)庫(kù)分片問(wèn)題展開介紹。分片問(wèn)題由分片方法的選擇和分片的設(shè)計(jì)組成。分片方法時(shí)序數(shù)據(jù)庫(kù)的分片方法和其他分布式系統(tǒng)是相通的。哈希分片：這種方法實(shí)現(xiàn)簡(jiǎn)單，均衡性較好，但是集群不易擴(kuò)展。一致性哈希：這種方案均衡性好，集群擴(kuò)展容易，只是實(shí)現(xiàn)復(fù)雜。代表有Amazon的DynamoDB和開源的Cassandra。范圍劃分：通常配合全局有序，復(fù)雜度在于合并和分裂。代表有Hbase。分片設(shè)計(jì)分片設(shè)計(jì)簡(jiǎn)單來(lái)說(shuō)就是以什么做分片，這是非常有技巧的，會(huì)直接影響寫入讀取的性能。結(jié)合時(shí)序數(shù)據(jù)庫(kù)的特點(diǎn)，根據(jù)metric+tags分片是比較好的一種方式，因?yàn)橥鶗?huì)按照一個(gè)時(shí)間范圍查詢，這樣相同metric和tags的數(shù)據(jù)會(huì)分配到一臺(tái)機(jī)器上連續(xù)存放，順序的磁盤讀取是很快的。再結(jié)合上面講到的單機(jī)存儲(chǔ)內(nèi)容，可以做到快速查詢。進(jìn)一步我們考慮時(shí)序數(shù)據(jù)時(shí)間范圍很長(zhǎng)的情況，需要根據(jù)時(shí)間范圍再將分成幾段，分別存儲(chǔ)到不同的機(jī)器上，這樣對(duì)于大范圍時(shí)序數(shù)據(jù)就可以支持并發(fā)查詢，優(yōu)化查詢速度。如下圖，第一行和第三行都是同樣的tag（sensor=95D8-7913;city=上海），所以分配到同樣的分片，而第五行雖然也是同樣的tag，但是根據(jù)時(shí)間范圍再分段，被分到了不同的分片。第二、四、六行屬于同樣的tag（sensor=F3CC-20F3;city=北京）也是一樣的道理。時(shí)序數(shù)據(jù)分片說(shuō)明真實(shí)案例下面我以一批開源時(shí)序數(shù)據(jù)庫(kù)作為說(shuō)明。1.InfluxDB非常優(yōu)秀的時(shí)序數(shù)據(jù)庫(kù)，但只有單機(jī)版是免費(fèi)開源的，集群版本是要收費(fèi)的。從單機(jī)版本中可以一窺其存儲(chǔ)方案：在單機(jī)上InfluxDB采取類似于LSMtree的存儲(chǔ)結(jié)構(gòu)TSM；而分片的方案InfluxDB先通過(guò)<database>+<timestamp>（事實(shí)上還要加上retentionPolicy）確定ShardGroup，再通過(guò)<metric>+<tags>的hashcode確定到具體的Shard。這里timestamp默認(rèn)情況下是7天對(duì)齊，也就是說(shuō)7天的時(shí)序數(shù)據(jù)會(huì)在一個(gè)Shard中。InfluxdbTSM結(jié)構(gòu)圖（注2）2.Kairosdb底層使用Cassandra作為分布式存儲(chǔ)引擎，如上文提到單機(jī)上采用的是LSMtree。Cassandra有兩級(jí)索引：partitionkey和clusteringkey。其中partitionkey是其分片ID，使用的是一致性哈希；而clusteringkey在一個(gè)partitionkey中保證有序。Kairosdb利用Cassandra的特性，將

<metric>+<timest