AliSQL - ฟอร์ก MySQL แบบโอเพนซอร์สของ Alibaba ที่ผสานเวกเตอร์และเอนจิน DuckDB

 (github.com/alibaba)
10 คะแนน โดย GN⁺ 2026-02-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็น สาขาโอเพนซอร์สที่พัฒนาบน MySQL โดย Alibaba Group ซึ่งรวมความสามารถด้าน OLTP และ OLAP ไว้ในเอนจินฐานข้อมูลเดียว
  • ฝัง เอนจินคอลัมน์ DuckDB มาในตัว เพื่อมอบ ประสิทธิภาพที่เร็วขึ้นสูงสุด 200 เท่า สำหรับคิวรีเชิงวิเคราะห์
  • รองรับ การค้นหาเวกเตอร์บนพื้นฐาน HNSW และประมวลผล AI·ML embedding ได้สูงสุด 16,383 มิติ
  • เข้ากันได้กับเครื่องมือ·ไดรเวอร์ MySQL เดิม 100% ใช้งานได้ทันทีโดยไม่ต้องเรียนรู้เพิ่มเติม
  • เป็นเทคโนโลยีที่ผ่านการพิสูจน์แล้วในสภาพแวดล้อมโปรดักชันขนาดใหญ่ของ Alibaba Cloud และกำลังได้รับความสนใจในฐานะ ฐานข้อมูลแบบบูรณาการสำหรับเวิร์กโหลด AI·การวิเคราะห์

ภาพรวมของ AliSQL

  • AliSQL คือ สาขาระดับองค์กรของ MySQL ที่พัฒนาโดย Alibaba Group โดยผสาน เอนจิน OLAP ของ DuckDB และ ความสามารถค้นหาเวกเตอร์แบบเนทีฟ
    • เป็นระบบที่ผ่านการตรวจสอบแล้วจากการใช้งานฐานข้อมูลนับล้านในสภาพแวดล้อมโปรดักชันของ Alibaba
  • ผสาน เสถียรภาพ OLTP ของ InnoDB เข้ากับ สมรรถนะการวิเคราะห์ความเร็วสูงของ DuckDB
  • ทุกความสามารถเข้าถึงได้ผ่าน อินเทอร์เฟซ MySQL เดิม

ประสิทธิภาพและคุณสมบัติหลัก

  • DuckDB Storage Engine เป็นเอนจิน OLAP แบบคอลัมน์ที่รองรับการบีบอัดอัตโนมัติ และปรับให้เหมาะกับเวิร์กโหลดการวิเคราะห์
    • ให้ ความเร็วในการประมวลผลคิวรีวิเคราะห์สูงสุด 200 เท่า เมื่อเทียบกับ InnoDB
  • Vector Index (VIDX) รองรับการจัดเก็บเวกเตอร์และการค้นหาเพื่อนบ้านใกล้เคียงโดยประมาณ (ANN) บนพื้นฐาน อัลกอริทึม HNSW
    • รองรับ การคำนวณระยะทางแบบ COSINE และ EUCLIDEAN และประมวลผล เวกเตอร์ได้สูงสุด 16,383 มิติ
  • คงไว้ซึ่ง ความเข้ากันได้กับ MySQL 100% จึงสามารถใช้ SQL, ไดรเวอร์ และเครื่องมือเดิมได้ทันที

โรดแมปการพัฒนาในอนาคต

  • ภายในไตรมาส 4 ปี 2025 จะเปิดให้ใช้งานแบบโอเพนซอร์สครบทั้ง DuckDB engine, Vector Index
  • ความสามารถที่วางแผนไว้หลังปี 2026
    • การปรับแต่ง DDL: instant DDL, การสร้าง B+tree แบบขนาน, non-blocking lock
    • การปรับแต่ง RTO: การกู้คืนหลังแครชที่รวดเร็ว, RTO ต่ำสุด
    • Replication Boost: parallel Binlog Flush, Binlog in Redo, การปรับแต่งทรานแซกชันขนาดใหญ่

ตัวอย่างการใช้งาน

  • การสร้างและคิวรีตารางวิเคราะห์ด้วย DuckDB
    • หลังสร้างตารางด้วยเอนจิน DuckDB การรันคิวรีสรุปยอดขายรายเดือนทำได้เร็วกว่า InnoDB ถึง 200 เท่า
  • การค้นหาเวกเตอร์สำหรับงาน AI
    • หลังสร้างตารางที่มีคอลัมน์เวกเตอร์ 768 มิติ สามารถทำ การค้นหาความคล้ายคลึงด้วยระยะทาง cosine ผ่าน ดัชนี HNSW ได้

