資料函式庫分片技術與ProxySQL應用

– 11 分鐘閱讀

隨著資料函式庫寫入流量的增長，單一資料函式庫伺服器或叢集的效能瓶頸日益凸顯。分片技術，透過將資料分散到多個資料函式庫例項，有效提升整體寫入效能和系統擴充套件性。選擇合適的分片鍵至關重要，需考量查詢模式和資料分佈，避免跨分片查詢的效能損耗。除了分片技術，Vitess 和 ProxySQL 等工具也提供強大的資料函式倉管理和擴充套件能力。Vitess 以其獨特的架構和元件，實作 MySQL 資料函式庫的高效擴充套件和高用性，而 ProxySQL 則作為輕量級的資料函式庫代理層，簡化分片路由和連線管理，提升資料庫存取效能。兩種工具各有優勢，可根據實際需求選擇合適的解決方案。

資料函式庫寫入擴充套件：分片技術的應用

當最佳化查詢和佇列寫入仍無法應對不斷增長的寫入流量時，分片（Sharding）便成為了下一個可行的解決方案。分片技術透過將資料分散到不同的小型資料函式庫叢集，實作了在多個主機上同時執行更多寫入操作，從而有效地提升了系統的整體寫入效能。

分片技術的兩種主要形式

  1. 功能性分割（Functional Partitioning）：這種方法涉及將不同的節點專用於執行不同的任務。例如，將使用者記錄儲存在一個叢集中，而將其帳單資訊儲存在另一個叢集。這種方法允許每個叢集根據其負載需求獨立擴充套件。例如，使用者註冊量的激增可能會對使用者叢集造成壓力，但由於帳單系統是獨立的，因此可以繼續為客戶提供帳單服務，而不會受到使用者註冊過程的影響。

  2. 資料分片（Data Sharding）：這是目前大型MySQL應用程式中最常見且成功的擴充套件方法。資料分片涉及將資料分割成較小的片段（稱為分片），並將這些分片儲存在不同的節點上。大多數應用程式只對需要擴充套件的資料進行分片，通常是那些會快速增長的資料集。例如，在一個部落格服務中，如果預期會有大量使用者，那麼使用者生成的內容（如文章和評論）很可能需要進行分片，因為這些記錄不僅數量龐大，而且所佔用的儲存空間也較大。

選擇合適的分片方案

在實施分片時，最重要的挑戰是如何高效地查詢和檢索資料。這取決於如何對資料進行分片。選擇一個適當的分割槽鍵（Partitioning Key） 至關重要。分割槽鍵決定了哪些資料應該儲存在特定的分片上，並且能夠幫助快速定位所需的資料。

分割槽鍵的選擇原則

  • 應該盡量使最重要和最頻繁的查詢只接觸盡可能少數的分片。
  • 避免跨分片的查詢，因為這會增加應用層的複雜度，並削弱分片帶來的效益。
  • 一個好的分割槽鍵通常是資料函式庫中某個非常重要的實體的主鍵。

使用Plantuml圖表示範實體關係圖

此圖示展示了使用者、文章和評論之間的關係。在這個例子中，使用者與文章和評論之間存在一對多的關係，而文章與評論之間也存在一對多的關係。透過視覺化這些關係，可以更容易地找出適合的分割槽鍵。

分割槽鍵的選擇考量

在選擇分割槽鍵時，不僅要考慮到資料的增長速度，還要考慮到經常一起被查詢的資料。如果某些較小的表格經常與某個特定的分割槽鍵相關聯，那麼將這些表格一起進行分片是有意義的，這樣可以避免跨資料函式庫的連線查詢。

內容解密：
  1. 功能性分割與資料分片：功能性分割是根據不同的任務將資料儲存在不同的叢集，而資料分片則是將資料分割成小片段儲存在不同節點。
  2. 選擇合適的分割槽鍵：選擇正確的分割槽鍵可以確保查詢只接觸少數分片，避免跨分片查詢帶來的複雜度和效能損失。
  3. 實體關係圖的應用：透過視覺化實體關係圖，可以更容易地找出適合的分割槽鍵，最佳化分片策略。
  4. 綜合考慮查詢模式：在設計分片方案時，不僅要考慮資料的增長速度，還要綜合考慮經常一起被查詢的資料，以最佳化查詢效能。

資料分片（Sharding）與擴充套件寫入效能

資料分片是擴充套件資料函式庫寫入效能的重要技術，透過將資料分散到多個伺服器或叢集，達到提升整體系統處理能力的目的。選擇適當的分片鍵（Partitioning Key）是成功的關鍵。

資料模型的難易度分析

