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

 

前言

隨着大數據，互聯網應用的快速發展，海量數據的存儲和訪問成爲了系統設計的瓶頸問題。對於一個大型的應用系統，天天幾十億的的數據無疑對數據庫形成了至關高的負載。對於系統的穩定性和擴展性形成了極大的問題。經過數據切分來提升性能，橫向擴展數據層的分佈式數據庫已經成爲一個趨勢。水平切分數據庫，能夠下降單臺機器的負載，同時最大限度的下降了宕機形成的損失。經過負載均衡策略，有效的下降了單臺機器的訪問負載，下降了宕機的可能性；經過集羣方案，解決了數據庫宕機帶來的單點數據庫不能訪問的問題；經過讀寫分離策略更是最大限度了提升了應用中讀取（Read）數據的速度和併發量。

在這裏，咱們主要介紹一下MySQL的集羣策略以及跟SDB的集羣的擴展。

MySQL集羣

一 MySQL Cluster

一、Cluster的介紹

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

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

      

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

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

     

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

二、數據存儲的冗餘與分佈

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

            

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

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

 

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

 

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

三、Cluster的優缺點

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

l 一個節點失敗不會致使其餘節點失敗；

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

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

l 不能在線增長和捨棄節點（須要作全備和恢復，須要重啓整個cluster）；

l 自己不實現動態的負載均衡；

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

l 目前應用的普遍程度遠不及它的複製。

四、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)

一、Replication的基本原理

MySQL Replication是兩個MySQL服務器之間的異步數據複製。

 

兩個MySQL服務器，一個爲Master（主），一個爲Slave（從）。master開啓二進制日誌；slave啓動一個線程鏈接master，來不斷地獲取master的二進制日誌，並寫到本地的relay binlog文件中；slave啓動另外一個線程把reIay binlog文件中的日誌應用到slave數據庫中；master中有一個線程負責與slave通信，不斷的讀取二進制日誌，並傳遞給slave。

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

 

slave能夠用作master的備份；slave能夠分流讀操做；備份到其餘介質時，可從slave備份，而不增長master的負載。

當master出現問題時：

 

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

三、複製（Replication）的優缺點

l slave能夠做爲master的備份；

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

l 配置簡單；

l master和slave相對獨立，創建新的複製關係時沒必要停機；當其中一方宕機，另外一方還能夠繼續運轉；宕機的一方通過恢復後，從新創建複製關係，也不須要正在運轉的一方停機；

l 應用普遍，這是MySQL很是成熟的技術，大量的案例都使用了複製；

l slave能夠分流數據庫讀操做，但這須要應用程序分別處理數據庫的讀和寫；

l 能夠對slave進行備份，而不影響master；特別是能夠lock全部表，而後作文件拷貝，甚至中止slave的MySQL服務，而後作文件拷貝，數據量大時，比mysqldump速度快。

四、複製（Replication）的限制

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

以下圖：

 

三 Mycat實現MySQL集羣

一、Mycat概述

Mycat從定義和分類來看，它是一個開源的分佈式數據庫系統，是一個實現了MySQL協議的服務器，前端用戶能夠把它看做是一個數據庫代理，用MySQL客戶端工具和命令行訪問，而其後端能夠用MySQL原生協議與多個MySQL服務器通訊，也能夠用JDBC協議與大多數主流數據庫服務器通訊，其核心功能是分表分庫，即將一個大表水平分割爲N個小表，存儲在後端MySQL服務器裏或者其餘數據庫裏。

MyCat發展到目前的版本，已經不是一個單純的MySQL代理了，它的後端能夠支持MySQL、SQL Server、Oracle、DB二、PostgreSQL等主流數據庫，也支持MongoDB這種新型NoSQL方式的存儲，將來還會支持更多類型的存儲。而在最終用戶看來，不管是那種存儲方式，在MyCat裏，都是一個傳統的數據庫表，支持標準的SQL語句進行數據的操做，這樣一來，對前端業務系統來講，能夠大幅下降開發難度，提高開發速度。

 

Mycat架構圖

 

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

讀寫分離

讀寫分離定義

爲了確保數據庫產品的穩定性，不少數據庫擁有雙機熱備功能。也就是，第一臺數據庫服務器，是對外提供增刪改查業務的生產服務器；第二臺數據庫服務器，僅僅接收來自第一臺服務器的備份數據。通常來講，爲了配置方便，以及穩定性，這兩臺數據庫服務器，都用的是相同的配置。

在實際運行中，第一臺數據庫服務器的壓力，遠遠大於第二臺數據庫服務器。所以，不少人但願合理利用第二臺數據庫服務器的空閒資源。

從數據庫的基本業務來看，數據庫的操做無非就是增刪改查這4個操做。但對於「增刪改」這三個操做，若是是雙機熱備的環境中作，一臺機器作了這三個操做的某一個以後，須要當即將這個操做，同步到另外一臺服務器上。出於這個緣由，第二臺備用的服務器，就只作了查詢操做。進一步，爲了下降第一臺服務器的壓力，乾脆就把查詢操做所有丟給第二臺數據庫服務器去作，第一臺數據庫服務器就只作增刪改了。

優缺點

優勢：合理利用從數據庫服務器的空閒資源。

缺點：原本第二臺數據庫服務器，是用來作熱備的，它就應該在一個壓力很是小的環境下，保證運行的穩定性。而讀寫分離，卻增長了它的壓力，也就增長了不穩定性。所以，讀寫分離，實質上是一個在資金比較缺少，但又須要保證數據安全的需求下，在雙機熱備方案上，作出的一種折中的擴展方案。

 

SequoiaDB分佈式集羣

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

 

1、分佈式架構

SequoiaDB 做爲典型 Share-Nothing 的分佈式數據庫，同時具有高性能與高可用的特性。 SequoiaDB 採用分片技術爲系統 供了橫向擴展機制，其分片過程對於應用程序來講徹底透明。 該機制解決了單臺服務器硬件資源(如內存、CPU、磁盤 I/O)受限的問題，並不會增長應用程 序開發的複雜性。 

 

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

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

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

 

2、彈性擴容

SequoiaDB支持橫向動態擴容。用戶在系統性能或存儲不足時，能夠經過快速擴展集羣，提高系統總體性能或存儲容量。經過原生的分佈式架構，能夠實現彈性的容量擴展，幫助用戶更靈活的調整數據庫的存儲空間。

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

· 集羣擴容速度快

· 支持數據均衡分佈

 

3、讀寫分離

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

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

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

總結

從MySQL 分佈式和SequoiaDB的功能和性能對比，咱們能夠概括一些結論：

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

• 數據量較大的狀況下，MySQL單點和

 

整體來講相對於MySQL，分佈式數據庫SequoiaDB的擴展性更加靈活,高效同時更能保證數據庫的高可用。