評價分散式事務資料庫的5個標準

1.為什麼分散式資料庫不是銀彈？
沒有任何一種技術可以成為你所有問題的靈丹妙藥，資料庫領域也不例外。如果你的資料可以用一個MySQL例項解決，而不會對伺服器造成太大壓力，或者對複雜查詢的效能要求不高，那麼分散式資料庫可能不是一個好的選擇。選擇使用分散式資料庫通常意味著額外的維護成本，這對於小型工作負載來說可能是不值得的。如果你需要針對小型工作負載的高可用性（HA），則使用MySQL的主從複製模型及其GTID解決方案可能足以完成工作。如果還不夠，你可以使用組複製擴充套件它。由於MySQL社群非常活躍，因此Google一下幾乎可以解決任何問題並找到解決方案。簡而言之，如果單個例項資料庫足夠，請堅持使用MySQL。當我們第一次開始構建TiDB與MySQL相容時，我們的目標永遠不是取代MySQL，而是解決單例項資料庫本身無法解決的問題。

如果你的資料可以適用於單個MySQL例項而伺服器上沒有太大的壓力，那麼分散式資料庫可能不是一個好的選擇。

那麼何時適合部署像TiDB這樣的分散式系統？就像對任何難題的任何答案一樣，這取決於：我並不想給出一個通用的答案，但在決定分散式資料庫是否是正確的答案時，還有一些跡象訊號。例如：

發現自己在考慮如何複製、遷移或擴充套件資料庫以獲得額外容量？
尋找最佳化現有儲存容量的方法？
關注慢查詢效能？
研究中介軟體擴充套件解決方案或實施手動分片策略？

如果你發現自己定期詢問這些型別的問題，那麼就應該考慮像TiDB這樣的解決方案是否可以幫助你。

MySQL和TiDB不是互斥的選擇。實際上，我們花了大量的工作來幫助我們的使用者繼續使用MySQL，透過構建工具來實現從MySQL到TiDB的無縫遷移。這保留了同時使用MySQL用於單個例項工作負載的選項。

2.為什麼要將SQL與儲存分開？
有幾個原因可以解釋為什麼要將SQL與底層儲存分開。(banq注：計算和儲存分離)

（1）易於維護。我們將TiDB平臺的SQL層（無狀態，也稱為TiDB）與其儲存層分離（負責儲存稱為TiKV））以使得部署，操作和維護更簡單。這是我們的最重要的設計選擇之一。這可能看起來違反直覺（不是更多的元件使部署更復雜嗎？）。好吧，作為一個DevOps不僅僅是進行部署，而且還可以快速隔離問題，系統除錯和整體維護 - 模組化設計真正支援這些職責。例如：如果你的整個系統融合在一起而不是單獨分層，一旦你在SQL層中發現需要緊急更新的錯誤，那麼滾動更新可能非常耗時，具有破壞性，甚至存在風險。但是，如果你的SQL層是無狀態且分離的，則更新很容易，並且不會破壞系統的其他部分。

（2）更好的資源使用。模組化設計也更適合資源分配和使用。儲存和SQL處理依賴於不同型別的計算資源。儲存嚴重依賴於輸入輸出（I / O），並受硬體型別的影響，例如PCIe / NVMe / Optane SSD。SQL處理更依賴於CPU功率和RAM大小。因此，將SQL和儲存放在不同的層中有助於使整個系統更有效地使用適當型別的資源進行正確的工作。

TiDB旨在支援HTAP（混合事務和分析處理）體系結構，同時支援OLTP和OLAP工作負載以出色的效能進行處理。每種型別的工作負載都有不同的最佳化，需要不同型別的物理資源才能產生良好的效能。OLAP請求通常是長而複雜的查詢，需要大量RAM才能快速執行。OLTP請求短而快，因此必須根據OPS（每秒運算元）最佳化延遲和吞吐量。由於TiDB的SQL層是無狀態的並且與儲存分離，因此它可以透過應用其SQL解析器和基於成本的最佳化器在執行之前分析查詢，智慧地確定哪種工作負載應該使用哪種物理資源。

（3）開發靈活性和效率。使用單獨的鍵值抽象來構建低階儲存層有效地提高了整個系統的靈活性。它可以輕鬆提供水平可伸縮性 - 使用key自動分片比使用具有複雜模式和結構的表更容易實現。單獨的儲存層也為利用分散式系統中的不同計算模式開闢了新的可能性。

TiSpark是我們利用Spark的OLAP引擎，就是這樣一個例子，它利用我們的層設計，位於TiKV之上，直接從它讀取資料，而不受TiDB的任何依賴或干擾。從開發角度來看，分離允許使用多種程式語言。我們選擇Go是一種高效的語言來構建TiDB並提高我們的生產力，而Rust是一種高效能的系統語言，用於開發速度和效能至關重要的TiKV。如果整個系統沒有模組化，則不可能採用多道程式設計語言方法。我們的分層架構允許我們的SQL團隊與我們的儲存團隊並行工作，並且我們使用RPC（更具體地說是TiDB中的gRPC）來實現元件之間的通訊。

