SynchDB 1.4 發布:支援 Oracle Container Database 與 TLS 加密快照複寫
PostgreSQL News · 2026-08-12
SynchDB 是一套 PostgreSQL extension,讓 PostgreSQL/IvorySQL 可以即時同步來自異質資料庫(Oracle、MySQL、SQL Server、PostgreSQL)的資料,同時提供初始 snapshot 與 CDC(change data capture)兩種路徑。本次 1.4 版的重點是把 Oracle Container Database(CDB/PDB)架構納入所有三條 Oracle 複寫路徑。官方公告與對應的 GitHub release notes 列出了完整改動。
核心改動
Oracle 19c 之後推行的 Container Database 架構把單一資料庫拆成一個 CDB(container database)與多個 PDB(pluggable database)。SynchDB 1.4 讓透過內嵌 Debezium engine 的 CDC 連接器、透過 oracle_fdw 的初始 snapshot,以及透過 Openlog Replicator(OLR)的 log-based 複寫,都能以 CDB/PDB 格式(例如 FREE/FREEPDB1)指定來源資料庫,並已針對 Oracle 23ai 做過測試。
安全連線方面新增了 synchdb_add_fdw_conninfo() function,讓透過 FDW 做初始 snapshot 時能走加密連線:MySQL 與 PostgreSQL 來源用 TLS,Oracle 與 OLR 來源則改用 Oracle Wallet。另外新增 synchdb_set_dbz_loglevel(),可以在連接器執行中直接調整 Debezium 的 log 等級,不用重啟連接器就能做診斷。
-- 範例:指定 Oracle CDB/PDB 來源
SELECT synchdb_add_fdw_conninfo(
'FREE/FREEPDB1', 'host=... wallet_location=...'
);
SELECT synchdb_set_dbz_loglevel('oracle_conn', 'DEBUG');影響範圍
底層 Debezium engine 從 2.6.2.Final 升級到 3.5.2.Final,一併帶上更新版的 Kafka Connect、Jackson 與 Log4j2,修補了上游的既有問題與安全更新。GitHub release notes 也列出多項穩定性修復:修正高負載持續複寫下的當機、data format converter 的 double-free、以及 IvorySQL 載入 OLR parser library 時的 symbol 衝突問題。
- Auto Launcher 修正:先前因寫死邏輯只會替預設
postgres資料庫啟動連接器,現在會列舉所有可連線的資料庫並各自啟動 launcher - snapshot mode
never現在僅限 MySQL 來源使用 - JNI reference leak 修復
這些變動主要影響從 Oracle 多租戶(multitenant)環境往 PostgreSQL 遷移或做即時整合的場景,尤其是原本卡在 CDB/PDB 架構無法直接對接的團隊。
iFood 如何在 ClickHouse Cloud 上打造代理式(agentic)安全平台
ClickHouse Blog · 2026-08-12
原本的問題
巴西外送平台 iFood 的資安團隊原本把事件回應平台建立在 Databricks 上,但隨著日誌量成長超過 130 TB,成本壓力讓管理層開始限制查詢時間——先是 20 分鐘上限,後來收緊到 10 分鐘。這使得分析師無法掃描威脅獵捕(threat hunting)所需的 3 到 6 個月歷史日誌,預算上限也限制了團隊能建立的告警數量。
日誌來源涵蓋基礎設施、Kubernetes、雲端主控台與稽核系統,每天光是端點偵測日誌就有 1.6 TB,總量超過 130 TB,目標是做到 6 到 12 個月的保存期。這類規模在查詢時間被砍到 10 分鐘的情況下,等同無法做真正的歷史回溯分析。
採用的方法
團隊把日誌落地到 AWS S3,再透過 ClickPipes 匯入 ClickHouse Cloud,端到端新鮮度做到 2 到 10 分鐘。分析師全程用 SQL 操作,並採用開源筆記本平台 Querybook 保留調查流程的紀錄。所謂「agentic」是指分析師先提出一個假設(例如「我們的 AWS 基礎設施是否已被入侵」),再由代理程式自動掃過日誌去驗證或排除這個假設。
系統會平行啟動五個 sub-agent,每個各自對數個月的資料跑獨立查詢,單次威脅獵捕就可能同時查詢超過 30 TB 的資料。代理程式的行為與獵捕邏輯的調整,則透過開源的 AI 可觀測性平台 Langfuse 監控,公司內部已有 500 多名員工接受過 Langfuse 相關的 agent telemetry 訓練。
實際效果
查詢效能提升 9 到 16 倍,同時成本下降 40% 到 50%。資料新鮮度從原本的每小時批次更新,變成接近即時。過去單一分析師要花一週才能完成的威脅獵捕工作,現在透過代理程式約 2 小時就能完成。
- 告警執行查詢:從每小時一次,提升到每 10 分鐘一次
- 計畫將 API/CDN 日誌從
OpenSearch遷移過來,保存成本可降低 75%,保存期同時從 7 天延長到 6 個月
原始來源:ClickHouse Blog
全新現代化 PostgreSQL JDBC 驅動程式 pg-java 亮相
PostgreSQL News · 2026-08-12
核心改動
pg-java 是由 Sehrope Sarkini(協同 Claude)從零開始寫的新 PostgreSQL JDBC 驅動程式,目前仍在 pre-release 階段,尚未發布到 Maven Central,原始程式碼在 pgjdbc/pg-java。它與現有 pgjdbc(傳統驅動)最大的差異,在於 API 是圍繞 PostgreSQL 的 wire protocol 與功能集去設計,而不是像 JDBC 規範那樣,要向所有資料庫的最小公分母妥協。專案採用與 PostgreSQL 本身相同的 PostgreSQL License。
架構上分兩層:底層是原生 API,直接對應 PostgreSQL 的能力;上層才是完整實作 java.sql.* 介面的相容層,提供 Connection、PreparedStatement、ResultSet、DatabaseMetaData、DataSource 與 XA 支援,JDBC 相容層是建立在原生 API 之上,而不是反過來讓原生 API 受限於 JDBC 的介面設計。目前已可用的功能包含 TCP/TLS 連線、SCRAM-SHA-256 驗證,以及 simple 與 extended query protocol。
影響範圍
效能設計上瞄準 Java 21 之後才有的 virtual threads:pg-java 用一般的 blocking 風格寫程式碼,但小心避免 pin 住 carrier thread(以 ReentrantLock 取代對 I/O 的 synchronized),因此可以在數千個連線上使用 virtual threads,不需要走事件迴圈或 callback API 那種寫法,等於是消除了「async/reactive API」與「一條 thread 對一個連線」這兩種模式之間的取捨。
查詢結果的核心讀取原語是 pull cursor,只讀出足夠產生下一列所需的資料,不會把整個結果集緩衝在記憶體裡,forEach、map、collect 等操作都是建立在這個 cursor 之上的介面。為了降低現有 pgjdbc 使用者的遷移成本,專案內含 postgresql-client-pgjdbc-compat 模組,刻意模仿 pgjdbc 的公開 API 與 org.postgresql.* 類型命名,官方說明中明確標註這是「遷移輔助工具,而非(目前)可認證的直接替換」。
- 目標 Java 版本:Java 21+
- 建置工具:Maven(含 checked-in 的
./mvnw) - 功能藍圖:extended query protocol、
COPY、LISTEN/NOTIFY、SSL/TLS、SCRAM 驗證