關于分布式數據庫，你該了解的幾件事

隨著業務對大數據技術需求的不斷演變，分布式數據庫在整個生態圈中的地位愈加重要，已可預見必將成為未來大數據技術發展的又一個核心，而其中OLAP(聯機分析處理)顯得尤其重要。

基本理論

數據庫的基本理論ACID

原子性(Atomic)。整個事務中的所有操作要么全部完成，要么全部不完成，不可能停滯在中間某個環節。事務在執行過程中發生錯誤，會被回滾(Rollback)到事務開始前的狀態，就像這個事務從來沒有執行過一樣。

一致性(Consistent)。在事務開始之前和事務結束以后，數據庫的完整性約束沒有被破壞。

隔離性(Isolated)。隔離狀態執行事務，使它們好像是在給定時間內系統執行的唯一操作。如果有兩個事務，運行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。這種屬性有時稱為串行化，為了防止事務操作間的混淆，必須串行化或序列化請求，使得在同一時間僅有一個請求用于同一數據。

持久性(Durable)。在事務完成以后，該事務對數據庫所作的更改便持久地保存在數據庫之中，并不會被回滾。

對于ACID的實現方式主要有兩個，一個是日志式的方式(Write ahead logging)，幾乎所有的數據庫系統(MySQL、Oracle等)都基于日志的方式。另外一種是Shadow paging，代表的數據庫主要是SQLite，Android或者iOS APP開發的話應該會比較了解，但大型的數據庫都不會用到。

圖1 事務隔離性一覽

分布式數據庫的CAP理論

一致性(C)。分布式系統中所有數據備份在同一時刻的值是否相同。

可用性(A)。當集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求(可用性不僅包括讀，還有寫)。

分區容忍性(P)。集群中的某些節點無法聯系后，集群整體是否還能繼續進行服務。

圖2 CAP三大定律

NoSQL分類

如果同時滿足這三點，成本將會非常高，所以建議根據業務的具體需求做好平衡選擇。把NoSQL做一個簡單分類將包括如下幾種：

Key/Value 或 ‘the big hash table’。典型的有Amazon S3 (Dynamo)、Voldemort、Scalaris、Memcached (in-memory key/value store)、Redis等。

Schema-less。典型的有Cassandra (column-based)、CouchDB (document-based)、MongoDB(document-based)、Neo4J (graph-based)、HBase (column-based)、ElasticSearch(document-based)等。

OLTP和OLAP的對比分析

目前分布式數據庫主要分為兩種場景——OLTP(聯機事務處理)和OLAP(聯機分析處理)。隨著大數據技術發展，數據庫選擇越來越多，其主要差別包括：面向事務還是面向分析;數據內容是當前的、詳細的數據還是歷史的、匯總的數據;數據庫設計是實體聯系模型ER和面向應用的數據庫設計，還是星型、雪花模型和面向主題的數據庫設計等。前者指的是OLTP場景，后者指的是OLAP場景。

表1 OLTP和OLAP對比

基于分布式數據庫的理論，不管是數據庫的優化還是設計、使用，遇到的問題非常多。舉例說，現在硬件發展很好，特別SSD，如果其設備性能遠遠沒有達到，那么使用SSD的數據庫性能該如何提高。如果只是為了滿足業務當前的簡單需求，可以把現在很多數據庫的傳輸引擎存儲直接換成SSD，可以快速地解決很大的問題。另外還有一個很經典的問題，怎么保證在高可靠的前提下提高數據庫插入和查詢性能。剛才說的是單機模式，多機的分布式模式下又該怎么提高數據調用性能，也有許多挑戰?？傊?，一定要根據業務的需求來選擇最合適自己的數據庫系統。

分布式數據庫實際案例

HBase

在HBase的設計原則中，每個列族可以包含任意多的列，每個列可以有任意多的版本，列只有在有值時才存在，列本身是排序的。

重點看一下Zookeeper的模型，它用了一個非常經典的模型叫Leader/Follower。舉個例子說，在去餐廳吃飯時，進餐廳肯定有領班把你領過去，安排到某個座位，點菜則不是他的工作，而由其同事完成，這是非常傳統的半同步模型。而Leader/Follower模型是領班把你領過去幫你點菜，他在之前會再選一個Follower做Leader，通過選舉制來實現，這樣會減少線程的調度，這對數據庫的性能會有很大的提升。