資料模型的可分片性取決於實體關係圖（Entity-Relationship Graph）中的連執行緒度。圖 11-2 展示了兩種不同的資料模型，左側的模型易於分片，而右側的模型則較為困難。

此圖示

內容解密：

此圖示展示了一個易於分片的資料模型。使用者、訂單、訂單明細和產品之間的關係清晰，方便進行資料分割。主要特點包括：

  1. 多個子圖（Subgraph）之間連線較少
  2. 可以輕易地在子圖之間進行「切割」
  3. 各個實體之間的關聯性適中

選擇適當的分片鍵

選擇分片鍵時，應盡量避免跨分片查詢，同時確保每個分片的資料量相對均勻。例如，若應用程式僅服務於美國地區，可以考慮按縣或電話區號進行分片，而不是按州，因為加州的人口遠高於其他州。

分片策略程式碼範例

def shard_data(user_id, num_shards):
    # 簡單的分片範例：根據使用者ID進行分片
    shard_index = user_id % num_shards
    return shard_index

# 使用範例
num_shards = 20
user_id = 12345
shard_index = shard_data(user_id, num_shards)
print(f"使用者 {user_id} 應存放於分片 {shard_index}")

內容解密：

  1. 此程式碼展示瞭如何根據使用者ID進行簡單的分片
  2. shard_data 函式計算使用者ID對應的分片索引
  3. num_shards 變數控制總共的分片數量
  4. 分片索引的計算使用了取餘運算（%），確保結果落在0到num_shards-1之間

多重分片鍵的考量

複雜的資料模型可能需要多個分片鍵。例如，在一個部落格應用程式中，可能需要同時按使用者ID和文章ID進行分片，以便高效地檢索使用者的所有文章和某篇文章的所有評論。

多重分片策略

class ShardingStrategy:
    def __init__(self, num_shards):
        self.num_shards = num_shards

    def shard_by_user(self, user_id):
        return user_id % self.num_shards

    def shard_by_post(self, post_id):
        return post_id % self.num_shards

# 使用範例
strategy = ShardingStrategy(num_shards=20)
user_shard = strategy.shard_by_user(12345)
post_shard = strategy.shard_by_post(67890)
print(f"使用者分片：{user_shard}, 文章分片：{post_shard}")

內容解密：

  1. 此程式碼展示瞭如何實作多重分片策略
  2. ShardingStrategy 類別封裝了分片邏輯
  3. 提供了 shard_by_user 和 shard_by_post 兩個方法，分別用於按使用者ID和文章ID進行分片
  4. 可以根據實際需求擴充套件更多分片方法

跨分片查詢的挑戰與解決方案

跨分片查詢是資料分片實施中的一大挑戰。為瞭解決這個問題，可以採用以下策略：

  1. 盡量簡化查詢邏輯，避免不必要的跨分片操作
  2. 使用摘要表格（Summary Tables）來儲存聚合資料
  3. 實施積極的快取機制，減少跨分片查詢的頻率

跨分片查詢最佳化範例

-- 建立摘要表格
CREATE TABLE shard_summary (
    shard_id INT,
    total_users INT,
    total_posts INT,
    PRIMARY KEY (shard_id)
);

-- 更新摘要表格
INSERT INTO shard_summary (shard_id, total_users, total_posts)
VALUES (0, 1000, 5000)
ON DUPLICATE KEY UPDATE
total_users = VALUES(total_users),
total_posts = VALUES(total_posts);

內容解密：

  1. 此SQL範例展示瞭如何建立和更新摘要表格
  2. shard_summary 表格用於儲存各個分片的匯總資料
  3. 使用 INSERT ... ON DUPLICATE KEY UPDATE 語法來更新現有的摘要資料

Vitess 架構與元件解析

Vitess 是一種強大的資料庫存取與管理工具，其設計理念源自於 Google 的實際需求與經驗。本章節將探討 Vitess 的架構組成及其關鍵元件，幫助讀者瞭解如何利用 Vitess 實作 MySQL 資料函式庫的有效擴充套件。

Vitess 架構概述

圖 11-3 展示了 Vitess 的整體架構圖，清楚地呈現了各個元件之間的關係與互動方式。

圖 11-3：Vitess 架構圖（改編自 vitess.io）

此圖示

此圖示顯示了 Vitess 的核心元件及其相互關係，包括 Vitess Pod、VTGate、VTTablet、Topology（中介資料儲存）等關鍵部分。

