(文中有驚喜)走進雲時代的資料庫

最近幾年，隨著雲端計算相關技術的發展，各種不同型別的雲層出不窮，服務越來越多不同型別的企業業務，傳統企業也漸漸開始探索上雲的道路。在雲上，作為業務最核心的資料庫，相比之前的傳統方案會有哪些變化呢？

那麼雲資料庫主要有一些什麼樣的特點呢？

• 彈性伸縮

傳統的資料庫方案，常見的會選用 Oracle，MySQL，PostgreSQL。在雲時代，資料量的規模有爆發性的增長，傳統的資料庫很容易遇到單機的儲存瓶頸，不得不選用一些叢集方案，常見的比如 Oracle RAC、 MySQL Sharding 等，而這些叢集方案或多或少都有一些不令人滿意的地方。

比如說，Oracle RAC 透過共享儲存的硬體方案解決叢集問題，這種方式基本上只能透過停機換用更大的共享記憶體硬體來解決擴容問題，RAC 節點過多會帶來更多的併發問題，同樣也會帶來更高的成本。

以 MySQL Sharding 為代表的資料分片方案，很多時候不得不提前對資料量進行規劃，把擴容作為很重要的一個計劃來做，從 DBA 到運維到測試到開發人員，很早之前就要做相關的準備工作，真正擴容的時候，為了保證資料安全，經常會選擇停服務來保證沒有新的資料寫入，新的分片資料同步後還要做資料的一致性校驗。當然業界大公司有足夠雄厚的技術實力，可以採用更複雜的方案，將擴容停機時間儘量縮短（但是很難縮減到 0），但是對於大部分中小網際網路公司和傳統企業，依然無法避免較長時間的停服務。

在雲時代，理想中所有的資源都是根據使用者業務需求按需分配的，伺服器資源，應用容器資源，當然也包括資料庫資源。新增或者減少新的資料庫資源，完全就像日常吃飯那樣稀疏平常，甚至使用者基本感知不到。比如作為一個電商使用者，在雙 11 促銷活動之前，可以透過增加資料庫節點的方式，擴大更多的資源池，用來部署相應的容器服務，當活動結束之後，再將多餘的資源移除去支援其他的服務，這樣可以極大地提高資源的利用率，同樣可以彈性地支撐各種峰值業務。

• 高可用

傳統的 MySQL 方案，資料複製的時候預設採用非同步的方式，對於一個寫入的請求，主庫寫入成功後就會傳回成功資訊給客戶端，但是這個時候資料可能還沒有同步給從庫，一旦主庫這個時候掛掉了，啟動從庫的時候就會有丟失資料的風險。當然，也有人會選擇半同步的複製方式，這種方式在正常情況下是同步的，但是在遇到資料壓力比較大的時候，依然會退化為非同步的方式，所以本質上來說，同樣有丟失資料的風險。其他也有一些多主的同步方案，比如在應用層做資料同步，但是這種方式一是需要應用層的配合，二是在對網路超時的處理非常複雜，增加心智負擔。

在雲時代，因為所有的資料庫資源都是分散式儲存的，每個資料庫節點出現問題都是很正常的事情，所以就必須有一種可以實現資料一致性的資料複製方式來保證服務的高可用，業界給出的答案就是：Paxos/Raft（關於 Paxos 和 Raft 的實現細節我們不在這裡展開）。

同樣，在雲時代，資料庫的 DDL 操作也會是一個非常有趣的事情。以一個常見的 Add Column 操作為例，在表規模已經很大的情況下，在傳統的實現方案中，比較有參考意義的是，透過一些工具，建立類似表級別的觸發器，將原表的資料同步到一個新的臨時表中，當資料追平的時候，再進行一個鎖表操作，將臨時表命名為原表，這樣一個 Add Column 操作就完成了。但是在雲時代，分散式的資料儲存方式決定了這種方案很難實現，因為每個資料庫節點很難保證 Schema 狀態變更的一致性，而且當資料規模增長到幾十億，幾百億甚至更多的時候，很短的阻塞時間都有可能會導致很大的負載壓力變化，所以 DDL 操作必須是保證無阻塞的線上操作。值得欣慰的是，Google 的 F1 給我們提供了很好的實現參考，TiDB 即是根據 F1 的啟發進行的研發，感興趣的同學可以看下相關的內容。

