分散式 SQL 資料庫與表格最佳化技術

來源：小技術君

分散式 SQL 資料庫會將應用程式資料儲存在多個節點上，從儲存和計算的角度提高了可擴充套件性。這種分佈意味著某些應用程式請求，包括 JOIN 操作和聚合，可能跨多個資料庫節點，可能導致資料在網路中的傳輸。

為了減輕網路延遲對整體應用程式效能的影響，一些資料庫支援共置和交錯表格。這種最佳化技術允許將子表格記錄與其父行一起儲存。因此，在執行查詢時，某些需要查詢父子記錄的請求可能會更快，因為資料庫節點在資料傳輸過程中的負載較小。

然而，像任何最佳化技術一樣，共置和交錯表格也有其優缺點。讓我們深入瞭解這些表格型別，以更好地理解它們的好處和權衡。

定義

共置表格（Colocated Tables）和交錯表格（Interleaved Tables）是資料庫中的最佳化技術，用於改善資料儲存和查詢效能。

共置表格（Colocated Tables）

共置表格是一種最佳化方法，允許將子表格（child table）的記錄與其父表格（parent table）的行一起儲存在相同的物理位置或相鄰的位置。它透過將相關資料放置在同一節點或相近節點上來提高查詢效率，尤其對於需要頻繁進行父子表格資料關聯的查詢來說，可以減少網路傳輸和提升查詢效能。

交錯表格（Interleaved Tables）

交錯表格是共置表格的一種特殊型別。與共置表格不同的是，交錯表格會在同一物理表結構和資料庫檔案中將子行與其父行物理地相鄰儲存，而不是分開儲存。邏輯上，這些子表格和父表格仍然是不同的表格，但物理上它們的資料行被交錯儲存，這有助於更快地執行聯合查詢和減少資料查詢的次數。

總的來說，這些最佳化技術旨在提高資料庫查詢效率，減少資料傳輸，特別是針對需要頻繁進行父子表格資料關聯的查詢，透過最佳化資料儲存和組織來改善效能。

共置表格

舉個例子: 設想一個虛構公司開發電子商務應用程式，允許各種商家線上銷售商品。

該應用程式包括兩個關鍵表格，跟蹤 Customers（客戶）和他們的 Orders（訂單）（注意，顏色用於區分來自不同客戶的訂單）。

公司預計每天會有數百萬活躍客戶，並決定使用一個包含 3 個節點的分散式資料庫叢集以增強可擴充套件性和可用性。

在開發階段，資料庫均勻地分佈了所有應用程式記錄到叢集中，確保每個節點儲存了可比較量的資料並處理了類似的讀寫工作負載。

在一個架構委員會會議期間，公司決定嘗試共置表格功能，該功能允許將子表格記錄與父表格的行一起儲存。

結果，Order（子表格）與 Customer（父表格）共置，並且資料庫開始在相同節點上將訂單與其客戶記錄一起儲存。

團隊選擇了實驗表共置技術來評估一些請求的效能改進，這些請求需要在 Customer 和 Order 表格之間進行 JOIN 操作。例如，當應用程式需要計算客戶的總支出時，該請求將在特定的資料庫節點上執行。

公司確實觀察到了一些查詢的效能改進。

交錯表格

在電子商務服務的開發階段，公司探索了幾個分散式 SQL 資料庫。其中一個資料庫提供了交錯表格的支援，促使團隊也嘗試了這種表格型別。

交錯表格是共置表格的一種特定類別。與共置表格類似，交錯表格將子表格記錄與其父表格記錄一起儲存。但與經典共置表格不同，經典共置表格在物理表格結構中將子和父記錄儲存在不同的物理表格結構中，交錯表格則在同一表格結構和資料庫檔案中 物理地 將子行放置在其父行旁邊（邏輯上，Customer 和 Order 仍然是不同的表格）。

透過這種儲存級別的最佳化，公司發現了與之前經典共置表格測試的相同查詢的額外效能增加。這種增加是因為客戶及其訂單儲存在記憶體和磁碟中的同一頁面上，需要更少的查詢。

共置和交錯表格權衡

隨著時間的推移，公司接近電子商務應用程式的預生產測試階段，出現了新的挑戰。