關鍵術語與元件

  1. Vitess Pod
    Vitess Pod 是對一系列資料函式庫及其相關元件的封裝，支援分片（sharding）、拓撲管理、結構變更管理以及應用程式對資料函式庫的存取。

  2. VTGate
    VTGate 是控制應用程式和操作人員存取資料函式庫例項的服務，類別似於負載平衡器。它負責管理拓撲結構、新增節點或對部分資料進行分片。

  3. VTTablet
    VTTablet 是執行在每個由 Vitess 管理的資料函式庫例項上的代理程式，可以接收來自操作人員的資料函式倉管理命令並代表其執行。

  4. Topology（中介資料儲存）
    Topology 用於儲存由 Vitess 管理的資料函式庫例項清單及其相關資訊，是整個系統的中樞神經。

  5. vtctl
    vtctl 是用於對 Vitess Pod 進行操作變更的命令列工具，提供直接的操作介面。

  6. vtctld
    vtctld 提供了一個圖形化介面，用於執行與 vtctl 相同的管理操作，方便不同使用者的操作習慣。

Vitess 運作機制

Vitess 的架構始於一個一致性的拓撲儲存，用於儲存所有叢集、MySQL 例項和 VTGate 例項的定義。當操作人員需要對由 Vitess 管理的叢集拓撲進行變更時，會透過 vtctl 服務向中介資料儲存傳送命令，再由該儲存將相關操作傳遞給 VTGate，從而完成拓撲變更。

Vitess 提供了一套在 Kubernetes 上佈署 VTGate 層和中介資料儲存的解決方案，將控制平面佈署在 Kubernetes 等平台上可提高系統對於單點故障的容忍度。

Vitess 的擴充套件理念

Vitess 的一大優勢在於其對於 MySQL 擴充套件的獨特理念，主要包括：

  • 偏好使用較小的例項
    將資料按照功能或水平分割，使用較小的例項可以降低單點故障的影響範圍。

  • 複製與自動寫入容錯移轉
    Vitess 自動化寫入容錯移轉流程，在轉移過程中管理拓撲變更和應用程式對資料函式庫節點的存取，盡量縮短寫入停機時間。

  • 使用半同步複製確保永續性
    Vitess 強烈建議使用半同步複製而非預設的非同步複製，以確保寫入操作在被確認前已持久化到多個節點，提升資料的可靠性。

這些架構原則有助於在業務流量呈指數增長時，保持資料函式庫層面的彈性與穩定。

向 Vitess 遷移

由於 Vitess 不是一個簡單的即插即用解決方案，因此在採用之前需要進行周密的規劃。遷移過程中需要注意以下步驟：

  1. 測試並記錄整體系統的延遲變化
    引入 Vitess 這樣的複雜堆積疊可能會增加系統延遲，尤其是啟用半同步複製時。需明確記錄這些變化並與下游依賴方溝通，以便制定合理的 SLO。

  2. 採用金絲雀佈署模型
    在生產環境中過渡時，可以將 vttablet 組態為「外部管理」，允許應用程式節點同時透過 vttablet 和直接連線存取資料函式庫，逐步調整連線比例。

  3. 開始分片
    當所有應用層存取均透過 VTGate/VTTTablet 而非直接連線 MySQL 時，便可利用 Vitess 的完整功能集進行表格拆分、水平分片或增加副本提升讀取容量。

此流程圖

此圖示展示了向 Vitess 遷移的主要步驟，包括測試延遲、採用金絲雀佈署模型以及開始分片等關鍵環節。

ProxySQL 簡介

ProxySQL 是另一款專為 MySQL 協定設計的代理工具，由 René Cannaò 主導開發並以 GPL 許可證釋出。ProxySQL 現已發展成一家成熟的公司，提供付費支援和客製化開發服務。

#### 內容解密：

此段落介紹了 ProxySQL 的基本情況，包括其開發背景和目前的發展狀態。ProxySQL 與 Vitess 一樣，都是為了最佳化 MySQL 資料庫存取而設計的工具，能夠提供負載平衡、查詢路由等功能。進一步瞭解 ProxySQL 可以幫助讀者根據自身需求選擇合適的資料函式倉管理方案。

ProxySQL 技術深度解析：架構、組態與應用實踐

ProxySQL 作為一個強大的資料函式庫代理層，能夠無縫地連線應用程式與 MySQL 資料函式庫例項，提供根據 MySQL 協定的介面。這種設計使得 ProxySQL 對應用程式來說幾乎是透明的，應用程式無需直接與資料函式庫建立連線，而是透過 ProxySQL 進行互動。

ProxySQL 架構概覽

ProxySQL 的架構設計使其具備了會話感知能力，能夠在不中斷服務的情況下，將連線在不同 MySQL 例項之間進行切換。特別是在處理不再積極開發的應用程式時，這種能力顯得尤為重要，因為它允許在無需修改程式碼的情況下，利用 ProxySQL 的功能。

