我們在平時的技術(shù)討論或者實際應(yīng)用中經(jīng)常會提到傳統(tǒng)數(shù)據(jù)庫。提到傳統(tǒng)數(shù)據(jù)庫，很多人會很容易聯(lián)想到Oracle、My、SQL Server等帶有很明顯關(guān)系型數(shù)據(jù)庫特征的數(shù)據(jù)庫系統(tǒng)。在我看來，傳統(tǒng)數(shù)據(jù)庫并不等于這些數(shù)據(jù)庫，而是看你怎么用的。一般來說，傳統(tǒng)數(shù)據(jù)庫包括以下三個鮮明的特點：

1、事務(wù)的保障：ACID

ACID一言以蔽之就是原子性、一致性、隔離性、持久化事務(wù)，它是四個單詞的縮寫：

Atomicity 原子性 事務(wù)中所有操作要么全部完成，要么全失敗。

Consistency 一致性 在事務(wù)開始時或者結(jié)束時，數(shù)據(jù)庫應(yīng)該處于同一狀態(tài)。

Isolation 隔離性 事務(wù)將假定只有它自己在操作數(shù)據(jù)庫，彼此不知曉。

Durablity 一旦事務(wù)完成，就不能返回。

要做到ACID，從編程的角度來說，數(shù)據(jù)庫系統(tǒng)一定會用到鎖。

一般對事務(wù)要求比較高的主要是交易場景，銀行系統(tǒng)、大型在線電商交易系統(tǒng)用得比較多。對于絕大多數(shù)創(chuàng)業(yè)公司而言，事務(wù)是一個偏理論的概念。實際上在，在線系統(tǒng)中，事務(wù)是一個很有用的東西，我們舉個栗子：

用戶A在平臺購買增值服務(wù)的場景，會有很多種處理方式。

一般的程序員會如下處理：

在財務(wù)表中增加一條用戶A的扣費記錄。（扣費）

在用戶增值服務(wù)表中增加一條用戶A的增值服務(wù)記錄。（開通服務(wù)）

用戶至上的程序員會如下處理：

在用戶增值服務(wù)表中增加一條用戶A的增值服務(wù)記錄。（開通服務(wù)）

在財務(wù)表中增加一條用戶A的扣費記錄。（扣費）

三年以上工作經(jīng)驗的程序員會如下處理：

在財務(wù)表中增加一條用戶A的扣費記錄。（扣費）

判斷財務(wù)表中是否扣費成功，不成功通知系統(tǒng)交易失敗。

在用戶增值服務(wù)表中增加一條用戶A的增值服務(wù)記錄。（開通服務(wù)）

判斷用戶增值服務(wù)表中是否增加成功，不成功刪除財務(wù)表中的扣費并且通知系統(tǒng)交易失敗。

那么用上事務(wù)之后，你只要提交給數(shù)據(jù)庫一般程序員操作，數(shù)據(jù)庫就會給你三年以上工作經(jīng)驗的程序員的操作結(jié)果，在主從架構(gòu)讀寫分離的數(shù)據(jù)庫結(jié)構(gòu)中效果還會更好。

2、豐富的數(shù)據(jù)類型和SQL的操作方式

傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)可以存很多種類型的數(shù)據(jù)，主要包括：

數(shù)字家族、整數(shù)和小數(shù)。整數(shù)又可以分為32位的，64位的…

字符串類型。字符串又分為固定長度的和可變長度的…

時間家族。日期、時間…

二進制流…

這么多類型，確實很豐富。我們所看到的，都可以是字符，就算二進制流，也可以通過Base64轉(zhuǎn)碼用字符串表示。當(dāng)然，在講字符串的時候，我們是把編程語言進化到了一個很高級的程度，開發(fā)的友好性大于存儲成本。

對于傳統(tǒng)數(shù)據(jù)庫系統(tǒng)的常用操作，我們一般會說CURD。即對表的增刪改查，基本都用SQL語句來實現(xiàn)。SQL語句的結(jié)構(gòu)主要分為以下幾大部分：

操作，select、insert、update、delete。

表對象。

字段范圍(*/f1/f2…)。

Where條件。

Order排序(desc/asc)。

查詢范圍限制（top/limit）。

……

SQL語句是為使用者友好而設(shè)計的，無論何種數(shù)據(jù)庫引擎，SQL最后都被映射成為IO和內(nèi)存操作。

3、嚴(yán)格的數(shù)據(jù)模型：行式存儲

