DuckDB 導入非同步 I/O 架構，遠端 Parquet 讀取實測最高快近 20 倍
DuckDB 官方工程部落格 · 2026-07-31
背景
DuckDB 團隊在官方部落格文章〈Asynchronous I/O in DuckDB: Work, Thread, Work〉中說明，DuckDB 過去採用同步 I/O 模型，也就是每個查詢工作執行緒（worker thread）在讀取資料時會直接阻塞，等待資料回傳才能繼續運算。這套設計在本機 SSD 上問題不大，因為延遲極低；但當資料來源換成 S3 等遠端物件儲存時，網路往返延遲遠高於本機磁碟，工作執行緒會長時間閒置等待，導致頻寬與 CPU 都用不滿。文章以此作為新架構的動機，目標是把「等待網路」與「執行運算」這兩件事解耦。
核心改動
新架構把執行緒分成兩個獨立的執行緒池：REGULAR（每顆 CPU 核心一條，負責運算）與 ASYNC（系統執行緒數的 4 倍，上限 256 條，專門處理會阻塞的 I/O 呼叫）。REGULAR 執行緒不再親自等待網路回應，而是把讀取請求丟給 ASYNC 執行緒池非同步執行，自己繼續處理下一批運算工作，這也是標題「Work, Thread, Work」想表達的分工模式。
為了讓 ASYNC 執行緒永遠有事可做，DuckDB 加入了提前讀取佇列（read-ahead queue）：REGULAR 執行緒在認領查詢工作時，會主動把後續需要的位元組範圍（byte-range）請求塞進佇列，由 ASYNC 執行緒並行抓取，並用倒數計數器追蹤完成進度。佇列深度受新設定 read_ahead_depth 控制，也可退回由記憶體管理器自動決定：
SET read_ahead_depth = 5; -- 手動限制最多提前抓取 5 個工作
SET read_ahead_depth = -1; -- 預設值，交由記憶體管理器動態決定
SET read_ahead_depth = 0; -- 完全關閉提前讀取
SET async_threads = 48;目前這套機制支援 Parquet 以及未壓縮、可 seek 的 UTF-8 CSV 檔案，JSON 與 DuckDB 原生格式的支援則規劃在 v2.0 之後。文章也提到團隊正在評估導入 Linux 的 io_uring——一種讓應用程式一次提交多筆 I/O 請求、由核心非同步完成後統一回報結果的介面，比傳統每次讀取都要進行一次系統呼叫（system call）的模式更省開銷——藉此進一步降低系統呼叫成本。
影響範圍
這項功能預計隨 DuckDB v2.0（2026 年秋季）正式發布，目前可在 v2.0.0-dev 預覽版中啟用測試。文章附上多組實測數據，比較 v1.5.5（同步 I/O）與 v2.0.0-dev（非同步 I/O）在不同情境下的耗時：
| 測試情境 | v1.5.5（同步） | v2.0.0-dev（非同步） | 倍數 |
|---|---|---|---|
| 單一 Parquet 檔（22GB，S3） | 8.230s | 2.844s（調校後 2.227s） | 2.9–3.7x |
| CSV（80.89GB，S3） | 877.563s | 45.264s | 19.4x |
| 本機磁碟冷讀取 | 1.321s | 0.883s | 1.5x |
| 分區資料集（976 檔，Parquet） | 9.344s | 2.945s | 3.2x |
在單檔 Parquet 測試中，網路頻寬使用率也從約 5 Gbit/s 提升到接近飽和的 25 Gbit/s。文章同時提供並行查詢的 TPC-H 測試（Q1、Q6、Q9、Q18）：v1.5.5 總耗時 35.8 秒、平均只用到 5.9 顆核心；v2.0.0-dev 總耗時降到 15.6 秒，平均使用 48.1 顆核心，峰值頻寬也從 10.7 Gbit/s 提升到 24.9 Gbit/s。這代表新架構讓查詢能真正把多核心與頻寬資源用滿，而非受限於同步等待。文章也坦言初次連線與 TLS 交握仍有數百毫秒延遲待優化，屬於後續改善方向。
原始來源：DuckDB Blog：Asynchronous I/O in DuckDB、GitHub：task_scheduler_type.hpp
clickhousectl v0.4.0：雲端服務開放水平自動擴展，新增 ClickPipe 結構探索指令
ClickHouse 官方部落格 · 2026-07-31
背景
ClickHouse 官方部落格發布〈What's new in clickhousectl v0.4.0〉，介紹命令列工具 clickhousectl 的最新版本。clickhousectl 是 ClickHouse 官方提供的 CLI，官方定位是「同時給人類與 AI agent 使用」的開發工具，涵蓋本機伺服器啟停、雲端服務（Cloud service）管理、ClickPipe 資料管線設定等操作，等於把原本要跑多個 API 呼叫或網頁後台操作的工作，收斂成一支指令列程式。
核心改動
雲端服務新增水平自動擴展（horizontal autoscaling）選項，service create與service scale指令新增 --min-replicas、--max-replicas、--autoscaling-mode horizontal 三個旗標，且與既有的垂直擴展旗標互斥：
clickhousectl cloud service create --name my-service \
--min-replicas 2 --max-replicas 8 \
--autoscaling-mode horizontal另一項重點是新增 clickpipe schema-discover 指令（Beta），可對 Kafka 或 Kinesis 來源做結構探測，回傳推斷出的欄位與型別，且不需要真的建立一條資料管線就能預覽結構；這個指令需要 API key，唯讀 OAuth 權限無法使用。本次版本也擴充了既有的 ClickPipe 匯入控制：
- 物件儲存管線新增
--skip-initial-load、--start-after旗標，可跳過首次全量載入或指定起始時間點 - MySQL CDC 管線新增
--server-id旗標，用於指定複寫用的伺服器 ID cloud postgres config patch改為真正的部分更新，只需帶入要修改的設定值
影響範圍
本次釋出合併了 28 個 PR，涵蓋錯誤修正與行為調整。OAuth token 改為存放在全域路徑 ~/.clickhouse/tokens.json，並會自動從舊的專案內 token 檔案遷移，避免每個專案要重新登入。本機伺服器生命週期管理也變得更安全：
local server stop改為冪等操作，對已停止的伺服器重複執行也會成功（修正 issue #255）local remove <version>若該版本仍有伺服器在執行中會拒絕刪除，需加--force才會先停止再刪除- 裸指令
local server start在全新安裝時會自動安裝並啟動最新的 master 版本
v0.4.0 也首次加入匿名使用遙測（telemetry），預設開啟但可退出：只收集指令路徑、旗標名稱（不含旗標值）、結束碼、CLI 版本與作業系統/架構，不含任何安裝 ID 或裝置指紋，可透過 clickhousectl telemetry disable 或環境變數 DO_NOT_TRACK=1 關閉。此外 CLI 也會把 AI agent 的 session/trace ID 轉發進外送請求標頭，方便在多個 agent 呼叫鏈路中追蹤請求來源。
其餘變動多屬於維運面的細節打磨：local server start 的 --config 旗標被提升為主要啟動參數，說明文字也把 latest 標示為建議使用的版本；CLI 內部改為從函式庫的 enum 直接衍生出可用值清單，並加入雙向 drift 偵測，避免 CLI 顯示的選項與後端 API 實際支援的欄位不同步，同時修正了多處 OpenAPI 定義（慢查詢模式、Postgres 指標、物件儲存控制、自動擴展欄位）已經跑掉的問題。安裝方式維持 curl、pip、uv、npm、cargo 五種管道不變，本次也把依賴套件 cmov 由 0.5.3 升到 0.5.4、is-ai-agent 升到 0.5.0，README 中的 beta 標示也一併移除，代表官方已將此 CLI 視為穩定可用的工具。
原始來源：ClickHouse Blog：What's new in clickhousectl v0.4.0、GitHub Release：clickhousectl v0.4.0
PostgreSQL 官方公告 plRuby：用 Ruby 寫資料庫函式的程序語言 handler
PostgreSQL News · 2026-07-31
背景
PostgreSQL 官方新聞頁面刊出〈plRuby〉公告，介紹這款程序語言 handler（procedural-language handler）：在 PostgreSQL 裡，程序語言 handler 是讓資料庫可以直接用 SQL 以外的語言（例如 PL/pgSQL、PL/Python）撰寫函式、觸發器與程序的外掛機制。plRuby 的做法是在後端行程中內嵌一個 MRI Ruby 直譯器，讓開發者能用 Ruby 的語法與生態系撰寫資料庫端邏輯，同時仍具備一般 PostgreSQL 函式（含觸發器、事件觸發器、可控制交易的程序）的能力。實際專案原始碼與文件維護在 commandprompt/plruby 這個 GitHub repo。
規格細節
此次公告相容範圍涵蓋 PostgreSQL 11 到 18（官方建議搭配 PostgreSQL 18）與 Ruby 3.x。功能上，plRuby 支援純量、陣列與複合型別自動轉為原生 Ruby 值，也支援 RETURNS SETOF 的 set-returning 函式、列與陳述式層級的觸發器（透過 $_TD 存取觸發資訊）、事件觸發器，以及可在程序中控制交易（commit/rollback）的邏輯。資料庫存取則透過 SPI（Server Programming Interface，PostgreSQL 內部提供給程序語言呼叫 SQL 的介面）執行，支援預備陳述式（prepared statement）與 cursor streaming 處理大量結果集。一個典型的函式寫法大致如下：
CREATE FUNCTION greet(name text) RETURNS text AS $$
"Hello, #{name}!"
$$ LANGUAGE plruby;plRuby 額外提供 jsonb、hstore 與 ltree 三種型別的 transform 支援，讓這些 PostgreSQL 特有型別在傳進 Ruby 函式時能自動轉成對應的原生 Ruby 物件，不需要手動解析字串。從專案 repo 內的 SQL 安裝腳本檔名（如 plruby--2.5.sql）可看出目前發行的擴充套件版本落在 2.5 系列。
影響範圍
公告特別強調一項安全限制：plRuby 屬於「不受信任」（untrusted）語言。原因是 Ruby 3.0 起移除了語言層級的沙箱（sandbox）機制，一旦函式能在後端執行，就能存取檔案系統、發起網路連線，甚至執行任意 shell 指令，權限等同於執行 PostgreSQL 服務的作業系統使用者。因此官方規定只有 superuser 才能建立 plRuby 函式，一般資料庫使用者無法自行安裝或使用這個語言，管理者在啟用前需評估風險。
- 支援型別：純量、陣列、複合型別、jsonb/hstore/ltree transform
- 函式種類：一般函式、set-returning 函式、觸發器、事件觸發器、可控交易的程序
- 資料庫存取：SPI、預備陳述式、cursor streaming
- 權限限制：僅 superuser 可建立函式（untrusted language）
對熟悉 PL/Python 或 PL/Perl 的維運人員來說，plRuby 的定位是同一類「內嵌腳本語言」的延伸選項：當團隊本身的技術棧以 Ruby 為主（例如後端服務用 Rails 撰寫）時，能直接沿用同一套語言與函式庫在資料庫端寫觸發器或批次邏輯，減少在 SQL 與另一門膠水語言之間切換的成本。專案文件也額外提供了 語言參考手冊與 Cookbook，收錄了觸發器、SPI 呼叫與型別轉換的實作範例，供評估導入時參考。