AliSQL - Alibaba'nın açık kaynak MySQL fork'u, vektör ve DuckDB motoru entegrasyonu

• Alibaba Group tarafından geliştirilen, MySQL tabanlı açık kaynak bir dal; OLTP ve OLAP işlevlerini tek bir veritabanı motorunda birleştiriyor
• Yerleşik DuckDB sütun tabanlı motoru sayesinde analitik sorgularda 200 kata kadar daha hızlı performans sunuyor
• HNSW tabanlı vektör aramayı destekliyor ve en fazla 16.383 boyutlu AI·ML embedding işlemleri gerçekleştirebiliyor
• Mevcut MySQL araçları ve sürücüleriyle %100 uyumlu; ek eğitim gerektirmeden hemen kullanılabiliyor
• Alibaba Cloud'un büyük ölçekli production ortamında doğrulanmış bir teknoloji olarak, AI·analitik iş yüklerini birleştiren veritabanı yaklaşımıyla öne çıkıyor

---

AliSQL genel bakış

• AliSQL, Alibaba Group tarafından geliştirilen kurumsal düzeyde bir MySQL dalı olup, DuckDB OLAP motoru ile yerel vektör arama özelliklerini entegre ediyor
  • Alibaba'nın production ortamında milyonlarca veritabanı çalıştırılarak doğrulanmış bir sistem
• MySQL'in InnoDB OLTP kararlılığını DuckDB'nin yüksek hızlı analitik performansıyla birleştiriyor
• Tüm özelliklere mevcut MySQL arayüzü üzerinden erişilebiliyor

Temel performans ve özellikler

• DuckDB Storage Engine, sütun tabanlı bir OLAP motorudur; otomatik sıkıştırmayı destekler ve analitik iş yükleri için optimize edilmiştir
  • InnoDB'ye kıyasla analitik sorgu işlemede 200 kata kadar daha yüksek hız sağlar
• Vector Index (VIDX), HNSW algoritması tabanlı vektör depolama ve yaklaşık en yakın komşu aramayı (ANN) destekler
  • COSINE ve EUCLIDEAN uzaklık hesaplamalarını destekler; en fazla 16.383 boyutlu vektörleri işleyebilir
• MySQL ile %100 uyumluluğu koruyarak mevcut SQL, sürücüler ve araçların doğrudan kullanılmasına imkan tanır

Gelecek geliştirme yol haritası

• 2025'in 4. çeyreğine kadar DuckDB motoru, Vector Index ve açık kaynak yayınlama sürecinin tamamlanması
• 2026 sonrası planlanan özellikler
  • DDL optimizasyonu: instant DDL, paralel B+tree oluşturma, non-blocking lock
  • RTO optimizasyonu: hızlı crash recovery, minimum RTO
  • Replication Boost: paralel Binlog Flush, Binlog in Redo, büyük hacimli transaction optimizasyonu

Kullanım örnekleri

• DuckDB analitik tablo oluşturma ve sorgulama
  • DuckDB motoruyla tablo oluşturup aylık satış toplulaştırma sorgusu çalıştırıldığında, InnoDB'ye göre 200 kat daha hızlı işleme elde edilebilir
• AI uygulamaları için vektör arama
  • 768 boyutlu vektör sütunu içeren bir tablo oluşturulduktan sonra, HNSW indeksi üzerinden cosine distance tabanlı benzerlik araması yapılabilir

Açık kaynak ve topluluk

• Aralık 2025'te açık kaynak olarak yayınlanacak; Alibaba Cloud Database ekibi tarafından aktif biçimde geliştirilecek, yönetilecek ve bakımı yapılacak
• GPL-2.0 lisansı ile dağıtılıyor; MySQL ile aynı lisans yapısı kullanılıyor
• Hata raporları ve özellik önerileri GitHub Issues üzerinden iletilebilir
• Alibaba Cloud RDS üzerinde DuckDB tabanlı analitik instance olarak ticari hizmet sunuluyor

[GN⁺]

Hacker News yorumları

• DuckDB’yi depolama motoru olarak kullanma yaklaşımı ilgi çekici
  Mevcut MySQL bağlantıları, araçları ve replikasyon yapısı aynen korunurken yalnızca analitik sorgular sütun tabanlı motora yönlendirilebilir
  Ayrı bir analitik veritabanı kurup senkronizasyon hattı oluşturmaktan operasyonel olarak çok daha basit
  Ancak asıl kilit nokta, InnoDB ile DuckDB arasında veri tutarlılığının nasıl korunacağı

  • MySQL’in binlog mekanizmasını kullanarak salt okunur bir Columnar Store (DuckDB) düğümünün nasıl uygulanacağı anlatılıyor
    Ayrıntılar AliSQL DuckDB dokümanında özetlenmiş
    binlog toplu aktarımı, yazma işlemleri ve benzeri alanlarda çeşitli optimizasyonlar yapılmış
  • Veri tutarlılığı sorununu çözmek için GTID tabanlı replikasyon kullanılıyor
    log_bin kapalıyken DuckDB işlemi GTID kaydı yazılmadan önce commit ediliyor ve hata kurtarma sırasında idempotent biçimde yeniden uygulanıyor
    log_bin açıkken ise Binlog doğrudan kullanılıyor ve DuckDB’ye geçerli Binlog konumu kaydedilerek hata durumunda bu konuma kadar geri alınıyor
    Sonuç olarak replica’daki gtid_executed, primary ile eşleşiyorsa DuckDB verisi de tutarlı oluyor

