【深度】MySQL集群 對比 SequoiaDB彈性擴展

前言

隨著大數據，互聯網應用的快速發展，海量數據的存儲和訪問成為了系統設計的瓶頸問題。對於一個大型的應用系統，每天幾十億的的數據無疑對資料庫造成了相當高的負載。對於系統的穩定性和擴展性造成了極大的問題。通過數據切分來提高性能，橫向擴展數據層的分散式資料庫已經成為一個趨勢。水平切分資料庫，可以降低單台機器的負載，同時最大限度的降低了宕機造成的損失。通過負載均衡策略，有效的降低了單台機器的訪問負載，降低了宕機的可能性；通過集群方案，解決了資料庫宕機帶來的單點資料庫不能訪問的問題；通過讀寫分離策略更是最大限度了提高了應用中讀取（Read）數據的速度和並發量。

在這裡，我們主要介紹一下MySQL的集群策略以及跟SDB的集群的擴展。

MySQL集群

一 MySQL Cluster

1、Cluster的介紹

MySQL Cluster的關鍵部分－－sql node（MySQL Server）、data node（storage或者ndbd）。至於它的結構，我們從圖形來進行理解。

下面是最小配置的cluster，使用兩台機器：

上圖有兩個數據節點（用於保存持久化數據的）、兩個SQL節點（提供給應用程序訪問的前端）。

下面是用了五台機器的cluster：

上圖有三個SQL節點，兩個數據節點。每個節點都獨自使用一台機器。

2、數據存儲的冗餘與分布

sql節點不存儲數據；數據節點之間可以是冗餘數據，也可以是分布存儲，即一份數據拆成多份，保存在不同的節點上。見下圖：

上圖表述在4個數據節點的情況下，拆分一個表的存儲。左上是一張表，欄位是ID、CAPITAL、COUNTRY、UTC。目前MySQL Cluster是根據數據節點的個數，和replica的個數（即冗餘的份數），對主鍵進行HASH，分布存儲到各個節點中。每一個組的成員個數與replica的個數相同。

當有數據節點出現宕機情況時，系統仍然可用。如下圖：

下面是集群的高可用方案：

上圖壞掉了兩個數據節點、四個SQL節點、一個管理節點，cluster仍然是「活」的。

3、Cluster的優缺點

l 能運行在普通硬體上，不需要專業的存儲設備；

l 一個節點失敗不會導致其他節點失敗；

l 數據節點和前端（SQL節點）都可以避免單點失效；

l 數據的冗餘是同步方式，不像複製採用非同步方式；一個數據節點實效，它的備份節點的數據不會與其不一致；

l 不能在線增加和捨棄節點（需要做全備和恢復，需要重啟整個cluster）；

l 本身不實現動態的負載均衡；

l 管理複雜程度比複製高；

l 目前應用的廣泛程度遠不及它的複製。

4、Cluster的限制

l 自增長列必須是主鍵；

l 不支持事務的部分回滾，重複鍵或者類似的錯誤會導致整個事務回滾；

l 只支持read committed隔離級別；

l varchar佔用與char相同的空間；

l 外鍵被忽略；

l 保存點被忽略；

l 執行範圍掃描時，開銷相對昂貴；

l 最大節點數為63；

l 數據節點最多為48；

l 不適宜處理大事務；

l commit時不能保證日誌刷新到硬碟；

l delete某個表的數據，釋放的空間，只由在同一個表的insert時再被使用，不會被其他表使用；

l 限制比較多，參見官方文檔，不一一列出了。

二 MySQL Replication(master+slave)

1、Replication的基本原理

MySQL Replication是兩個MySQL伺服器之間的非同步數據複製。

兩個MySQL伺服器，一個為Master（主），一個為Slave（從）。master開啟二進位日誌；slave啟動一個線程連接master，來不斷地獲取master的二進位日誌，並寫到本地的relay binlog文件中；slave啟動另一個線程把reIay binlog文件中的日誌應用到slave資料庫中；master中有一個線程負責與slave通訊，不斷的讀取二進位日誌，並傳遞給slave。

2、只基於複製的高可用方案

slave可以用做master的備份；slave可以分流讀操作；備份到其他介質時，可從slave備份，而不增加master的負載。

當master出現問題時：

master失效時，通過手工操作，讓應用只訪問slave。

3、複製（Replication）的優缺點

l slave可以作為master的備份；

l 是非同步的，不會給master帶來很大的壓力，但某些情況下，當master宕掉時，可能有些數據還未複製到slave中去；

l 配置簡單；

l master和slave相對獨立，建立新的複製關係時不必停機；當其中一方宕機，另一方還可以繼續運轉；宕機的一方經過恢復後，重新建立複製關係，也不需要正在運轉的一方停機；

l 應用廣泛，這是MySQL非常成熟的技術，大量的案例都使用了複製；

l slave可以分流資料庫讀操作，但這需要應用程序分別處理資料庫的讀和寫；

l 可以對slave進行備份，而不影響master；特別是可以lock所有表，然後做文件拷貝，甚至停止slave的MySQL服務，然後做文件拷貝，數據量大時，比mysqldump速度快。

4、複製（Replication）的限制

一個master可以帶多個slave；一個slave只能有一個master；slave也同時可以作為master，從而形成鏈式複製、雙向複製、環式複製。但雙向複製和環式複製，在官方文檔中並不提倡，因為容易產生衝突，衝突之後也沒有自動解決的機制。