此外，ProxySQL 提供了強大的連線池管理機制。應用程式與 ProxySQL 之間的連線和 ProxySQL 與後端資料函式庫之間的連線是分開管理的。這種分離設計能夠保護資料函式庫例項免受應用層突發流量的衝擊。

組態 ProxySQL

ProxySQL 使用組態檔案進行初始化，但其執行時組態同時儲存在記憶體和嵌入式 SQLite 資料函式庫中，可以透過管理介面進行查詢和修改。管理介面允許使用 MySQL 命令進行組態變更，並將變更持久化到磁碟上，從而實作零停機的組態更新。

-- 範例：透過管理介面新增 MySQL 使用者
INSERT INTO mysql_users (username, password, active, default_hostgroup, comment)
VALUES ('accounts', 'shard0_pass', 1, 0, 'Routed to the accounts shard'),
       ('transactions', 'shard1_pass', 1, 1, 'Routed to the transactions shard'),
       ('logging', 'shard2_pass', 1, 2, 'Routed to the logging shard');
LOAD MYSQL USERS RULES TO RUNTIME;
SAVE MYSQL USERS RULES TO DISK;

內容解密：

  • INSERT INTO mysql_users：將新使用者新增到 mysql_users 表中，用於定義不同使用者對應的後端資料函式庫分片。
  • LOAD MYSQL USERS RULES TO RUNTIME：將變更載入到執行時組態中，使新的使用者組態立即生效。
  • SAVE MYSQL USERS RULES TO DISK：將執行時組態儲存到磁碟上，確保重啟後組態仍然有效。

使用 ProxySQL 進行分片

ProxySQL 可以作為一個輕量級的分片路由層，根據不同的規則將應用程式的連線路由到對應的分片資料函式庫。

根據使用者的分片

可以根據不同的使用者名稱，將流量路由到不同的後端資料函式庫池。這種方式適用於資料按業務功能或使用者分佈在不同資料函式庫叢集中的場景。

根據 Schema 的分片

ProxySQL 也支援根據 Schema 名稱進行流量路由。這種方式適用於水平分片或功能分片的場景。

-- 範例：根據 Schema 的路由規則
INSERT INTO mysql_query_rules (rule_id, active, schemaname, destination_hostgroup, apply)
VALUES (1, 1, 'shard_0', 0, 1),
       (2, 1, 'shard_1', 1, 1),
       (3, 1, 'shard_2', 2, 1);
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

內容解密：

  • INSERT INTO mysql_query_rules：定義查詢規則，將特定 Schema 的查詢路由到對應的主機群組。
  • schemaname：用於匹配查詢的 Schema 名稱。
  • destination_hostgroup：指定匹配查詢要路由到的目標主機群組。
  • LOAD MYSQL QUERY RULES TO RUNTIME 和 SAVE MYSQL QUERY RULES TO DISK：與使用者規則相同，用於載入和儲存查詢規則。

其他使用 ProxySQL 的好處

ProxySQL 不僅能用於分片，還能幫助解決快速成長環境中的常見問題，如連線管理、流量控制和容錯移轉等。其內建的健康檢查機制能夠自動檢測後端資料函式庫的狀態，並根據需要調整流量權重或暫時移除不健康的節點。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 資料函式庫分片技術與ProxySQL應用

package "資料庫架構" {
    package "應用層" {
        component [連線池] as pool
        component [ORM 框架] as orm
    }

    package "資料庫引擎" {
        component [查詢解析器] as parser
        component [優化器] as optimizer
        component [執行引擎] as executor
    }

    package "儲存層" {
        database [主資料庫] as master
        database [讀取副本] as replica
        database [快取層] as cache
    }
}

pool --> orm : 管理連線
orm --> parser : SQL 查詢
parser --> optimizer : 解析樹
optimizer --> executor : 執行計畫
executor --> master : 寫入操作
executor --> replica : 讀取操作
cache --> executor : 快取命中

master --> replica : 資料同步

note right of cache
  Redis/Memcached
  減少資料庫負載
end note

@enduml

此圖示展示了應用程式透過 ProxySQL 連線到多個後端資料函式庫的架構。ProxySQL 根據組態規則，將查詢請求路由到適當的資料函式庫例項上。

綜上所述，ProxySQL 提供了一個靈活、高效且可靠的資料函式庫代理解決方案，特別適合需要擴充套件性和高用性的現代應用程式。透過合理的組態和管理，ProxySQL 能夠顯著提升資料函式庫層的效能和穩定性。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。