當團隊載入一個生產級資料集並開始負載測試時，他們遇到了共置表格的第一個權衡 — 資料和負載傾斜。此外，由於新的業務需求，工程團隊遇到了這些表格特定的另一個權衡 — 選擇最佳的父表格進行共置。

資料和負載傾斜權衡

資料傾斜是指叢集中的一個節點開始儲存比其他節點顯著更多的應用程式記錄。這種不平衡通常導致負載傾斜，因為過載的節點必須處理更多的應用程式請求並處理更大的資料量。

在早期開發階段，團隊已經注意到某些客戶比其他客戶更頻繁地購物。這種客戶行為導致某些資料庫節點儲存的訂單比其他節點多。例如，第二個節點最終儲存了比第一和

第三個節點合計更多的訂單（5 > 2 + 2 = 4）。

當公司開始在使用生產級資料集的預生產環境中進行測試時，這些資料和負載傾斜問題變得更加明顯。雖然某些客戶在系統中只有幾十個訂單，但其他購物頻率更高的客戶則積累了數百甚至數千個透過應用程式處理的訂單。

這些經常購物的顧客是某些節點儲存和處理更多資料的主要原因。

據我所知，針對這種特定的資料傾斜問題沒有簡潔的解決方案。共置表格將子記錄對映到儲存父記錄的節點，並且每個父記錄一次只能對映到一個資料庫節點。

因此，為了將特定客戶的訂單分佈到多個節點，必須有多個標識該客戶的記錄。例如，透過在 Customer 主鍵 (id, bucket) 中新增 bucket ID，你可以為經常購買者建立多個記錄 — Customer (1, 1), Customer (1, 2), Customer (1, 3) 等。然後，可以將客戶的訂單新增到特定的桶中，從而允許資料庫將它們分佈到多個節點。然而，這種方法使應用程式邏輯變得更加複雜，需要決定桶的數量和每個新訂單的合適桶。

最佳父表格權衡

共置表格的第二個權衡與選擇最合適的父表格進行共置有關。

實際上，電子商務應用程式的資料庫架構要複雜得多，涵蓋了許多關係和依賴關係。

例如，儘管客戶最初打算購買一件商品，但通常會最終在購物車中有幾個產品。因此，一個訂單可能包括兩個或更多已購買的產品。

假設公司引入了 SoldProducts 表格來跟蹤所有客戶訂單中銷售的產品。類似於 Orders 表格，決定將這個新表格與 Customer 表格共置。

選擇這種共置策略是有原因的。應用程式經常需要執行請求，這些請求連線了 Customer、Order 和 SoldProduct 表格的資料。例如 — 客戶在最近一個月內購買了什麼產品？

因此，訂單和已售產品的記錄現在都與保持其客戶記錄的資料庫節點一起儲存。

然而，在預生產測試的中途，來自業務團隊的新要求出現了。他們的目標是優先考慮一個專門用於商家和公司物流以及業務增長部門的微服務。該服務旨在使商家和公司能夠跟蹤和預測各種產品的需求和可用性。透過實施此功能，公司可以透過向具有相似喜好的客戶推薦熱門產品來提高銷售，而商家則可以主動補充產品。

工程團隊決定將表 Product（子表格）記錄與 Merchant 表格（父表格）的行共置。

然而，從效能的角度來看，這種方法證明是不夠的，因為許多查詢需要連線 Merchant、Product 和 SoldProduct 表格的資料。這樣一個查詢的示例是 — 最近 12 小時內購買的最熱門產品是什麼？

從技術上講，將已售產品記錄儲存在相應的商家附近是可行的。但有一個複雜問題 — SoldProduct 記錄已經與 Customer 表格共置，以滿足另一個微服務的要求。

這是最佳父表格權衡的一個例子。例如，SoldProducts 表格一次只能與一個父表格共置。確定哪種共置策略從長遠來看是最好的通常是一項困難的任務。

總結

像每一種最佳化技術一樣，表共置和交錯都有其優點和權衡。要確保共置不是你的用例的過早最佳化，首先在沒有共置的情況下執行應用程式工作負載。檢查查詢執行計劃，並應用避免需要共置表格的最佳化。有時，你只需要建立適當的索引，為 JOIN 操作啟用批處理，為頁面緩衝區提供更多記憶體等 — 在看到執行計劃之前你永遠不會知道。但是，如果什麼都不起作用，那麼考慮共置表格，確保它們的權衡不會對長期產生不良影響。