如何做好大數(shù)據(jù)的實(shí)時(shí)復(fù)雜查詢

在過去的幾年里，我們生活中幾乎每一個功能都依賴于實(shí)時(shí)應(yīng)用。無論是通過社交媒體更新我們的朋友圈，在線購物，還是等待客戶服務(wù)的立即回應(yīng)，我們已經(jīng)變得越來越依賴快速有效的得到我們想要的信息。

然而我們不知道的是，這其中存在幾個挑戰(zhàn)：

在這些系統(tǒng)中流動著的大量數(shù)據(jù)

·需要一個高度可用的應(yīng)用程序和數(shù)據(jù)存儲

·高性能的要求·支持復(fù)雜查詢。

·事務(wù)支持

我們可以嘗試把這些挑戰(zhàn)轉(zhuǎn)化為3個部分：大數(shù)據(jù)，實(shí)時(shí)性和復(fù)雜查詢。

第一個挑戰(zhàn)-大數(shù)據(jù)

從大數(shù)據(jù)開始，要解決這些問題，我們有很多可以利用的解決方案。 最流行的解決方案是NoSQL數(shù)據(jù)庫和Hadoop。 它們屬于分布式環(huán)境，其中存在多個包含數(shù)據(jù)的分區(qū)。 通過分區(qū)間的復(fù)制，以確保在某一臺服務(wù)器宕機(jī)時(shí)，我們可以從另一臺服務(wù)器獲取數(shù)據(jù)（大多數(shù)是最終一致的，這意味著副本可能沒有最新的數(shù)據(jù)更新，但是這屬于另外的討論范疇）。 那么，如果我們采用這些NoSQL數(shù)據(jù)庫，我以很容易地克服數(shù)據(jù)量和高可用性問題所帶來的挑戰(zhàn)。 它也是一種可擴(kuò)展的解決方案，可以添加更多的計(jì)算和存儲資源，這些將能夠支持更多的數(shù)據(jù)和吞吐量。

第二個挑戰(zhàn)-實(shí)時(shí)

實(shí)時(shí)是面臨的主要挑戰(zhàn)。目前主流的解決方案主要是基于磁盤的，這意味著沒有對實(shí)時(shí)部分的支持，面對復(fù)雜的查詢可能需要幾分鐘，有時(shí)甚至更多。 這就是為什么我們需要內(nèi)存數(shù)據(jù)網(wǎng)格，它在內(nèi)存中存儲了部分?jǐn)?shù)據(jù)或全部數(shù)據(jù)。 當(dāng)數(shù)據(jù)存儲在內(nèi)存中，計(jì)算是可以做到非?？焖俚氖褂肦AM而不是I / O訪問。

但這種解決方案也不是那么容易。 我們也許可以在RAM中存儲幾個TB數(shù)據(jù)，但如果我們有更多的數(shù)據(jù)，那怎么辦？ 比如說50TB ......即使如今RAM變得便宜得多，但50TB也將是非常昂貴的。 此外，這也導(dǎo)致管理一個數(shù)據(jù)網(wǎng)格集群的機(jī)器數(shù)量過多。 一些內(nèi)存數(shù)據(jù)網(wǎng)格解決方案提供了另一種方法，在磁盤中存儲一些非活躍的數(shù)據(jù)。

固態(tài)硬盤可以為我們提供一個將二者合二為一的機(jī)會，前提是我們使用正確。雖然SSD并不像RAM一樣快，但它比正常的磁盤快得多，而且比RAM便宜很多。 現(xiàn)在有2種方式，我們可以利用固態(tài)硬盤來實(shí)現(xiàn)非常大的集群和實(shí)時(shí)復(fù)雜查詢：

*快速索引模式 - 我們將查詢的字段存儲在RAM中，將其余部分都存儲在SSD上。 例如，如果我們有一個包含很多字段的大對象，我們只能在RAM中存儲其中的一些索引，將一些次要字段存儲在固態(tài)硬盤中，所以相比于常規(guī)磁盤，我們依然可以在它們之上進(jìn)行非?？斓牟樵?。

*熱數(shù)據(jù)---最近被使用的對象將被存儲在RAM中，其他對象將被放入SSD。 這種方法還可能具有實(shí)時(shí)性的挑戰(zhàn)，因?yàn)椴樵円嬖赟SD上進(jìn)行需要全部數(shù)據(jù)的復(fù)雜運(yùn)算，而不是在RAM上。

第三個挑戰(zhàn)-復(fù)雜查詢

還剩下復(fù)雜查詢這部分挑戰(zhàn)，大多數(shù)應(yīng)用在關(guān)系型數(shù)據(jù)庫中有實(shí)時(shí)分析的需求，我們可以很容易地通過聚合查詢實(shí)現(xiàn) （avg， min， max， sum， group by）。而分布式環(huán)境中，這要復(fù)雜得多，因?yàn)閿?shù)據(jù)在集群的分區(qū)中，聚和就意味著我們要么需要把所有的數(shù)據(jù)傳輸?shù)娇蛻舳耍ㄟ@不是一種好的選擇，因?yàn)樗鼘?shí)在是太多了）或使用MapReduce邏輯模型，使用Map Reduce邏輯模型是一種不錯解決方案，只不過沒有簡單SQL group by來的更直觀而已。