資料與儲存 2026 年 5 月 22 日

2026-05-22 — DuckDB Lance 湖屋格式整合向量搜尋、ClickHouse vs Prometheus 高基數 Part 2

primary=https://duckdb.org/2026/05/21/test-driving-lance.html primary=https://lance.org/ primary=https://clickhouse.com/blog/clickhouse-vs-promethous-high-cardinality-part-2-cardinality-in-clickhouse

DuckDB 與 Lance 格式整合:向量搜尋、全文搜尋、混合搜尋一次到位

DuckDB Blog · 2026-05-21

DuckDB 與 LanceDB 團隊於 2026 年 5 月 21 日聯合發布技術文章,介紹 Lance 湖屋格式與 DuckDB 的整合方式。Lance 不只是一個欄式檔案格式,它同時扮演表格格式與輕量型目錄規格的角色,內建版本控制、schema evolution、索引與 MVCC 交易語義——這些都是 Parquet 原生不支援的能力。

架構與 DuckDB 整合方式

Lance 採用「fragment-based layout」儲存架構,將資料分割為小型欄式片段(fragment),兼顧隨機存取效率與掃描效能。DuckDB Lance extension 提供下列整合點:

  • 標準 SQL 直接查詢 Lance dataset
  • COPY ... TO ... (FORMAT lance) 寫入資料
  • lance_vector_search()lance_fts()lance_hybrid_search() SQL 函式
  • Namespace attach 以表格形式存取
  • SQL 指令管理索引

效能基準

測試資料集為 LAION-1M(69,632 筆,含 embedding、caption 與影像位元組)。結果顯示 Lance 在向量搜尋場景的冷啟動優勢顯著:

查詢類型Lance(冷)DuckDB(冷)Lance(暖)DuckDB(暖)
向量搜尋(有索引)12ms104ms5ms2ms
混合搜尋17ms80ms8ms11ms
全文搜尋21ms11ms7ms10ms

暖快取下兩者差距縮小,DuckDB 原生全文搜尋在暖快取下略優,但向量搜尋和混合搜尋場景 Lance 具備明顯優勢,尤其是對需要快速冷啟動的 serverless 工作負載。

影響範圍

Lance 格式目前版本為 v2,規格文件位於 lance.org,DuckDB extension 文件位於官方 core extensions 頁面。對於 ML 工作負載中需要在同一工具鏈內結合 SQL 分析與向量相似度搜尋的場景,這個整合提供了一條無需引入額外服務的路徑。

原始來源:DuckDB BlogLance 格式規格


ClickHouse vs Prometheus 高基數觀測性(Part 2):ClickHouse 如何處理基數

ClickHouse Blog · 2026-05-15

ClickHouse 工程團隊於 2026 年 5 月 15 日發布系列文章第二篇,深入說明 ClickHouse 如何從儲存架構層面應對高基數(high cardinality)觀測資料。第一篇(2026-05-14)已介紹問題定義——高基數指 label 組合數量極大,例如 Kubernetes 叢集中每個 Pod 的 container_id、trace_id 等維度的笛卡兒積。

Prometheus 的高基數瓶頸

Prometheus 的 TSDB 以 time series 為最小單位,每個 label 組合對應一條獨立的 time series。高基數場景下 time series 數量爆炸,導致 head block 記憶體需求線性增長,典型症狀是 OOM 或查詢超時。Cortex、Thanos 等遠端儲存方案雖然能分散負載,但根本問題(每組 label 一條 series)依然存在。

ClickHouse 的處理方式

ClickHouse 以欄式儲存與 MergeTree 引擎為基礎,label 作為普通欄位儲存,而非 time series 的 key。高基數欄位(如 pod_id)透過 LowCardinality 資料型別進行字典編碼,實際儲存的是整數索引而非原始字串,壓縮比可達 10x 以上。查詢時使用標準 SQL GROUP BY 聚合,不受 label 組合爆炸影響。

D.E. Shaw 案例(同系列另一篇文章)顯示,他們用 ClickHouse 支撐每秒數百萬指標攝入,label 基數達數十億級別,查詢延遲維持在秒級。關鍵設計差異:ClickHouse 的查詢複雜度與 label 基數解耦,Prometheus 則是耦合的。

適用場景

ClickHouse 並非要取代 Prometheus 作為 scrape 端點(Prometheus remote write 可以直接寫入 ClickHouse),而是作為長期儲存與高基數分析引擎。對於 15 天以上的指標歷史查詢、需要跨多個 label 維度 GROUP BY 的分析,ClickHouse 在效能和成本上均有優勢。

原始來源:ClickHouse Blog — Part 2


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