數據技術嘉年華等你來
雲時代的數據庫
最近幾年，隨着雲計算相關技術的發展，各種不同類型的雲層出不窮，服務越來越多不同類型的企業業務，傳統企業也漸漸開始探索上雲的道路。在雲上，作爲業務最核心的數據庫，相比之前的傳統方案會有哪些變化呢？
那麼雲數據庫主要有一些什麼樣的特點呢？
- 彈性伸縮
傳統的數據庫方案，常見的會選用 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 的多副本方案，本身就保證了會有多份備份。
- 自動負載平衡
對於雲數據庫來說，負載平衡是一個很重要的問題，它直接決定了整個雲數據庫系統性能的好壞，如果一個數據庫節點的數據訪問過熱的話，就需要考慮把數據遷移到其他的數據庫節點來分擔負載，不然就很容易出現性能瓶頸。整個負載平衡是一個動態的過程，調度算法需要保證資源配比的最大平衡，還有保證數據遷移的過程對系統整體的負載影響最小。這在未來也是雲數據庫需要解決的一個核心問題。