資料與儲存 2026 年 7 月 16 日

2026-07-16 — Trainy 把實驗中繼資料搬進 ClickHouse Managed Postgres、ClickHouse 取代金融業歷史報價資料庫 HDB、Odyssey 連線池釋出 1.5.1

primary=https://clickhouse.com/blog/trainy-postgres-managed-by-clickhouse primary=https://clickhouse.com/blog/historical-ticker-data primary=https://www.postgresql.org/about/news/odyssey-151-released-3348/

ML 實驗追蹤平台 Pluto 把中繼資料從 RDS Postgres 搬進 ClickHouse

ClickHouse Blog · 2026-07-15

Y Combinator 背景的 ML 基礎設施新創 Trainy,在 2026-07-15 的 ClickHouse 官方部落格公開了旗下開源實驗追蹤工具 Pluto 的資料庫遷移過程。Pluto 原本用 Amazon RDS Postgres 儲存訓練執行時間、超參數等中繼資料,指標與觀測資料則另外放在 ClickHouse Cloud。這次改動只動 OLTP 層,把 metadata 搬到同一個 ClickHouse Cloud 帳號內的 ClickHouse Managed Postgres

原本的問題

團隊表示「一開始用的 RDS 預設規格,對我們的資料量來說太貴了」。更麻煩的是頁面初次載入延遲:實驗頁面要從 RDS 抓 metadata 才能渲染,網路儲存的存取速度成了瓶頸。同時維護兩套雲端資料庫供應商也增加了維運負擔。

採用的方法

遷移後 metadata 落在同帳號的 Managed Postgres 上,直接吃到本機 NVMe 儲存而非網路掛載儲存,並沿用原本就熟悉的 ClickHouse Cloud Query Insights 工具做查詢診斷,加上自動擴縮容省去手動調整規格的工作。

實際效果

指標遷移前遷移後
頁面初次載入基準快 2-3 倍
數十萬步驟的視覺化查詢(P50)-50-100ms
複雜查詢執行時間10-15 分鐘5 秒
資料寫入掉點率-0%

團隊接下來計畫用 ClickPipes 做 CDC,把 Postgres 的資料即時複寫進 ClickHouse,讓 GPU 指標與訓練執行紀錄可以直接跨庫 join。

原始來源:ClickHouse Blog: Trainy migration


用 ClickHouse 取代金融業歷史報價資料庫 HDB

ClickHouse Blog · 2026-07-15

ClickHouse 工程師 Mark Needham 在同一天發布的部落格文章中,示範如何用 ClickHouse 取代金融業傳統的 HDB(Historical Database)——一套獨立於即時交易系統之外、專門保存每日成交與報價歷史的歸檔資料庫,供研究、回測、交易成本分析與監理重建使用。範例資料取自 Binance 公開的成交與報價資料集。

原本的問題

傳統 row-oriented 資料庫在 tick 等級資料量下,儲存效率差、查詢也慢,因此業界通常把即時與歷史拆成兩套系統,增加維運複雜度。文章指出 ClickHouse 標準 SQL 加上欄式儲存的壓縮特性,可以把兩層合併成一套。

採用的方法

成交表用 MergeTree,依 (symbol, ts) 排序,symbol 欄用 LowCardinality(String),時間戳用 DateTime64(3) 搭配 DoubleDelta + ZSTD(1) 編碼,價格與數量欄則是 DecimalZSTD

CREATE TABLE trades (
  symbol LowCardinality(String),
  ts DateTime64(3) CODEC(DoubleDelta, ZSTD(1)),
  trade_id UInt64 CODEC(DoubleDelta, ZSTD),
  price Decimal(18,8) CODEC(ZSTD),
  qty Decimal(18,8) CODEC(ZSTD),
  quote_qty Decimal(18,8) CODEC(ZSTD)
) ENGINE = MergeTree
ORDER BY (symbol, ts)

實際效果

10 個月共 162 億筆成交紀錄,壓縮後只佔 76GB,換算 ClickHouse Cloud 儲存成本約每月 $1.88;單月原始 191GB 壓縮到 10GB,比例達 19 倍(其中 trade_id 欄壓縮比高達 292 倍)。查詢 60 秒區間的成交明細只花 0.053 秒,靠索引只讀取 383,083 個 granule 中的 4 個(0.001%);對 1,236 萬筆資料算 VWAP 也只要 0.126 秒。文章另外示範用 ASOF JOIN 把每筆成交比對到當下最新報價,計算滑價。

原始來源:ClickHouse Blog: Replacing the HDB


Yandex 連線池 Odyssey 釋出 1.5.1,補上排隊延遲觀測與 CPU 親和性

PostgreSQL News Archive · 2026-07-14

Yandex 維護的 PostgreSQL 多執行緒連線池 Odyssey,在 PostgreSQL News Archive 公告 1.5.1 版釋出。連線池的作用是在應用端與資料庫之間維護一批常駐連線,讓短連線請求重用既有連線而非每次都重新建立,藉此降低 Postgres 後端行程開銷;Odyssey 是這類工具中支援多執行緒排程的實作。

核心改動

  • 新增簡易共享連線池(simple shared pools)與 pool_pin_on_listen 選項
  • 負載平衡邏輯改善、支援 CPU affinity
  • 支援以 AWS-LC 編譯、支援 SSLKEYLOGFILE
  • 新增排隊時間指標 avg_wait_time / total_wait_time,並可透過 pool_notice_after_waiting_ms 在等待過久時發出 NOTICE
  • 新增 server_drop_on_cached_plan_error 選項;attach 後主動 poll 後端連線以偵測失效節點

影響範圍

修正項目集中在連線生命週期的邊界情況:建立後端連線後重新檢查連線池大小、修掉取消查詢時等待 PG 關閉 cancel 連線的競態、修正 auth_query、Extended 協定下的 CloseCOPY 支援,以及補上 DEALLOCATE ALL 的處理。Prometheus 指標匯出器也一併調整。這些修正主要影響高並發、大量短連線的部署場景。

原始來源:PostgreSQL News Archive: Odyssey 1.5.1


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