原生分散式資料庫與中介軟體的區別
編者按：
本文作者宮學慶，是華東師範大學電腦科學與軟體工程學院教授、博士生導師。 研究領域為資料庫技術和分散式系統，主持過國家自然科學基金專案和多項企業合作專案，發表研究論文30多篇，曾參與交通銀行分散式資料庫系統研發專案，交流請聯絡 [email protected] 。
以下為正文：
網際網路和移動應用的普及讓人們使用資訊服務越來越方便，也使各類資訊系統面臨著越來越大的資料規模和訪問請求的壓力。隨著分散式資料庫在網際網路行業的廣泛應用，通過分散式資料庫來擴充套件資訊系統的處理能力，成為近年來服務提供商的一種普遍選擇。目前，分散式資料庫解決方案已經呈現百花齊放的態勢，如何選擇合適的分散式資料庫又成為困擾決策者的一個問題。
從技術角度來看，分散式資料庫解決方案大致可以分為兩大類，即分散式資料庫中介軟體和原生分散式資料庫。分散式資料庫中介軟體是架構在多個傳統單點資料庫系統上的中間層解決方案，通過將資料分拆到不同的資料庫節點上，利用中介軟體來管理和訪問各個資料庫中的資料，通常需要使用者參與到資料分拆和節點管理過程中。網際網路行業最初所使用的分散式資料庫方案多是基於中介軟體的，在解決服務壓力問題上也取得了較好的效果，但同時也暴露出不少問題。原生分散式資料庫是指從架構設計、底層儲存和查詢處理均面向分散式資料管理需求，資料庫叢集作為一個整體對外提供服務，使用者無需關注叢集內部的實現細節。由於原生資料庫系統開發的難度大，最初的版本通常功能簡單，限制了其應用的場景。隨著版本的不斷成熟，原生分散式資料庫已經展現出了取代分散式資料庫中介軟體的趨勢。
本文將從資料可靠性、副本同步和服務可用性等幾個方面進行分析，對比兩種方案的區別。
資料可靠性
幾乎所有的分散式資料庫解決方案都宣稱可以在普通PC伺服器叢集上實現超過高階共享儲存的資料可靠性。這一點都是通過冗餘來實現的，即將資料進行分片，然後將每個分片複製出n個副本，並且儲存在叢集中的n個不同節點上，當叢集中宕機的節點數少於n時，總能保證有一個副本的資料不會丟失。由於節點宕機等原因導致分片副本的數量少於n時，需要通過將副本複製到新節點來保證副本數量。
在分散式資料庫中介軟體方案中，由於底層的每個節點都是一個獨立的資料庫系統，中介軟體很難實現分片副本在不同節點間的複製，因此多利用底層資料庫的主備同步機制為每個節點配置獨立的備份節點。為了實現更好的資料可靠性，通常需要一主兩備3個副本，這樣會導致伺服器利用率降低和管理的複雜性升高。對於原生分散式資料庫系統來說，系統支援資料的自動分片，以及分片副本在叢集節點間的自動遷移和複製，實現負載均衡，在伺服器利用率和管理複雜性上均明顯優於中介軟體方案。
副本同步
多副本技術雖然保證了分散式資料庫中的資料可靠性，但同時帶來了副本同步的問題，即如何保證資料分片不同副本的同步更新。具體實現副本同步的技術可以分為四類：
a) 更新主副本，同步複製到從副本：資料副本有主從之分，所有的更新發生在主副本，當更新被同步複製到從副本後，更新完成。這種方式可以保證副本間的資料一致性，但更新的效能會受節點間通訊影響。
b) 更新主副本，非同步複製到從副本：資料副本有主從之分，所有的更新發生在主副本，且即時生效，主副本的更新以非同步方式複製給從副本。這種方式的更新效能較好，但不同副本間存在更新延遲，在主副本宕機場景下有丟失更新的風險。
c) 併發更新不同副本：資料副本無主從之分，資料更新可以發生在任何副本，並且更新可以同步或非同步方式複製到其它副本。這種方式需要解決不同副本間的更新衝突，即所有存在衝突的更新應當以相同順序被寫入所有的副本。在更新衝突較少的場景下具有很好的更新效能。
d) 集中儲存更新，定期合併副本：資料副本無主從之分，所有的更新被儲存在叢集中的特定節點上，定期被合併到各個副本中。這種方式易於實現，能夠保證副本間的資料一致性，並且更新效能較好，但查詢資料時需要將更新與資料副本進行融合。
不同的原生分散式資料庫系統根據針對的應用場景不同，可以選擇其中的一種或多種實現技術，並且技術實現的細節對使用者透明。對於分散式資料庫中介軟體來說，由於其資料副本是依賴於底層資料庫的主從複製機制實現的，只可能採用技術a或者b，並且使用者需要對每個節點的主從複製進行配置和監控。
服務可用性
服務可用性是指叢集中的任何一個或多個節點宕機都不會影響資料庫服務的可用性。在分散式資料庫系統中，通常都會有管理節點和服務節點兩類角色。管理節點負責感知叢集中各節點的狀態，實現管理資料分佈和節點上下線等功能；服務節點中儲存資料分片副本，對外提供資料庫服務。可容忍宕機節點的角色和數量是影響分散式資料庫可用性的重要因素，一般來說管理節點宕機會直接影響服務可用性，而少於資料副本數量的服務節點宕機不會影響服務可用性。
在原生分散式資料庫系統中，管理節點通常是輕節點，僅需維護資料分佈等少量的元資料，通過心跳和租約機制監控叢集中其它節點的狀態。為了避免管理節點宕機造成的單點故障，原生分散式資料庫中會部署多個管理節點，然後採用Paxos協議來自動選舉主管理節點。所有服務節點是對等的，通過心跳機制與主管理節點保持通訊，少於資料副本數量的服務節點宕機不會影響服務可用性。通過向主管理節點註冊，可以方便地新增新的節點，從而實現良好的擴充套件性。 在分散式資料庫中介軟體方案中，中介軟體節點不僅需要維護資料分佈等元資料，還需要實現查詢解析、查詢重寫和結果聚合等功能，因此可以看成是包含管理節點和服務節點功能的複合節點。為了保證服務可用性，早期的中介軟體通常採用HA軟體來實現中介軟體節點的容災，但在實際使用過程中往往暴露出不夠穩定的缺點。近來，也有一些分散式資料庫中介軟體開始將管理功能和服務功能分離成單獨的管理節點和中介軟體節點，然後採用Paxos協議來自動選舉主管理節點。底層的資料庫節點雖然負責儲存資料，但並不能直接對外提供服務，必須和中介軟體節點配合才能對外提供服務。由於底層資料庫節點的容災是依賴於各自的主備同步機制，因此，任何一個數據庫節點的主備庫同時宕機都會導致整個系統的服務不可用。
綜合來看，影響分散式資料庫中介軟體解決方案服務可用性的因素要比原生分散式資料庫更多並且更復雜，需要使用者花費更多的精力去配置和管理。
跨節點訪問
將資料分片後冗餘儲存於叢集中的各個節點，是分散式資料庫實現大規模資料的可靠儲存的有效手段。然而，當用戶需要在一個事務中同時訪問位於不同節點上的資料時，如何保證事務的ACID特性成為所有解決方案的共同難題。有一些分散式資料庫中介軟體產品建議使用者對資料進行劃分，避免出現跨節點訪問資料，從一定程度上來緩解這個難題；在無法避免跨節點訪問資料時，通過最終一致性和補償機制來解決。然而，一方面這種思路大幅度增加了使用者使用的難度，另一方面，很多場景下是無法應用最終一致性和補償機制的。
目前，兩階段提交協議（2PC）是公認的解決這一難題的有效手段。2PC是一種阻塞協議，即當事務處理過程中出現協調者故障時，部分參與者的事務會處於未決狀態，影響到所涉及資料的可用性，必須等待協調者恢復後才能解決。分散式資料庫系統中2PC實現效率和故障恢復機制是影響跨節點事務效能的主要因素。對於原生分散式資料庫系統來說，在協議通訊、日誌系統和恢復演算法方面是作為一個整體進行規劃和實現的，比較容易實現一個高效的2PC機制。也有一些原生分散式資料庫產品將基線資料和增量資料分開管理，通過集中進行事務處理，以犧牲單個查詢效能的代價，有效地避免了分散式事務。對於分散式資料庫中介軟體來說，底層的節點都是獨立的資料庫系統，有各自的日誌系統和事務處理機制，只能在中介軟體節點上來實現2PC，其實現的難度相當於重寫一個數據庫引擎，所實現的效率也難以與原生資料庫相媲美。因此，雖然有部分分散式資料庫中介軟體也提供2PC的支援，但通常不建議使用者使用或者建議使用者自行解決使用過程中的未決事務。
資料快照
分散式系統中的時間同步是一個難以解決的問題。使用NTP協議或原子鐘對每個節點的時鐘進行同步，能夠滿足對時效性要求不高的應用需求，但對於毫秒級的交易系統來說，所存在的誤差仍然是不可接受的。在分散式資料庫系統中，基於各節點的時間來獲取一個全域性的資料快照是不可行的，存在著資料不一致的風險。通常的解決辦法是設定一個全域性協調者，來為所有的事務分配全域性唯一的事務號，這個事務號可以作為一個邏輯時間來使用。
對於原生分散式資料庫系統，全域性唯一事務號分配機制是整合在事務處理過程中的，並沒有額外的處理開銷。而對於分散式資料庫中介軟體來說，底層的每個資料庫節點都有自己獨立的事務處理機制，如果不設定全域性協調者來分配全域性唯一的事務號，則在不停機的狀態下使用者無法獲取統一的全域性資料快照；如果設定全域性協調者來分配事務號，一方面會增加額外申請事務號的開銷，另一方面還需要對底層資料庫節點的事務處理機制進行改造，使其必須按照事務號順序執行事務，這都會對極大地影響資料庫的效能。
小結
分散式資料庫中介軟體技術是十多年前伴隨網際網路應用的興起而發展起來的，幫助很多網際網路企業有效地解決了控制成本和應對服務壓力等問題，也誕生了很多優秀的中介軟體產品，但同時也暴露出對應用開發的侵入、功能效能受限和管理運維難度大等問題。究其原因，這類技術是在特定的歷史時期利用現有資料庫產品來解決問題的一種應用級方案，雖然其中用到了一些資料庫實現技術，但本質上並不是一個數據庫系統。原生分散式資料庫系統從誕生之初便是針對大規模資料儲存和高併發資料訪問而設計的系統級解決方案，假以時日，它一定會取代中介軟體成為這一領域的主流技術。