• Önümüzdeki 10 yılda SQL veritabanlarının evrim yönünün üç aşamada olacağı düşünülüyor

  1. Mevcut OLTP motoruna OLAP motoru entegre etmek ve sorguları yönlendirmek
  2. İki motorun ortak bir depolama katmanı kullanacağı şekilde yeniden tasarlanması
  3. Sonunda motorların tamamen birleşerek eski kayıtları otomatik sıkıştıran ve arşivleyen, gerekirse uzak depolamadan geri çağıran bir yapıya evrilmesi
     Eski verileri sorgulamak sadece biraz daha yavaş olur, geri kalan her şey tamamen birleşik bir sorgu deneyimi sunar

• pg_duckdb ile karşılaştırıldığında farkın ne olacağı merak ediliyor
  Postgres’in eklenti mekanizması sayesinde pg_duckdb oldukça temiz görünüyor

  • (silinmiş yorum)

• Bu sistemin, SAP HANA gibi işlem iş yükü verilerini gerçek zamanlı olarak DuckDB’ye besleyip beslemediği merak ediliyor
  Eğer öyleyse Kafka ya da Debezium ile veri ambarını senkronize etmeye yönelik karmaşık işler ciddi ölçüde azalır
  apavlo’nun görüşü de merak ediliyor

• Görünüşe göre HTAP çağı artık gerçekten geldi
  Bu tür hibrit veritabanlarının giderek daha fazla benimsenmesi ilginç
  Özellikle AliSQL DuckDB dokümanında açıklanan işlem işleme iyileştirmeleri etkileyici
  Temel tablolar ile analitik tablolar arasındaki senkronizasyonun hızlı ve işlem düzeyinde garanti edilmesi çok iyi

  • Ancak bu, gerçek bir HTAP’ten ziyade iki veritabanını tek bir arayüz altında birleştiren bir yapıya daha yakın
    Materialize gibi sistemlerle olan tutarlılık garantisi çok farklı değil
    Aslında bu tür denemeler eskiden beri vardı ve MySQL/Postgres’e OLAP depolama motoru eklenen pek çok örnek bulunuyor

• Geleneksel bir veritabanına gömülü sütun tabanlı bir motor eklemek, üretkenlik ve operasyonel sadelik açısından büyük avantaj sağlıyor
  Şu anda PG + Tiger Data kombinasyonu kullanılıyor ama MySQL tarafında böyle bir alternatif yoktu
  Bu girişim o boşluğu doldurabilir gibi görünüyor

  • MariaDB’de zaten ColumnStore motoru var
    Son dönemde vector storage type da eklendiği için Alibaba’nın uygulamasıyla performans karşılaştırması ilginç olur
    Postgres sık anılıyor ama MariaDB de oldukça çok yönlü
  • ClickHouse, MySQL protokolünü yerel olarak destekliyor ve MySQL tablolarını sarmalayabiliyor ya da içe aktarabiliyor
    İki bağlantı gerektirse de oldukça iyi çalışıyor
  • Tiger Data’nın basit bir sütun deposu gibi kullanılıp kullanılamayacağı merak ediliyor
    ClickHouse gibi sadece hızlı count gerekse de tüm senkronizasyon sürecinden geçmek zahmetli
    TimeSeries belirli kullanım alanlarına optimize edildiği için genel kullanımda zorlayıcı olabiliyor
  • TiDB de bir seçenek
    Satır tabanlı ve sütun tabanlı veriyi birlikte destekliyor ama yalnızca MySQL uyumlu; kod tabanı farklı
    Bu yüzden tam anlamıyla bir MySQL eklentisi değil
  • MariaDB zaten sütun tabanlı tabloları destekliyor

• Bu özelliği MySQL Operator ile birleştirip dağıtmanın ne kadar kolay olacağı merak ediliyor

  • Henüz denenmedi ama ileride mysql-operator ile entegrasyon test edilmeyi planlanıyor

• İlk bakışta bu, PSQL’in FDW’sinin DuckDB ve Vector Storage ile daha sıkı entegre edilmiş bir sürümü gibi görünüyor
  Vespa’yı da andırıyor; bu yüzden neden FDW yaklaşımı yerine MySQL eklentisinin seçildiği ilginç

  • Muhtemelen zaten milyonlarca satır MySQL kodu kullanılıyor olduğu içindir

• Commit geçmişi tuhaf görünüyor
  2022’de 2, 2024~2026 arasında da birkaç commit var; ilk commit ise “First commit, Support DuckDB Engine”

  • Muhtemelen geliştirme önce içeride, kapalı olarak yapıldı ve açığa çıkarılırken yalnızca asgari sayıda commit düzenlendi
    İç sürüm Jira referansları, ürün bilgileri, Çince yorumlar vb. yüzünden karmaşık olabilir
    Bu nedenle temiz bir herkese açık git geçmişi yeniden oluşturulmuş gibi duruyor

• TiDB, ClickHouse yerine DuckDB kullansaydı nasıl olurdu diye merak ediliyor

  • Eğer DuckDB 2020 civarında istikrar kazanmış bir açık kaynak olarak mevcut olsaydı, TiDB’nin kesinlikle ClickHouse yerine DuckDB’yi seçeceğine inanılıyor