摘要：并且這種格式?jīng)]有事先對(duì)時(shí)間序列的數(shù)量做任何限制。使用格式來(lái)存儲(chǔ)時(shí)間序列數(shù)據(jù)的兩種可能的。其中存放了時(shí)間列序列列和數(shù)值列三列。隨著數(shù)據(jù)規(guī)模的繼續(xù)增長(zhǎng)，基于的應(yīng)用程序越來(lái)越不適合處理這樣規(guī)模的時(shí)間序列數(shù)據(jù)了。

就像我們?cè)谇耙徽绿岬降?，一個(gè)時(shí)間序列是一系列數(shù)值，每個(gè)數(shù)值都伴隨著一個(gè)時(shí)間值，代表數(shù)據(jù)被記錄時(shí)的時(shí)間。時(shí)間序列數(shù)據(jù)存入后就很少再需要修改了，查詢時(shí)經(jīng)常是查詢一個(gè)連續(xù)時(shí)間段的數(shù)據(jù)，也可能查詢匯總或者聚合后的數(shù)據(jù)。時(shí)間序列數(shù)據(jù)庫(kù)是一種儲(chǔ)存多個(gè)時(shí)間序列的方式，在其中檢索一個(gè)或幾個(gè)時(shí)間序列的某一個(gè)特定時(shí)間段的數(shù)據(jù)是特別高效的。同樣地，主要用來(lái)查詢一個(gè)時(shí)間段數(shù)據(jù)的應(yīng)用程序也適合使用時(shí)間序列數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)。像之前所解釋的，本書(shū)的主題是存儲(chǔ)和處理大規(guī)模時(shí)間序列數(shù)據(jù)，為了實(shí)現(xiàn)這個(gè)目標(biāo)，首選技術(shù)是非關(guān)系型NoSQL數(shù)據(jù)庫(kù)，比如Apache HBase或MapR-DB。

為大規(guī)模時(shí)間序列數(shù)據(jù)庫(kù)的實(shí)際實(shí)現(xiàn)提供務(wù)實(shí)的建議，是本書(shū)的目標(biāo)，所以我們需要聚焦于一些可以簡(jiǎn)化和增強(qiáng)真實(shí)世界中應(yīng)用程序發(fā)展進(jìn)程的一些基本步驟。我們會(huì)簡(jiǎn)單看看適用于中小型數(shù)據(jù)集的方法，然后深入探究我們主要關(guān)注的問(wèn)題：如何實(shí)現(xiàn)大規(guī)模TSDB。

為了得到一個(gè)扎實(shí)的實(shí)現(xiàn)，有幾種可供選擇的設(shè)計(jì)方法。如何選擇取決于數(shù)據(jù)的屬性。有多少種不同的時(shí)間序列？獲得的數(shù)據(jù)是什么類型的？使用怎樣的速度采集數(shù)據(jù)？需要存儲(chǔ)多久的數(shù)據(jù)？這些問(wèn)題的答案有助于我們確定最優(yōu)的實(shí)現(xiàn)策略。

這一章中的主要思想路線

盡管我們已經(jīng)提到處理時(shí)間序列數(shù)據(jù)的一些主要方面，這一章會(huì)比之前更深入地探討存儲(chǔ)和訪問(wèn)時(shí)間序列數(shù)據(jù)的基本方法。第四章會(huì)提供如何使用現(xiàn)有開(kāi)源軟件來(lái)最好地實(shí)現(xiàn)這些概念的建議。這兩章有比較多的內(nèi)容需要理解。然后你就可以記住如果將這些關(guān)鍵的想法集中到一起而不是迷失在細(xì)節(jié)中，這里是一個(gè)本章內(nèi)容的一個(gè)簡(jiǎn)單路線圖：

平面文件

對(duì)時(shí)間序列數(shù)據(jù)來(lái)說(shuō)是受限的工具，不適合快速增長(zhǎng)的數(shù)據(jù)，查詢起來(lái)也會(huì)效率低下

真正的數(shù)據(jù)庫(kù)：關(guān)系型數(shù)據(jù)庫(kù)

擴(kuò)展性不好，常見(jiàn)的星型模式（star schema）不適合處理時(shí)間序列數(shù)據(jù)

真正的數(shù)據(jù)庫(kù)：非關(guān)系型NoSQL數(shù)據(jù)庫(kù)

首選方案，因?yàn)樗蓴U(kuò)展型好、高效、能快速響應(yīng)基于時(shí)間段的查詢

