第一章 前言

前面介紹的GFS 和 MapReduce 通過非常簡單的設計，幫助我們解決了海量資料的儲存、順序寫入，以及分散式批量處理的問題。

不過我們也要看到，GFS 和 MapReduce 的侷限性也很大。

在 GFS 裡，資料寫入只對順序寫入有比較弱的一致性保障。而對於資料讀取，雖然 GFS 支援隨機讀取，但是考慮到當時 Google 用的是孱弱的 5400 轉的機械硬碟，實際上是支撐不了真正的高併發地讀取的。

而 MapReduce，它也是一個批量處理資料的框架，吞吐量（throughput）確實很大，但是延時（latency）和額外開銷（overhead）也不小。

所以，即使有了 GFS 和 MapReduce，我們仍然有一個非常重要的需求沒有在大型的分散式系統上得到滿足，那就是可以高併發

本文主要通過下面三個問題，來深入理解Bigtable。

• Bigtable 想要解決什麼問題？我們不能用 MySQL 這樣的關係型資料庫，搭建一個叢集來解決嗎？
• Bigtable 的架構是怎麼樣的？它是怎麼來解決可用性、一致性以及容易運維這三個目標的？
• Bigtable 的底層資料結構是怎麼樣的？它是通過什麼樣的方式在機械硬碟上做到高併發地隨機讀寫呢？

第二章 Bigtable的設計目標

Bigtable想要解決的問題是系統的可伸縮性和可運營性。

Bigtable最基礎的目標自然是應對業務需求的，能夠支撐百萬級別隨機讀寫 IOPS（input/Output Operations Per Second，即每秒進行讀寫(I/O)操作的次數），並且伸縮到上千臺伺服器的一個數據庫。但是光能撐起 IOPS 還不夠。在這個資料量下，整個系統的“可伸縮性”和“可運維性”就變得非常重要。

這裡的伸縮性，包括兩點：

• 第一個，是可以隨時加減伺服器，並且對新增減少伺服器數量的限制要小，能夠做到忙的時候加幾臺伺服器，過幾個小時峰值過去了，就可以把伺服器降下來。
• 第二個，是資料的分片會自動根據負載調整。某一個分片寫入的資料多了，能夠自動拆成多個分片來平衡負載。而如果負載大了，添加了伺服器之後，也能很快平衡資料，讓各個節點均勻承擔壓力。

而可運維性，則除了上面的兩點之外，小部分節點的故障，不應該影響整個叢集的執行，我們的運維人員也不用急匆匆地立刻去恢復。叢集自身也要有很強的容錯能力，能夠把對應的請求和服務，排程到其他節點去。

至於為什麼不能使用MySQL來搭建叢集？

MySQL如果要擴充套件成分散式的，需要分庫分表，這需要一開始就對如何切分資料做好精心設計，一旦稍有不慎，設計上出現了資料傾斜，就很容易造成伺服器忙得忙死，閒得閒死的現象。並且即使你已經考慮得非常仔細了，隨著業務本身的變化，比如要搞個雙十一，也會把你一朝打回原形。

以 MySQL 使用者表分表作為例子，分到 4 臺機器上，用了使用者出生的月份“模”上個 4。這個時候，很幸運，一年是有 12 個月，正好可以均勻分佈到 4 臺不同的機器上。但是當我們進行擴容，變成 8 臺機器之後，問題就出現了。我們會發現，伺服器 A 分到了 1 月和 9 月生日的使用者，而伺服器 B 只分到了 6 月生日的使用者。在擴容之後，伺服器 A 無論是資料量，還是日常讀寫的負載，都比伺服器 B 要高上一倍。而我們只能按照伺服器 A 的負載要求來採購硬體，這也就意味著，伺服器 B 的硬體效能很多都被浪費了。

而且，不但用月份不行，用年份和日也不行。比如公司是 2018 年成立，2019 年和 2020 年快速成長，每年訂單數漲 10 倍，如果你用年份來進行訂單的分片，那麼伺服器之間的負載就要差上十倍。而用日的話，雙十一這樣的大促也會讓你猝不及防。

第三章 Bigtable的整體架構

-------------------------------------------

個性簽名：罔談彼短，靡持己長。做一個謙遜愛學的人！

本站使用「署名 4.0 國際」創作共享協議，轉載請在文章明顯位置註明作者及出處。鑑於博主處於考研複習期間，有什麼問題請在評論區中提出，博主儘可能當天回覆，加微信好友請註明原因