High Availability Database 的架構設計

High Availability Database 的架構設計

這篇文章主要說明資料庫的 High Availability 有哪些技術上的選擇可以採用,

High Availability 指的是當機時間最少、99.99x%,當資料庫發生錯誤時,

可以隨時有另外一台資料庫備援,另外,當使用者突然暴增的時候,還能夠正常的服務!

要達到這些目標,技術上有哪些選擇可以採用?

這篇文章提到的相關技術與應用套件主要用 MySQL 為例子。

Clustering

提到 High Availability 就不得不提到 Clustering,Clustering 主要由三大元素組成:

  • MySQL Server (資料庫伺服器)
  • Cluster Engine (控制資料存取與備份的引擎)
  • Data Nodes (存放資料的地方)

Clustering 解決了一些會造成服務中斷問題的可能性,例如:

  • single point of failure:不會因為一台電腦的當機而中斷整個服務
  • 即時備援:由於資料不斷的在 Master/Slave間相互備份,所以當 Master 電腦中斷服務時,另外台電腦Slave會啟動繼續服務。

其中Clustering 多半會設定資料間如何在電腦間做資料同步。(Replication)

所以會有 Master / Slave。Slave會定期將Master 的資料同步。

雖然Clustering 可以避免 single point of failure,但是卻很難延展。

多增加一台Slave 資料庫並沒有辦法有效的分散資料庫的負擔。

因此就需要資料庫的Load balance解決方案。

Clustering vs Replication

方法 優點 缺點
MySQL clustering 提供比較好的效能

可以相對的延展
減少當機或是中斷服務的時間

需要耗用大量的記憶體t
相對比較複雜。
因為伺服器間需要經常得做資料同步,因此需要依賴網路的架構
MySQL Replication 簡單
比較沒有額外的效能負擔
資料有可能會遺失

當一台資料庫中斷服務時,另外一台無法即時啟動繼續服務

 

資料庫的 Load Balance

資料庫的 Load Balance 有一個困難的問題要解決。那就是資料的寫入!

針對資料的讀取,我們可以用許多資料庫讓前端應用程式讀取比較沒有問題。

但是,因為資料庫有資料的寫入,因此資料庫的 Load Balance就必須考慮資料值不一致的狀況。

另外,資料庫間還會需要額外資料相互同步的問題。

因此,資料庫的 Load Balance 適用在讀取。而非寫入!

現實世界中資料庫多半都是有讀取跟寫入。怎麼辦呢?

這個時候就必須將資料庫的資料表作適當的切割。將很少寫入的資料表與經常寫入的資料表分開。

讓寫入與讀取透過不同的資料庫來服務。這樣寫入的資料庫就可以做到 Load Balance來分散資料庫的負擔。

要做到 Database Load Balance/proxy,有許多的 Open source 可以參考:

資料庫的快取

關聯式資料庫由於有 Table join, ACID, Transactions, Locks,Isolation Level 等,

造成多人同時資料讀取效能上的問題,

因此,另外一個方式是將經常存取的資料,存放在利用Key/Value的方式存放在 Memory Cache,

再建置多台的快取記憶體伺服器,如此一來也可以減少資料庫直接讀取的負擔。

由於 Memcached 本身並不提供 Load Balancing 的機制,

因此還是需要一個 Load Balancing 的 routing,來告訴前端應用程式該資料應該到哪一台 memcached 取得。

memcached比 Clustering效能好的另外一個原因是memcached間資料不需要相互同步。

每一台快取記憶體伺服器有自己快取的資料,獨立運作。

當其中一台快取記憶體伺服器無法運作時,資料的存取還是回到原本資料庫本身。

 

NoSQL 的使用

當有大量的資料需要大量的同步讀取時,可以考慮將這些資料規畫放在 NoSQL。

NoSQL 除了讀取效率比較好之外,對於資料結構、Table 欄位等,經常要修改也比較容易。

另外,NoSQL如果要擴充效能,只要透過增加NoSQL節點的方式就可以完成。

所以,可以現有資料庫資料重新規劃。在 SQL 與 NoSQL的儲存取得一個平衡。

 

Leave a Reply

Your email address will not be published.