圖3 HBase中的功能實現

ElasticSearch(ES)

對于分布式數據庫里把ElasticSearch也作為一種分布式數據庫是有原因的，如果需要快速查詢，但列很多，HBase的SQL支持不太好，使用不方便。而ES對于前端工程師開發非常簡單，不需要對分布式數據庫內核了解很深就可以很快使用起來，而只需要了解RestfulAPI就可以了，并且也很方便。ES底層都是分布式的Lucene，如Github使用Elasticsearch搜索20TB的數據，包括13億的文件。ES的模型比較清晰比較簡單，就兩個步驟，一個步驟是怎么把數據建索引，建完索引主要是做查詢，怎么把SQL的語句做查詢。

圖4 ElasticSearch亮點

ES最重要的是建索引，每個的記錄都會根據需求建索引，這么做有好有壞——如果突然來了100億條記錄，建索引的時間會很長，對于業務索引是不能忍受的。所以如果支持離線建立索引，后面實時增量建索引這樣會更好，目前ES這個模型還不能支持。 但是ES時下已發展的比較成熟，現在能對接的接口都能支持，所以是非常方便的。

分布式數據庫系統對比

圖5 ElasticSearch功能模塊

這里主要對比Pinot和Druid，支持多維度實時查詢的分布式系統。

表2 Druid和Pinot功能實現對比

由于Pinot跟ES系統架構很類似，而Pinot比Druid支持存儲格式更多一些，所以我們用Pinot和ES做了一個性能測試對比，測試條件如下：

記錄條數分為100億以內和1000億條

服務器數量為70臺，配置為：CPU 12核，內存96G，硬盤48T

測試語句：select count(*) from test where age > 25 and gender > 0 and os > “500” and sc in (“0001009″,”0002036″,”0016030″,”…”) or bs>585 and group by age,gender,os,bs

總共12列：動態列為3列(多值列)，普通列為9列

表3 ElasticSearch和Pinot百億條檢索對比

表4 ElasticSearch和Pinot千億條檢索對比

對于Pinot和ES有一個共性，他們都有多值列的屬性，即類似的屬性可以放入同一列，這樣查的話大部分需要把一個列的數據查出來，從而更有益于性能。

真實案例分析

業務需求：

1.每天請求數超過 100 億

2. 每天增長超過 5TB 級數據

3. 每天對幾千億條記錄進行上 1000 種維度的計算

4. 客戶有流式、實時、離線需求

圖6是系統數據流程。

圖6 系統數據流程

數據采集用WebService，如Nginx;數據收集服務用Kafka和Flume;數據清洗服務Storm，采用Storm主要有下面兩個原因，業務需求在毫秒級需要;有嚴格要求的時間序列，如原來輸入是1、2、3、4、5，輸出還必須是1、2、3、4、5。其他用Spark Streaming將會比較好。

接下來把Kafka分流出來的數據對應每一條不同的業務，然后導入對應的存儲，如HBase、HDFS等，通過不同的流來解決不同的業務問題，然后基于不同存儲做各種算法分析;最后將各種結果數據導入ElasticSearch或者MySQL給前端做數據可視化。

通過閱讀上述知識相信各位對分布式數據庫的發展和不同系統的技術特點已經有了一定的了解，限于篇幅的原因，筆者以分享幾個ES的使用心得結束：

1.用 ES 的 Alias 特性實現數據的水平擴展。

2. 用 Kibana 分析和展現數據(ELK三劍客)可以滿足很多公司業務80%以上的需求，ELK是指ElasticSearch、Logstash、Kibana，它們分別功能為：ElasticSearch是負責日志檢索和分析;Logstash負責日志的收集，處理和儲存;Kibana負責日志的可視化，建議用Kibana4版本。

3. 多條件聚合查詢，布爾查詢。

4. 定制分詞插件(IK)，實現對特殊字符的精確匹配，目前現在主流的搜索引擎在搜索關鍵詞的時候對標點符號是忽略的，但是在實現一些對監控微博等社交數據時，如果微博里有很多符號，舉例來說“：)”其實代表的是笑臉，而笑臉對于我們來判斷正負面是非常有用的，所以判斷正負面不只是語義分析的，還有對標點符號分析也非常重要。