為什麼要選擇分散式資料庫？

這些年，由於資料規模和業務訪問負載越來越大，越來越多的公司無法依賴單臺資料庫伺服器支撐其業務，越來越多的公司不得不做資料分割槽儲存，也就是所謂的分庫分表，但大量的煩惱與困惑也隨之而來。

• 令人“頭都大了”的分庫分表中介軟體

10多年前阿里因此原因不得不把淘寶後臺系統從Oracle RAC切換到數百個 MySQL叢集構成的分庫分表叢集，不過那時的淘寶僅僅使用一個分庫分表中介軟體，名為tddl（又名：頭都大了，江湖上現在還有tddl的傳說），而不是分散式資料庫，這兩者之間的區別，也可能正是tddl讓淘寶後臺業務開發者“頭都大了”的原因。

具體來說，諸如tddl，mysql_proxy，mysql_router，mycat等資料行路由中介軟體的問題在於：

 

01 它們不支援完備的分散式查詢處理

使用者程式發給這些中介軟體的合法的SQL語句，只要涉及一些高階SQL功能，比如多表連線，子查詢，CTE，window function，aggregation等，都無法正確執行；這導致大量SQL生態下的工具，比如低程式碼工具，OR對映中介軟體，機器學習演算法等各種資料分析工具和演算法 都無法與這些中介軟體互動和協作。

應用軟體程式設計師需要在業務程式碼中，分別到目標資料所在的儲存叢集查詢資料片段，然後在業務程式碼中組裝出最終結果。這些操作就是在應用層針對一個特定的SQL語句做了一次查詢處理和執行。

這個工作本來可以直接傳送SQL語句給分散式資料庫就得到結果的，但是沒有分散式資料庫就只能針對每一個SQL語句做一次類似的查詢處理實現，工作量自然非常巨大。特別是，這樣的查詢處理程式碼還可能因為業務邏輯的需求的變化和迭代而需要反覆修改，這個開發工作量比直接修改SQL語句要大而且複雜太多了。

02 它們不支援可靠容災的分散式事務處理

應用程式設計師大多並沒有意識到分散式事務不做兩階段提交到底會有什麼業務風險，處於“不知不覺”狀態；少數應用程式設計師想到了這個潛在風險，但是無法解決，於是得過且過。

只有極少數程式設計師認識到了問題並且能夠解決，但也只能case by case地解決，比如為了實現可靠的轉賬功能，需要設計出一套技術在業務層實現轉賬場景的容災能力。遇到其它場景又需要重新設計和實現一套演算法。

因此開發技術門檻和工作量陡增。儘管有些中介軟體使用了mysql的XA功能做兩階段提交，但是無法可靠地保障在節點當機/斷網/超時等異常情況發生時確保使用者資料的一致性（ACID）等屬性。

上述一個共同的問題是，應用軟體開發者需要知道他的每一個表到底儲存在哪個儲存叢集中，才能做出正確的資料管理和查詢功能，這讓資料管理與業務邏輯產生了進一步的繫結，是一個巨大的問題。

03 它們無法做到自動水平彈性擴容

擴容需要DBA手動完成，需要暫停服務一段時間（比如若干個小時），停服會嚴重影響業務持續性和使用者體驗。

• 石器時代的應用分庫分表

業界還有一種更加原始的方法來解決資料儲存規模和訪問負載過大的問題——應用層資料分割槽。這種做法之所以更加原始，是因為它除了具有所有上述令人“頭都大了”的問題之外，還有以下一系列嚴重的問題，以至於我們可以說這些公司的產品和服務還處於石器時代。令人吃驚的是，這樣的石器時代的公司還不在少數。

應用層分表的獨有問題包括：

01 分表邏輯硬編碼

這樣要針對每一個表都做相似的功能實現，開發負擔和複雜性很高。特別是如果多個應用軟體/web服務需要使用同一套資料表的話（這是常見情況），還需要保持所有這些程式對每一個表的分表規則相同，開發工作量和複雜性將指數上升而不僅僅是線性成倍上升。 

即使做的聰明一些像上述頭都大了的中介軟體那樣使用配置檔案，也仍然有問題——需要實現分表邏輯，仍然大大增加了業務開發工作量。並且到最後你就實現了一個平庸的中介軟體。之所以說它平庸是因為只有你們公司/團隊在用，並且可能只適用於你們的特定業務場景。這又讓資料管理與應用邏輯進一步緊密繫結和依賴，是非常拙劣的系統設計。

02 水平擴容比“頭都大了”更加困難

在分庫分表邏輯硬編碼的情況下，彈性擴容幾乎無法完成，因為你需要修改業務程式碼實現新的資料分割槽規則才能擴容，那簡直是開發人員和DBA的噩夢。

所以，我們決定研發一款真正的分散式資料庫產品，把上述“頭都大了”的使用者和處於“石器時代”的使用者徹底解救出來，讓他們來到現在這個科技時代，感受到前沿的現代科技的魅力。

從此，他們將不再絞盡腦汁設計和實現分散式資料管理和查詢程式，只要簡單地傳送SQL語句即可發起和提交分散式事務，以及執行分散式查詢並直接得到查詢結果。

這樣就真正把資料管理重新與應用軟體隔離開來，把資料管理從應用邏輯中抽象出來——這正是50年前資料庫理論和技術先驅們的初心，也是他們用無數人/月和美金換來的教訓：

用獨立的資料庫系統做資料管理，把應用軟體開發與通用的資料管理邏輯分離開來，達到最大程度地軟體複用和應用研發簡單化，大大提升開發者的工作效率和其業務邏輯與產品的可靠性，降低使用者業務系統的技術門檻並大大提升其可靠性，降低公司開發成本，保障其線上業務系統的上線時間可控可預期。

• 三、崑崙分散式資料庫的技術特點

崑崙分散式資料庫是一款高效能NewSQL OLTP 分散式資料庫。我們的核心目標是解決使用者的海量資料儲存管理和利用面臨的問題。

面向新技術時代海量資料管理和利用的全方位新需求，透過水平彈性擴容，資料自動分割槽，分散式事務處理和分散式查詢處理，容災，高可用，強一致等核心關鍵特性，讓各行業應用軟體開發者聚焦應用邏輯開發，完全不需要承擔資料管理功能實現，大大提升開發者的工作效率和其業務邏輯與產品的可靠性，降低使用者業務系統的技術門檻並大大提升其可靠性，降低公司開發成本，保障其線上業務系統的上線時間可控可預期。

點選閱讀原文

推薦閱讀

專案已全部開源

【GitHub：】

【Gitee：】

-END-