基本設(shè)計(jì)

使用包含時(shí)間序列ID的唯一row key，列是不同時(shí)間偏移的數(shù)值

存儲(chǔ)多于一個(gè)時(shí)間序列

可選設(shè)計(jì)

使用寬表逐點(diǎn)存儲(chǔ)數(shù)據(jù)

混合寬表和blob類型的設(shè)計(jì)

將數(shù)據(jù)緩存到內(nèi)存，然后blob直寫(xiě)

我們已經(jīng)回顧了主要思想，現(xiàn)在我們更詳細(xì)地重溫一下并且解釋它們的重要性。

你可以擴(kuò)展非常簡(jiǎn)單的設(shè)計(jì)（比如簡(jiǎn)單的二維表），使用更聰明的文件格式來(lái)使其更先進(jìn)，比如列存儲(chǔ)的Parquet格式。Parquet是一個(gè)有效并且簡(jiǎn)單的現(xiàn)代化格式，可以存儲(chǔ)時(shí)間和一些可選值。圖3-1展示了兩種記錄時(shí)間序列數(shù)據(jù)的Parquet schema。左圖中的schema適合你已經(jīng)知道怎么合理使用時(shí)間序列數(shù)據(jù)的情況，它是一個(gè)特定場(chǎng)景的存儲(chǔ)方案。例子中，只存了明確指定的4個(gè)時(shí)間序列的數(shù)據(jù)（一個(gè)存放時(shí)間的t和一個(gè)存放數(shù)據(jù)的tempIn組合起來(lái)，為一個(gè)時(shí)間序列。t和它對(duì)應(yīng)的tempIn、pressureIn、tempOut、pressureOut即4個(gè)時(shí)間序列），如果需要增加新的，就需要修改schema。右圖中的Parguet schema抽象程度更高，對(duì)你想要往文件里嵌入更多元數(shù)據(jù)的場(chǎng)景更適合。并且這種格式?jīng)]有事先對(duì)時(shí)間序列的數(shù)量做任何限制。如果你想要構(gòu)建一個(gè)給其他人使用的時(shí)間序列庫(kù)，右邊的格式會(huì)更合適一些。

圖3-1。使用Parquet格式來(lái)存儲(chǔ)時(shí)間序列數(shù)據(jù)的兩種可能的schema。左邊的schema使用固定的類型名稱將問(wèn)題域確定了。在不改變schema的情況下，只可以存儲(chǔ)4個(gè)時(shí)間序列。相反地，右邊的schema更加靈活，你可以增加新的時(shí)間序列。另外它的抽象層次也更高，把幾個(gè)單一的時(shí)間序列（一對(duì)time、value）按照tags分組，然后放到一個(gè)多帶帶的block中。

這樣的一種時(shí)間序列數(shù)據(jù)（特別是使用類似Parquet格式的情況）是非常有用的，但前提是你需要分析的時(shí)間序列數(shù)量相對(duì)較小，并且所感興趣的時(shí)間范圍相對(duì)于單個(gè)文件所存儲(chǔ)數(shù)據(jù)的時(shí)間跨度很大（比如每個(gè)文件存放一個(gè)月的數(shù)據(jù)，你查的時(shí)候也應(yīng)該每次查一個(gè)月的數(shù)據(jù)，而不是每次查一天的）。

系統(tǒng)最初使用平面文件來(lái)實(shí)現(xiàn)是一種非常普遍的情況，而且不久之后這種簡(jiǎn)單的實(shí)現(xiàn)不再適應(yīng)快速增長(zhǎng)的數(shù)據(jù)的情況也是很普遍的?；締?wèn)題是單一文件中的時(shí)間序列數(shù)量增加了，任何特定的查詢中，真正有用的數(shù)據(jù)占所讀取數(shù)據(jù)的比例就下降了，因?yàn)槎鄶?shù)讀取到的數(shù)據(jù)其實(shí)是屬于其他時(shí)間序列的。

