一個名為 PgDog 的新 PostgreSQL 管理工具已經問世，承諾解決資料庫領域最具挑戰性的問題之一：具有透明查詢處理的自動分片。該開源專案使用 Rust 構建，採用 AGPL v3 許可證，旨在讓 PostgreSQL 擴充套件對開發者來說盡可能無縫。
主要特性：
- 支援數十萬連線的事務池化
- 應用層（OSI 第7層）負載均衡，提供多種策略
- 使用 PostgreSQL 原生解析器進行自動查詢解析和分片路由
- 在記憶體中進行跨分片查詢結果組裝
- 內建 CSV 解析器，用於將 COPY 命令拆分到各個分片
- 支援邏輯複製協議，實現即時重新分片
透明分片與跨分片智慧
PgDog 最引人注目的方面在於其處理分散式查詢的方法。與需要應用程式瞭解資料分佈的傳統分片解決方案不同，PgDog 在網路層執行，同時保持 PostgreSQL 相容性。該工具使用 PostgreSQL 的原生解析器來理解查詢、提取分片鍵，並自動將請求路由到適當的分片。
當查詢跨越多個分片時，PgDog 在記憶體中組裝結果，然後傳送給客戶端。這種透明性意味著現有應用程式無需更改程式碼就能從分片中受益。然而，這種方法引發了關於效能和資源使用的重要問題，社群對此非常關注。
效能問題和現實關切
早期社群反饋突出了當前基準測試中的一個關鍵缺口。雖然 PgDog 在標準連線池方面展現了令人印象深刻的效能，但真正的考驗來自查詢解析和跨分片操作。
「這是我多年來見過的最有趣的 Postgres 專案之一。所展示的基準測試似乎只涉及標準池化，我想看看一旦涉及查詢解析和跨分片連線時會是什麼樣子。」
這種擔憂反映了行業對透明分片解決方案更廣泛的懷疑態度。解析每個查詢的計算開銷，加上組裝跨分片結果的記憶體需求，可能會在高負載下顯著影響效能。
 |
|---|
| 這張截圖展示了 PgDog 專案的 GitHub 倉庫，反映了關於其效能和基準測試的持續討論 |
高可用性和運維挑戰
該專案的高可用性方法既顯示了優勢也暴露了侷限性。PgDog 透過同步配置而非共識機制來處理多個前端代理。這種設計選擇避免了複雜的腦裂場景，但需要仔細的部署協調。
對於零停機部署，推薦的方法包括暫停流量、重新載入配置，並在幾秒鐘內恢復操作。雖然這適用於計劃維護，但它無法解決意外故障，此時需要使用 TCP 負載均衡器進行藍綠部署。
配置要求：
- 主配置： pgdog.toml （通用設定和伺服器資訊）
- 使用者配置： users.toml （身份驗證詳細資訊）
- 監控： OpenMetrics 端點和 PgBouncer 風格的管理資料庫
- 部署：配置驅動，支援多個代理的同步過載
商業模式和許可證考量
PgDog 的 AGPL v3 許可證引發了關於企業採用的討論。該許可證允許內部使用和私有修改而無需共享原始碼，但要求將 PgDog 作為公共服務提供的組織必須共享其修改。
開發團隊計劃透過託管部署和支援服務來實現盈利，遵循基礎設施軟體的既定模式。然而，儘管開發者提供了澄清，一些組織對 AGPL 許可證仍然保持謹慎態度。
展望未來
PgDog 代表了透過智慧代理解決 PostgreSQL 水平擴充套件挑戰的雄心勃勃的嘗試。該專案的成功很大程度上取決於它如何處理透明分片的效能影響，以及是否能兌現無縫可擴充套件性的承諾。
由於該專案仍處於早期階段，建議潛在採用者徹底測試其特定用例，特別是涉及複雜跨分片查詢的場景。未來幾個月將揭示 PgDog 是否能夠在 PostgreSQL 的可靠性和現代應用程式的擴充套件需求之間架起橋樑。
參考：PgDog