AliSQL - Fork MySQL mã nguồn mở của Alibaba, tích hợp vector và engine DuckDB

 (github.com/alibaba)
10 điểm bởi GN⁺ 2026-02-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một nhánh mã nguồn mở dựa trên MySQL do Alibaba Group phát triển, tích hợp engine cơ sở dữ liệu hợp nhất cả OLTP và OLAP
  • Tích hợp sẵn engine dạng cột DuckDB, mang lại hiệu năng nhanh hơn tới 200 lần cho các truy vấn phân tích
  • Hỗ trợ tìm kiếm vector dựa trên HNSW, xử lý embedding AI·ML với tối đa 16.383 chiều
  • Tương thích 100% với các công cụ·driver MySQL hiện có, có thể dùng ngay mà không cần học thêm
  • Công nghệ đã được kiểm chứng trong môi trường production quy mô lớn của Alibaba Cloud, nổi bật như một cơ sở dữ liệu hợp nhất cho workload AI·phân tích

Tổng quan về AliSQL

  • AliSQL là nhánh MySQL cấp doanh nghiệp do Alibaba Group phát triển, tích hợp engine OLAP DuckDB và chức năng tìm kiếm vector native
    • Hệ thống đã được kiểm chứng khi vận hành hàng triệu cơ sở dữ liệu trong môi trường production của Alibaba
  • Kết hợp độ ổn định OLTP của InnoDB trong MySQL với hiệu năng phân tích tốc độ cao của DuckDB
  • Mọi tính năng đều có thể truy cập thông qua giao diện MySQL hiện có

Hiệu năng và đặc điểm chính

  • DuckDB Storage Engine là engine OLAP dạng cột, hỗ trợ nén tự động và được tối ưu cho workload phân tích
    • Cung cấp tốc độ xử lý truy vấn phân tích nhanh hơn tới 200 lần so với InnoDB
  • Vector Index (VIDX) hỗ trợ lưu trữ vector và tìm kiếm láng giềng gần đúng (ANN) dựa trên thuật toán HNSW
    • Hỗ trợ tính khoảng cách COSINE và EUCLIDEAN, có thể xử lý vector tối đa 16.383 chiều
  • Duy trì khả năng tương thích MySQL 100%, nên có thể tiếp tục sử dụng nguyên trạng SQL, driver và công cụ hiện có

Lộ trình phát triển sắp tới

  • Hoàn tất engine DuckDB, Vector Index, và công bố mã nguồn mở vào quý 4 năm 2025
  • Các tính năng được lên kế hoạch từ năm 2026 trở đi
    • Tối ưu hóa DDL: instant DDL, tạo B+tree song song, khóa non-blocking
    • Tối ưu hóa RTO: phục hồi sau crash nhanh, RTO tối thiểu
    • Replication Boost: Binlog Flush song song, Binlog in Redo, tối ưu hóa giao dịch dung lượng lớn

Ví dụ sử dụng

  • Tạo bảng phân tích DuckDB và truy vấn
    • Khi tạo bảng bằng engine DuckDB rồi chạy truy vấn tổng hợp doanh thu theo tháng, tốc độ xử lý nhanh hơn 200 lần so với InnoDB
  • Tìm kiếm vector cho ứng dụng AI
    • Sau khi tạo bảng có cột vector 768 chiều, thực hiện tìm kiếm độ tương đồng dựa trên khoảng cách cosine thông qua chỉ mục HNSW

