建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
?大家好，很開(kāi)心能夠和大家一起交流時(shí)序數(shù)據(jù)庫(kù)的相關(guān)的內(nèi)容。
首先還是簡(jiǎn)單自我介紹一下，我是 孫金城，花名 金竹。我是2011年加入阿里，在2016年之前一直做公司內(nèi)部的研發(fā)工作，包括阿里郎，Blink等平臺(tái)。
從2016年到現(xiàn)在我一直重心在開(kāi)源建設(shè)上面，包括ApacheFlink/ApacheBeam/ApacheIoTDB，在這個(gè)過(guò)程中也得到了開(kāi)源的一些肯定，目前是BeamCommitter，ApacheFlink和ApacheIoTDB的PMC，也是Apache Member，目前全球華人大概有30+的ApacheMember，當(dāng)然，隨著開(kāi)源的越來(lái)越熱，國(guó)內(nèi)每年參與開(kāi)源建設(shè)的同學(xué)也在逐漸的在增加。
那么2020之后會(huì)有怎樣的規(guī)劃呢？本著但做好事，莫問(wèn)前程的心態(tài)，會(huì)多多在訂閱號(hào)中記錄我在流計(jì)算和IoT方面的認(rèn)知。最終努力做到走進(jìn)阿里/踏入開(kāi)源，成為最好的自己J
那么為什么一直做流計(jì)算會(huì)慢慢選擇了解IoT相關(guān)領(lǐng)域呢？因?yàn)樵隈R老師看來(lái)“5G時(shí)代，加速的不僅僅是通訊行業(yè)，而是更多的促進(jìn)物聯(lián)網(wǎng)（IOT）領(lǐng)域的發(fā)展。IoT將是一個(gè)新的浪潮。那么我參與IOT領(lǐng)域的切入點(diǎn)是什么呢，就是從了解時(shí)序數(shù)據(jù)庫(kù) 進(jìn)行著陸的...
如圖，這不是一篇經(jīng)驗(yàn)分享，而是一個(gè)學(xué)習(xí)過(guò)程分享J
了解時(shí)序數(shù)據(jù)庫(kù)最先想到的是: 了解一下時(shí)序數(shù)據(jù)庫(kù)的現(xiàn)狀及發(fā)展趨勢(shì)，那么這個(gè)數(shù)據(jù)的權(quán)威性，大家應(yīng)該有所共識(shí)，在db-engines網(wǎng)站的排名應(yīng)該很客觀的。如圖，從2018年開(kāi)始，TimeSeriesDBMS的關(guān)注度就持續(xù)迅猛的增長(zhǎng)。其實(shí)不僅僅db-engines網(wǎng)站有這樣的數(shù)據(jù)，Gartner也給出了預(yù)見(jiàn)性的判斷。我們一起看一下...
在2019年"賦權(quán)的邊緣" 就成為了十大戰(zhàn)略性技術(shù)趨勢(shì)之一，邊緣由物聯(lián)網(wǎng)驅(qū)動(dòng)，需要使處理計(jì)算更接近端而不是集中式的云服務(wù)器。當(dāng)然早在2018年 "云向邊緣計(jì)算挺進(jìn)" 的趨勢(shì)就已經(jīng)非常明顯。邊緣設(shè)備的信息的收集/存儲(chǔ)和計(jì)算需求與日俱增，一直到目前2020年，更多的計(jì)算和存儲(chǔ)能力都逐漸下沉到設(shè)備端，云邊端一體將是今后幾年持續(xù)的焦點(diǎn)。設(shè)備數(shù)據(jù)具備時(shí)序性，而作為物聯(lián)網(wǎng)領(lǐng)域具備存儲(chǔ)和計(jì)算能力的產(chǎn)品就是時(shí)序數(shù)據(jù)庫(kù)。那么目前業(yè)界時(shí)序數(shù)據(jù)庫(kù)的陣營(yíng)是怎樣的狀況呢？我們繼續(xù)看一下...
同樣出自DB-Engines的排名信息，目前有幾十種（大概34種）時(shí)序數(shù)據(jù)庫(kù)，大家熟知的InfluxDB自2016年以來(lái)穩(wěn)穩(wěn)的位居榜首，隨著2018年IoT領(lǐng)域的崛起，InfluxDB的熱度也持續(xù)飆升，穩(wěn)穩(wěn)地龍頭位置，那么InfluxDB為啥如此受到時(shí)序數(shù)據(jù)存儲(chǔ)技術(shù)的青睞呢？我們接下來(lái)就會(huì)和大家細(xì)致進(jìn)行分析...
其實(shí)時(shí)序數(shù)據(jù)庫(kù)早在1999年就已經(jīng)有RRDtool,全稱(chēng)RoundRobin Database。新數(shù)據(jù)會(huì)自動(dòng)覆蓋老數(shù)據(jù)，也就是考慮了時(shí)序數(shù)據(jù)的時(shí)效性，在2008年又出現(xiàn)了Graphite，Graphite是一個(gè)用于采集網(wǎng)站實(shí)時(shí)信息，并進(jìn)行統(tǒng)計(jì)的開(kāi)源項(xiàng)目，可用于采集多種網(wǎng)站服務(wù)運(yùn)行狀態(tài)信息。隨后就是大家熟知的OpenTSDB，InfluxDB，還有feacebook的內(nèi)存版時(shí)序數(shù)據(jù)庫(kù)，再有就是非常著名的用于監(jiān)控的Prometueus，2017年，2018年的時(shí)候時(shí)序數(shù)據(jù)庫(kù)已經(jīng)發(fā)展的非常迅速來(lái)，這個(gè)在剛才的DB-engines網(wǎng)站數(shù)據(jù)和Gartner給出的戰(zhàn)略技術(shù)趨勢(shì)信息是非常吻合的。那么在2020年，Apache開(kāi)源社區(qū)又出現(xiàn)了時(shí)序數(shù)據(jù)庫(kù)的黑馬 ApacheIoTDB，將來(lái)還會(huì)有哪些時(shí)序數(shù)據(jù)庫(kù)產(chǎn)品呢？我們讓時(shí)間來(lái)揭曉。J
那么，在這里，拋出一個(gè)問(wèn)題，就是：“時(shí)序數(shù)據(jù)庫(kù)難道不能直接存儲(chǔ)到關(guān)系數(shù)據(jù)庫(kù)嗎？”為啥要造出很多時(shí)序數(shù)據(jù)庫(kù)，時(shí)序數(shù)據(jù)庫(kù)和關(guān)系數(shù)據(jù)庫(kù)又有怎樣的本質(zhì)區(qū)別呢？
其實(shí)數(shù)據(jù)存到哪里合適，還是要看數(shù)據(jù)本身的特點(diǎn)，以及數(shù)據(jù)處理的需求。面對(duì)IoT領(lǐng)域，時(shí)序數(shù)據(jù)有很多的數(shù)據(jù)來(lái)源，比如汽車(chē)，火車(chē)，飛機(jī)等交通工具，以及我們?cè)絹?lái)越被大家認(rèn)可的智能家居產(chǎn)品等。
當(dāng)然最大的數(shù)據(jù)量來(lái)源還是工業(yè)領(lǐng)域的各種設(shè)備傳感器數(shù)據(jù)，這些設(shè)備的工況數(shù)據(jù)收集和處理將給存儲(chǔ)和計(jì)算帶來(lái)巨大的挑戰(zhàn)。
我們以一個(gè)具體的案例來(lái)說(shuō)，這是GoldWind發(fā)電數(shù)據(jù)采集，GoldWind有超過(guò)2w個(gè)風(fēng)機(jī)，一個(gè)風(fēng)機(jī)有120-510個(gè)傳感器，采集頻率高達(dá)50Hz，就是每個(gè)傳感器1秒50個(gè)數(shù)據(jù)點(diǎn)采集峰值。這要算下來(lái)就是每秒5億個(gè)時(shí)序指標(biāo)點(diǎn)的數(shù)據(jù)。
這個(gè)數(shù)據(jù)量讓數(shù)據(jù)采集/存儲(chǔ)/計(jì)算面臨很大的挑戰(zhàn)。同時(shí)還有我們業(yè)務(wù)中的一些非常常見(jiàn)的采集/查詢(xún)需求，20萬(wàn)/妙的吞肚需求是非常常見(jiàn)的，但是這樣的需求單機(jī)關(guān)系數(shù)據(jù)庫(kù)也是很難搞定的，我們接下來(lái)會(huì)分析一下具體原因。
好的，那么還是簡(jiǎn)單梳理一下時(shí)序數(shù)據(jù)的特點(diǎn)，首先時(shí)序數(shù)據(jù)有特定的一些概念。如圖：Metric，就是我們要采集的指標(biāo)，類(lèi)似一張表，還有Tag，就是metric的屬性特點(diǎn)，比如指標(biāo)屬于哪個(gè)設(shè)備，哪個(gè)區(qū)域等等維度信息。再有Field就是真實(shí)要采集的指標(biāo)名稱(chēng)。那么非常重要的時(shí)序數(shù)據(jù)一定有數(shù)據(jù)產(chǎn)生的時(shí)間，就是Timestamp時(shí)間戳信息，指標(biāo)數(shù)據(jù)的時(shí)效性也是非常重要的，所以要有時(shí)間信息。那么Point就是類(lèi)似表的一行數(shù)據(jù)。我們以風(fēng)力 指標(biāo) 為例 簡(jiǎn)單圖示一下這些概念。
Wind-force就是Metric，其中 city，region就是Tag，speed和direction就是Field。當(dāng)然Timestamp不用多說(shuō)就是指標(biāo)數(shù)據(jù)產(chǎn)生的時(shí)間了。
那么這種關(guān)系設(shè)計(jì)的方式大家不難發(fā)現(xiàn)，tag的數(shù)據(jù)存儲(chǔ)會(huì)有很多的冗余。這是關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)時(shí)序數(shù)據(jù)的一個(gè)涉及到存儲(chǔ)成本的問(wèn)題。當(dāng)然問(wèn)題不僅如此，我們繼續(xù)往下看。
現(xiàn)在，我們簡(jiǎn)單總結(jié)一下時(shí)序數(shù)據(jù)場(chǎng)景的特點(diǎn)或者說(shuō)是需求核心會(huì)涉及到寫(xiě)入/讀取/存儲(chǔ)成本三個(gè)維度。寫(xiě)入要支撐上千萬(wàn)甚至上億的吞吐能力；讀取就需要根據(jù)不同的業(yè)務(wù)有不同的讀取需求，后面我們會(huì)慢慢分析到。當(dāng)然面對(duì)成本問(wèn)題，海量數(shù)據(jù)的存儲(chǔ)成本無(wú)疑是時(shí)序數(shù)據(jù)庫(kù)設(shè)計(jì)的重中之重。所以，面對(duì)這樣的時(shí)序數(shù)據(jù)場(chǎng)景的特點(diǎn)，時(shí)序數(shù)據(jù)存儲(chǔ)到關(guān)系數(shù)據(jù)庫(kù)就會(huì)有很多弊端，比如剛才說(shuō)的數(shù)據(jù)冗余造成的成本問(wèn)題，還有寫(xiě)入的吞吐問(wèn)題等，那么我們接下來(lái)就要討論這些問(wèn)題存在的本質(zhì)原因...
好,回過(guò)頭來(lái)我們?cè)趤?lái)看看目前的時(shí)序數(shù)據(jù)庫(kù)從架構(gòu)的角度有哪幾種？
第一種，就是在關(guān)系數(shù)據(jù)庫(kù)基礎(chǔ)上進(jìn)行改進(jìn)的時(shí)序數(shù)據(jù)庫(kù)，比如基于PG開(kāi)發(fā)的Timescale。
第二種，就是在KV數(shù)據(jù)庫(kù)的基礎(chǔ)之上進(jìn)行改進(jìn)的時(shí)序數(shù)據(jù)庫(kù)，比如，基于HBase開(kāi)發(fā)的OpenTSDB。
第三種，就是為時(shí)序數(shù)據(jù)量身定制的時(shí)序數(shù)據(jù)庫(kù)，那么目前的領(lǐng)頭羊就是InfluxDB。當(dāng)然，我前面說(shuō)過(guò)，我也很看好2020新晉的Apache頂級(jí)項(xiàng)目ApacheIoTDB。
這三類(lèi)時(shí)序數(shù)據(jù)庫(kù)又怎樣的特點(diǎn)呢，我們接下來(lái)逐一進(jìn)行討論分析...
我們先來(lái)看看基于關(guān)系數(shù)據(jù)庫(kù)的時(shí)序數(shù)據(jù)庫(kù)，既然基于關(guān)系數(shù)據(jù)庫(kù)，那么我就要聊聊和關(guān)系數(shù)據(jù)庫(kù)密切相關(guān)的存儲(chǔ)結(jié)構(gòu)。
首先我們看一個(gè)簡(jiǎn)單的二叉樹(shù),我們知道二叉樹(shù)是樹(shù)形結(jié)構(gòu)的一個(gè)重要類(lèi)型。許多實(shí)際問(wèn)題抽象出來(lái)的數(shù)據(jù)結(jié)構(gòu)往往是二叉樹(shù)形式，而且二叉樹(shù)的存儲(chǔ)結(jié)構(gòu)及其算法都較為簡(jiǎn)單，二叉樹(shù)特點(diǎn)是每個(gè)結(jié)點(diǎn)最多只能有兩棵子樹(shù)，且有左右之分。那么我們看看怎樣向二叉樹(shù)里面插入一個(gè)數(shù)據(jù)點(diǎn)呢？
如圖，我們插入節(jié)點(diǎn)10，插入的過(guò)程是二分法，即使從整個(gè)節(jié)點(diǎn)的數(shù)值的中間開(kāi)始，如果要插入的值比這個(gè)數(shù)小就從左子樹(shù)繼續(xù)二分查找，如果要插入的數(shù)據(jù)比當(dāng)前數(shù)大，就從右子樹(shù)繼續(xù)查找，那么按照這個(gè)算法，二叉樹(shù)的寫(xiě)入和查詢(xún)的復(fù)雜度都是logN。
我們?cè)倥e一個(gè)小例子，可能目前我們講解的內(nèi)容很簡(jiǎn)單，大家都很熟悉，不過(guò)為了為后面的內(nèi)容做鋪墊，大家還是稍微耐心聽(tīng)我多啰嗦幾句。這個(gè)例子，就是假設(shè)我們有如圖8個(gè)數(shù)據(jù)，我們?nèi)绻胍檎覕?shù)據(jù)2，那么我們先看中間數(shù)據(jù)（第4個(gè)）點(diǎn)，13，比較一下13比2大，所以要查詢(xún)的2一定在13的左邊，我們?cè)購(gòu)淖筮叺臄?shù)據(jù)進(jìn)行二分查找，左邊的中間數(shù)據(jù)5，發(fā)現(xiàn)5還是比2大，那么就需要查找左子樹(shù)，目前只剩下了2，當(dāng)然也就是我們要找的數(shù)據(jù)了。那么logN其實(shí)就是log2N對(duì)吧，集合8個(gè)數(shù)據(jù)，查找一條數(shù)據(jù)就是log8，2的3次方等于8，所以log8就是3次，這是二叉樹(shù)的查詢(xún)復(fù)雜度的一個(gè)簡(jiǎn)單示例說(shuō)明。OK，這個(gè)二叉樹(shù)介紹呢有點(diǎn)浪費(fèi)大家時(shí)間，廢話(huà)有點(diǎn)多，大家見(jiàn)諒，那么，接下來(lái)我們就介紹關(guān)系數(shù)據(jù)庫(kù)中使用的存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)。
在實(shí)際的關(guān)系數(shù)據(jù)庫(kù)中有2種數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，一個(gè)是BTree一個(gè)是B+Tree，那么，這兩種數(shù)據(jù)結(jié)構(gòu)格局特色，都有使用的場(chǎng)景。那么這兩種數(shù)據(jù)結(jié)構(gòu)的查詢(xún)復(fù)雜度是怎樣的呢？有什么本質(zhì)區(qū)別。
BTree的寫(xiě)入成本是LogBN，B就是樹(shù)的階數(shù)，如圖就是3階BTree，每個(gè)節(jié)點(diǎn)的黃色方框表示的指針個(gè)數(shù)就是樹(shù)的階數(shù)，藍(lán)色部分就是具體構(gòu)建BTree節(jié)點(diǎn)的數(shù)值，如果是索引樹(shù)的話(huà)，藍(lán)色部分就是構(gòu)建索引的key的值，比如訂單號(hào)之類(lèi)的關(guān)系數(shù)據(jù)庫(kù)的索引字段。
B+Tree的寫(xiě)入成本是LogBN，如果都是LogBN那么Btree和T+Tree有啥本質(zhì)區(qū)別呢？這要看看BTree和B+Tree從數(shù)據(jù)的結(jié)構(gòu)上有啥區(qū)別？
最本質(zhì)的區(qū)別是BTree在每個(gè)樹(shù)節(jié)點(diǎn)是有數(shù)據(jù)存放的，B+Tree只有葉子節(jié)點(diǎn)才會(huì)存放數(shù)據(jù)，我們說(shuō)的數(shù)據(jù)就是關(guān)系數(shù)據(jù)庫(kù)中一行數(shù)據(jù)（包括Key和普通字段），比如訂單號(hào)是key，訂單號(hào)以及訂單對(duì)應(yīng)的產(chǎn)品名稱(chēng)，數(shù)量，金額等就是數(shù)據(jù)。同時(shí)還有一個(gè)很大的區(qū)別就是B+Tree結(jié)構(gòu)在樹(shù)葉節(jié)點(diǎn)是有指針指向相鄰的葉子節(jié)點(diǎn)的，是一個(gè)鏈表。這特點(diǎn)，大家想想有什么利好？對(duì)，這個(gè)特點(diǎn)是有助于區(qū)間查詢(xún)的。大家花幾秒鐘時(shí)間思考一下，相對(duì)于BTree是不是有這樣的優(yōu)勢(shì)？:)
這里大家可能發(fā)現(xiàn)一個(gè)問(wèn)題，就是這個(gè)算法復(fù)雜度應(yīng)該是LogN，為啥是LogBN。本質(zhì)上在存儲(chǔ)角度我們考慮的是DAM模型，也就是計(jì)算磁盤(pán)訪(fǎng)問(wèn)次數(shù)的成本。
我們繼續(xù)思考另外一個(gè)有意思的問(wèn)題？Btree的成本和B+Tree都一樣，B+Tree又有友好支持區(qū)間查詢(xún)的優(yōu)勢(shì)，那么兩個(gè)共存的意義是什么呢？好，我們還需要繼續(xù)搞清楚這件事情...其實(shí)對(duì)于不太了解這些數(shù)據(jù)結(jié)構(gòu)的同學(xué)是有點(diǎn)燒腦的，對(duì)于熟悉的同學(xué)可以放松一下，我們繼續(xù)探究B+Tree存在的意義，拋開(kāi)算法復(fù)雜度之外，還有哪些其他存儲(chǔ)領(lǐng)域的實(shí)際因素，導(dǎo)致B+Tree更有優(yōu)勢(shì)。
上面是BTree從算法角度的復(fù)雜度推導(dǎo)，下面是B+Tree的...
這里有一個(gè)地方要說(shuō)明一下，這里推理的復(fù)雜度是logN，但是前面我們說(shuō)的是logBN，這個(gè)差別是什么？其實(shí)本質(zhì)前面是磁盤(pán)訪(fǎng)問(wèn)復(fù)雜度，不包括數(shù)據(jù)塊內(nèi)的key值查找。這個(gè)大家如過(guò)感興趣，可以思考一下，如果有問(wèn)題歡迎留言J
OK，放松3秒鐘，然后繼續(xù)分析 B+ Tree ？我們繼續(xù)和這個(gè)問(wèn)題死磕...
要想清楚上面的問(wèn)題，我們還需要一些算法之外的輔助內(nèi)容，雖然是輔助但卻是和存儲(chǔ)系統(tǒng)密切相關(guān)的部分。那就是磁盤(pán)。在存儲(chǔ)領(lǐng)域選擇BTree還是B+Tree和磁盤(pán)IO有著直接的關(guān)系。那么什么是磁盤(pán)IO呢？
我們知道計(jì)算機(jī)的CPU就如同人的大腦，大腦根據(jù)外部輸入進(jìn)行思考，并為我們下達(dá)行為命令，那么CUP同樣要依托于外部輸入進(jìn)行計(jì)算，然后將計(jì)算的結(jié)果再向外輸出。那么我們存儲(chǔ)里面的磁盤(pán)IO可以簡(jiǎn)單理解成從磁盤(pán)讀取數(shù)據(jù)和向磁盤(pán)寫(xiě)數(shù)據(jù)的過(guò)程。
這個(gè)圖應(yīng)該是我們上學(xué)課本或者數(shù)據(jù)庫(kù)理論方面書(shū)籍里的圖片，處理器，數(shù)據(jù)總線(xiàn)，主存，磁盤(pán)等等，我們?cè)偈煜げ贿^(guò)的名詞，當(dāng)然內(nèi)部也是非常復(fù)雜的，我們今天挑與我們要討論的問(wèn)題相關(guān)的內(nèi)容進(jìn)行分析。
那就聊聊磁盤(pán)，首先磁盤(pán)內(nèi)有很多的盤(pán)片，每個(gè)盤(pán)片又由若干扇區(qū)組成，扇區(qū)是磁盤(pán)讀寫(xiě)的最小單元，每個(gè)扇區(qū)多大呢？一般是512個(gè)字節(jié)。好，那么這個(gè)和數(shù)據(jù)庫(kù)又有啥關(guān)系呢？
數(shù)據(jù)庫(kù)的數(shù)據(jù)就存儲(chǔ)在磁盤(pán)上，但是從數(shù)據(jù)庫(kù)系統(tǒng)角度如果每次讀取一個(gè)扇區(qū)的數(shù)據(jù)就太慢了，所以數(shù)據(jù)庫(kù)一般會(huì)有數(shù)據(jù)塊的抽象設(shè)計(jì)，數(shù)據(jù)都是一個(gè)數(shù)據(jù)塊讀取一次磁盤(pán)，一般數(shù)據(jù)塊大小是4～64KB，那么重點(diǎn)來(lái)了，通常讀取一個(gè)數(shù)據(jù)塊的磁盤(pán)IO需要消耗大概10ms左右的時(shí)間，這是非常耗時(shí)的操作了，所以我們?cè)跀?shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候一定要盡量減少磁盤(pán)的訪(fǎng)問(wèn)次數(shù)。那么MySQL的InnoDB默認(rèn)數(shù)據(jù)塊的大小是16KB，當(dāng)然這是可以配置的。不同數(shù)據(jù)庫(kù)默認(rèn)值不一樣，比如HBase存儲(chǔ)的數(shù)據(jù)塊大小應(yīng)該默認(rèn)64M。好的，說(shuō)到這里，不知道大家是不是知道我接下來(lái)要說(shuō)什么了？有這方面經(jīng)驗(yàn)的估計(jì)秒懂，但是第一次思考這個(gè)問(wèn)題的，還是需要些解釋的，我們往下繼續(xù)進(jìn)行...
OK,我們還是舉一個(gè)例子來(lái)討論，假設(shè)以16K為塊大小，也就是每16K數(shù)據(jù)需要訪(fǎng)問(wèn)一次磁盤(pán)，我們的目標(biāo)是減少磁盤(pán)I/0,那么數(shù)據(jù)相同的情況下，B-Tree和B+Tree哪個(gè)磁盤(pán)I/O更少呢？假設(shè)我們有一個(gè)查詢(xún)：select* from device where deviceId=38deviceID是一個(gè)bigint的8字節(jié)類(lèi)型，作為索引key。我們分別分析一下，Btree和B+Tree哪個(gè)訪(fǎng)問(wèn)磁盤(pán)更少？
主鍵deviceId為bigint類(lèi)型，長(zhǎng)度為8字節(jié)，而指針大小在InnoDB源碼中設(shè)置為6字節(jié)，這樣一共14字節(jié)，也即是如圖一個(gè)藍(lán)色框數(shù)據(jù)和一個(gè)橙色框指針需要14個(gè)字節(jié)存儲(chǔ)。那么，我們一個(gè)數(shù)據(jù)塊中能存放多少這樣的單元，就代表一次可以在內(nèi)存加載多少數(shù)據(jù)key（deviceID）和對(duì)應(yīng)的地址指針，即16384(16K)/14bytes=1170。也即是，每1170個(gè)設(shè)備id讀取一次磁盤(pán)，那么也就是內(nèi)存構(gòu)建一個(gè)1170階的B+Tree。
那么大家想，如果是BTree結(jié)構(gòu)，一行數(shù)據(jù)除了設(shè)備Id還有他設(shè)備信息，那么Btree在沒(méi)有節(jié)點(diǎn)不但存儲(chǔ)key和指針，還要存儲(chǔ)數(shù)據(jù)，所以同樣的數(shù)據(jù)塊大小，是不是一次加載到內(nèi)存的Key數(shù)量比B+tree要少很多，那么在查詢(xún)時(shí)候必然比B+Tree訪(fǎng)問(wèn)磁盤(pán)IO要多，大家思考2秒鐘，是不是這個(gè)道理？:)
那么如果是BTree，相同的塊大小，樹(shù)的階數(shù)就比較小，相對(duì)于B+Tree來(lái)說(shuō)，相同條件B+Tree的階數(shù)更大，也就是復(fù)雜度上的logBN，的B比較較大，B越大，相同的查詢(xún)開(kāi)銷(xiāo)越小。
那么，既然B+tree很優(yōu)秀，我們看看一個(gè)B+Tree能支持怎樣的數(shù)據(jù)規(guī)模呢？好我們想想B+Tree只有葉子節(jié)點(diǎn)要數(shù)據(jù)，比如我們一行數(shù)據(jù)是1K，一個(gè)數(shù)塊是16K，那么也即是一個(gè)數(shù)據(jù)塊可以存放16行數(shù)據(jù)。那么一個(gè)3層的B+Tree，葉子節(jié)點(diǎn)有多少行記錄呢？三層的樹(shù)的話(huà)，第二層有多少數(shù)據(jù)指針指向第三層葉子節(jié)點(diǎn)就有多少數(shù)據(jù)塊數(shù)據(jù)的數(shù)據(jù)，每個(gè)葉子是一個(gè)數(shù)據(jù)塊，每塊有16行數(shù)據(jù)就能計(jì)算數(shù)據(jù)規(guī)模了。那么底層有多少指針呢？還是按照剛才MySQLinnoDB的例子算，會(huì)構(gòu)建一個(gè)1170階的B+Tree，大家還記得“階”的概念吧，就是一個(gè)節(jié)點(diǎn)指針的數(shù)量，那么1170階的B+tree，第二層首先有1170個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)又有1170個(gè)指針（剛才我們計(jì)算過(guò)），那么我們可以計(jì)算第三層的記錄行數(shù)了，那就是：1170*1170*16=2000w+。也即是3層的1170階B+tree可以完美的支持2000w的數(shù)據(jù)量，那么這2000w數(shù)據(jù)量查詢(xún)一條數(shù)據(jù)的成本是多少呢？通常磁盤(pán)IO的代價(jià)是最大的，剛才我們說(shuō)的了一次磁盤(pán)大概10ms，那么3層，我們最多要3次磁盤(pán)IO就可以查詢(xún)到了。也就是毫秒級(jí)的查詢(xún)延時(shí)。
我們?cè)倏匆粋€(gè)例子，分析為啥3次就夠了，假設(shè)這棵樹(shù)，我們要查找key為30的數(shù)據(jù)，那么過(guò)程如下。
根據(jù)根結(jié)點(diǎn)指針找到文件目錄的根磁盤(pán)塊1，將其中的信息導(dǎo)入內(nèi)存。[1次磁盤(pán)IO] 此時(shí)內(nèi)存中有三個(gè)key(5,28,65)和三個(gè)存儲(chǔ)其他磁盤(pán)塊的地址的數(shù)據(jù)。我們發(fā)現(xiàn)28<30<65，因此我們找到指針p2。
- 根據(jù)p2指針，我們定位到磁盤(pán)塊3，并將其中的信息導(dǎo)入內(nèi)存。 [2次磁盤(pán)IO] 此時(shí)內(nèi)存中有3個(gè)key(28,35,56)和三個(gè)存儲(chǔ)其他磁盤(pán)塊的地址的數(shù)據(jù)。我們發(fā)現(xiàn)28<30<35，因此我們找到指針p1。
- 根據(jù)p1指針，我們定位到磁盤(pán)塊8，并將其中的信息導(dǎo)入內(nèi)存。 [3次磁盤(pán)IO] 此時(shí)內(nèi)存中有3個(gè)key(28,30,33)和對(duì)應(yīng)的數(shù)據(jù)，完成查找。
OK，查詢(xún)的邏輯和成本消耗先介紹到這里。下面更重要的內(nèi)容來(lái)了，也就是內(nèi)容會(huì)涉及到了為什么關(guān)系數(shù)據(jù)庫(kù)不適合作為IoT場(chǎng)景的存儲(chǔ)，大家要多花精力理解，我給大家演示一下BTree的寫(xiě)入的過(guò)程。。。
好，接下來(lái)，假設(shè)我們有數(shù)據(jù)按照如圖的順序到來(lái)，如何一步，一步的構(gòu)建一顆BTree索引樹(shù)呢？
好，首先來(lái)的數(shù)據(jù)是3，35，90我們構(gòu)建一個(gè)樹(shù)的形態(tài)如圖，35是root，左右各有一個(gè)孩子。
然后又來(lái)了17和26，二分的方式，17和26都小于35，所以都在35的左子樹(shù)，但是這里有個(gè)問(wèn)題？
就是我們是一個(gè)3階Btree，指針有3個(gè)，節(jié)點(diǎn)只能有2個(gè)，所以3，17，26已經(jīng)超了，我們要進(jìn)行節(jié)點(diǎn)的分裂，后面存儲(chǔ)層面就涉及到磁盤(pán)塊的分裂。
好，我們進(jìn)行節(jié)點(diǎn)分裂之后，樹(shù)的樣子變成，root節(jié)點(diǎn)有2個(gè)key3個(gè)指針。我們繼續(xù)看后面的變化。。。
我們看看后面來(lái)了哪些數(shù)據(jù)。。。樹(shù)的變化如圖，這里提醒一點(diǎn)，中序遍歷的不同的樹(shù)形狀可以得到相同的結(jié)果。我們這個(gè)例子核心是想說(shuō)明數(shù)據(jù)的構(gòu)建過(guò)程有節(jié)點(diǎn)的分裂，也意味著存儲(chǔ)有磁盤(pán)塊的分裂，會(huì)產(chǎn)生大量的隨機(jī)磁盤(pán)IO。我們繼續(xù)看變化。。。
接下來(lái)再后面的數(shù)據(jù)。。好，36，87，29，65，75到來(lái)后，樹(shù)的形狀如圖。。。(這棵樹(shù)是故意弄的很平衡哈:)
最后，我們看看有哪些數(shù)據(jù)到來(lái)，最終樹(shù)的形成?；贐-Tree/B+Tree的存儲(chǔ)，數(shù)據(jù)寫(xiě)入造成很多的隨機(jī)IO。我簡(jiǎn)單說(shuō)一下，大家思考，如果一個(gè)節(jié)點(diǎn)已經(jīng)寫(xiě)入磁盤(pán)了，后面樹(shù)形發(fā)生變化之后，節(jié)點(diǎn)分裂，原先存儲(chǔ)到一個(gè)磁盤(pán)塊的數(shù)據(jù)，就會(huì)分開(kāi)存儲(chǔ)到2個(gè)新的磁盤(pán)塊，那么原先的磁盤(pán)塊就要?jiǎng)h除。這樣反復(fù)的操作，那就造成了Btree/B+tree很多的隨機(jī)IO了。
OK，聊到隨機(jī)IO對(duì)存儲(chǔ)系統(tǒng)的影響，我們也要順便說(shuō)一下相對(duì)于隨機(jī)I/O就是順序I/O。
- 順序IO - 是本次 I/O 給出的初始扇區(qū)地址和上一次 I/O 的結(jié)束扇區(qū)地址是完全連續(xù)或者相隔不多的。在順序I/O訪(fǎng)問(wèn)中，磁盤(pán)所需的磁道搜索時(shí)間較少，讀/寫(xiě)磁頭可以以最小的移動(dòng)訪(fǎng)問(wèn)下一個(gè)塊。
- 隨機(jī)IO - 是指讀寫(xiě)操作時(shí)間連續(xù)，但訪(fǎng)問(wèn)扇區(qū)地址不連續(xù)，隨機(jī)分布在磁盤(pán)LUN的地址空間中。
隨機(jī)I/O可能是因?yàn)榇疟P(pán)碎片導(dǎo)致磁盤(pán)空間不連續(xù)，或者當(dāng)前block空間小于文件大小導(dǎo)致的。連續(xù) I/O 比隨機(jī) I/O 效率高的原因是：在做連續(xù) I/O 的時(shí)候，磁頭幾乎不用換道，或者換道的時(shí)間很短；而對(duì)于隨機(jī) I/O，如果I/O 很頻繁的話(huà)，會(huì)導(dǎo)致磁頭不停地?fù)Q道，造成效率的極大降低。如圖，我們看到不同磁盤(pán) 順序?qū)懞碗S機(jī)寫(xiě)的性能差異，差不多都是數(shù)量級(jí)的差距。即便SSD的硬盤(pán)，希捷公司也有明確的說(shuō)明，大家可以參考鏈接查看測(cè)試數(shù)據(jù)。
所以隨機(jī)IO和順序IO對(duì)存儲(chǔ)系統(tǒng)的寫(xiě)入性能有很大的影響。那么這些差異和時(shí)序數(shù)據(jù)場(chǎng)景有什么關(guān)系呢？我們繼續(xù)聊。。
首先我們還是要切回時(shí)序數(shù)據(jù)場(chǎng)景的特點(diǎn)，IoT場(chǎng)景是寫(xiě)多/讀少的場(chǎng)景，寫(xiě)入性能至關(guān)重要。所以基于關(guān)系數(shù)庫(kù)，也就是Btree的存儲(chǔ)結(jié)構(gòu)的時(shí)序數(shù)據(jù)塊在存儲(chǔ)時(shí)序數(shù)據(jù)時(shí)候都存在IO效率低下，寫(xiě)入速度很慢的現(xiàn)象。那么需要如何解決呢？
解決BTree的寫(xiě)入問(wèn)題一般有兩種方式，一種是是COLA（Cache-Oblivious Look ahead Array）- tokuDB。另一類(lèi)就是我們今天要重點(diǎn)分析的，LSM tree(Log-structured merge Tree)結(jié)構(gòu)。這個(gè)數(shù)據(jù)結(jié)構(gòu)的插入復(fù)雜度是O（1），這個(gè)比B+Tree的logN要優(yōu)秀很多了。
目前基于LSM Tree數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)有很多，如著名的KV存儲(chǔ)HBase還有LEVELDB，RocksDB等等。
那么為了解決時(shí)序數(shù)據(jù)寫(xiě)入問(wèn)題，時(shí)序數(shù)據(jù)庫(kù)陣營(yíng)出現(xiàn)了一些基于KV存儲(chǔ)的時(shí)序數(shù)據(jù)庫(kù)，比如大家熟知的，基于HBase的OpenTSDB。
LSM Tree全稱(chēng)是 Log-structured merge Tree，Merge就是合并，Log structured就是像寫(xiě)日志一樣進(jìn)行順序?qū)懭?，append only的方式。
LSM樹(shù)的核心思想就是放棄部分讀能力，換取寫(xiě)入能力的最大化。核心思路其實(shí)非常簡(jiǎn)單，就是假定內(nèi)存足夠大，因此不需要每次有數(shù)據(jù)更新就必須將數(shù)據(jù)寫(xiě)入到磁盤(pán)中，而可以先將最新的數(shù)據(jù)駐留在內(nèi)存中，等到積累到一定程度后，再使用歸并排序的方式將內(nèi)存中的數(shù)據(jù)合并追加到磁盤(pán)隊(duì)尾。我們來(lái)看一下這個(gè)基于LSM Tree的寫(xiě)入過(guò)程：
首先我們要解決如何做到順序IO，就是一個(gè)數(shù)據(jù)寫(xiě)入到來(lái)之后，先進(jìn)行WAL的落盤(pán)。那么如何解決亂序？那就是，寫(xiě)WAL是為了恢復(fù)，真正的有序?qū)懭胍獙?shù)據(jù)寫(xiě)入內(nèi)存，也就是Mem-Table，然后對(duì)Mem-Table進(jìn)行排序，數(shù)據(jù)寫(xiě)入到內(nèi)存之后，就表示寫(xiě)入成功了。那么寫(xiě)到內(nèi)存之后會(huì)怎樣操作呢？就是要解決落盤(pán)問(wèn)題。當(dāng)內(nèi)存數(shù)據(jù)到達(dá)一定規(guī)模，就需要寫(xiě)入磁盤(pán)，LSM Tree的做法是將要刷磁盤(pán)的Mem-Table變成immutable，刷磁盤(pán)同時(shí)不影響寫(xiě)入請(qǐng)求，在創(chuàng)建一個(gè)新的Mem-table。這樣的持久化在數(shù)據(jù)持續(xù)變化和查詢(xún)的時(shí)候會(huì)有什么問(wèn)題嗎？當(dāng)然有，比如，key更新/刪除了怎么辦？要查詢(xún)的key在多個(gè)文件怎么辦？所以，LSM Tree結(jié)構(gòu)還需要有一個(gè)Compactions的階段，以及對(duì)數(shù)據(jù)創(chuàng)建索引的過(guò)程。我們以HBase的HFile為例，存儲(chǔ)結(jié)構(gòu)如圖，文件中除了數(shù)據(jù)還需要有索引和Boolmfilter的機(jī)制進(jìn)行加速查詢(xún)。
上面我們了解了LSM Tree的寫(xiě)入邏輯，那么查詢(xún)邏輯是怎么樣的呢？查詢(xún)邏輯最核心的是要查詢(xún)索引,首先在內(nèi)存Mem-table里面查詢(xún)，然后在immutable Mem-table里面進(jìn)行查找，然后是磁盤(pán)Flie里面進(jìn)行查找。當(dāng)然這里有Bloom filter輔助查詢(xún)。Bloom filter本質(zhì)就是一個(gè)bitmap，每個(gè)key數(shù)據(jù)用k個(gè)獨(dú)立的hash就行計(jì)算，填充bitmap，數(shù)據(jù)查詢(xún)時(shí)候Bloomfilter說(shuō)沒(méi)有一定沒(méi)有，Bloomfilter說(shuō)有，不一定有，還要繼續(xù)索引查找。
LSMTree雖然以犧牲查詢(xún)?yōu)榇鷥r(jià)來(lái)解決Btree寫(xiě)入問(wèn)題，但是會(huì)利用一些輔助手段，比如索引，Bloomfilter基數(shù)估計(jì)等手段加速查詢(xún)，同時(shí)各種數(shù)據(jù)庫(kù)還會(huì)有不同的Cache機(jī)制加速查詢(xún)。這樣聽(tīng)起來(lái)基于LSMTree結(jié)構(gòu)的KV存儲(chǔ)應(yīng)該有很不錯(cuò)的讀寫(xiě)表現(xiàn)。那么基于KV存儲(chǔ)的時(shí)序數(shù)據(jù)庫(kù)應(yīng)該怎樣設(shè)計(jì)呢？
我們還是以大家熟知的基于HBase的OpenTSDB為例來(lái)進(jìn)行分析，看看KV存儲(chǔ)在設(shè)計(jì)時(shí)序數(shù)據(jù)存儲(chǔ)時(shí)候的設(shè)計(jì)技巧和存在的問(wèn)題。
以HBase為例，我們聊聊KV存儲(chǔ)對(duì)LSMTree的應(yīng)用，如圖大家應(yīng)該很熟悉，HBaseClient向HBase的RegionServer發(fā)起讀寫(xiě)請(qǐng)求，當(dāng)然HLog就是LSMTree中的WAL部分，MemStore就相當(dāng)于LSM里面的Mem-table部分，HFile就是持久化文件。
簡(jiǎn)化一下就是HBase的HRegionServer包括HLog和HRegion，一個(gè)HRegion包括很多的HStore又分為MemStore和HFile兩個(gè)核心部分。
其中按照Rowkey進(jìn)行region劃分，每個(gè)region對(duì)應(yīng)一個(gè)ColumnFamily，一個(gè)MemStore。
每個(gè)ColumnFamily里面又有若干Qualifiler。當(dāng)然任何一個(gè)KV數(shù)據(jù)又會(huì)包含一個(gè)時(shí)間戳Timestamp。
那么按照這個(gè)架構(gòu)，一條完整的數(shù)據(jù)是怎樣的呢？
如圖這是一條完整的KV數(shù)據(jù)，開(kāi)頭KeyLength和ValueLength：兩個(gè)固定的長(zhǎng)度，分別代表Key和Value的長(zhǎng)度。
在Key部分：RowLength是固定長(zhǎng)度的數(shù)值，表示RowKey的長(zhǎng)度，Row 就是RowKey的值。
Column Family Length是固定長(zhǎng)度的數(shù)值，表示ColumnFamily的長(zhǎng)度
接著就是ColumnFamily，再接著是Qualifier，然后是兩個(gè)固定長(zhǎng)度的數(shù)值，表示TimeStamp和KeyType（Put/Delete）
Value部分沒(méi)有什么復(fù)雜的結(jié)構(gòu)，就是純粹的二進(jìn)制數(shù)據(jù)，這個(gè)也是很大的成本問(wèn)題，后面我們會(huì)介紹。
那么這里有兩個(gè)常見(jiàn)問(wèn)題，一是按Rowkey進(jìn)行Region的劃分，熱點(diǎn)問(wèn)題怎么處理？二是按ColumnFamily進(jìn)行Store存儲(chǔ)，如何設(shè)計(jì)ColumnFamily包含的Qualifier？這個(gè)磁盤(pán)塊，磁盤(pán)IO有什么關(guān)系？
我們知道HBase的Rowkey都是字典序的，一般Rowkey的典型組成會(huì)是：業(yè)務(wù)KEY+時(shí)間倒序（Long.MAX_VALUE -timestamp）/加鹽/Hash組成，那么時(shí)間倒序有利于最新的數(shù)據(jù)在最前面，加鹽或者Hash可以緩解熱點(diǎn)問(wèn)題。關(guān)于ColumnFamily的Qualifier的設(shè)計(jì),簡(jiǎn)單講一個(gè)原則就是經(jīng)常一起查詢(xún)的數(shù)據(jù)要作為同一個(gè)ColumFamily的Qualifier。
除了這兩個(gè)問(wèn)題，我們還有2個(gè)問(wèn)題需要考慮，那就是數(shù)據(jù)查詢(xún)時(shí)候如何定位一條數(shù)據(jù)屬于哪個(gè)Region？HFile里面的KV數(shù)據(jù)如何快速讀??？
回答Region尋址和HFile快速讀取的問(wèn)題，也要分析HBase對(duì)Region的管理方式，Region信息屬于HBase的內(nèi)部抽象，對(duì)Region的管理HBase也建立了一顆B+樹(shù)，我們前面聊過(guò)，如果一個(gè)數(shù)據(jù)塊事16K，那么一個(gè)3階的B+Tree能容納2000w的數(shù)據(jù)量，一次查詢(xún)只需要3次IO，那么HBase數(shù)據(jù)塊默認(rèn)大小事64M（可以配置更大），那么這些Region一般會(huì)加載在內(nèi)存中，所以在B+Tree的數(shù)據(jù)機(jī)構(gòu)上HBase對(duì)region的尋址非?？焖?。
同樣在HFile里面定位rowkey的位置也是基于二分查找的，如圖查詢(xún)Rowkey為fb的過(guò)程，圖中紅色箭頭部分，第一層f在a和m之間，所以查詢(xún)a的子樹(shù)，第二層f在d和h之間，所以查詢(xún)d所指向的子樹(shù)，第三層我就找到了f這個(gè)值，然后在第四層在查找fb數(shù)據(jù)最終返回?cái)?shù)據(jù)。
這里提醒一下HBase存儲(chǔ)是LSMTree數(shù)據(jù)結(jié)構(gòu)，但是為了加速查詢(xún)內(nèi)部對(duì)Rowkey的索引建立和Region的管理都是采用了B+Tree的數(shù)據(jù)結(jié)構(gòu)。
好了，解了HBase的基本內(nèi)容之后，我們思考一下，我們?nèi)绾位贖Base設(shè)計(jì)一個(gè)時(shí)序數(shù)據(jù)庫(kù)呢，首先要思考的問(wèn)題就是，如何在HBase中對(duì)時(shí)序數(shù)據(jù)的核心概念進(jìn)行抽象映射。也就是時(shí)序數(shù)據(jù)核心概念是Metric相關(guān)內(nèi)容，Tag相關(guān)內(nèi)容，和Timestamp時(shí)間戳。HBase現(xiàn)有的概念是ColumnFamily，ColumnQualifier當(dāng)然也具備Timestamp信息。
那么我們無(wú)法改變HBase的KV數(shù)據(jù)結(jié)構(gòu)，只能在表達(dá)時(shí)間序列數(shù)據(jù)的同時(shí)最充分的利用HBase現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)抽象，最核心的就是Rowkey的設(shè)計(jì)和ColumnFamily和ColumnQualifier的利用技巧。我們逐一看一下。
那么基于HBase的時(shí)序數(shù)據(jù)庫(kù)OpenTSDB是如何設(shè)計(jì)的呢？
我們先看最核心的OpenTSDB的RowKey Schema的設(shè)計(jì)，其組成是salt]
那么，按照HBase的思維這里有一個(gè)很奇怪的問(wèn)題，就是【salt】設(shè)計(jì)竟然放在了rowkey的最前面，這個(gè)Salt解決了什么問(wèn)題，同時(shí)有帶來(lái)了什么問(wèn)題呢？
當(dāng)然Salt部分和前面我說(shuō)的HBaseRowkey里面也可以加Salt的作用是一樣的，解決熱點(diǎn)問(wèn)題。但是這里問(wèn)題是，在查詢(xún)的時(shí)候用戶(hù)不知道salt的值如果進(jìn)行查詢(xún)呢？這肯定是帶來(lái)了數(shù)據(jù)查詢(xún)的性能問(wèn)題。其實(shí)OpenTSDB里面Salt是分桶的抽象，默認(rèn)20個(gè)桶，用戶(hù)可以配置，那么查詢(xún)時(shí)候同一個(gè)業(yè)務(wù)rowkey就要查詢(xún)20次然后在進(jìn)行merge，這個(gè)會(huì)極大的影響get查詢(xún)。
好，那么通常Rowkey設(shè)計(jì)不攜帶salt部分，同時(shí)OpenTSDB在Rowkey設(shè)計(jì)上也下了不少功夫，首先大家看到Rowkey的開(kāi)始是一個(gè)metric的uid。
如圖，OpenTSDB里面的一個(gè)rowkey示例，包括 metric部分，時(shí)間戳部分，tagk和tagv的組成。
我們以前面我們風(fēng)力數(shù)據(jù)采集的信息為例，Rowkey就應(yīng)該是speed+ts+city+hangzhou+region+xihu。
那么這里面我們還沒(méi)有解釋uid的作用，后面我們慢慢進(jìn)行說(shuō)明。現(xiàn)在要考慮的問(wèn)題是，Metric&Time&Tag這個(gè)在rowkey中的順序可以變化嗎？或者說(shuō)如何設(shè)計(jì)最合理呢？
HBase是按照rowkey的字典序順序排列的，為了減少查詢(xún)IO,最好將相同的Metric寫(xiě)到相同的磁盤(pán)塊，所以O(shè)penTSDB需要將Metric作為Rowkey的最前面。
Timestamp沒(méi)有業(yè)務(wù)語(yǔ)義，不適合放到最前面（如何放到前面可能出現(xiàn)，多個(gè)Metric會(huì)混雜在一個(gè)磁盤(pán)塊，不利于查詢(xún),寫(xiě)入也會(huì)造成熱點(diǎn)問(wèn)題）
Tags放在最前面，會(huì)造成大量的Scan操作，比如，用戶(hù)指定多個(gè)Tags中的某個(gè)查詢(xún)，而且不是前綴Tag的話(huà)，就會(huì)在HBase里面將會(huì)變成大范圍的掃描過(guò)濾查詢(xún)，當(dāng)然Tags放到Timestamp前面也存在Scan的問(wèn)題。
好，思考了這些現(xiàn)實(shí)問(wèn)題，OpenTSDB對(duì)rowkey的設(shè)計(jì)就是根據(jù)用戶(hù)的metric+ts+tag信息的方式組成。那么目前看這個(gè)rowkey的設(shè)計(jì)還是很合理的，那么是否也在海量的時(shí)序數(shù)據(jù)場(chǎng)景有一些明顯弊端呢？
很明顯，這個(gè)key組成里面根據(jù)業(yè)務(wù)的不同會(huì)變得復(fù)雜，首先就是HBase的key里面有timestamp，是一定要有的，然后業(yè)務(wù)的rowkey里面也是有時(shí)間戳信息的。
為了套用先有的HBase結(jié)構(gòu)，存儲(chǔ)中有很多無(wú)用的信息，比如comumnFamily部分，KeyType部分等。同時(shí)Rowkey里面的metric是一個(gè)業(yè)務(wù)字符串，這些數(shù)據(jù)在實(shí)際存儲(chǔ)過(guò)程中很多冗余，造成存儲(chǔ)成本的浪費(fèi)。
還有HBase是弱類(lèi)型問(wèn)題，不能對(duì)Value部分根據(jù)業(yè)務(wù)的不同字段類(lèi)型進(jìn)行專(zhuān)門(mén)的壓縮。同時(shí)，Rowkey部分包含很多tag信息，沒(méi)有對(duì)Rowkey和tag進(jìn)行倒排索引，同樣使得查詢(xún)受限。大量scan操作性能很差。所以基于KV的時(shí)序數(shù)據(jù)庫(kù)存在客觀的設(shè)計(jì)弊端。
面對(duì)HBase設(shè)計(jì)時(shí)序數(shù)據(jù)存儲(chǔ)的弊端，OpenTSDB做了哪些比較核心的優(yōu)化呢？
首先是Rowkey里面的Timestamp時(shí)間粒度不是毫秒，而是小時(shí)，這樣極大的減小了scan的部分，一小時(shí)的數(shù)據(jù)可以一個(gè)get進(jìn)行獲取。另外我們一直提到的metric_uid，其實(shí)也是對(duì)存儲(chǔ)的優(yōu)化，將業(yè)務(wù)字符串映射成uid，可以極大簡(jiǎn)化存儲(chǔ)。還有在Compactions部分，會(huì)將很多Qualifier數(shù)據(jù)合并成一個(gè)Qualifier里面，提高壓縮效率。
我們細(xì)致的看一下OpenTSDB的data Scheam和uid mapping的Schema。
最核心要了解的就是RowKey部分，我們看到很多的編碼，我們看到編碼后的rowkey和上面編碼前的字符串有極大的改進(jìn)。
關(guān)于UID，OpenTSDB里面采用3個(gè)字節(jié)存儲(chǔ)，約1600萬(wàn)個(gè)值，足夠滿(mǎn)足大部分業(yè)務(wù)場(chǎng)景，同時(shí)我們也可以根據(jù)業(yè)務(wù)規(guī)模改變UID的生產(chǎn)策略。這樣極大的節(jié)省存儲(chǔ)和key排序成本。
同時(shí)我們看到，TSDB-UID的映射表，是雙向的，既可以同UID找到key，也可以通過(guò)key找到UID。大大提高搜索效率。
OK，坦白講，不論OpenTSDB怎么優(yōu)化，首先都需要先填補(bǔ)HBase設(shè)計(jì)在時(shí)序數(shù)據(jù)庫(kù)場(chǎng)景適配的坑，再進(jìn)行優(yōu)勢(shì)發(fā)揮，那么這樣的客觀事實(shí)，勢(shì)必會(huì)催生為IoT時(shí)序數(shù)據(jù)而生的原生時(shí)序數(shù)據(jù)庫(kù)。
一個(gè)是大家熟知的時(shí)序數(shù)據(jù)庫(kù)領(lǐng)域的領(lǐng)頭羊Influxdb，另一個(gè)是2020年Apache 新晉的頂級(jí)項(xiàng)目ApacheIoTDB。我們分別探討一下。
InfluxDB在時(shí)序數(shù)據(jù)庫(kù)排名第一，這個(gè)成績(jī)不是浪得虛名，而是實(shí)至名歸，有句話(huà)叫，天才出于勤奮，其實(shí)InfluxDB從誕生伊始，一直到現(xiàn)在都在不停的努力，不停的為解決現(xiàn)實(shí)問(wèn)題而優(yōu)化改進(jìn)。我們接下來(lái)都是基于InfluxDB1.8版本進(jìn)行描述的。
我們了解一下Influxdb 引擎升級(jí)的歷程，最初為避免B+Tree帶來(lái)的寫(xiě)入問(wèn)題，InfluxDB采用了LSMTree的存儲(chǔ)設(shè)計(jì)，底層引擎采用LevelDB，但是后面發(fā)現(xiàn)LevelDB存儲(chǔ)不能熱備份問(wèn)題，于是底層引擎又采用RocksDB解決，但是RocksDB當(dāng)時(shí)又存在時(shí)序數(shù)據(jù)場(chǎng)景冷數(shù)據(jù)的高效刪除問(wèn)題，我們知道海量的數(shù)據(jù)通過(guò)api的方式逐條刪除是相當(dāng)耗時(shí)的（會(huì)死人的），所以InfuxDB又進(jìn)行改進(jìn)引入Shard，每個(gè)shard存儲(chǔ)一片時(shí)間連續(xù)的數(shù)據(jù)，冷數(shù)據(jù)都是時(shí)間較老的數(shù)據(jù)，一個(gè)shard對(duì)應(yīng)一個(gè)底層LevelDB數(shù)據(jù)庫(kù)，要?jiǎng)h除的時(shí)候只需要關(guān)庫(kù)，刪文件即可。但是這個(gè)設(shè)計(jì)又帶來(lái)了新的問(wèn)題，就是系統(tǒng)的文件句柄問(wèn)題，后面又有BoltdDB來(lái)解決，但是BoltDB里面利用了mmap和B+Tree的數(shù)據(jù)結(jié)構(gòu)，B+Tree的隨機(jī)寫(xiě)問(wèn)題又糙成了IOPS限制問(wèn)題，所謂痛苦造就成就，種種投產(chǎn)問(wèn)題推升了目前InfulxDB全新的存儲(chǔ)和索引架構(gòu)，TSM架構(gòu)。
接下來(lái)我們看看目前InfluxDB的TSM架構(gòu)細(xì)節(jié)，嘗試 盡量 知其然，知其所以然。Lets go...
首先，不可避免的我們要了解InfuxDB針對(duì)時(shí)序數(shù)據(jù)場(chǎng)景的核心概念的抽象，我們看InfluxDB新增了一些抽象，一個(gè)是database，一個(gè)是retentionpolicy，尤其retentionpolich是專(zhuān)門(mén)針對(duì)時(shí)序數(shù)據(jù)的冷數(shù)據(jù)設(shè)計(jì)的，原生的時(shí)序數(shù)據(jù)庫(kù)的優(yōu)勢(shì)就是在設(shè)計(jì)之初就會(huì)考慮時(shí)序場(chǎng)景的種種典型問(wèn)題。那么這些概念的層次結(jié)構(gòu)是怎樣的呢？
首先Database是一個(gè)最上層的抽象，或者說(shuō)是管理單元，然后數(shù)據(jù)也是要按時(shí)間進(jìn)行Sharding的，每個(gè)shard都?xì)w屬于一個(gè)ShardGroup，然后Shard里面就是具體時(shí)序數(shù)據(jù)了，當(dāng)然包括時(shí)間戳，Series和Field信息，其中Series就包含了metric和tag信息。上面的RP就是retentionpolicy。
同時(shí)Point相當(dāng)于一行數(shù)據(jù)，如代碼片段所示，包括被排序的key，key的組成是measurement和tags的組合，后面我們還會(huì)大量的涉及大key的介紹。好，簡(jiǎn)單了解了這個(gè)層次邏輯，我們?cè)俸?jiǎn)單看看這些概念的代碼抽象。
首先是Store，Store是為Database管理shards和index的抽象。
其中InfluxDB的索引機(jī)制有兩種，一是基于內(nèi)存的版本，一是基于文件的版本，后面我們逐步詳細(xì)介紹。
我繼續(xù)向下進(jìn)行鉆取，那就是文件存儲(chǔ)的分區(qū)管理Shard的代碼抽象，Shard里面會(huì)包含時(shí)序數(shù)據(jù)和Tag到SeriesKey的倒排索引。大家會(huì)發(fā)現(xiàn)，有了tag的倒排索引，基于HBase的OpenTSDB里面根據(jù)一部分tag查詢(xún)的scan操作就可以避免了。
那么Shard里面還有一個(gè)Engine，Engine負(fù)責(zé)進(jìn)行合并多shard的查詢(xún)結(jié)果等工作。Engine代表了一個(gè)存儲(chǔ)引擎，這里面包含了TSM架構(gòu)最核心的組成部分，WAL/CACHE/TSMFile/Compaction/Compression組件。我們后面一一介紹。在往下就是FileStore部分了，F(xiàn)ileStore里面包括很多的TSMFile。那么一個(gè)TSMFile是怎樣的結(jié)構(gòu)呢？如圖包括4個(gè)部分。
其中Blocks和index部分尤為重要，我們先看看數(shù)據(jù)是如何寫(xiě)入的...
首先，一個(gè)寫(xiě)請(qǐng)求到來(lái)之后的寫(xiě)入流程如下：
- 第1步，進(jìn)行AppendOnly的WAL寫(xiě)入。
- 第2步，然后就要更新索引，這個(gè)是加速查詢(xún)的本質(zhì)，包含了tag和serieskey的倒排索引內(nèi)容。
- 第3步，就是數(shù)據(jù)更新到緩存，相當(dāng)于LSMTree里面的Mem-table角色。
- 第4步就是返回客戶(hù)端成功應(yīng)答。
當(dāng)然數(shù)據(jù)不能一直保留在內(nèi)存，我們需要某種機(jī)制進(jìn)行落盤(pán)處理。同時(shí)落盤(pán)的時(shí)候最好不要影響寫(xiě)入請(qǐng)求。
- 第5步，落盤(pán)的過(guò)程在InfluxDB里面叫做Snapshotting。進(jìn)行快照的時(shí)機(jī)有2個(gè)，一個(gè)是內(nèi)存使用達(dá)到預(yù)定的閾值大小，一個(gè)是給定時(shí)間間隔沒(méi)有數(shù)據(jù)寫(xiě)入。
- cache-snapshot-memory-size= ”25m”
- cache-snapshot-write-cold-duration= “10m”
落盤(pán)之后我們就變成了Level的文件，InfluxDB設(shè)計(jì)4層的TSMFlile，每個(gè)TSMFile內(nèi)部又有精巧的結(jié)構(gòu)設(shè)計(jì)。
這里再特別注意一下內(nèi)存中Cache結(jié)構(gòu)，是一個(gè)SortedMap結(jié)構(gòu)。
同時(shí)說(shuō)明一下，在目前InfluxDB（1.8）版本，我沒(méi)有看到做快照時(shí)候?qū)ache變成只讀，快照影響寫(xiě)請(qǐng)求，然后寫(xiě)完清空Cache。
- 第6步，我想正是因?yàn)檫@個(gè)Cache沒(méi)有只讀動(dòng)作，在進(jìn)行Compaction時(shí)候也考慮了低層級(jí)采用低CPU消耗的算法，緩解對(duì)寫(xiě)入的影響。而高層級(jí)的文件合并就要考慮壓縮成本。
在回到索引部分，我們剛才提到InfluxDB有兩種類(lèi)型的索引可以選擇，一個(gè)是基于內(nèi)存的，一個(gè)是基于文件的。在索引的構(gòu)建中也絞盡腦汁，利用了可用的一切優(yōu)化手段，B+Tree，BloomFilter，HashIndex等等來(lái)加速查詢(xún)。
那么，我們來(lái)哦細(xì)究一下最核心的部分，內(nèi)存Cache里面的數(shù)據(jù)結(jié)構(gòu)是如何設(shè)計(jì)的，有怎樣的優(yōu)勢(shì)呢？
首先設(shè)計(jì)的初衷一定是在SeriesKey有序的前提下，高性能寫(xiě)入。
如圖，Cache內(nèi)部提供了一個(gè)ring結(jié)構(gòu)，來(lái)對(duì)數(shù)據(jù)進(jìn)行分桶/分區(qū)管理理論上分區(qū)的數(shù)量最多水256個(gè)，為啥呢？因?yàn)镮nfluxDB采用 SeriesKey的前8個(gè)bits進(jìn)行Hash，8個(gè)bit最多256個(gè)值。而每個(gè)Partiton的數(shù)據(jù)存儲(chǔ)是一個(gè)sortedmap，包括Series，F(xiàn)ield和時(shí)間戳信息。
OK,這里YY一下，按照代碼里面的注釋這個(gè)取余操作是可以?xún)?yōu)化的。大家感興趣可以看看源代碼，怎樣優(yōu)化最好。:) 歡迎線(xiàn)下討論...
我們根據(jù)代碼的的分析，可以得到Cache的數(shù)據(jù)結(jié)構(gòu)是這樣的，內(nèi)存數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)是partiton+map的層級(jí)管理，那么這樣的數(shù)據(jù)結(jié)構(gòu)有什么好處呢？
- 環(huán)結(jié)構(gòu)可以Split數(shù)據(jù)結(jié)構(gòu)，降低讀寫(xiě)時(shí)候鎖的競(jìng)爭(zhēng)
- 取前8個(gè)bit進(jìn)行hash，確保連續(xù)數(shù)據(jù)存儲(chǔ)在一個(gè)磁盤(pán)塊（時(shí)間連續(xù)）
- Map是有序的，確保在Snapshoting時(shí)候可以快速有序落盤(pán)
接下來(lái)我們?cè)賮?lái)看看TSMFile細(xì)節(jié)內(nèi)容。
好，是時(shí)候聊聊TSMFile的數(shù)據(jù)結(jié)構(gòu)和對(duì)讀/寫(xiě)性能和存儲(chǔ)成本的設(shè)計(jì)考慮了。
首先，TSMFile的四核部分中，Header 是5個(gè)字節(jié)存放Magic和版本，F(xiàn)ooter是8個(gè)字節(jié)，記錄TSMFile中索引數(shù)據(jù)在TSMFile的偏移量。Blocks里面存儲(chǔ)很多數(shù)據(jù)塊，索引部分的Key是SeriesKey+Field。
其中IndexEntry對(duì)應(yīng)一個(gè)Block進(jìn)行索引的構(gòu)建。包括數(shù)據(jù)塊包含數(shù)據(jù)的最小最大時(shí)間，以及數(shù)據(jù)塊在TSMFile中的位置。
Block部分除了CRC的數(shù)據(jù)校驗(yàn)部分，還有數(shù)據(jù)類(lèi)型，時(shí)間戳信息和數(shù)據(jù)值。
InfluxDB目前支持Integer/Float/Boolean/String等數(shù)據(jù)類(lèi)型，每種數(shù)據(jù)類(lèi)型都有專(zhuān)門(mén)的壓縮算法。
對(duì)于不可或缺的Timestamps信息，InfluxDB采用Facebook的Delta-delta算法，極大壓縮有序時(shí)間戳的存儲(chǔ)。
同時(shí)在Index結(jié)構(gòu)設(shè)計(jì)上也考慮了時(shí)間要素和區(qū)間查詢(xún)。索引部分利用minTime為每個(gè)block的indexEntry構(gòu)建基于B+Tree索引樹(shù)，一遍更要的加速查詢(xún)。
這里，我們提出一個(gè)問(wèn)題，在Footer中記錄整體Index在TSMFile的偏移量，如果我想獲得所有Key，需要怎樣操作？我們看這個(gè)數(shù)據(jù)結(jié)構(gòu)，會(huì)發(fā)現(xiàn)很明顯是需要根據(jù)offset定位到Index的區(qū)域，然后讀取所有的index數(shù)據(jù)。這樣其實(shí)這是一個(gè)很耗時(shí)，耗空間的操作，需要將整體index進(jìn)行讀取，那么是否可以?xún)?yōu)化一下呢？
當(dāng)然，InfluxDB對(duì)索引進(jìn)行了優(yōu)化，為每一個(gè)Key的索引信息都添加了offset信息，維護(hù)了一張offset表格。
在代碼的抽象上，在IndirectIndex的數(shù)據(jù)結(jié)構(gòu)中有offsets的數(shù)據(jù)維護(hù)，這樣想要查詢(xún)所有Kyes的時(shí)候，我們讀取offsets信息根據(jù)偏移直接獲取對(duì)應(yīng)key的信息。
那么還有什么跟多的設(shè)計(jì)考慮嗎？
當(dāng)然，除了剛才我們提到的Level文件合并算法考慮，還有索引優(yōu)化考慮，以及定期的FullCompaction。除此之外，在索引設(shè)計(jì)上面增加BloomFilter輔助判斷key在索引樹(shù)里面的存在性，還利用HashIndex加速key的查找。總體看來(lái)InfluxDB在查詢(xún)上面花了很多的細(xì)節(jié)優(yōu)化。
在繼續(xù)拷問(wèn)，還有什么其他優(yōu)化嗎？
回答還是肯定的，在Measurement索引區(qū)域進(jìn)行tag和SeriesKey的倒排索引結(jié)構(gòu)。這在很大程度增加了查詢(xún)的靈活性和查詢(xún)性能。
同時(shí)我們發(fā)現(xiàn)在tagkey到SeriesKey的映射中，我們還有seriesID和SeriesKey的映射維護(hù)，這又是出于怎樣的考慮呢？對(duì)，這里是對(duì)存儲(chǔ)成本也進(jìn)行了考慮。
這是索引文件TSI的結(jié)構(gòu)設(shè)計(jì)，包括4個(gè)部分，
- 首先是Trailer層面，這是索引的入口，記錄Measurement/Tag/Series三個(gè)Block在TSI的偏移量（offset）和大小
- 然后是Measurement block，記錄所有的指標(biāo)信息，也就是measurement（表）的Meta信息。
- 然后是 tag信息部分，這個(gè)部分核心維護(hù)了面介紹的倒排數(shù)據(jù)結(jié)構(gòu)
- 最后series Block索引區(qū)域，記錄了database中所有的SeriesKey信息
當(dāng)有了SeriesKey和時(shí)間戳之后，我們就可以進(jìn)一步在Cache/File中進(jìn)行查詢(xún)，找到對(duì)應(yīng)的分桶和對(duì)應(yīng)value的時(shí)間序列值。
找到對(duì)飲的TSMFile對(duì)應(yīng)的數(shù)據(jù)塊之后，加載數(shù)據(jù)塊到內(nèi)存，根據(jù)TSFMFile中的B+Tree樹(shù)索引，二分法找到具體的查詢(xún)值。
具體的查詢(xún)邏輯如圖標(biāo)注。
對(duì)應(yīng)TSI的每個(gè)部分，內(nèi)部都有精細(xì)的設(shè)計(jì)和優(yōu)化。這里簡(jiǎn)單提兩點(diǎn)：
- 一個(gè)是每個(gè)部分都有一個(gè)Trailer部分保存該部分的組成的偏移量。
- 另一個(gè)是，每個(gè)部分都利用hashindex加速對(duì)應(yīng)的key查詢(xún)。
OK，總之InfluxDB利用TSM和TSI架構(gòu)，完美解決了高吞吐，熱備份，冷刪除，高性能的查詢(xún),和基于tag的倒排索引索引所支撐了靈活的業(yè)務(wù)查詢(xún)。
這里特別提醒InfluxDB自動(dòng)根據(jù)Tag進(jìn)行倒排索引的建立，在實(shí)際業(yè)務(wù)中要充分利用。
當(dāng)然，InfluxDB的龍頭地位除了存儲(chǔ)查詢(xún)?cè)O(shè)計(jì)的優(yōu)勢(shì)，還有很多實(shí)用的功能，比如ContinuousQueries。這個(gè)的實(shí)現(xiàn)本質(zhì)就是定時(shí)調(diào)度，我們可以根據(jù)語(yǔ)法很清楚的了解設(shè)計(jì)的語(yǔ)義。其中 EVERY是計(jì)算頻度，F(xiàn)OR 是計(jì)算區(qū)間，GroupBy的時(shí)間區(qū)間，就是每次計(jì)算的數(shù)據(jù)窗口。
我們簡(jiǎn)單看一個(gè)示例，EVERY1小時(shí)，F(xiàn)or90分鐘，groupby30分鐘。的業(yè)務(wù)含有是，每1小時(shí)調(diào)度一下計(jì)算，每次計(jì)算的數(shù)據(jù)處理區(qū)間是90分鐘，業(yè)務(wù)聚合計(jì)算的窗口數(shù)據(jù)30分鐘的數(shù)據(jù)。
我們假設(shè)8點(diǎn)中觸發(fā)了計(jì)算，那么計(jì)算數(shù)據(jù)區(qū)間是6:30～8:00（90分鐘），計(jì)算窗口是30分鐘，也就是90分鐘的數(shù)據(jù)計(jì)算三次，有三個(gè)計(jì)算結(jié)果。
當(dāng)然1小時(shí)觸發(fā)一次，到9點(diǎn)還會(huì)再次出發(fā)計(jì)算邏輯。
還有豐富的生態(tài)，也是InfluxDB親民的資本。既后數(shù)據(jù)的采集又有基于訂閱的實(shí)時(shí)計(jì)算，還有方便的界面查看。OK，這里可以為InfluxDB點(diǎn)個(gè)贊了，很優(yōu)秀。:)
OK,再來(lái)看看另外一個(gè)Apache開(kāi)源社區(qū)優(yōu)秀的時(shí)序數(shù)據(jù)庫(kù)，ApacheIoTDB。
首先是夠新，ApacheIoTDB是2020年9月從Apache 孵化器畢業(yè)，成本Apache頂級(jí)項(xiàng)目的。
第二是，ApacheIoTDB足夠強(qiáng)大，左邊的寫(xiě)入和查詢(xún)的性能測(cè)試已經(jīng)超越了目前的領(lǐng)頭羊InfluxDB。
那么，為什么IoTDB會(huì)有這樣的優(yōu)秀表現(xiàn)呢？
首先，ApacheIoTDB也是在LSMTree的基礎(chǔ)進(jìn)行了架構(gòu)優(yōu)化，提出了tLSM的存儲(chǔ)架構(gòu)，在tLSM的架構(gòu)中，優(yōu)化了LSM中的Mem-table部分，提出了為亂序數(shù)據(jù)提供獨(dú)立的處理邏輯，這在寫(xiě)入上有很大的優(yōu)勢(shì)。同時(shí)IoTDB更加注重從SQL的角度進(jìn)行查詢(xún)優(yōu)化，讓用戶(hù)的查詢(xún)邏輯智能的獲取最優(yōu)的查詢(xún)性能。OK，我們?cè)倏纯茨壳癐oTDB整體組件棧是一個(gè)怎樣的情況呢？一起來(lái)看一下...
圖中，棕色部分是現(xiàn)在發(fā)布的版本已經(jīng)具備的，橙色部分是后續(xù)發(fā)布版本中陸續(xù)規(guī)劃的，當(dāng)然還有一些有待進(jìn)一步討論和社區(qū)交流的部分。那么就IoTDB的現(xiàn)有功能來(lái)說(shuō)，已經(jīng)得到了一些工業(yè)企業(yè)的認(rèn)可，我們一起看一下幾個(gè)投產(chǎn)的案例。
這是IoTDB的一部分工業(yè)企業(yè)用戶(hù)，包括上海的地鐵項(xiàng)目，這個(gè)場(chǎng)景1臺(tái)IoTDB實(shí)例就支持了每天4000多億的海量時(shí)序數(shù)據(jù)采集和存儲(chǔ)。關(guān)于IoTDB的分享還有太多的內(nèi)容可以交流。。。時(shí)間原因我們將內(nèi)容留在下次:)
作者介紹
孫金城，社區(qū)編輯，Apache Flink PMC 成員，Apache Beam Committer，Apache IoTDB PMC 成員，ALC Beijing 成員，Apache ShenYu 導(dǎo)師，Apache 軟件基金會(huì)成員。關(guān)注技術(shù)領(lǐng)域流計(jì)算和時(shí)序數(shù)據(jù)存儲(chǔ)。
文章題目：No.1-時(shí)序數(shù)據(jù)庫(kù)隨筆-時(shí)序數(shù)據(jù)庫(kù)綜述
網(wǎng)頁(yè)路徑：http://m.fisionsoft.com.cn/article/dpscisj.html