同樣地，在文件中的時(shí)間跨度比平均查詢的時(shí)間范圍已經(jīng)長(zhǎng)很多的情況，真正有用的數(shù)據(jù)占所被讀取數(shù)據(jù)的比例又下降了，因?yàn)槲募械拇蟛糠謹(jǐn)?shù)據(jù)已經(jīng)在你感興趣的時(shí)間范圍之外了（比如數(shù)據(jù)記錄了1個(gè)月的數(shù)據(jù)，而查詢時(shí)一般只查某一天的，那為了定位到這一天，需要先讀大量前邊的實(shí)際不需要的數(shù)據(jù)）。努力解決這些問(wèn)題的同時(shí)一般又會(huì)引入其他的問(wèn)題。使用大量的文件來(lái)確保每個(gè)文件中只有較少的時(shí)間序列，會(huì)使文件數(shù)量大幅增長(zhǎng)。同樣地，減少每個(gè)文件所存儲(chǔ)數(shù)據(jù)的時(shí)間范圍會(huì)使得文件數(shù)量翻倍增長(zhǎng)。當(dāng)在一個(gè)類似Apache Hadoop中HDFS的文件系統(tǒng)存儲(chǔ)數(shù)據(jù)時(shí)，大量的文件會(huì)導(dǎo)致嚴(yán)重的穩(wěn)定性問(wèn)題?；贖adoop的上層系統(tǒng)，如MapR可以輕松處理大量的文件，但檢索和管理大量的小文件也是很低效的，因?yàn)樾枰黾雍芏嗨阉鲿r(shí)間。

為了避免這些問(wèn)題，很自然的一步是轉(zhuǎn)而使用某些形式的真正的數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)這些數(shù)據(jù)。選擇合適的數(shù)據(jù)庫(kù)的方法并不是顯而易見(jiàn)的，但基于數(shù)據(jù)庫(kù)的類型和它的設(shè)計(jì)方案，你有幾個(gè)選項(xiàng)。我們會(huì)研究這些問(wèn)題來(lái)幫助你作選擇。

即使是經(jīng)過(guò)良好分區(qū)的平面文件，在處理大規(guī)模時(shí)間序列數(shù)據(jù)時(shí)也會(huì)力不從心，所以你也行會(huì)考慮使用某些類型的真正的數(shù)據(jù)庫(kù)。當(dāng)?shù)谝淮卧跀?shù)據(jù)庫(kù)中存儲(chǔ)時(shí)間序列數(shù)據(jù)時(shí)，使用所謂的星型模式（star schema）設(shè)計(jì)，并且將數(shù)據(jù)存放到RDBMS是個(gè)很誘人的選擇。在這樣一種數(shù)據(jù)庫(kù)設(shè)計(jì)中，核心數(shù)據(jù)存放在事實(shí)表（fact table），就像圖3-2展示的那樣。

圖3-2。將時(shí)間序列數(shù)據(jù)存放到RDBMS的一個(gè)事實(shí)表的設(shè)計(jì)。其中存放了時(shí)間（TIme列）、序列ID（Time series ID列）和數(shù)值（Value列）三列。序列的細(xì)節(jié)存放在維表（dimension table）中（這一對(duì)Time、Value是一個(gè)時(shí)間序列，但這個(gè)時(shí)間序列的細(xì)節(jié)，比如Value的含義是什么，存放在另一張表中，可以使用Time series ID去那個(gè)表查）。

在星型模式中，一個(gè)表存儲(chǔ)主要的數(shù)據(jù)，并且會(huì)引用其他表（維表）。該設(shè)計(jì)一個(gè)核心假定是維表要相對(duì)小巧，而且不常變動(dòng)。圖3-2中的時(shí)間序列事實(shí)表里，唯一被引用的維表，就是存放這個(gè)時(shí)間序列詳細(xì)信息的維表，它的內(nèi)容是表中數(shù)據(jù)（Value列）的含義。比如，如果我們的時(shí)間序列數(shù)據(jù)是從一個(gè)工廠的泵或者其他設(shè)備從采集的，我們會(huì)希望在獲取這個(gè)泵的多個(gè)維度的數(shù)據(jù)，如入口和出口的壓強(qiáng)和溫度、泵在不同頻段的震動(dòng)和泵自身的溫度等。這其中的每個(gè)泵的每一個(gè)維度，都是一個(gè)多帶帶的時(shí)間序列，每個(gè)時(shí)間序列會(huì)有類似泵的序列號(hào)、位置、商標(biāo)、型號(hào)等信息，這些信息都存放在維表中。

