分散式數據劃分的技術挑戰

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：日照

對於OceanBase這樣的分散式資料庫，首先要解決的問題就是數據劃分，即如何將數據分散到整個集群中。從分散式系統的角度看，數據劃分無外乎幾種方式：按照哈希分片，按照數據範圍分片，或者這兩種分片方式的組合。數據劃分的最終目的是負載均衡，儘可能充分利用集群資源。分散式系統中往往也有一個全局管控節點，真正執行負載均衡操作，將劃分後的數據分片按照一定策略分散到整個集群。

存儲劃分

對於普通的存儲系統，例如分散式文件系統，分散式Key-Value系統。數據劃分的核心在於使得每個分片不大不小。所謂不大，意味著每個分片的數據量不會特別大，也沒有訪問熱點，遷移複製單個數據分片的成本不高，從而便於根據實時負載情況執行動態均衡；所謂不小，意味著每個分片不能特別小，從而減少元數據的存儲管理開銷。大部分存儲系統的分片大小在100MB ~ 1GB之間，部分文件系統的分片大小可以達到幾十GB甚至上百GB，這是因為這些文件系統單機的硬碟容量很大（幾十TB甚至上百TB），且大部分數據分片不活躍，不怎麼需要進行負載均衡操作。

事務劃分

對於分散式資料庫，除了考慮存儲劃分，還需要考慮事務的影響。對於無共享（share-nothing）的分散式資料庫架構，往往採用JimGray提出的兩階段提交協議來實現跨機分散式事務。然而，相比單機事務，跨機事務的性能有不小的差距。其中，最大的影響莫過於兩階段事務持有鎖的時間太長，容易導致熱點行/熱點賬戶等一系列問題。對於這個問題，有兩個解決思路：一個是儘可能優化兩階段提交事務的性能和可用性，還有一個是在數據劃分時盡量使得經常一起操作的數據分布在同一台伺服器，降低跨機事務的概率。

AmazonAurora是一種存儲、計算分離的共享存儲架構，從數據劃分的角度看，Aurora的底層存儲通過分散式實現了可擴展和高可用，上面的事務層仍然採用單機模式來避免事務劃分導致的跨機事務性能問題。Oracle RAC也是一種共享存儲架構，和Amazon Aurora不同點在於，Oracle RAC的事務層通過分散式鎖、隊列和緩存協調機制來實現多機之間的事務狀態共享，從而支持多機且對使用者透明。當然，Oracle RAC事務層全局協調的網路開銷很大，因此，Oracle RAC強依賴高性能網路，例如InfiniBand。

透明性

Oracle RAC雖然對用戶透明，但是成本很高，且可擴展性受限。理想的方案成本很低，構建在普通PC伺服器組成的集群之上，通過軟體實現容錯，同時需要做到對使用者基本透明。對於分散式事務，透明性和性能看起來是矛盾的，如果需要做到對使用者透明，就會更多地引入跨機分散式事務，這裡需要做一個取捨。

阿里巴巴的業務往往包含兩類角色，用戶和客戶，用戶是互聯網服務使用者，客戶往往是商家。分散式資料庫可以支持表格組（table group）和自動分片這兩個特性。其中，表格組用來標識同一個用戶/客戶經常一起操作的多張表格，並允許這些表格自動執行哈希或者範圍分片。通過這兩個特性，大部分事務操作都在單機上執行，避免了分散式事務的開銷，且使用者學習成本較低，對業務基本透明。當然，這裡面還需要解決下面兩個性能問題：

1. 單機多表事務的性能：同一個表格組下同一個用戶所在的多張表格的分片，往往會調度到同一台伺服器，此時，需要能夠具備將兩階段提交優化到一階段的能力，如何自適應地實現這一優化比較關鍵，尤其是如何處理各種伺服器宕機等異常情況；
2. 全局索引的更新性能：雖然可以通過表格組和自動分片來使得同一個事務操作的多張主表的數據分片調度到一台伺服器，但是這裡並不包含全局索引。從理論上講，全局索引和主表的數據分布方式總是不同的，如何優化數據分片和索引分片不在一台機器、不在一個機房甚至不在一個城市的全局索引更新性能，是這裡的關鍵。

原生分散式 vs 分庫分表

國內資料庫市場上也存在大量構建在MySQL分庫分表基礎之上的分散式中間層解決方案，且號稱「分散式資料庫」。分庫分表和原生分散式資料庫看似相同，但是卻有著本質差別。分庫分表往往是建立在把複雜度暴露給使用者這一前提之上的，而原生的分散式資料庫卻為了對業務透明而做了大量的努力。舉例如下：

1. 全局一致性。分庫分表方案將同一個表格對象拆分為多個表格對象分散到多台伺服器，這就喪失了全局一致性，可能出現某台機器已經更新了表格schema，另外一台機器還沒有更新的情況，無法保證原子性。分庫分表方案也無法得到整個系統的全局統一快照。另外，分庫分表方案缺少全局索引功能，類似MySQL自增列或者Oracle Sequence這樣的全局性功能也都變了味道。
2. 可擴展性。分庫分表方案往往採用預先劃分的方式，無法做到按需劃分，也不支持靈活的數據分片方式。對於快速發展的業務，當實際容量超出預期時，將無法擴展。即使實際容量沒有超出預期，分庫分表也只能採用雙倍擴容的方案，無法根據需要線性擴展，分庫分表本身的維護成本也比較高。
3. 事務支持。很多分庫分表方案只支持單機事務，不支持跨機事務。即使支持跨機事務，往往也會在功能和異常處理上有所限制。例如，不支持複雜的DML語句; 又如，某互聯網巨頭分庫分表方案雖然支持分散式事務，但是伺服器故障時需要手工殺死正在進行的事務。
4. HTAP處理能力。大部分分庫分表方案底層基於MySQL，MySQL本身對OLAP場景支持就不好，再加上基本沒有跨機分散式執行計劃的優化能力，因此，無法處理HTAP負載，只能在業務上將數據同步到專門的數據倉庫系統，大大地增加了業務複雜度。
5. SQL功能完備性。無論是複雜SQL語句，優化器能力，存儲過程，SQL兼容性，還是schema變更操作，分庫分表方案都存在各種限制，要求使用者通過修改業務來規避各種「坑」。

OceanBase的理念是做一個可擴展、高可用、高性能、低成本且對業務透明的原生分散式商業資料庫。相比基於MySQL分庫分表的中間件解決方案，OceanBase的產品潛力和技術複雜度都要高得多，這就使得OceanBase的研發周期更長，且初期功能缺失會比較多，但隨著產品功能逐步補全，它的競爭優勢也將逐步發揮出來。

當然，一個系統最終使用何種數據分布方案，上述對比並不是唯一考量點。例如將原系統由MySQL遷到OceanBase時，如果原系統使用分庫分表方案，那麼為保證平滑遷移，OceanBase中也可以考慮使用分庫分表方案。