ClickHouse Cloud 推出 Postgres 至 Postgres ClickPipes，以 PeerDB 驅動低停機遷移
ClickHouse Blog · 2026-06-11
ClickHouse 於 2026 年 6 月 11 日宣佈 Postgres to Postgres ClickPipes 進入公開 Beta，作為「Postgres by ClickHouse」產品線的一部分。這項全託管服務以 PeerDB 技術為基礎，讓使用者在兩個 PostgreSQL 實例之間完成低停機遷移，無需在本機手動安裝任何工具。
背景
傳統 Postgres 遷移工具（如 pg_dump、pg_restore）在 TB 級資料集上往往需要數天的停機視窗。ClickHouse 收購 PeerDB 後，將其並行初始載入（parallel initial load）與 CDC（Change Data Capture）能力整合進 ClickPipes 框架，目的是把遷移時間從「天」縮短至「小時」。Postgres to Postgres ClickPipes 直接在 ClickHouse Cloud 基礎設施內執行，無需使用者維護額外的遷移叢集。
架構上，服務分為兩條獨立管道：初始快照管道負責分批讀取源端資料，CDC 管道則持續追蹤 WAL（Write-Ahead Log）並將變更套用到目標端。兩條管道各自擁有完整的重試機制，能夠容忍源端或目標端的短暫錯誤，不影響整體進度。
核心改動
Schema 遷移是整個流程最容易出錯的環節。Postgres to Postgres ClickPipes 自動化了 Schema Dump 與還原，並在此過程中處理以下細節：TLS 與憑證式加密連線、跨版本相容性轉換、角色衝突迴避（role conflict avoidance），以及冪等性（idempotent）Schema 套用，確保重跑後不會產生重複定義。對於有特殊需求的場景，服務也提供手動模式（manual mode）。
初始載入階段，服務預設使用 4 條並行執行緒、每批 100,000 行的批次大小，以及每分割 100,000 行的快照分割（snapshot partitioning）。CDC 階段則支援欄位自動新增傳播（automatic column addition propagation）與 TOAST 欄位處理，兩者在一般 Postgres 邏輯複寫中是常見的痛點。
關於同步設定，預設同步間隔為 60 秒，可透過 UI 精靈（wizard-based onboarding）調整。Schema dump 的執行位置被刻意安排在靠近源端資料庫的節點（colocation），以降低網路延遲。當重試失敗達到閾值時，服務會透過電子郵件與 UI 發出警示通知。
目標表的名稱與欄位允許自訂對應，並以 ReplacingMergeTree 引擎處理已刪除列的合併去重（deleted row removal during merges）。NULL 值保留語義與源端一致，避免遷移後資料失真。
影響範圍
Postgres by ClickHouse 定位於讓開發者以熟悉的 Postgres 協議存取 ClickHouse 的分析能力。Postgres to Postgres ClickPipes 補完了這個生態：使用者可以不改動應用層程式碼，直接將現有 Postgres 工作負載遷移至 ClickHouse Cloud。
服務支援三種複製模式：初始載入 + CDC（官方推薦）、僅初始載入（one-time snapshot）、以及僅 CDC（僅捕捉新增變更）。針對大型遷移，並行初始載入能顯著壓縮遷移視窗，配合 CDC 的持續同步可達成近乎零停機的遷移策略。技術細節可參閱 官方整合文件。
原始來源：ClickHouse Blog — Introducing Postgres to Postgres ClickPipes、ClickHouse Docs — Postgres Integration
RedisVL MCP：以 Model Context Protocol 將 Redis 向量索引標準化暴露給 AI 代理
Redis Blog · 2026-06-11
Redis 於 2026 年 6 月 11 日發布 RedisVL MCP，一個基於 RedisVL 的 MCP（Model Context Protocol）伺服器，讓 AI 代理能夠透過標準化介面查詢和寫入既有的 Redis Search 索引。安裝方式僅需 pip install redisvl[mcp]，再以 YAML 設定檔指向現有索引即可啟動。
背景
Redis Search 提供向量搜尋、全文檢索與混合搜尋能力，長期被用於 RAG（Retrieval-Augmented Generation）管道。然而，不同 AI 代理框架（Claude Desktop、Cursor 等）各自有不同的整合方式，維護成本高。MCP 作為代理與外部資源之間的標準化通訊層，提供了一個統一介面。RedisVL MCP 將 Redis 索引包裝為符合 MCP 規範的工具，讓平台團隊能夠集中控管存取政策、搜尋行為與資源限制，而不必逐一修改代理端程式碼。
這個設計的核心理念是關注點分離：代理只負責表達搜尋意圖（query text、過濾條件、回傳欄位），搜尋模式、向量化方式、並發上限等調校參數則由操作人員透過 YAML 設定檔管理，不暴露在請求合約（request contract）中。Schema 探索透過 FT.INFO 命令在啟動時自動重建，無需額外維護 Schema 定義檔。
核心改動
RedisVL MCP 伺服器對外暴露兩個主要工具。search-records 接受自然語言查詢，伺服器端自動完成嵌入（embedding）、查詢構建與結果正規化；支援 vector、fulltext、hybrid 三種搜尋模式，可透過 YAML 設定。upsert-records 則負責寫入，會依索引 Schema 驗證記錄，並在缺少向量欄位時進行伺服器端嵌入。若需唯讀部署，可透過 --read-only 旗標或環境變數 REDISVL_MCP_READ_ONLY=true 停用 upsert 工具。
過濾條件支援結構化語法，代理無須撰寫原始 Redis 查詢字串：Tag/Text 欄位接受 eq、ne、like、in 運算子，數值欄位額外支援 gt、gte、lt、lte，邏輯組合有 and、or、not。需要完整控制時，也可直接傳入原始 Redis 過濾字串。
執行時治理（runtime governance）以 YAML 設定驅動，主要參數如下：
| 參數 | 預設值 | 說明 |
|---|---|---|
default_limit | 10 | 預設回傳筆數 |
max_limit | 100 | 單次查詢硬性上限 |
max_result_window | 1000 | 最大 offset + limit |
max_upsert_records | 64 | 單次 upsert 記錄數 |
max_concurrency | 16 | 並發請求上限 |
request_timeout_seconds | 60 | 單次請求逾時 |
錯誤回應包含穩定的錯誤代碼（invalid_request、invalid_filter、backend_unavailable 等）以及 retryable 旗標，讓代理框架能夠正確處理重試邏輯。
影響範圍
傳輸層面，伺服器支援三種模式：stdio（本地 MCP 客戶端，如 Claude Desktop、Cursor）、SSE（HTTP Server-Sent Events，用於遠端部署）、以及 streamable-http（持久型 HTTP 服務）。SSE 與 HTTP 端點預設不啟用認證，官方建議部署於可信網路並配合認證型反向代理。
RedisVL MCP 明確定位為補充而非取代官方 Redis MCP 伺服器——後者提供通用 Redis 存取，前者專注於已建立向量索引的高語意搜尋場景。路線圖中計畫支援多索引，屆時單一 MCP 伺服器實例可將多個索引暴露為獨立工具（如 search-knowledge-base、search-products），進一步降低多資料集場景的整合複雜度。對於已在 Redis 上建立 RAG 管道的團隊，RedisVL MCP 提供了一條低摩擦路徑，在不重構現有索引的前提下讓代理直接取用這些能力。
原始來源：Redis Blog — Connect Your Redis Index to AI Agents with RedisVL MCP、RedisVL Documentation
ClickCannon 開源：ClickHouse 工程團隊如何打造真實負載壓測框架
ClickHouse Blog · 2026-06-11
ClickHouse 工程師 Spencer Torres 於 2026 年 6 月 11 日發布 ClickCannon v0.4.0，一個以 Go 撰寫的開源壓測框架。工具使用約 2 TiB 的生產 OpenTelemetry trace 資料重放真實工作負載，同步模擬多位並發用戶查詢。ClickCannon 最初是 ClickStack（基於 ClickHouse 的可觀測性平台）的內部容量規劃工具，現在以通用框架形式開源。
原本的問題
「我需要多少硬體才能跑 ClickHouse？」是使用者最常提出的規格問題，但現有的合成基準測試工具（synthetic benchmark）難以反映真實場景。ClickHouse 的壓縮能力可能使小型資料集的基準結果產生誤導——若反覆循環相同的小資料集，實際上是在測試壓縮演算法，而非系統的整體吞吐與延遲。真實資料的基數分布（cardinality distribution）、時間序列密度與查詢存取模式都與合成資料存在顯著差異。
傳統壓測工具還有一個常見盲點：長時間測試（天級甚至週級）中的記憶體成長問題。Go 的 ch-go 客戶端在長時間使用後會累積配置（allocation），導致記憶體持續增長，使壓測結果失真甚至中途崩潰。
採用的方法
ClickCannon 的資料攝取管道採用 ClickHouse Native 格式搭配 ZSTD 壓縮，資料流路徑為：檔案 → 壓縮計數器 → 緩衝讀取器 → ZSTD 解壓縮器 → 未壓縮計數器（速度限制器）→ ch-go block 解碼器。速度限制器採用滑動視窗吞吐量量測搭配令牌桶（token-bucket）強制執行，能夠精準地持續在目標速率（例如 100 MiB/s）附近運作，支援從 1 TiB/month 到 20 PiB/month 的寬廣吞吐範圍。
並發架構採用雙工作者模式（dual-worker pattern）：磁碟工作者負責讀取與解壓縮，插入工作者負責執行資料庫寫入，兩者透過共享的區塊佇列（block queue）解耦。磁碟工作者會將解壓縮後的資料預先解碼為 ch-go block 並存入記憶體池（pool）供插入工作者重用，最小化配置次數與記憶體複製，同時維持管道各階段之間的清晰邊界。
針對長時間壓測的記憶體問題，工具實作了兩項機制：區塊退休（block retirement）——每個 block 在被使用 N 次後強制釋放並重建，防止 ch-go 內部配置無限累積；以及工作者退休（worker retirement）——以錯開的偏移量（計算為 (i * retirement_batches) / threads）循環重啟插入工作者，避免編碼器緩衝區（encoder buffer）漂移。兩者合力讓記憶體在 30 天以上的測試中維持平穩。時間戳移位（timestamp shifting）確保每列資料都以符合目標吞吐率的時間戳插入，維持真實的 part 建立與壓縮行為。
用戶模擬方面，第三類工作者執行參數化查詢工作流程（parameterized workflow）：預查詢（preflight query）先從資料庫取得隨機服務名稱等上下文，後續查詢再以此為參數。查詢時間範圍從當前時間戳往回採樣，同時覆蓋近期熱分區與已合併的冷分區。可設定的「思考時間」（think time）搭配種子隨機化能防止多個工作者同步觸發「群體驚嚇」（thundering herd）問題。
實際效果
ClickCannon 本身暴露 45 個指標（計數器、儀表、樣本），涵蓋工作者效能、佇列狀態、吞吐穩定性與查詢延遲，並透過獨立的 ClickHouse 資料庫與 Grafana 儀表板即時呈現。工具刻意不抓取被測 ClickHouse 實例的指標，以避免監控開銷影響測試結果；取而代之，使用 ClickHouse 內建儀表板與原生指標系統，並可透過 ClickHouse MCP 伺服器對比不同壓測輪次的原始指標。
對於無法取得 2 TiB 生產資料的使用者，ClickCannon 提供以程式碼定義的資料生成設定檔（code-defined data generation profile），能產出帶有加權隨機服務名稱與屬性鍵的擬真日誌與 trace，讓使用者在控制基數分布的前提下進行壓測。下一篇系列文章將介紹 ClickCannon 如何被用於 ClickStack 預設 Schema 的優化與硬體容量建議推導。
原始來源：ClickHouse Blog — Building ClickCannon、GitHub — ClickHouse/ClickCannon