3.為什麼延遲不是首要考慮目標？
很多人問我：TiDB可以取代Redis嗎？不幸的是，因為TiDB根本不是快取服務。TiDB是一種分散式資料庫解決方案，首先支援具有強一致性，高可用性和水平可伸縮性的分散式事務，其中資料在多臺計算機（或多個資料中心）上持久化和複製。簡而言之，TiDB的目標是成為每個系統的“真相之源”。但是為了使所有這些功能在分散式系統中發生，一些與延遲有關的權衡是不可避免的（相反，任何爭論都在藐視物理學）。因此，如果你的生產場景需要非常低的延遲，比如說不到1毫秒，那麼你應該使用像Redis這樣的快取解決方案！實際上，我們的許多客戶都在TiDB之上使用Redis，因此他們可以結合可靠的“真相之源”實現低延遲。

相對延遲指標，對分散式資料庫的更有意義的測量標準是吞吐量。如果系統的吞吐量隨著新增到系統的機器數量（更多機器，更多吞吐量）線性增加，而延遲保持穩定，那麼這是一個強大的分散式資料庫的真實標誌。我們的一些生產使用者已經在TiDB叢集上每秒處理多達100萬個查詢; 在單臺機器上幾乎不可能達到這種吞吐量水平。

我們在PingCAP中有一句話，“在快速行動之前做好準備。”正確性，一致性和可靠性總是勝過速度。沒有它們，低延遲有什麼用呢？

4.基於範圍(Range-Based)的分片是否優於基於雜湊的分片？
我們在TiKV中實現了基於範圍的分片而不是基於雜湊雜湊，因為我們的目標從一開始就是支援功能齊全的關聯式資料庫，關聯式資料庫必須支援各種型別的掃描操作，如表掃描，索引掃描等，儘管基於範圍的分片更難構建，但基於雜湊的分片無法按順序維護指定表的資料，因此即使在基於雜湊的設定中的幾行上進行小掃描也可能意味著在多個分片之間跳轉節點伺服器。基於範圍的分片則不會出現此問題。

當然，這並不意味著基於範圍的分片不具有自己的權衡。例如，如果你的查詢模式主要是順序寫入，其中寫入操作遠遠超過非更新或非刪除的讀取（如日誌），則可能形成熱點。對於這種情況，我們計劃使用分割槽表作為解決方案，以減輕由此寫入模式引起的系統壓力（這是我們2018年的路線圖））。另一種難以解決的情況是，如果你的請求模式包含恰好位於同一Raft區域的小型表上的頻繁讀/寫。現在，每個TiKV Raft區域按順序鍵值對分割，預設為96MB。如果頻繁讀/寫的一個小表大小小於96MB，則無疑會形成熱點，唯一的解決方案（到目前為止）是將該區域手動拆分為兩個並在不同節點上重新分配它們。這個“修復”不會解決熱點問題，但只是透過縮小熱點來緩解它。這是分散式資料庫不適合解決的問題，因此如果你有這種型別的請求模式，我們建議你使用記憶體快取層，如Redis，或者將這個小表直接放在你的應用程式中層。

5.為什麼可伸縮性對業務如此重要？
當一家公司開始規模較小時，任何資料庫和基礎設施都可以執行，但當該公司開始出現爆炸性（通常是意外的）增長時，你選擇的基礎架構技術就會非常重要。根據你的業務需求做出正確的選擇，可以輕鬆地向任一方向擴充套件，這可能意味著你公司的生死存亡。

我們都記得Twitter臭名昭著的“ 失敗的鯨魚fail whale ”，因為這項服務不僅因使用者增長而不斷下降，而且基礎設施也很糟糕。當你的資料庫成為瓶頸時，解決方案不是手動對錶進行分片，犧牲關係功能，製作同一個表的一堆副本，並沖洗並重復這個惡性迴圈。正確（且最具成本效益）的方法是使用可彈性擴充套件的分散式資料庫，因此你所要做的就是新增新機器以增加容量。增加更多的機器可能看起來成本越來越高，但與人力資源節省的成本和在競爭環境中響應和適應所需的寶貴工程時間相比，它要便宜得多。

概要
當我們第一次開始設計和構建TiDB時，我們從我們自己的經驗和其他DBA和基礎設施工程師那裡學到了很多教訓。一個真正有用且強大的分散式資料庫應立即解決可伸縮性瓶頸並使所有“快速修復”如手動分片過時，因此應用程式開發人員可以專注於做他們最擅長的事情 - 為客戶提供服務並發展業務，而不是管理資料庫分片。

最近，我們看到我們的兩個使用者，Mobike（無人駕駛腳踏車）和轉轉（線上市場，banq注：也許就是中國的那個轉轉）就是這麼做的。這兩家公司都經歷了爆炸式增長，並且因為他們在這種增長騰飛的過程中部署了TiDB，他們的資料庫基礎設施並不是阻礙他們以這種方式發展的瓶頸。實際上，轉轉是對TiDB賭注全押，因為它知道精心打造的分散式資料庫對其未來至關重要。

5 Questions for Evaluating a Distributed Database

[該貼被banq於2018-08-16 08:45修改過]