在傳統(tǒng)數(shù)據(jù)庫系統(tǒng)中，一般來說在第一次寫入數(shù)據(jù)之前，都需要創(chuàng)建庫和創(chuàng)建表，而每一個表都有確定的表頭，確定列數(shù)，每一列的名字以及確定的數(shù)據(jù)類型。在新數(shù)據(jù)的寫入或者數(shù)據(jù)的修改的時候，數(shù)據(jù)庫系統(tǒng)會根據(jù)創(chuàng)建好的表結(jié)構(gòu)嚴(yán)格校驗數(shù)據(jù)的合法性，對表結(jié)構(gòu)的調(diào)整一般都需要很大的修改代價。

在存儲單元里，同一行的數(shù)據(jù)會分布在相鄰的存儲單元里。

列式存儲相對于行式存儲而言，其同一列的數(shù)據(jù)會分布在相鄰的存儲單元里。

題外話：除了行存儲和列存儲，常見還有文檔模型，典型的代表就是MongoDB。如果用傳統(tǒng)的行的角度來看，不同的行列數(shù)可以不一樣，列的名字和數(shù)據(jù)類型也可以不一樣，列里面可以是另一個嵌套的行。

互聯(lián)網(wǎng)的需求

在互聯(lián)網(wǎng)化的大環(huán)境下，很多系統(tǒng)都很容易在短時間內(nèi)系統(tǒng)收集上億的數(shù)據(jù)，并且這些數(shù)據(jù)經(jīng)過加工，還要為幾十萬、幾百萬甚至更多用戶提供訪問。從平臺角度來說，一般就是從小到大，從簡單到復(fù)雜的過程。主要來說，具有一下三方面特點：

對數(shù)據(jù)高并發(fā)讀寫的要求

數(shù)據(jù)庫讀寫壓力巨大，硬盤IO無法承受。一般處理方法是主從架構(gòu)，讀寫分離，分庫、分表，緩解寫壓力，增強讀庫的可擴展性。

對海量數(shù)據(jù)的存儲和訪問

存儲記錄數(shù)量有限，SQL查詢效率極低的情況下。通過分庫、分表，緩解數(shù)據(jù)增長壓力。

伸縮性，可用性，可靠性方面的需求

橫向擴展艱難，無法通過快速增加服務(wù)器節(jié)點實現(xiàn)，系統(tǒng)升級和維護造成服務(wù)不可用。通過主從架構(gòu)，增強讀庫的擴展性，利用MMM架構(gòu)處理寫的瓶頸。

傳統(tǒng)數(shù)據(jù)庫的瓶頸

分庫分表缺點：

受業(yè)務(wù)規(guī)則影響，需求變動導(dǎo)致分庫分表的維護復(fù)雜。

系統(tǒng)數(shù)據(jù)訪問層代碼需要修改。

主從架構(gòu)缺點：

Slave實時性的保障，對于實時性很高的場合可能需要做一些處理（在第一個購買增值服務(wù)的例子中，添加扣費記錄之后，在讀寫分離的場景下，立馬去從庫查詢扣費記錄不一定能查到）。

高可用性問題，Master就是那個致命點，容易產(chǎn)生單點故障。

MMM缺點：

本身擴展性差，一次只能一個Master可以寫入，只能解決有限數(shù)據(jù)量下的可用性。

分布式基礎(chǔ)理論

1、CAP

分布式領(lǐng)域CAP理論

Consistency 一致性：數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的。

Availability(可用性)：好的響應(yīng)性能。

Partition tolerance：分區(qū)容忍性。

在中，這三個要素最多只能同時實現(xiàn)兩點，不可能三者兼顧；對于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求；對于大多數(shù)Web應(yīng)用，犧牲一致性而換取高可用性，是目前多數(shù)分布式數(shù)據(jù)庫產(chǎn)品的方向。

2、Base

Basically Available：基本可用 支持分區(qū)失敗。

Soft state 軟狀態(tài)：狀態(tài)可以有一段時間不同步，異步。

Eventually consistent：最終一致性 ，最終數(shù)據(jù)是一致的就可以了，而不是時時一致。

3、運動兩個核心理論

Google的BigTable

BigTable提出了一種很有趣的數(shù)據(jù)模型，它將各列數(shù)據(jù)進行排序存儲。數(shù)據(jù)值按范圍分布在多臺機器，數(shù)據(jù)更新操作有嚴(yán)格的一致性保證。

Amazon的Dynamo

