国产片区二区三区,岛国视频在,国产毛片JAPA

分布式數據庫HBase的架構設計詳解

轉帖|使用教程|編輯：龔雪|2017-05-16 11:37:01.000|閱讀 263 次

概述：Web系統的流行，數據收集越來越容易，促使各類數據庫系統應用得越來越廣泛。本文主要介紹了HBase數據庫架構設計的詳情

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

1、事務的保障：ACID

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

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

Consistency 一致性在事務開始時或者結束時，數據庫應該處于同一狀態。

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

Durablity 一旦事務完成，就不能返回。

要做到ACID，從編程的角度來說，數據庫系統一定會用到鎖。

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

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

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

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

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

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

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

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

三年以上工作經驗的程序員會如下處理：

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

判斷財務表中是否扣費成功，不成功通知系統交易失敗。

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

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

那么用上事務之后，你只要提交給數據庫一般程序員操作，數據庫就會給你三年以上工作經驗的程序員的操作結果，在主從架構讀寫分離的數據庫結構中效果還會更好。

2、豐富的數據類型和SQL的操作方式

傳統的數據庫系統可以存很多種類型的數據，主要包括：

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

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

時間家族。日期、時間…

二進制流…

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

對于傳統數據庫系統的常用操作，我們一般會說CURD。即對表的增刪改查，基本都用SQL語句來實現。SQL語句的結構主要分為以下幾大部分：

操作，select、insert、update、delete。

表對象。

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

Where條件。

Order排序(desc/asc)。

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

……

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

3、嚴格的數據模型：行式存儲

在傳統數據庫系統中，一般來說在第一次寫入數據之前，都需要創建庫和創建表，而每一個表都有確定的表頭，確定列數，每一列的名字以及確定的數據類型。在新數據的寫入或者數據的修改的時候，數據庫系統會根據創建好的表結構嚴格校驗數據的合法性，對表結構的調整一般都需要很大的修改代價。

在存儲單元里，同一行的數據會分布在相鄰的存儲單元里。

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

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

互聯網的需求

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

對數據高并發讀寫的要求

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

對海量數據的存儲和訪問

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

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

橫向擴展艱難，無法通過快速增加服務器節點實現，系統升級和維護造成服務不可用。通過主從架構，增強讀庫的擴展性，利用MMM架構處理寫的瓶頸。

傳統數據庫的瓶頸

分庫分表缺點：

受業務規則影響，需求變動導致分庫分表的維護復雜。

系統數據訪問層代碼需要修改。

主從架構缺點：

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

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

MMM缺點：

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

分布式基礎理論

1、CAP

分布式領域CAP理論

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

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

Partition tolerance：分區容忍性。

在中，這三個要素最多只能同時實現兩點，不可能三者兼顧；對于分布式數據系統，分區容忍性是基本要求；對于大多數Web應用，犧牲一致性而換取高可用性，是目前多數分布式數據庫產品的方向。

2、Base

Basically Available：基本可用支持分區失敗。

Soft state 軟狀態：狀態可以有一段時間不同步，異步。

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

3、運動兩個核心理論

Google的BigTable

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

Amazon的Dynamo

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

特征

HBase是Google Bigtable的開源實現，類似Google Bigtable利用GFS作為其文件存儲系統，HBase利用 HDFS作為其文件存儲系統；Google運行MapReduce來處理Bigtable中的海量數據，HBase同樣利用Hadoop MapReduce來處理HBase中的海量數據；Google Bigtable利用 Chubby作為協同服務，HBase利用ZooKeeper作為對應。

主要特點

列的可以動態增加，并且列為空就不存儲數據，節省存儲空間。

HBase自動切分數據，使得數據存儲自動具有水平bility。

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

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

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

HBase底層架構

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