關(guān)于分布式數(shù)據(jù)庫，你該了解的幾件事

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

基本理論

數(shù)據(jù)庫的基本理論ACID

原子性(Atomic)。整個(gè)事務(wù)中的所有操作要么全部完成，要么全部不完成，不可能停滯在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯(cuò)誤，會(huì)被回滾(Rollback)到事務(wù)開始前的狀態(tài)，就像這個(gè)事務(wù)從來沒有執(zhí)行過一樣。

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

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

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

對于ACID的實(shí)現(xiàn)方式主要有兩個(gè)，一個(gè)是日志式的方式(Write ahead logging)，幾乎所有的數(shù)據(jù)庫系統(tǒng)(MySQL、Oracle等)都基于日志的方式。另外一種是Shadow paging，代表的數(shù)據(jù)庫主要是SQLite，Android或者iOS APP開發(fā)的話應(yīng)該會(huì)比較了解，但大型的數(shù)據(jù)庫都不會(huì)用到。

圖1 事務(wù)隔離性一覽

分布式數(shù)據(jù)庫的CAP理論

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

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

分區(qū)容忍性(P)。集群中的某些節(jié)點(diǎn)無法聯(lián)系后，集群整體是否還能繼續(xù)進(jìn)行服務(wù)。

圖2 CAP三大定律

NoSQL分類

如果同時(shí)滿足這三點(diǎn)，成本將會(huì)非常高，所以建議根據(jù)業(yè)務(wù)的具體需求做好平衡選擇。把NoSQL做一個(gè)簡單分類將包括如下幾種：

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的對比分析

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

表1 OLTP和OLAP對比

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

分布式數(shù)據(jù)庫實(shí)際案例

HBase

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

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

圖3 HBase中的功能實(shí)現(xiàn)

ElasticSearch(ES)

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

圖4 ElasticSearch亮點(diǎn)

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

分布式數(shù)據(jù)庫系統(tǒng)對比

圖5 ElasticSearch功能模塊

這里主要對比Pinot和Druid，支持多維度實(shí)時(shí)查詢的分布式系統(tǒng)。

表2 Druid和Pinot功能實(shí)現(xiàn)對比

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

記錄條數(shù)分為100億以內(nèi)和1000億條

服務(wù)器數(shù)量為70臺(tái)，配置為：CPU 12核，內(nèi)存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列：動(dòng)態(tài)列為3列(多值列)，普通列為9列

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

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

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

真實(shí)案例分析

業(yè)務(wù)需求：

1.每天請求數(shù)超過 100 億

2. 每天增長超過 5TB 級數(shù)據(jù)

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

4. 客戶有流式、實(shí)時(shí)、離線需求

圖6是系統(tǒng)數(shù)據(jù)流程。

圖6 系統(tǒng)數(shù)據(jù)流程

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

接下來把Kafka分流出來的數(shù)據(jù)對應(yīng)每一條不同的業(yè)務(wù)，然后導(dǎo)入對應(yīng)的存儲(chǔ)，如HBase、HDFS等，通過不同的流來解決不同的業(yè)務(wù)問題，然后基于不同存儲(chǔ)做各種算法分析;最后將各種結(jié)果數(shù)據(jù)導(dǎo)入ElasticSearch或者M(jìn)ySQL給前端做數(shù)據(jù)可視化。

通過閱讀上述知識(shí)相信各位對分布式數(shù)據(jù)庫的發(fā)展和不同系統(tǒng)的技術(shù)特點(diǎn)已經(jīng)有了一定的了解，限于篇幅的原因，筆者以分享幾個(gè)ES的使用心得結(jié)束：

1.用 ES 的 Alias 特性實(shí)現(xiàn)數(shù)據(jù)的水平擴(kuò)展。

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

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

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