- Alibaba Groupが開発したMySQLベースのオープンソースブランチで、OLTPとOLAP機能を統合したデータベースエンジン
- DuckDBカラム型エンジンを内蔵し、分析クエリで最大200倍高速な性能を提供
- HNSWベースのベクトル検索をサポートし、最大16,383次元のAI・ML埋め込み処理を実行
- 既存のMySQLツール・ドライバと100%互換で、追加学習なしですぐに利用可能
- Alibaba Cloudの大規模な本番環境で検証された技術として、AI・分析ワークロード統合型データベースとして注目
AliSQL概要
- AliSQLはAlibaba Groupが開発したMySQLのエンタープライズ向けブランチで、DuckDB OLAPエンジンとネイティブベクトル検索機能を統合
- Alibabaの本番環境で数百万のデータベースを運用しながら検証されたシステム
- MySQLのInnoDB OLTPの安定性とDuckDBの高速分析性能を組み合わせ
- すべての機能は既存のMySQLインターフェースを通じて利用可能
主な性能と特徴
- DuckDB Storage Engineはカラム型OLAPエンジンで、自動圧縮をサポートし、分析ワークロードに最適化
- InnoDB比で最大200倍高速な分析クエリ処理速度を提供
- Vector Index (VIDX) はHNSWアルゴリズムベースのベクトル保存と近似最近傍探索（ANN）をサポート
- COSINEおよびEUCLIDEAN距離計算をサポートし、最大16,383次元ベクトルを処理可能
- MySQL 100%互換性を維持し、既存のSQL、ドライバ、ツールをそのまま利用可能
今後の開発ロードマップ
- 2025年第4四半期までにDuckDBエンジン、Vector Index、オープンソース公開を完了
- 2026年以降に予定されている機能
- DDL最適化: Instant DDL、並列B+ツリー作成、ノンブロッキングロック
- RTO最適化: 高速クラッシュリカバリ、最小RTO
- Replication Boost: 並列Binlog Flush、Binlog in Redo、大規模トランザクション最適化
使用例
- DuckDB分析テーブルの作成とクエリ
- DuckDBエンジンでテーブルを作成し、月次売上集計クエリを実行すると、InnoDB比で200倍高速に処理
- AIアプリケーション向けベクトル検索
- 768次元ベクトルカラムを含むテーブルを作成し、HNSWインデックスを通じてコサイン距離ベースの類似度検索を実行
オープンソースとコミュニティ
- 2025年12月にオープンソース公開、Alibaba Cloud Databaseチームが中心となって開発・管理し、保守を担当
- GPL-2.0ライセンスで配布、MySQLと同じライセンス体系
- GitHub Issuesを通じてバグ報告や機能提案が可能
- Alibaba Cloud RDSでDuckDBベースの分析インスタンスとして商用サービスを提供
1件のコメント
Hacker Newsのコメント
DuckDBをストレージエンジンとして使うアプローチが興味深い
既存のMySQL接続、ツール群、レプリケーション構造をそのまま維持しつつ、分析クエリだけをカラム指向エンジンにルーティングできる
別途分析用DBを立てて同期パイプラインを作るより、運用面ではるかにシンプル
ただし、InnoDBとDuckDB間のデータ一貫性をどう維持するかが核心になる
詳細はAliSQL DuckDBドキュメントにまとまっている
binlogのバッチ転送や書き込み処理などでさまざまな最適化が行われている
log_binがオフのときはDuckDBトランザクションをGTID記録前にコミットし、障害復旧時にはidempotentな方式で再適用するlog_binがオンのときはBinlogを直接使い、DuckDBに有効なBinlog位置を記録して失敗時にはその位置までロールバックする結果として、replicaの
gtid_executedがprimaryと一致していればDuckDBのデータも整合する今後10年のSQLデータベースの進化は3段階になると見ている
古いデータの参照が少し遅くなるだけで、それ以外は完全に統合されたクエリ体験を提供する
pg_duckdbと比べてどんな違いがあるのか気になる
Postgresの拡張メカニズムのおかげで、pg_duckdbはかなりきれいに見える
このシステムがSAP HANAのように、トランザクションワークロードのデータをリアルタイムでDuckDBに供給するのか気になる
もしそうなら、KafkaやDebeziumでデータウェアハウスを同期していた複雑な作業が大きく減るはず
apavloの意見も聞いてみたい
HTAPの時代が本格的に来たように思う
こうしたハイブリッドデータベースの採用が増えているのは興味深い
特にAliSQL DuckDBドキュメントで説明されているトランザクション処理の改善が印象的
ベーステーブルと分析テーブルの間の同期を高速かつトランザクション単位で保証している点がすばらしい
Materializeのようなシステムと一貫性保証はそれほど変わらない
実際、こうした試みは以前からあり、MySQL/PostgresにOLAPストレージエンジンを組み合わせる例も多かった
従来型DBに組み込みカラム型エンジンを付けるのは、生産性と運用の単純さの面で大きな利点がある
今はPG + Tiger Dataの組み合わせを使っているが、MySQL側にはこうした代替がなかった
今回の試みはその空白を埋めるかもしれない
最近はvector storage typeも追加されており、Alibabaの実装との性能比較が興味深い
Postgresがよく話題になるが、MariaDBもかなり多芸だ
接続が2つ必要ではあるが、かなりうまく動く
ClickHouseのように高速なcountだけ欲しいのに、全同期プロセスを経ないといけないのが面倒
TimeSeriesは特定用途向けに最適化されているので、一般用途には使いづらい
行指向と列指向のデータの両方をサポートしているが、MySQL互換であってコードベースは異なる
そのため完全なMySQL拡張ではない
この機能をMySQL Operatorと組み合わせてデプロイするのがどれだけ簡単か気になる
一見すると、PSQLのFDWをDuckDBとVector Storageでさらに緊密に統合した版のように見える
Vespaにも似た印象で、なぜFDW方式ではなくMySQL拡張を選んだのか興味深い
コミット履歴が妙だ
2022年に2件、2024〜2026年に数件しかなく、最初のコミットが「First commit, Support DuckDB Engine」になっている
社内版はJira参照、製品情報、中国語コメントなどで複雑だったのかもしれない
そのため、きれいな公開用git履歴を新たに作ったのだろう
TiDBがClickHouseではなくDuckDBを使っていたらどうなっていたか気になる