Dynamo使用的是另外一種分布式模型。Dynamo的模型更簡單，它將數(shù)據(jù)按key進行hash存儲。其數(shù)據(jù)分片模型有比較強的容災(zāi)性，因此它實現(xiàn)的是相對松散的弱一致性：最終一致性。

特征

HBase是Google Bigtable的開源實現(xiàn)，類似Google Bigtable利用GFS作為其文件存儲系統(tǒng)，HBase利用 HDFS作為其文件存儲系統(tǒng)；Google運行MapReduce來處理Bigtable中的海量數(shù)據(jù)，HBase同樣利用Hadoop MapReduce來處理HBase中的海量數(shù)據(jù)；Google Bigtable利用 Chubby作為協(xié)同服務(wù)，HBase利用ZooKeeper作為對應(yīng)。

主要特點

列的可以動態(tài)增加，并且列為空就不存儲數(shù)據(jù)，節(jié)省存儲空間。

HBase自動切分?jǐn)?shù)據(jù)，使得數(shù)據(jù)存儲自動具有水平bility。

HBase可以提供高并發(fā)讀寫操作的支持，分布式架構(gòu)，讀寫鎖等待的概率大大降低。

不能支持條件查詢，只支持按照Rowkey來查詢。

暫時不能支持Master server的故障切換，當(dāng)Master宕機后，整個存儲系統(tǒng)就會掛掉。

HBase底層架構(gòu)

HBase是一個列式存儲的數(shù)據(jù)庫系統(tǒng)，跟所有的數(shù)據(jù)庫系統(tǒng)一樣，數(shù)據(jù)庫是依賴文件系統(tǒng)的，在傳統(tǒng)數(shù)據(jù)庫里面我們經(jīng)常提到存儲引擎，例如MySQL有MyISAM/InnoDB，Oracle/SqlServer不開源，沒有那么多選擇，但都會有自己的存儲引擎，說得通俗一點就是虛擬文件系統(tǒng)，HBase的文件系統(tǒng)是HDFS，一種分布式文件系統(tǒng)，所以HBase天然具備分布式的特性。同時Hadoop MapReduce為HBase提供了高性能的計算能力，Zookeeper為HBase提供了穩(wěn)定服務(wù)和failover機制。

HBase設(shè)計要點

1、邏輯數(shù)據(jù)模型

Table

Region

ColumnFamily

Row

Column

Value

TimeStamp

你也可以把HBase看成一個多維度的Map模型去理解它的數(shù)據(jù)模型。正如下圖。

2、HBase的體系組成

NameNode存儲DataNode信息，ZooKeeper負(fù)責(zé)調(diào)度。

一個Region只會存在一臺RegionServer上，一臺RegionServer上可以包含多個Region。

一個邏輯的表包含多個Region，分布在各個RegionServer上，對應(yīng)用程序來說只有一個大表不用管分表分庫。

Region的定位

-ROOT-

.META

存儲分布

每一行包含N個列，以列的形式分布在不同Region里面。

3、HBase各對象職責(zé)

Client

HBase的訪問接口，維護cache加快HBase的訪問。

Zookeeper

監(jiān)控Master，保證只有一個Master；

存儲Region的入口地址；

監(jiān)控RegionServer上下線，并告知Master；

存儲Hbase shcema和Table的元數(shù)據(jù)。

Master

分配Region到RegionServer；

RegionSever的負(fù)載均衡；

發(fā)現(xiàn)失效的RegionServer并重新分配其上的Region

管理用戶對Table的增刪改查操作。

RegionServer

維護Region，處理對這些Region的IO；

Split&Compact。

4、應(yīng)用方式

HBase是三維有序存儲的，通過RowKey（行鍵），column key（column family和qualifier）和TimeStamp（時間戳）這個三個維度可以對HBase中的數(shù)據(jù)進行快速定位。

RowKey是HBase表結(jié)構(gòu)設(shè)計中很重要的一環(huán) ，HBase中RowKey可以唯一標(biāo)識一行記錄，在HBase查詢的時候，有以下2種方式：

按指定RowKey獲取唯一一條記錄，get方法

（org.apache.hadoop.hbase.client.Get）

按指定的條件獲取一批記錄，scan方法

（org.apache.hadoop.hbase.client.Scan）

第一種類似key-value查找，第二種可以實現(xiàn)簡單的條件查詢功能。

轉(zhuǎn)載自：煉數(shù)成金網(wǎng)