解耦事務：在抖動的SQL伺服器上實現低尾延遲線上事務 (CIDR 2022)

banq發表於2022-01-30
解耦SQL伺服器

這是Pat Helland 的論文：Pat Helland 的 CIDR22 論文，Pat的論文總是非凡的、與眾不同的。他們有很多智慧。
 

問題和範圍
抖動是指最大延遲與最小延遲的時間差，如最大延遲是20毫秒，最小延遲為5毫秒，那麼網路抖動就是15毫秒，它主要標識一個網路的穩定性。
Jittery抖動指的是網路中的機率響應時間、訊息延遲。在大資料處理系統中，很容易透過重試等零碎方式來解決抖動問題，事實上這在MapReduce的論文中已經提出。
但同樣的方法並不適用於資料庫，我們無法實現同樣的冪等性要求，資料庫本質應該是事務性的。

這篇論文提出了一個假設性的設計（意味著這並沒有實現）。該設計探討了在執行於雲資料中心的資料庫系統中抑制應用程式可見抖動的技術，在該資料中心中，大多數伺服器都是響應式的。本文的目標不是定義一個超級可擴充套件的SQL系統，而是在一個基本不可預測的環境中執行時，以可預測的響應時間擴充套件到幾十臺伺服器。

該設計將問題進一步限制為使用快照隔離的事務。只要沒有衝突的更新，並且每個事務只看到快照讀取，快照隔離的事務就可以對資料庫做獨立的修改。那麼問題就來了，這兩件事能不能在不耽誤抖動的伺服器的情況下完成？
 
在分散式系統中，quorums仲裁已經提供了答案。如果除了最近的資料外，所有的資料都儲存在雲端的共享儲存中，並且我們可以在沒有抖動的情況下讀取這些資料（多虧了quorums），而這已經解決了快照隔離的無抖動快照讀取方面的問題。
 

解決方案 

解耦事務：在抖動的SQL伺服器上實現低尾延遲線上事務 (CIDR 2022)
在此架構中，五種不同型別的伺服器執行不同的工作。（這對我來說太過分了，我將在介紹這些之後討論這個問題。）工作是透過生成新的記錄版本和讀取正確的記錄版本來進行快照讀取的。

  • 工作伺服器WorkerServer是資料庫伺服器。SQL 請求中的傳入 DB 連線饋送。執行、讀取和更新發生在工作伺服器中。工作Worker在共享儲存中記錄自己的日誌。
  • 協調器伺服器Coordinator有助於避免在事務提交時發生衝突更新，並幫助定位快照讀取的最新更改。
  • 資料儲存伺服器Shared Data Storage儲存帶有資料庫資料的資料檔案的副本。
  • 日誌儲存伺服器Shared Log Storage儲存用於附加到日誌的日誌副本。
  • Storage Catalog隨著資料的老化，它會遷移到共享儲存中的鍵值儲存，該儲存是作為 LSM（日誌結構化合並系統）實現的。目錄將鍵範圍對映到儲存的資料及其在共享儲存中的位置。目錄伺服器跟蹤工作人員worker、日誌儲存和資料儲存的後設資料。他們管理工作人員worker的日誌範圍和副本。

在這種分離的事務資料庫架構中，每個記錄更新都會建立一個新的記錄版本，該記錄版本位於較早的記錄版本之上，並且對具有較晚快照時間的事務可見。早於幾分鐘左右的記錄版本位於共享儲存中，並且對資料庫中的所有資料庫伺服器可見。在執行建立它們的事務的工作人員中可以找到最近的記錄版本。快照讀取語義是透過讀取在讀取器快照時間之前提交的最新記錄版本來提供的。
在每筆事務開始時從協調員那裡獲得最近更新的行蹤。每個行蹤條目都描述了工作伺服器最近可能進行的更新。協調員提供指導以在工作伺服器中定位最近的記錄版本。
表是透過連線表的 Table-ID 為每行建立具有唯一主鍵的記錄版本來實現的，並且 SQL 定義的唯一主鍵包括一組有序的表列。描述了為快照查詢記錄版本，但我無法清楚地瞭解這是如何工作的，因為第 2.3 節到第 2.7 節並不容易理解。
 

該論文確定了該架構中的許多抖動風險。
  • 風險 #1：worker到協調員
  • 風險#2：worker追加到他們的日誌
  • 風險#3：worker閱讀資料檔案
  • 風險#4：worker到Catalog
  • 風險 #5：向其他worker詢問最近的記錄版本
  • 風險 #6：閱讀慢的worker的日誌以避開它。如果worker無法響應其最近的更新，我們會檢視其日誌。這也有我們必須避免的抖動風險。

解決方案？
仲裁每個元件的。
點選標題原文中有更新的圖表。請注意，協調器、目錄和日誌儲存子系統都是仲裁的。
 

關於架構的討論
worker是水平擴充套件計算的好主意。協調者（coordinator quorum）是管理交易糾紛的好主意。

我不喜歡擁有單獨的資料儲存伺服器、日誌儲存伺服器和目錄伺服器？
最近資料與舊資料的雙重性質使設計不必要地複雜化。最近的資料是在worker中，worker從協調員那裡learn，並在需要時與其他worker交談以獲得這些資料？這種worker對worker的通訊是瓶頸的來源，也是由於worker不可用而導致的大抖動風險。（本文試圖解決這個問題，但我不相信這些論點，並將在最後討論原因。）

為什麼不直接使用作為分散式鍵值儲存實現的learn伺服器，我們可以對它進行分割槽（透過分散式雜湊表）以進行水平擴充套件。這將顯著簡化架構。只需放置一個持久的分散式日誌。（Delos 工作只是一個例子。請注意，它也是透過 loglet 級別的 quorums 實現的。）

日誌方法的另一個優點是它在閱讀方面更具可擴充套件性。法定人數讀取不會擴充套件。從節點的多數（如果您將仲裁定義為大多數工作中的多數）讀取節點會保持每個節點上的負載。
您可以透過將分片劃分得更小來克服這個限制，但這也很麻煩並且有成本。
相反，日誌方法在這裡有所幫助，您可以從一個節點讀取並更好地擴充套件讀取,許多系統使用這種方法。
.....
 

相關文章