實(shí)際上一些應(yīng)用程序已經(jīng)使用像這樣的星型模式來(lái)存放時(shí)間序列數(shù)據(jù)了。我們?cè)诙鄶?shù)NoSQL數(shù)據(jù)庫(kù)中也可以使用這樣的設(shè)計(jì)。星型模式解決了有大量不同時(shí)間序列的問(wèn)題，在數(shù)據(jù)點(diǎn)的規(guī)模達(dá)到數(shù)億甚至數(shù)十億的情況下也可以工作得很好。然而就像我們?cè)诘谝徽轮锌吹降?，即使?9世紀(jì)的航運(yùn)數(shù)據(jù)也會(huì)產(chǎn)生上十億的數(shù)據(jù)點(diǎn)。在2014年，納斯達(dá)克證券交易所在過(guò)去三個(gè)月就會(huì)處理十億規(guī)模的交易量。記錄一個(gè)中型計(jì)算機(jī)集群的運(yùn)行環(huán)境的話，一天會(huì)產(chǎn)生五億的數(shù)據(jù)點(diǎn)。

并且簡(jiǎn)單地將這些數(shù)據(jù)存儲(chǔ)起來(lái)是一回事，對(duì)其檢索和處理就是另一回事了?，F(xiàn)代的應(yīng)用程序如機(jī)器學(xué)習(xí)系統(tǒng)甚至狀態(tài)顯示系統(tǒng)都需要每秒檢索和處理上百萬(wàn)的數(shù)據(jù)點(diǎn)。

雖然RDBMS可以擴(kuò)展到這些大小、速度需求的下限，但帶來(lái)的消耗和引入的復(fù)雜性會(huì)急劇上升。隨著數(shù)據(jù)規(guī)模的繼續(xù)增長(zhǎng)，基于RDBMS的應(yīng)用程序越來(lái)越不適合處理這樣規(guī)模的時(shí)間序列數(shù)據(jù)了。使用星型模式但轉(zhuǎn)而使用NoSQL數(shù)據(jù)庫(kù)的話，也沒(méi)有特別的幫助，因?yàn)檫@個(gè)問(wèn)題的核心是星型模式帶來(lái)的，而不只是數(shù)據(jù)量。

星型模式所觸及的核心問(wèn)題是每次測(cè)量都要使用一行。一個(gè)增加時(shí)間序列數(shù)據(jù)庫(kù)中數(shù)據(jù)檢索速度的技術(shù)是在每一行存儲(chǔ)很多數(shù)值。在一些像Apache HBase或者M(jìn)apR-DB的NoSQL數(shù)據(jù)庫(kù)中，列的數(shù)量幾乎是不受限制的，只要任何特定一行中有數(shù)據(jù)的列的數(shù)量在幾十萬(wàn)之內(nèi)。這種能力可以被用來(lái)在每行存放多個(gè)數(shù)值。這樣做的話，數(shù)據(jù)點(diǎn)就可以被更高速地檢索，因?yàn)閽呙钄?shù)據(jù)的最大速度部分取決于需要掃描的行的數(shù)量，部分取決于待檢索數(shù)據(jù)點(diǎn)的總數(shù)，部分取決于待檢索數(shù)據(jù)的總量。減少行的數(shù)量，就大幅減少了一部分檢索開(kāi)銷，檢索速度就提升了。圖3-3展示了使用寬表來(lái)減少時(shí)間序列數(shù)據(jù)行數(shù)量的一種方式。這個(gè)技術(shù)和OpenTSDB（一個(gè)開(kāi)源的數(shù)據(jù)庫(kù)，我們會(huì)在第四章詳細(xì)講到）之中使用的默認(rèn)表結(jié)構(gòu)很相似。需要注意這樣的表設(shè)計(jì)，和那些需要提前定義詳細(xì)schema的系統(tǒng)的表設(shè)計(jì)是很不一樣的。有一件事情，如果你想把schema寫(xiě)下來(lái)，那將異常龐大。

圖3-3，在NoSQL時(shí)間序列數(shù)據(jù)庫(kù)中一個(gè)寬表的使用。關(guān)鍵的結(jié)構(gòu)是直觀的，在真正的應(yīng)用程序中，使用的會(huì)是一個(gè)二進(jìn)制的格式，但這樣順序的屬性是一樣的。

