資料與儲存 2026 年 7 月 1 日

2026-07-01 — ClickHouse 發布 Silk Fiber 執行環境、Vibe.co 億級廣告曝光架構、PGX 為 EOL PostgreSQL 提供長期安全支援

primary=https://clickhouse.com/blog/silk primary=https://github.com/ClickHouse/silk primary=https://clickhouse.com/blog/vibe-adtech-analytics primary=https://www.postgresql.org/about/news/pgx-announces-support-for-eol-versions-of-postgresql-3334/ primary=https://pgexperts.com/contact/?o=longevity

ClickHouse 發布 Silk:為高並發查詢打造的 C++ Fiber 執行環境

ClickHouse · 2026-06-25

背景

2026 年 6 月 25 日,ClickHouse 工程師 James Cunningham 與 Vadim Skipin 以開源形式發布了 Silk,一套專為 ClickHouse 設計的 C++ stackful fiber 執行環境。傳統執行緒模型在面對數百節點的分散式快取查詢時,上下文切換成本高且尾端延遲難以控制,Silk 的出現正是為了解決這個瓶頸。

核心改動

Silk 採用「每顆 CPU 一條 OS 執行緒」的架構,搭配 NUMA-aware work-stealing 排程器,依照 CPU 拓撲(超執行緒同胞 ≈1μs、同 socket ≈50μs、跨 socket ≈500μs)決定工作竊取的優先順序。I/O 統一透過 io_uring 完成,穩態路徑零堆積配置,Fiber 物件本身即為佇列節點,不另行 malloc。同步原語(FiberFuture、FiberMutex 等)均以一套「打包狀態 + CAS + 暫停回呼」抽象實作。

  • Fiber yield 延遲 ≈ 3.6 奈秒
  • io_uring ping-pong ≈ 7.6 微秒
  • 檔案 IOPS 達 590 萬次/秒
  • 單連線吞吐量較 boost::asio 高約 15 倍
  • 10,000 並發 S3 請求的 P99.9 延遲比等效執行緒池低約 65%

影響範圍

目前 Silk 僅支援 Linux(依賴 io_uring、eventfd、rseq 等),且為行程級單例排程器,首個部署目標是 ClickHouse 的分散式快取層。原始碼已公開於 GitHub,需 Clang 21 與 CMake 3.28+ 建置;BPF profiler 尚未支援 per-fiber 歸因,列為後續路線圖項目。

原始來源:ClickHouse Blog — Announcing Silkgithub.com/ClickHouse/silk


Vibe.co 如何以 ClickHouse Cloud 處理數十億次 CTV 廣告曝光

ClickHouse · 2026 年近期

原本的問題

Vibe.co 是專注於聯網電視(CTV)的廣告科技平台,早期以 PostgreSQL 為核心,但當資料量成長至數十億筆廣告曝光後,預聚合層成為嚴重瓶頸。每新增一種報表維度,工程團隊就必須為其建立獨立的 ETL 管線,開發成本與維運複雜度持續攀升。

採用的方法

遷移至 ClickHouse Cloud 後,Vibe 完全捨棄中間的預計算中介層,資料直接載入資料庫並進行即時 OLAP 查詢。架構上採用 hot/cold 分層物化視圖:熱層保存最近 30 天資料供高頻查詢,冷層保留完整歷史;兩層各自針對查詢模式獨立最佳化。儲存與運算分離的雲端架構讓成本隨用量線性擴展,無需預先超額配置。

實際效果

遷移後儲存資料從約 100 GB 擴增至逾 2 TB,架構無需改動。逾 90% 的客戶活動報表回應時間低於 100 毫秒,可同時服務數千名 CTV 廣告主的即時報表需求。Vibe 工程團隊表示,即便資料量再增加 20 倍,現行架構亦只需調整實例規格,毋須重新設計資料流。

指標遷移前 (PostgreSQL)遷移後 (ClickHouse Cloud)
儲存規模~100 GB>2 TB
P90 報表延遲不可接受<100 ms
新報表維度上線需建新 ETL直接查詢

原始來源:ClickHouse Blog — Vibe Adtech Analytics


PGX 宣布推出 Longevity 服務,為 EOL 版本 PostgreSQL 提供安全修補

PostgreSQL.org · 2026-06-25

背景

2026 年 6 月 25 日,PostgreSQL 顧問公司 PostgreSQL Experts(PGX)宣布推出 PGX Longevity 服務,針對已結束社群支援(EOL)的 PostgreSQL 版本繼續提供安全性修補與資料完整性修正。許多企業受制於相容性、法規或升級成本,無法立即遷移至受支援版本,此服務正是填補這段空窗期。

核心改動

PGX Longevity 涵蓋 PostgreSQL 9.6 至 14 的所有 EOL 版本,服務內容包含關鍵安全漏洞回移修補與資料完整性缺陷修正,並提供 SLA 保障。計費採固定月費制,以客戶為單位而非以實例或核心數計算,降低多節點部署的費用預測難度。

影響範圍

PostgreSQL 14 將於 2026 年 11 月終止社群支援,屆時將自動納入 Longevity 服務範圍。對於仍運行 PostgreSQL 9.6 至 13 的老舊系統而言,此服務提供一條無需立即升級的合規過渡路徑。PGX 同時保留升級諮詢服務,協助客戶規劃長期遷移計畫。

原始來源:PostgreSQL.org 新聞公告PGX Longevity 服務頁


End of article
0
Would love your thoughts, please comment.x
()
x