Mã nguồn mở và cộng đồng

  • Công bố mã nguồn mở vào tháng 12/2025, do đội ngũ Alibaba Cloud Database chủ trì phát triển, quản lý và bảo trì
  • Phát hành theo giấy phép GPL-2.0, cùng hệ thống giấy phép với MySQL
  • Có thể gửi báo cáo lỗi và đề xuất tính năng thông qua GitHub Issues
  • Cung cấp dịch vụ thương mại trên Alibaba Cloud RDS dưới dạng instance phân tích dựa trên DuckDB

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-05
Ý kiến trên Hacker News

  • Cách tiếp cận dùng DuckDB làm storage engine khá thú vị
    Có thể giữ nguyên kết nối MySQL, tooling và cấu trúc replication hiện có, đồng thời chỉ định tuyến các truy vấn phân tích sang engine dạng cột
    Về vận hành, cách này đơn giản hơn nhiều so với việc dựng một DB phân tích riêng và tạo pipeline đồng bộ hóa
    Tuy vậy, điểm mấu chốt là làm sao duy trì tính nhất quán dữ liệu giữa InnoDB và DuckDB

    • Giới thiệu cách triển khai node Columnar Store (DuckDB) chỉ đọc bằng cách tận dụng cơ chế binlog của MySQL
      Chi tiết được tổng hợp trong tài liệu AliSQL DuckDB
      Đã thực hiện nhiều tối ưu hóa trong việc truyền binlog theo lô, thao tác ghi, v.v.
    • Để giải quyết vấn đề nhất quán dữ liệu, hệ thống sử dụng replication dựa trên GTID
      Khi log_bin tắt, transaction DuckDB được commit trước khi ghi GTID, và khi khôi phục sự cố sẽ được áp dụng lại theo cách idempotent
      Khi log_bin bật, hệ thống dùng trực tiếp Binlog, đồng thời ghi lại vị trí Binlog hợp lệ trong DuckDB để có thể rollback đến vị trí đó nếu xảy ra lỗi
      Kết quả là nếu gtid_executed của replica khớp với primary thì dữ liệu trong DuckDB cũng nhất quán

  • Hướng tiến hóa của cơ sở dữ liệu SQL trong 10 năm tới được nhìn theo ba giai đoạn

    1. Tích hợp engine OLAP vào engine OLTP hiện có và chuyển tiếp truy vấn
    2. Thiết kế lại để hai engine dùng lớp lưu trữ chung
    3. Cuối cùng hợp nhất hoàn toàn các engine, tự động nén/lưu trữ dữ liệu cũ và khi cần thì nạp lại từ remote storage
      Việc truy vấn dữ liệu cũ chỉ chậm hơn một chút, còn lại sẽ mang đến trải nghiệm truy vấn hợp nhất hoàn toàn

  • Tò mò không biết so với pg_duckdb thì sẽ khác biệt như thế nào
    Nhờ cơ chế extension của Postgres, pg_duckdb trông khá gọn gàng

    • (bình luận đã bị xóa)

  • Tò mò liệu hệ thống này có giống SAP HANA, tức là cấp dữ liệu của workload giao dịch sang DuckDB theo thời gian thực hay không
    Nếu vậy thì những công việc phức tạp kiểu đồng bộ data warehouse bằng Kafka hay Debezium sẽ giảm đi đáng kể
    Cũng muốn nghe ý kiến của apavlo

  • Có vẻ như thời đại HTAP đang thực sự bắt đầu
    Thật thú vị khi những cơ sở dữ liệu lai như thế này ngày càng được chấp nhận
    Đặc biệt ấn tượng với các cải tiến xử lý transaction được mô tả trong tài liệu AliSQL DuckDB
    Việc đảm bảo đồng bộ nhanh và ở cấp độ transaction giữa bảng gốc và bảng phân tích là rất hay

    • Nhưng có lẽ đây chưa phải HTAP đúng nghĩa, mà gần hơn với việc gói hai DB dưới một giao diện
      Về đảm bảo nhất quán, nó không khác quá nhiều so với các hệ thống như Materialize
      Thực ra các thử nghiệm kiểu này đã có từ lâu, và cũng có nhiều trường hợp gắn engine lưu trữ OLAP vào MySQL/Postgres

  • Việc gắn engine dạng cột nhúng vào DB truyền thống mang lại lợi ích lớn về năng suất và độ đơn giản trong vận hành
    Hiện tại đang dùng tổ hợp PG + Tiger Data, nhưng phía MySQL trước giờ chưa có lựa chọn tương tự
    Có vẻ lần thử này có thể lấp khoảng trống đó

    • MariaDB đã có engine ColumnStore
      Gần đây còn bổ sung vector storage type, nên sẽ rất thú vị khi so sánh hiệu năng với cách triển khai của Alibaba
      Postgres thường được nhắc nhiều, nhưng MariaDB cũng khá đa năng
    • ClickHouse hỗ trợ native giao thức MySQL, đồng thời cũng có thể bọc hoặc nhập các bảng MySQL
      Dù cần hai kết nối, nó vẫn hoạt động khá tốt
    • Tò mò không biết Tiger Data có thể được dùng như một column store đơn thuần hay không
      Chỉ cần count nhanh như ClickHouse, nhưng việc phải đi qua toàn bộ quá trình đồng bộ khiến mọi thứ khá phiền
      TimeSeries được tối ưu cho mục đích cụ thể nên dùng chung thì hơi khó
    • TiDB cũng là một lựa chọn
      Nó hỗ trợ cả dữ liệu dạng hàng và dạng cột, nhưng chỉ tương thích MySQL chứ không dùng chung codebase
      Vì vậy đây không phải là extension MySQL hoàn chỉnh
    • MariaDB đã hỗ trợ bảng dạng cột

  • Tò mò không biết việc triển khai sẽ dễ đến đâu nếu kết hợp tính năng này với MySQL Operator

    • Chưa thử bao giờ, nhưng sau này có kế hoạch test việc tích hợp với mysql-operator

  • Thoạt nhìn, nó giống như một phiên bản tích hợp chặt chẽ hơn của FDW trong PSQL với DuckDB và Vector Storage
    Cảm giác cũng hơi giống Vespa, nên khá thú vị khi họ chọn extension MySQL thay vì cách tiếp cận FDW

    • Có lẽ là vì họ đã dùng sẵn hàng triệu dòng code MySQL

  • Lịch sử commit trông khá lạ
    Năm 2022 có 2 commit, còn giai đoạn 2024~2026 chỉ có vài commit, trong khi commit đầu tiên là “First commit, Support DuckDB Engine”

    • Khả năng cao là dự án đã được phát triển nội bộ, không công khai trong thời gian dài, rồi chỉ chắt lọc một số commit tối thiểu để public
      Bản nội bộ có thể khá rối với tham chiếu Jira, thông tin sản phẩm, chú thích tiếng Trung, v.v.
      Vì vậy có vẻ họ đã tạo lại một git history gọn gàng cho bản công khai

  • Tò mò nếu TiDB dùng DuckDB thay vì ClickHouse thì sẽ thế nào

    • Nếu DuckDB đã tồn tại như một dự án mã nguồn mở ổn định vào khoảng năm 2020, tôi tin chắc TiDB đã chọn DuckDB thay vì ClickHouse