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

分布式數(shù)據(jù)庫大數(shù)據(jù) 數(shù)據(jù)分析

盧億雷 | 2016-03-21 15:41

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

基本理論

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

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

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

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

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

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

事務(wù)隔離性一覽

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

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

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

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

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

CAP三大定律

圖2 CAP三大定律

NoSQL分類

如果同時滿足這三點，成本將會非常高，所以建議根據(jù)業(yè)務(wù)的具體需求做好平衡選擇。把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的對比分析

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

表1 OLTP和OLAP對比

OLTP和OLAP對比

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

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

HBase

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

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

HBase中的功能實現(xiàn)

圖3 HBase中的功能實現(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的模型比較清晰比較簡單，就兩個步驟，一個步驟是怎么把數(shù)據(jù)建索引，建完索引主要是做查詢，怎么把SQL的語句做查詢。

ElasticSearch亮點

圖4 ElasticSearch亮點

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

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

ElasticSearch功能模塊

圖5 ElasticSearch功能模塊

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

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

Druid和Pinot功能實現(xiàn)對比

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

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

服務(wù)器數(shù)量為70臺，配置為：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列：動態(tài)列為3列(多值列)，普通列為9列

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

ElasticSearch和Pinot百億條檢索對比

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

ElasticSearch和Pinot千億條檢索對比

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

真實案例分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

來源：csdn

收藏分享

聲明：數(shù)據(jù)猿尊重媒體行業(yè)規(guī)范，相關(guān)內(nèi)容都會注明來源與作者；轉(zhuǎn)載我們原創(chuàng)內(nèi)容時，也請務(wù)必注明“來源：數(shù)據(jù)猿”與作者名稱，否則將會受到數(shù)據(jù)猿追責(zé)。