ClickHouse 26.8 讓資料庫本身長出一組串流 HTTP API
ClickHouse Blog · 2026-09-05
ClickHouse 26.8(LTS,2026-08-27 發布)新增一組完整的 SQL 陳述式,可以直接在資料庫內定義具名 HTTP 端點、正規表示式路由與型別化參數,不必再另外部署一層應用程式來接收請求、組查詢、回傳結果。ClickHouse 官方工程部落格在 2026-09-05 以英國房產交易資料集為例,示範如何用這組機制做出可分頁、可篩選、可串流回應的查詢 API。這篇文章聚焦在語法本身與存取控制的設計取捨。
核心改動:CREATE HANDLER 與型別化參數
新語法用 CREATE HANDLER 把一段查詢綁定到 URL 路徑,URL REGEXP 支援具名擷取群組,查詢字串或 POST 表單欄位可以直接以 {town:String}、{minimum_price:UInt32} 這種型別標註的方式解析成參數。這代表路由與型別檢查都下放到資料庫層,少了一層手動轉型與驗證的程式碼。
CREATE HANDLER town_sales_path
URL REGEXP '/api/town-sales/(?P<town>[^/]+)(?P<district_path>(?:/[^/]+)?)'
METHODS (GET)
AS
SELECT date, price, postcode
FROM uk_price_paid
WHERE town = {town:String};查詢結果可以再用一組新的 setting 做二次加工而不必改寫底層 SQL:limit、offset、filter、select、sort(URL 風格,如 -price 代表遞減)、order(標準 SQL 排序)與 page。若要讓網址上未被識別的參數自動變成 WHERE 條件,需要對使用者額外開啟 http_allow_filters_as_unrecognized_url_parameters 這個 setting。
資料表直接當端點,以及串流輸出格式
除了手寫 handler,26.8 也讓資料表本身可以直接被當成路徑存取:在 config.d/http-path-requests.yaml 開啟 http_allow_path_requests: 1,再對使用者授予 http_allow_table_as_file、http_allow_database_as_path 兩個 setting,就能用 curl 'http://localhost:8123/database/table.csv?town=LONDON&sort=-price&limit=3' 這種網址直接查表。輸出面則新增 framing 格式:JSONEachPacketString 把資料、進度、metadata 包成獨立 JSON 封包依序吐出,EventStream 則是 Base64 編碼、走 Server-Sent Events 協定的版本,讓二進位資料也能安全塞進事件流。搭配的 setting 還有 framing_output_format、send_profile_events、interactive_delay(控制進度回報間隔的毫秒數)。
影響範圍:權限模型與可觀測性
Handler 目前沒有獨立的 per-handler 權限系統——只要是已驗證使用者都能呼叫,查詢一律以呼叫者本身的權限執行。要做欄位級或列級的限縮,官方建議的模式是搭配 SQL SECURITY DEFINER 視圖:建一個以特定服務帳號身份執行的 view,只把這個 view 的 SELECT 權限授予 API 使用者,底層表格本身不開放。每一次 handler 呼叫都會記錄進 system.query_log 與新增的 system.user_query_log,並多出 http_handler_name、http_request_url 等欄位,方便事後追查是哪個端點、哪個使用者送出的查詢。
原始來源:ClickHouse Blog - ClickHouse as a streaming HTTP API、ClickHouse 26.8 Changelog
ClickHouse 26.8 新增 |> 管線運算子,查詢語法改成線性寫法
ClickHouse Blog · 2026-09-04
ClickHouse 26.8(LTS,2026-08-27 發布)在 SQL 方言中加入管線運算子 |>,讓一段查詢可以寫成一連串循序的轉換步驟,而不是傳統先寫 SELECT 再往下描述資料來源與條件的巢狀寫法。ClickHouse 工程師 Mark Needham 在 2026-09-04 發表的文章解釋,這個語法要解決的是查詢的敘述順序與實際執行順序長期不一致的問題。
背景:FROM-first 語法之後的下一步
ClickHouse 從 22.12 版開始就支援 FROM-first 語法,允許把 FROM table SELECT ... 這樣的順序寫在前面,但每個子句依然是傳統 SQL 的巢狀組合方式,讀者仍得在腦中把多層子查詢攤平才能還原資料流動的先後順序。管線語法要處理的正是這一層可讀性落差:當一段查詢需要先過濾、再彙總、再排序、再限制筆數時,巢狀寫法會把這串邏輯順序反過來寫。
核心改動:|> 運算子與 AGGREGATE / EXTEND
新語法用 |> 把每個轉換階段串接起來,每個檢查點都是一段完整、可單獨檢視的查詢階段:
FROM t
|> WHERE x > 1
|> AGGREGATE count() AS c GROUP BY y
|> ORDER BY c DESC
|> LIMIT 10;新增的關鍵字裡,AGGREGATE 用來做帶 GROUP BY 的彙總階段,EXTEND 則是在保留既有欄位的前提下,額外加入計算欄位——這對照傳統 SQL 得靠子查詢或 WITH 才能做到同樣的事。ClickHouse 在執行前會把整段管線語法轉譯成標準的巢狀 SQL,再交給既有的查詢最佳化器處理整段查詢,轉譯過程不會產生中介的物化結果。
影響範圍
因為管線語法最終仍轉譯成同一套巢狀 SQL 並走同一個最佳化器與執行引擎,語法轉換本身不改變查詢的實際執行計畫,差異只在撰寫與維護時的可讀性。這對由程式動態組裝、經常需要一段段疊加篩選與彙總條件的查詢(例如 ETL 或報表產生器產出的查詢字串)較為受用,因為每個 |> 階段都能單獨插入或刪除,不必重新調整外層子查詢的巢狀層級。官方文章沒有附上與傳統寫法的效能比較數字。
原始來源:ClickHouse Blog - Pipelined SQL in ClickHouse 26.8、ClickHouse 26.8 Changelog