因?yàn)镠Base和MapR-DB都是按照主鍵的順序來(lái)存儲(chǔ)數(shù)據(jù)，圖3-3中的鍵設(shè)計(jì)會(huì)導(dǎo)致每行包含一小段時(shí)間的數(shù)據(jù)在磁盤(pán)上是連續(xù)存儲(chǔ)的（因?yàn)镽ow key是按時(shí)間順序增長(zhǎng)，HBase和MapR-DB是按列族存放數(shù)據(jù)的，Data values中的數(shù)據(jù)就會(huì)全部按照時(shí)間順序存放在磁盤(pán)上）。這個(gè)設(shè)計(jì)意味著檢索一個(gè)特定時(shí)間段的數(shù)據(jù)，涉及的主要是順序磁盤(pán)操作，就會(huì)比數(shù)據(jù)按行分散開(kāi)的情況快很多。為了從這個(gè)表結(jié)構(gòu)獲得性能優(yōu)勢(shì)，每個(gè)時(shí)間窗口的采樣點(diǎn)要足夠富裕，這樣就可以減少行的數(shù)量，從而提升檢索速度。典型情況，時(shí)間窗口會(huì)被調(diào)整成每一行包括100-1000采樣點(diǎn)的樣子。

圖3-3中的表設(shè)計(jì)可以繼續(xù)改進(jìn)，通過(guò)將一行中的所有數(shù)據(jù)壓縮成一個(gè)單一的被稱作blob的數(shù)據(jù)結(jié)構(gòu)。Blob可以高度壓縮，所以需要從磁盤(pán)讀取的數(shù)據(jù)量就更少了。并且，如果使用HBase來(lái)存儲(chǔ)時(shí)間序列數(shù)據(jù)，每行只有一列的情況會(huì)減少了每列數(shù)據(jù)在HBase所使用的磁盤(pán)文件格式上的開(kāi)銷，這樣又進(jìn)一步提高了性能。圖3-4的混合式表結(jié)構(gòu)中，一些行的數(shù)據(jù)已經(jīng)被壓縮，另一些行沒(méi)有。

圖3-4。在混合模式設(shè)計(jì)中，行中的數(shù)據(jù)可以被存儲(chǔ)成一個(gè)單一的數(shù)據(jù)結(jié)構(gòu)（blob）。注意實(shí)際壓縮的數(shù)據(jù)更可能是二進(jìn)制的格式。這里使用JSON格式顯示是為了更容易理解。

圖3-3中的寬表格式可以進(jìn)化成圖3-4的壓縮格式（blob樣式），只要確保那些被壓縮的行對(duì)應(yīng)的時(shí)間窗口不會(huì)或者很少再有新增的數(shù)據(jù)。一般地，一旦時(shí)間窗口結(jié)束后，新的數(shù)據(jù)就不屬于這個(gè)時(shí)間窗口了，然后對(duì)這個(gè)時(shí)間窗口中數(shù)據(jù)的壓縮就可以開(kāi)始了。因?yàn)樵谕恍兄校褖嚎s和未壓縮的數(shù)據(jù)可以共存，如果在對(duì)行壓縮之后，又有新數(shù)據(jù)過(guò)來(lái)了，可以再簡(jiǎn)單地重新壓縮這一行，將新數(shù)據(jù)合并進(jìn)來(lái)。

圖3-5展示的是概念上的混合式時(shí)間序列數(shù)據(jù)庫(kù)的數(shù)據(jù)流。

在后臺(tái)將數(shù)據(jù)從舊格式轉(zhuǎn)換成blob格式，會(huì)讓renderer（圖3-5中所顯示的）檢索數(shù)據(jù)并繪制出來(lái)的速度有質(zhì)的提升。例如，在4個(gè)節(jié)點(diǎn)的MapR集群中，數(shù)據(jù)以壓縮格式存放的話，3千萬(wàn)的數(shù)據(jù)點(diǎn)可以在大概20秒內(nèi)被檢索、聚合、繪制出來(lái)。

圖3-5?；旌鲜綍r(shí)間序列數(shù)據(jù)庫(kù)的數(shù)據(jù)流。數(shù)據(jù)從數(shù)據(jù)源到達(dá)catcher，然后被插入到NoSQL數(shù)據(jù)庫(kù)中。之后blob maker在后臺(tái)定時(shí)將數(shù)據(jù)壓縮成blob格式。數(shù)據(jù)由renderer檢索和格式化。

壓縮舊數(shù)據(jù)依然存在一個(gè)性能瓶頸。因?yàn)閿?shù)據(jù)以未壓縮的格式插入進(jìn)來(lái)，每個(gè)數(shù)據(jù)點(diǎn)到來(lái)后都需要對(duì)行做一個(gè)更新來(lái)將數(shù)值插入到數(shù)據(jù)庫(kù)中。對(duì)行的更新操作會(huì)限制數(shù)據(jù)的插入速度到每個(gè)集群中的每個(gè)節(jié)點(diǎn)上只有每秒2萬(wàn)個(gè)數(shù)據(jù)點(diǎn)。

