背景

阿里巴巴開源的 AliSQL 是一款基於 MySQL 的分支版本，其最受矚目的特性在於原生整合了 DuckDB 作為分析引擎，並支援向量檢索功能。這項專案旨在解決傳統關聯式資料庫在處理大規模分析（OLAP）與機器學習相關任務時的效能瓶頸，透過在 MySQL 內部嵌入列式存儲引擎，試圖在單一系統內實現混合事務與分析處理（HTAP）的能力。

社群觀點

在 Hacker News 的討論中，開發者們對於在傳統資料庫中嵌入列式引擎表現出極高的興趣。許多留言者認為，這種做法能大幅簡化運維複雜度，避免了為了加速查詢而必須維護複雜的 Kafka 或 Debezium 同步鏈路。一位使用者分享了他在 PostgreSQL 搭配 Tiger Data 的經驗，並指出在 MySQL 生態中長期缺乏類似的解決方案，因此 AliSQL 的出現填補了這塊空白。然而，也有觀點質疑這種「膠水式」的整合是否能稱作真正的 HTAP，認為這只是將兩個完全不同的資料庫封裝在同一個介面下，其事務一致性與資料同步的可靠性仍待驗證。

針對技術實作的優劣，社群展開了一場關於 MySQL 與 PostgreSQL 擴展性的深度辯論。支持 AliSQL 的開發者 baotiao 指出，MySQL 天生的插件式存儲引擎架構（Pluggable Storage Engine）使其比 PostgreSQL 更適合整合 DuckDB。他認為 PostgreSQL 雖然有 Table Access Method，但在主從複製與崩潰恢復的標準化介面上仍不如 MySQL 成熟，且 MySQL 的 Binlog 生態系能更流暢地處理資料流轉。對此，PostgreSQL 的支持者則反駁，認為透過外部資料包裝器（FDW）或擴展機制，PostgreSQL 同樣能實現高效的分析整合，並指出如 pg_lake 等專案已證明了其靈活性，認為 AliSQL 的分析過於偏向 MySQL 的既有立場。

關於資料一致性的疑慮，AliSQL 的核心開發團隊在討論中詳細解釋了其處理機制。他們利用 MySQL 的 GTID 確保事務不遺漏，並在 DuckDB 內部建立表格記錄 Binlog 的有效位置，以應對系統崩潰後的恢復需求。這種設計確保了當從庫的 GTID 與主庫一致時，DuckDB 內的分析資料也能與主庫保持同步。此外，討論也觸及了與其他競爭對手的比較，例如 MariaDB 的 ColumnStore 被批評過於簡單且缺乏索引支援，而 TiDB 雖然具備列式存儲與向量支援，但因其並非基於 MySQL 原生代碼，對於追求完全相容性的用戶來說，AliSQL 仍具備獨特的吸引力。

最後，社群也對這類混合資料庫的未來演進提出了預測。有觀點認為，未來的 SQL 資料庫將會走向統一存儲層，自動將舊資料壓縮並轉存為列式格式，甚至無縫對接遠端物件存儲。AliSQL 整合 DuckDB 的嘗試被視為這一演化過程中的重要一步，儘管目前仍處於將兩種引擎「縫合」的階段，但其降低了中小規模企業進入大數據分析的門檻，讓開發者能繼續留在熟悉的 MySQL 生態圈內處理更複雜的資料任務。

延伸閱讀

• TiDB：具備列式存儲與向量支援的 MySQL 相容資料庫。
• pg_duckdb / pg_lake：PostgreSQL 生態系中整合 DuckDB 或雲端存儲的相關專案。
• MariaDB ColumnStore：MariaDB 提供的列式存儲引擎解決方案。
• ClickHouse：常被用於與 MySQL 搭配的開源分析型資料庫，支援原生 MySQL 協議。
• OrioleDB：PostgreSQL 的新型存儲引擎，旨在提升擴展性與效能。