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

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

基本理論

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

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

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

隔離性(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ù)操作間的混淆，必須串行化或序列化請(qǐng)求，使得在同一時(shí)間僅有一個(gè)請(qǐng)求用于同一數(shù)據(jù)。

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

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

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

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

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

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

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

圖2 CAP三大定律

NoSQL分類(lèi)

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

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的對(duì)比分析

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

表1 OLTP和OLAP對(duì)比

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

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

HBase

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

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

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

ElasticSearch(ES)

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

圖4 ElasticSearch亮點(diǎn)

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

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

圖5 ElasticSearch功能模塊

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

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

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

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

服務(wù)器數(shù)量為70臺(tái)，配置為：CPU 12核，內(nèi)存96G，硬盤(pán)48T

測(cè)試語(yǔ)句：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百億條檢索對(duì)比

表4 ElasticSearch和Pinot千億條檢索對(duì)比

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

真實(shí)案例分析

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

1.每天請(qǐng)求數(shù)超過(guò) 100 億

2. 每天增長(zhǎng)超過(guò) 5TB 級(jí)數(shù)據(jù)

3. 每天對(duì)幾千億條記錄進(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ù)需求在毫秒級(jí)需要;有嚴(yán)格要求的時(shí)間序列，如原來(lái)輸入是1、2、3、4、5，輸出還必須是1、2、3、4、5。其他用Spark Streaming將會(huì)比較好。

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

通過(guò)閱讀上述知識(shí)相信各位對(duì)分布式數(shù)據(jù)庫(kù)的發(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)對(duì)特殊字符的精確匹配，目前現(xiàn)在主流的搜索引擎在搜索關(guān)鍵詞的時(shí)候?qū)?biāo)點(diǎn)符號(hào)是忽略的，但是在實(shí)現(xiàn)一些對(duì)監(jiān)控微博等社交數(shù)據(jù)時(shí)，如果微博里有很多符號(hào)，舉例來(lái)說(shuō)“：)”其實(shí)代表的是笑臉，而笑臉對(duì)于我們來(lái)判斷正負(fù)面是非常有用的，所以判斷正負(fù)面不只是語(yǔ)義分析的，還有對(duì)標(biāo)點(diǎn)符號(hào)分析也非常重要。