另一方面，圖3-6中的blob直寫(xiě)方式的數(shù)據(jù)流允許插入速度增加了大概1千倍。為什么blob直寫(xiě)方式會(huì)帶來(lái)如此大的性能提升？基本的區(qū)別是blob maker被轉(zhuǎn)移到catcher和NoSQL時(shí)間序列數(shù)據(jù)庫(kù)之間了。使用這種方式，blob maker就可以從內(nèi)存的數(shù)據(jù)緩存中直接讀取輸入的數(shù)據(jù)，而不是從存儲(chǔ)層的寬表中提取之前已經(jīng)被寫(xiě)入進(jìn)去的數(shù)據(jù)。

基本的思想是數(shù)據(jù)到達(dá)后先被存放在內(nèi)存中。這些數(shù)據(jù)同時(shí)也被寫(xiě)入到日志文件中。這些日志文件就是圖3-6中的restart logs，它們是在Hadoop系統(tǒng)存放的平面文件，不是存儲(chǔ)層的一部分。Restart logs允許內(nèi)存中的數(shù)據(jù)緩存被重新導(dǎo)入，在數(shù)據(jù)管道必須被重建的時(shí)候。

在正常操作中，在時(shí)間窗口的末尾，新的內(nèi)存中數(shù)據(jù)結(jié)構(gòu)會(huì)被創(chuàng)建，現(xiàn)在舊的內(nèi)存中數(shù)據(jù)結(jié)構(gòu)就可以用來(lái)創(chuàng)建壓縮的blob然后寫(xiě)入數(shù)據(jù)庫(kù)了。一旦blob被寫(xiě)入了，日志文件就被刪除了。這樣就無(wú)需像之前的混合設(shè)計(jì)中將數(shù)據(jù)兩次寫(xiě)入。在圖3-5中的混合設(shè)計(jì)中，全部的輸入數(shù)據(jù)流都會(huì)逐點(diǎn)寫(xiě)入到存儲(chǔ)層，然后再被blob maker讀取。讀的情況和寫(xiě)大致一樣。一旦數(shù)據(jù)被壓縮成了blob，它又被寫(xiě)入到數(shù)據(jù)庫(kù)中。相反地，在圖3-6的blob直寫(xiě)設(shè)計(jì)的數(shù)據(jù)流中，完整的數(shù)據(jù)流只寫(xiě)入到內(nèi)存中（這樣速度很快），而不是寫(xiě)入到數(shù)據(jù)庫(kù)中。數(shù)據(jù)在壓縮成blob之前不會(huì)被寫(xiě)入到數(shù)據(jù)庫(kù)，所以寫(xiě)入速度大幅提升。數(shù)據(jù)庫(kù)操作的次數(shù)從之前數(shù)據(jù)點(diǎn)的數(shù)量變成了blob的數(shù)量，很容易將次數(shù)減少到之前幾千分之一這樣的量級(jí)。

圖3-6。Blob直寫(xiě)方式的數(shù)據(jù)流。Catcher在內(nèi)存中暫存數(shù)據(jù)，并且將其寫(xiě)入到restart logs中。Blob maker周期地從緩存中讀取數(shù)據(jù)，然后將壓縮成的blob寫(xiě)入到數(shù)據(jù)庫(kù)中。這個(gè)設(shè)計(jì)的性能提升來(lái)自于renderer可以同時(shí)從內(nèi)存和數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)。

blob直寫(xiě)方式的優(yōu)勢(shì)是什么？一個(gè)真實(shí)世界的例子展示了它可以做什么。使用了這個(gè)架構(gòu)，僅使用了一個(gè)10節(jié)點(diǎn)的MapR集群中的4個(gè)節(jié)點(diǎn)，就可以實(shí)現(xiàn)每秒往MapR-DB的表中插入超過(guò)一億的數(shù)據(jù)點(diǎn)。這些節(jié)點(diǎn)都有著很高的性能，其中每個(gè)節(jié)點(diǎn)有15個(gè)CPU核、大量?jī)?nèi)存和12塊高配置磁盤(pán)，但你使用多數(shù)硬件都可以達(dá)到這個(gè)性能級(jí)別的1/5到1/2。

