Pinterest 工程團隊的部落格文章“Pinterest 棄用 HBase”概述了 Pinterest 棄用分散式 NoSQL 資料庫 Apache HBase 並遷移到開源分散式 SQL 資料庫 TiDB 的歷程。
為何棄用 HBase
- 維護成本高:由於歷史原因,我們的 HBase 版本落後上游五年,缺少關鍵的錯誤修復和改進。
- 缺少功能
- 系統複雜度高:我們在 HBase 和Manas realtime之上構建了[url=https://medium.com/pinterest-engineering/building-scalable-near-real-time-indexing-on-hbase-7b5eeb411888]Ixia ,以支援 HBase 中的全域性二級索引。我們還在[/url]Apache Phoenix Omid之上構建了 Sparrow,以支援 HBase 上的分散式事務。雖然當時我們沒有更好的替代方案來滿足業務需求,但這些系統產生了巨大的開發成本並增加了維護負擔。
- 基礎設施成本高:生產 HBase 叢集通常使用具有六個資料副本的主備用設定以實現快速災難恢復,但在我們的規模下,這會帶來極高的基礎設施成本。將 HBase 遷移到其他每個唯一資料副本成本較低的資料儲存將帶來巨大的基礎設施節省機會。例如,透過謹慎的複製和放置機制,TiDB、Rockstore 或 MySQL 可以使用三個副本,而不會在可用性 SLA 上做出太大犧牲。
- 行業使用和社群支援的減弱:過去幾年,我們看到行業內 HBase 的使用率和社群活動似乎穩步下降,因為許多同行公司都在尋找更好的替代方案來替代其生產環境中的 HBase。這反過來又導致人才庫萎縮、進入門檻提高,新工程師成為 HBase 主題專家的動力降低。
為了滿足其餘的 HBase 使用情況,我們需要一種新技術,它既能提供像 NoSQL 資料庫一樣的出色可擴充套件性,又能支援像傳統 RDBMS 一樣強大的查詢功能和 ACID 語義。我們最終選擇了TiDB,這是一種滿足我們大部分要求的分散式 NewSQL 資料庫。
關鍵點
- Pinterest 於 2012 年採用 HBase 來儲存和提供其核心產品 Pins 的後設資料。然而,隨著 Pinterest 的規模和需求的增長,HBase 在效能、可操作性和可維護性等方面面臨挑戰。
- 在評估了各種替代方案後,Pinterest 選擇了 PingCAP 開發的雲原生分散式 SQL 資料庫 TiDB 作為 HBase 的替代品。
- 從 HBase 遷移到 TiDB 涉及多個階段,包括資料遷移、應用程式更改和基礎架構更新。Pinterest 開發了工具和流程以確保順利過渡。
- TiDB 的雲原生架構、水平可擴充套件性和 SQL 介面為 Pinterest 提供了比 HBase 更好的效能、更簡單的維護和更大的靈活性。
- 成功遷移到 TiDB 使 Pinterest 能夠更好地支援其不斷增長的業務需求,併為其使用者提供更可靠、更高效的服務。
這篇博文詳細介紹了 Pinterest 的決策過程、面臨的挑戰以及採用 TiDB 替代 HBase 所實現的好處。它強調了選擇正確的技術堆疊來支援公司不斷變化的需求的重要性,以及 TiDB 等開源解決方案在實現可擴充套件性和創新方面的價值。