如下圖：

三 Mycat實現MySQL集群

1、Mycat概述

Mycat從定義和分類來看，它是一個開源的分散式資料庫系統，是一個實現了MySQL協議的伺服器，前端用戶可以把它看作是一個資料庫代理，用MySQL客戶端工具和命令行訪問，而其後端可以用MySQL原生協議與多個MySQL伺服器通信，也可以用JDBC協議與大多數主流資料庫伺服器通信，其核心功能是分表分庫，即將一個大表水平分割為N個小表，存儲在後端MySQL伺服器里或者其他資料庫里。

MyCat發展到目前的版本，已經不是一個單純的MySQL代理了，它的後端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流資料庫，也支持MongoDB這種新型NoSQL方式的存儲，未來還會支持更多類型的存儲。而在最終用戶看來，無論是那種存儲方式，在MyCat里，都是一個傳統的資料庫表，支持標準的SQL語句進行數據的操作，這樣一來，對前端業務系統來說，可以大幅降低開發難度，提升開發速度。

Mycat架構圖

Mycat支持基於MySQL主從複製狀態的高級讀寫分離控制機制

讀寫分離

讀寫分離定義

為了確保資料庫產品的穩定性，很多資料庫擁有雙機熱備功能。也就是，第一台資料庫伺服器，是對外提供增刪改查業務的生產伺服器；第二台資料庫伺服器，僅僅接收來自第一台伺服器的備份數據。一般來說，為了配置方便，以及穩定性，這兩台資料庫伺服器，都用的是相同的配置。

在實際運行中，第一台資料庫伺服器的壓力，遠遠大於第二台資料庫伺服器。因此，很多人希望合理利用第二台資料庫伺服器的空閑資源。

從資料庫的基本業務來看，資料庫的操作無非就是增刪改查這4個操作。但對於「增刪改」這三個操作，如果是雙機熱備的環境中做，一台機器做了這三個操作的某一個之後，需要立即將這個操作，同步到另一台伺服器上。出於這個原因，第二台備用的伺服器，就只做了查詢操作。進一步，為了降低第一台伺服器的壓力，乾脆就把查詢操作全部丟給第二台資料庫伺服器去做，第一台資料庫伺服器就只做增刪改了。

優缺點

優點：合理利用從資料庫伺服器的空閑資源。

缺點：本來第二台資料庫伺服器，是用來做熱備的，它就應該在一個壓力非常小的環境下，保證運行的穩定性。而讀寫分離，卻增加了它的壓力，也就增加了不穩定性。因此，讀寫分離，實質上是一個在資金比較缺乏，但又需要保證數據安全的需求下，在雙機熱備方案上，做出的一種折中的擴展方案。

SequoiaDB分散式集群

SequoiaDB 是業界領先的新一代分散式資料庫產品，功能上包括了分散式 OLTP，分散式對象存儲以及分散式 NoSQL 實現全類型數據的覆蓋。

1）分散式架構

SequoiaDB 作為典型 Share-Nothing 的分散式資料庫，同時具備高性能與高可用的特性。 SequoiaDB 採用分片技術為系統 供了橫向擴展機制，其分片過程對於應用程序來說完全透明。 該機制解決了單台伺服器硬體資源(如內存、CPU、磁碟 I/O)受限的問題，並不會增加應用程 序開發的複雜性。

SDB分散式的邏輯架構

· 協調節點:負責調度、分配、匯總，是SequoiaDB的數據分發節點，本身不存儲任何數據，主要負責接收應用程序的訪問請求;

· 編目節點:負責存儲整個資料庫的部署結構與節點狀態信息，並且記錄集合空間與集合的參數信息，同時記錄每個集合的數據切分狀況;

· 數據節點:承載數據存儲、計算的進程為用戶 供高性能的讀寫服務，並且在多索引的支持下針對海量數據查詢性能優越。多個數據節點可以組成一個數據節點組，採取一主多備結構。

2）彈性擴容

SequoiaDB支持橫向動態擴容。用戶在系統性能或存儲不足時，可以通過快速擴展集群，提升系統整體性能或存儲容量。通過原生的分散式架構，可以實現彈性的容量擴展，幫助用戶更靈活的調整資料庫的存儲空間。

圖、集群擴容舉例

· 集群擴容過程對應用系統透明，應用系統無需修配置、程序。

· 集群擴容速度快

· 支持數據均衡分布

3）讀寫分離

基於數據組「一主多從」的特性，SequoiaDB可以實現分散式架構下的讀寫分離。

? 數據在多個分布節點內自動複製，並實現寫請求和讀請求的自動分離，避免讀請求對數據寫入的影響。

? 此外，可進一步定製數據分布策略，保證不同類型業務可以運行在同一平台上，但同時又不會互相干擾，比如「冷/熱數據區分離」，寫交易的「強一致性」和「弱一致性」分離以及「查詢/批量分離」

總結

從MySQL 分散式和SequoiaDB的功能和性能對比，我們可以歸納一些結論：

? 在數據量較小的情況下，使用單點的MySQL和SequoiaDB的性能差別不回特別大。

? 數據量較大的情況下，MySQL單點和

總體來說相對於MySQL，分散式資料庫SequoiaDB的擴展性更加靈活,高效同時更能保證資料庫的高可用。