• 易用透明

我們可以將雲資料庫想象成一個提供無限大容量的資料庫，傳統資料庫遇到單機資料儲存瓶頸的問題將不復存在。已有的程式基本上不怎麼需要修改已有的程式碼，就可以很自然地接入到雲資料庫中來獲得無限 Scale 的能力。增減資料庫節點，或者節點的故障恢復，對於應用層來說完全透明。另外，雲資料庫的監控、運維、部署、備份等等操作都可以在雲端透過高效的自動化工具來自動完成，極大地降低了運維成本。

• 多租戶

雲資料庫本身應該是可以彈性伸縮的，所以很自然的，從資源利用率的角度來考慮，多個不同使用者的資料庫服務底層會跑在一個共享的雲資料庫中。因此多租戶技術會成為雲資料庫的標配。

低成本

低成本應該是雲時代基礎設施最明顯的特點。首先，雲資料庫的高可用和容錯能力，使得我們不再需要昂貴的硬體裝置，只需要普通的 X86 伺服器就可以提供服務。然後，受益於 Docker 的虛擬化技術，使得不同型別的應用容器可以跑在同一個物理機上，這樣可以極大地提高資源的利用率。其次，多租戶的支援，使得不同的使用者可以共用一套底層的資料庫儲存系統，在資料庫層面再一次提高了資源的利用效率。再次，雲資料庫的自動化運維工具，降低了整個核心資料庫的運維成本。最後，雲資料庫資源是按需分配的，使用者完全可以根據自身的業務特點，選購合適的服務資源。

• 高吞吐

雲資料庫雖然可以做到彈性擴容，但是本身是分散式儲存的，雖然可以透過 Batch Write、Pipeline 和 Router Cache 等方式加快訪問 SQL 請求的資料，但是相對傳統單機的資料庫來說，在資料訪問鏈路上至少也要多走一次網路，所以大部分併發量不大的小資料量請求，都會比單機延遲要高一些。也就是說，當沒有足夠高的併發 SQL 訪問的話，其實不能完全體現雲資料庫的效能優勢，所以這也是我們在選用雲資料庫的時候需要認識到的問題，雲資料庫更多的是追求高吞吐，而不是低延遲。當併發大到一定規模，雲資料庫高吞吐特性就顯現出來了，即使在很高的併發下，依然可以維持相當穩定的延遲，而不會像單機資料庫那樣，延遲線性增長。當然，延遲的問題，在合理的架構設計方案下，可以透過快取的方式得到極大的緩解。

• 資料安全

雲資料庫的物理伺服器分佈在多個機房，這就為跨資料庫中心的資料安全提供了最基礎的硬體支援。談到金融業務，大家耳熟能詳的可能就是兩地三中心，比如北京有兩個機房，上海有一個。未來一切服務都跑在雲上，金融類的業務當然也不例外。相比其他業務，金融類業務對資料安全要求就要高得多。當然，每個公司內部都有核心的業務，所以如果上雲的話，也會有同樣的強烈需要。這樣，對雲資料庫來說，資料的一致性、分散式事務、跨資料中心的資料安全等更高階的需求有可能會日益強烈。常見的資料備份也有可能會被其他新的樣式所取代或者弱化，比如基於 Paxos/Raft 的多副本方案，本身就保證了會有多份備份。

• 自動負載平衡

對於雲資料庫來說，負載平衡是一個很重要的問題，它直接決定了整個雲資料庫系統效能的好壞，如果一個資料庫節點的資料訪問過熱的話，就需要考慮把資料遷移到其他的資料庫節點來分擔負載，不然就很容易出現效能瓶頸。整個負載平衡是一個動態的過程，排程演演算法需要保證資源配比的最大平衡，還有保證資料遷移的過程對系統整體的負載影響最小。這在未來也是雲資料庫需要解決的一個核心問題。