系統設計基礎 — 資料庫分片與複寫 (Database Sharding & Replication)

在負載均衡器 (load balancer) 單元有提到，當網站的流量變大時，我們可以透過負載均衡器，把請求分派給多個不同的伺服器。不過，當我們怎麼做，卻只有一個資料庫時，多個伺服器會同時向資料庫做操作。而資料庫本身也是硬體，硬體也有其上限，能同時處理的請求並非無限，或是能存的資料也非無限。因此，當流量大起來時，很可能單一資料庫會不堪負荷。這時候我們會需要進一步思考如何擴增我們的資料庫。

擴增資料庫有哪些方法？

如果要擴增資料庫，我們可以嘗試以下幾種可能性：

垂直擴展

白話來說就是提升硬體性質，假如本來用 8GB 的 RAM，不夠的話就升級成 16GB，再不夠的話就提升到 32GB，以此類推。同理，儲存空間不夠，那就換一個更大的存儲空間。這種方式在處理不是真的那麼大的流量，或許還堪用。但如果真的是巨量的流量，因為硬體能升級的程度有其上限，很可能再強大的硬體也不夠用。因此實務上，如果是真的很大量的流量，通常不會選這方案。

資料庫分割 (database partitioning)

如果一個資料庫裡的東西太多，導致要撈資料出來時間太長，我們可以把資料庫分割成多個小的表 (或者資料庫實例)，這樣一來在比較小的表 (或資料庫)中，要撈出資料的速度也能加快。同時因為有了多個資料庫實例，能夠容納的整體資料量也因此提升。而資料庫分割中，其中水平的分割，如果是把資料庫分割到多個資料庫實例，又會被叫資料庫切片 (database sharding)，而這也是此篇要談論的重點之一。

什麼是資料庫切片？為什麼要用它？

資料庫切片 (database sharding) 就是把資料庫切成多個，並創建多個資料庫實例，把資料分散地放在不同的資料庫中。從上面這張來自 Digital Ocean 的圖可以看到，本來一個有 A、B、C、D 四筆資料，我們切成 A 與 B 放在一個 shard，而 C 與 D 放在另一個 shard。這邊的每個 shard 都會是一個資料庫實例。

從上面這簡要的例子，我們可以推出資料庫切片的幾個好處

如果單一資料庫能同時執行的操作有限，例如某資料庫一秒鐘能處理 1000 個寫的請求，當我們切片成多個實例，那就能突破這個限制。
如果切片分的好，能進一步提升性能。舉例來說，某個航班查詢的應用程式，若把國際航班放一個 shard、國內航班放一個 shard，當今天要找國際航班時，不用從一個大的資料庫撈，而是僅需要從國際航班的 shard 撈，因為單一個 shard 的資料量比較小，這樣撈也會比較快。
更高的可用性 (availability) 避免單一實例的風險。假如今天只有一個資料庫，那麼資料庫掛了就什麼資料都沒辦法寫、沒辦法撈。但如果切片成多個，假如國際航班的資料庫掛了，起碼國內航班的還可以用，不會所有的都不能用。

資料庫切片的方法

將資料庫切成數個小的資料庫，shard key (中文會翻成片鍵)。shard key 的分法常見的有幾種，一種是按照順序，例如 0 - 10 歲的族群放一個 shard，11 - 20 歲的使用者的放一個 shard，以此累推。業務需求也是常見的分法，例如國際航班的放一個 shard，國內航班放一個 shard。或是用雜湊 (hashing) 的方式來分，好的雜湊演算法應該能均勻分布，同時雜湊是 O(1) 操作，當有了 shard key，要找到對應的 shard 也會很快。

分片完，但如何解決單點故障問題？

當我們把資料庫分片成多個小的資料庫，這時仍會遇到單點故障 (Single Point of Failure) 的問題，換句話說，如果某個資料庫掛機 (例如存有國際航班的資料庫掛了)，則該資料庫的資料就沒辦法被伺服器請求。這種問題該如何解決呢？這時我們可以透過把資料庫複製多份，放到多台不同機器來避免這問題。

Single-primary Replication

有一個是主要資料庫 (primary database)，只有該資料庫可以寫，其他資料庫則只可以讀。這個做法會遇到僅能最終一致性 (eventual consistency) 的問題，因為資料庫同步需要時間，很可能某個寫入的請求已經發生了，但因為還沒同步該資料到讀的資料庫，所以與此同時的讀取請求發生時，可能不是讀到最新的資料，而是要等到同步後才會是最新的。在某些應用程式這沒問題，例如 Facebook 別人的留言，你過幾秒後才看到也不會怎麼樣；但在一些需要高度精準的應用程式 (例如金融類的) 則不太適合。
除此之外，這種方法僅適合大量讀、少量寫的情境，因為讀可以被多個資料庫分散負擔，不過如果應用程式是需要支援同時多個寫的，例如直播超級盃時的聊天室，可能同時上萬人留言，這時大量同時的寫入請求，都是由該主要資料庫來承擔，這也會是有風險的。除此之外，如果主要資料庫掛機，那也會變得沒有資料庫可以寫，因為剩下的資料庫都只可以讀。這種情況該如何解決呢？

multi-primary replication

如果說只有一台主要資料庫可以寫，同樣會有單點故障的可能，那或許我們可以讓能夠寫的資料庫變成多台。這個概念又稱作 multi-primary replication。
然而這種方法會遇到，如果有同時多個寫入，如何同步資料庫的問題。以及跨資料庫遇到 race condition 該如何處理的問題。