โอเพนซอร์สและชุมชน

  • จะเปิดเป็นโอเพนซอร์สในเดือนธันวาคม 2025 โดยทีม Alibaba Cloud Database เป็นผู้พัฒนา ดูแล และบำรุงรักษาหลัก
  • เผยแพร่ภายใต้ สัญญาอนุญาต GPL-2.0 ซึ่งเป็นรูปแบบเดียวกับ MySQL
  • สามารถรายงานบั๊กและเสนอฟีเจอร์ผ่าน GitHub Issues
  • ให้บริการเชิงพาณิชย์บน Alibaba Cloud RDS ในรูปแบบ อินสแตนซ์วิเคราะห์ที่ใช้ DuckDB

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-05
ความคิดเห็นจาก Hacker News

  • แนวทางที่ใช้ DuckDB เป็น storage engine น่าสนใจมาก
    สามารถคงการเชื่อมต่อ MySQL, เครื่องมือ, และโครงสร้างการทำ replication เดิมไว้ได้ตามเดิม ขณะที่ส่งต่อเฉพาะ query เชิงวิเคราะห์ไปยังเอนจินแบบคอลัมน์
    ในแง่การปฏิบัติการแล้วง่ายกว่าการตั้งฐานข้อมูลสำหรับงานวิเคราะห์แยกต่างหากและสร้าง pipeline สำหรับซิงก์ข้อมูลมาก
    แต่ประเด็นสำคัญคือจะรักษา ความสอดคล้องของข้อมูล ระหว่าง InnoDB กับ DuckDB อย่างไร

    • มีการอธิบายวิธีใช้ กลไก binlog ของ MySQL เพื่อสร้างโหนด Columnar Store (DuckDB) แบบอ่านอย่างเดียว
      รายละเอียดมีสรุปไว้ใน เอกสาร AliSQL DuckDB
      มีการทำ optimization หลายอย่างทั้งในส่วนการส่ง binlog แบบ batch และการดำเนินการเขียน
    • เพื่อแก้ปัญหาความสอดคล้องของข้อมูล มีการใช้ replication แบบอิง GTID
      เมื่อปิด log_bin จะ commit ธุรกรรมของ DuckDB ก่อนบันทึก GTID และเมื่อกู้คืนจากความขัดข้องจะนำกลับมาใช้ใหม่แบบ idempotent
      เมื่อเปิด log_bin จะใช้ binlog โดยตรง และบันทึก ตำแหน่ง Binlog ที่มีผล ไว้ใน DuckDB เพื่อให้ rollback กลับถึงตำแหน่งนั้นได้เมื่อเกิดความล้มเหลว
      ผลลัพธ์คือถ้า gtid_executed ของ replica ตรงกับ primary ข้อมูลใน DuckDB ก็จะสอดคล้องกันด้วย

  • มองทิศทางวิวัฒนาการของฐานข้อมูล SQL ในอีก 10 ปีข้างหน้าเป็น 3 ขั้น

    1. รวม OLAP engine เข้ากับ OLTP engine เดิมและทำ query forwarding
    2. ออกแบบใหม่ให้ทั้งสองเอนจินใช้ storage layer ร่วมกัน
    3. ท้ายที่สุดรวมเอนจินเข้าด้วยกันอย่างสมบูรณ์ แล้วพัฒนาไปเป็นโครงสร้างที่บีบอัดและเก็บถาวรเรคอร์ดเก่าโดยอัตโนมัติ และดึงกลับจาก remote storage ได้เมื่อจำเป็น
      การอ่านข้อมูลเก่าจะช้าลงเล็กน้อยเท่านั้น ส่วนที่เหลือจะมอบประสบการณ์ query แบบรวมเป็นหนึ่งเดียวอย่างสมบูรณ์

  • สงสัยว่าถ้าเทียบกับ pg_duckdb แล้วจะแตกต่างกันอย่างไร
    ด้วยกลไกส่วนขยายของ Postgres ทำให้ pg_duckdb ดูค่อนข้างเรียบร้อยดี

    • (ความคิดเห็นถูกลบ)

  • สงสัยว่าระบบนี้จะป้อนข้อมูลงานธุรกรรมเข้า DuckDB แบบเรียลไทม์เหมือน SAP HANA หรือไม่
    ถ้าใช่ งานซับซ้อนในการซิงก์ data warehouse ด้วย Kafka หรือ Debezium ก็น่าจะลดลงมาก
    อยากฟังความเห็นของ apavlo ด้วย

  • ดูเหมือนว่ายุคของ HTAP จะมาถึงอย่างจริงจังแล้ว
    น่าสนใจที่ ฐานข้อมูลไฮบริด แบบนี้ถูกนำไปใช้มากขึ้นเรื่อย ๆ
    โดยเฉพาะการปรับปรุงการประมวลผลธุรกรรมที่อธิบายไว้ใน เอกสาร AliSQL DuckDB นั้นน่าประทับใจ
    การรับประกันการซิงก์ระหว่างตารางหลักกับตารางสำหรับงานวิเคราะห์ได้อย่างรวดเร็วและ ในระดับธุรกรรม เป็นสิ่งที่ยอดเยี่ยม

    • แต่สิ่งนี้ใกล้เคียงกับการ ผูก DB สองตัวเข้าด้วยกัน ผ่านอินเทอร์เฟซเดียว มากกว่าจะเป็น HTAP ที่แท้จริง
      การรับประกันความสอดคล้องก็ไม่ได้ต่างจากระบบอย่าง Materialize มากนัก
      จริง ๆ แล้วความพยายามแบบนี้มีมานานแล้ว และก็มีหลายกรณีที่เพิ่ม OLAP storage engine ให้กับ MySQL/Postgres

  • การเพิ่ม embedded columnar engine ให้กับ DB แบบดั้งเดิมมีข้อดีมากในแง่ productivity และความเรียบง่ายในการปฏิบัติการ
    ตอนนี้ใช้งานชุด PG + Tiger Data อยู่ แต่ฝั่ง MySQL ยังไม่มีทางเลือกแบบนี้
    ความพยายามครั้งนี้ดูเหมือนจะช่วยเติมช่องว่างนั้นได้

    • MariaDB ก็มี ColumnStore engine อยู่แล้ว
      ช่วงหลังยังเพิ่ม vector storage type เข้ามาด้วย จึงน่าสนใจที่จะเปรียบเทียบประสิทธิภาพกับของ Alibaba
      คนมักพูดถึง Postgres บ่อย แต่ MariaDB ก็สารพัดประโยชน์ไม่น้อย
    • ClickHouse รองรับ MySQL protocol แบบเนทีฟ และยังสามารถห่อหุ้มหรือนำเข้าตาราง MySQL ได้ด้วย
      แม้จะต้องใช้การเชื่อมต่อสองชุด แต่ก็ทำงานได้ค่อนข้างดี
    • สงสัยว่าสามารถใช้ Tiger Data เป็นเพียง column store ได้หรือไม่
      ต้องการแค่ count ที่เร็วแบบ ClickHouse แต่การต้องผ่านกระบวนการซิงก์ทั้งหมดนั้นยุ่งยาก
      TimeSeries ถูกปรับให้เหมาะกับงานเฉพาะทาง จึงใช้งานทั่วไปได้ลำบาก
    • TiDB ก็เป็นอีกตัวเลือกหนึ่ง
      รองรับทั้ง ข้อมูลแบบ Row และแบบ Column แต่เข้ากันได้กับ MySQL เท่านั้น ไม่ได้ใช้ codebase เดียวกัน
      เพราะฉะนั้นจึงไม่ใช่ส่วนขยายของ MySQL แบบสมบูรณ์
    • MariaDB รองรับ ตารางแบบคอลัมน์ อยู่แล้ว

  • สงสัยว่าจะ deploy ฟีเจอร์นี้ร่วมกับ MySQL Operator ได้ง่ายแค่ไหน

    • ยังไม่เคยลอง แต่มีแผนจะทดสอบ การรวมกับ mysql-operator ในภายหลัง

  • ดูเผิน ๆ แล้วเหมือนเวอร์ชันของ FDW ใน PSQL ที่รวมกับ DuckDB และ Vector Storage แบบ แน่นแฟ้นยิ่งขึ้น
    ให้ความรู้สึกคล้าย Vespa ด้วย เลยสงสัยว่าทำไมถึงเลือกส่วนขยายของ MySQL แทนแนวทาง FDW

    • น่าจะเป็นเพราะใช้งาน โค้ด MySQL หลายล้านบรรทัด อยู่แล้ว

  • ประวัติ commit ดูแปลก ๆ
    ในปี 2022 มี 2 รายการ และในปี 2024~2026 ก็มีเพียงไม่กี่รายการ แต่ commit แรกคือ “First commit, Support DuckDB Engine”

    • เป็นไปได้สูงว่าน่าจะพัฒนาแบบ ภายในที่ไม่เปิดเผยสาธารณะ มาก่อน แล้วค่อยจัดระเบียบเหลือเพียง commit ขั้นต่ำสำหรับการเปิดเผย
      เวอร์ชันภายในอาจซับซ้อนเพราะมีการอ้างอิง Jira, ข้อมูลผลิตภัณฑ์, คอมเมนต์ภาษาจีน ฯลฯ
      เลยเหมือนสร้าง git history สำหรับเผยแพร่สาธารณะแบบสะอาดขึ้นมาใหม่

  • สงสัยว่าถ้า TiDB ใช้ DuckDB แทน ClickHouse จะเป็นอย่างไร

    • ถ้า DuckDB มีสถานะเป็น โอเพนซอร์สที่เสถียร ตั้งแต่ราวปี 2020 ก็มั่นใจว่า TiDB คงเลือก DuckDB แทน ClickHouse อย่างแน่นอน