這個(gè)性能級(jí)別聽(tīng)起來(lái)是用來(lái)處理海量數(shù)據(jù)的，可能超出了我們所需要的處理能力，但是在第五章我們會(huì)展示為什么這樣的性能是非常有用的，即使是對(duì)那些相對(duì)溫和的應(yīng)用程序。

在這一點(diǎn)，詢問(wèn)為什么一個(gè)關(guān)系型數(shù)據(jù)庫(kù)不能處理和使用混合模式的MapR-DB或者HBase所能承受的插入和分析數(shù)據(jù)的負(fù)載是公平的。當(dāng)只有blob數(shù)據(jù)被插入而不使用寬表的情況，這個(gè)問(wèn)題特別有趣，因?yàn)楝F(xiàn)代關(guān)系型數(shù)據(jù)庫(kù)通常支持blob或者array類型。

這個(gè)問(wèn)題的答案是，關(guān)系型數(shù)據(jù)庫(kù)主要解決的問(wèn)題不是提高插入和檢索數(shù)據(jù)的速度，它現(xiàn)在這樣運(yùn)行是有其合理性的。使用關(guān)系型數(shù)據(jù)庫(kù)的主要原因也不是因?yàn)樗懈玫男阅堋Ｈ绻褂藐P(guān)系系型數(shù)據(jù)庫(kù)的blob格式存儲(chǔ)數(shù)據(jù)，就意味著需要放棄大多數(shù)其他好處。此外，SQL沒(méi)有提供一個(gè)好的抽象方法，來(lái)隱藏訪問(wèn)blob格式數(shù)據(jù)中的細(xì)節(jié)。SQL不能用任何合理的方式來(lái)訪問(wèn)這些數(shù)據(jù)，并且像多行事務(wù)等特性也完全派不上用場(chǎng)了。事務(wù)在這里還會(huì)成為問(wèn)題，因?yàn)榧词共皇褂茫矔?huì)成為一種消耗。一個(gè)關(guān)系型數(shù)據(jù)庫(kù)需要滿足多行事務(wù)的需求，這使它更難被擴(kuò)展到多個(gè)節(jié)點(diǎn)上。盡管使用如Oracle的高成本數(shù)據(jù)庫(kù)可以在單個(gè)節(jié)點(diǎn)實(shí)現(xiàn)很高的性能。而使用類似Apache Hbase或者M(jìn)apR-DB的NoSQL數(shù)據(jù)庫(kù)，你可以簡(jiǎn)單地通過(guò)加硬件的方式實(shí)現(xiàn)更高的性能。

為自己用不到的特性買單的模式在一些高性能系統(tǒng)中是存在的。為了可擴(kuò)展而犧牲傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的一些固有特性也是常見(jiàn)的，但即使你這樣做了，還是得不到自己想要的擴(kuò)展性。在這種情況，使用類似HBase或者M(jìn)apR-DB的替代方案是有實(shí)質(zhì)上的好處的，因?yàn)槟阃瑫r(shí)得到了性能和可擴(kuò)展性。

這些寬表、blob混合的表設(shè)計(jì)是非常誘人的。它們所許諾的巨大性能級(jí)別令人興奮，而且它們能運(yùn)行在有容錯(cuò)機(jī)制、基于Hadoop的系統(tǒng)（比如MapR），從運(yùn)維的角度看也是很吸引人的。這些新方法都不是空想，它們已經(jīng)被構(gòu)建出來(lái)，并且被證明有著驚人的結(jié)果。然而我們?cè)谶@里呈現(xiàn)的，很大程度都是概念上的東西。有真正已經(jīng)實(shí)現(xiàn)的嗎？下一章我們會(huì)講到如何使用OpenTSDB（一個(gè)開(kāi)源時(shí)間序列數(shù)據(jù)庫(kù)工具）和幾個(gè)開(kāi)源的MapR擴(kuò)展，來(lái)實(shí)現(xiàn)這些新的設(shè)計(jì)。結(jié)果是利用本章所描述的概念以達(dá)到高性能的時(shí)間序列數(shù)據(jù)庫(kù)是現(xiàn)代使用場(chǎng)景所需要的。

付費(fèi)解決 Windows、Linux、Shell、C、C++、AHK、Python、JavaScript、Lua 等領(lǐng)域相關(guān)問(wèn)題，靈活定價(jià)，歡迎咨詢，微信 ly50247。