▲

AliSQL - Alibaba의 오픈소스 MySQL 포크, 벡터 및 DuckDB 엔진 통합

 (github.com/alibaba)
6P by GN⁺ 17시간전 | ★ favorite | 댓글 1개
  • 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 최적화: 인스턴트 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 기반 분석 인스턴스로 상용 서비스 제공
▲
GN⁺ 17시간전  [-]
Hacker News 의견들

  • DuckDB를 스토리지 엔진으로 사용하는 접근이 흥미로움
    기존 MySQL 연결, 툴링, 복제 구조를 그대로 유지하면서 분석 쿼리만 컬럼 기반 엔진으로 라우팅할 수 있음
    별도의 분석 DB를 세우고 동기화 파이프라인을 만드는 것보다 운영적으로 훨씬 간단함
    다만 InnoDB와 DuckDB 간 데이터 일관성을 어떻게 유지하는지가 핵심 포인트임

    • MySQL의 binlog 메커니즘을 활용해 읽기 전용 Columnar Store(DuckDB) 노드를 구현하는 방법을 소개함
      자세한 내용은 AliSQL DuckDB 문서에 정리되어 있음
      binlog 배치 전송, 쓰기 연산 등에서 다양한 최적화를 수행했음
    • 데이터 일관성 문제를 해결하기 위해 GTID 기반 복제를 활용함
      log_bin이 꺼져 있을 때는 DuckDB 트랜잭션을 GTID 기록 전에 커밋하고, 장애 복구 시 idempotent 방식으로 재적용함
      log_bin이 켜져 있을 때는 Binlog를 직접 사용하며, DuckDB에 유효 Binlog 위치를 기록해 실패 시 해당 위치까지 롤백함
      결과적으로 replica의 gtid_executed가 primary와 일치하면 DuckDB 데이터도 일관됨

  • 앞으로 10년간 SQL 데이터베이스의 진화 방향을 세 단계로 봄

    1. 기존 OLTP 엔진에 OLAP 엔진을 통합하고 쿼리를 포워딩함
    2. 두 엔진이 공통 스토리지 레이어를 사용하도록 재설계함
    3. 결국 엔진을 완전히 병합해, 오래된 레코드를 자동으로 압축·보관하고 필요 시 원격 스토리지에서 불러오는 구조로 발전함
      오래된 데이터 조회만 약간 느려질 뿐, 나머지는 완전히 통합된 쿼리 경험을 제공함

  • pg_duckdb와 비교했을 때 어떤 차이가 있을지 궁금함
    Postgres의 확장 메커니즘 덕분에 pg_duckdb는 꽤 깔끔하게 보임

    • (삭제된 댓글)

  • 이 시스템이 SAP HANA처럼 트랜잭션 워크로드 데이터를 실시간으로 DuckDB에 공급하는지 궁금함
    그렇다면 Kafka나 Debezium으로 데이터 웨어하우스를 동기화하던 복잡한 작업이 크게 줄어들 것임
    apavlo의 의견도 들어보고 싶음

  • HTAP 시대가 본격적으로 온 것 같음
    이런 하이브리드 데이터베이스가 점점 채택되는 게 흥미로움
    특히 AliSQL DuckDB 문서에 설명된 트랜잭션 처리 개선이 인상적임
    기본 테이블과 분석 테이블 간 동기화를 빠르고 트랜잭션 단위로 보장하는 점이 멋짐

    • 하지만 이건 진정한 HTAP이라기보다는 두 DB를 하나의 인터페이스로 묶은 형태에 가까움
      Materialize 같은 시스템과 일관성 보장은 크게 다르지 않음
      사실 이런 시도는 예전부터 있었고, MySQL/Postgres에도 OLAP 스토리지 엔진을 붙이는 사례가 많았음

  • 전통적인 DB에 임베디드 컬럼형 엔진을 붙이는 건 생산성과 운영 단순성 면에서 큰 이점임
    현재는 PG + Tiger Data 조합을 쓰고 있는데, MySQL 쪽에는 이런 대안이 없었음
    이번 시도가 그 공백을 메워줄 수 있을 듯함

    • MariaDB에도 이미 ColumnStore 엔진이 있음
      최근에는 vector storage type도 추가되어 Alibaba의 구현과 성능 비교가 흥미로움
      Postgres가 자주 언급되지만 MariaDB도 꽤 다재다능함
    • ClickHouse는 MySQL 프로토콜을 네이티브 지원하며, MySQL 테이블을 래핑하거나 가져올 수도 있음
      연결이 두 개 필요하긴 하지만 꽤 잘 작동함
    • Tiger Data를 단순한 컬럼 스토어로 쓸 수 있는지 궁금함
      ClickHouse처럼 빠른 count만 필요한데, 전체 동기화 과정을 거쳐야 하는 게 번거로움
      TimeSeries는 특정 용도에 최적화되어 있어서 일반적인 사용에는 어려움이 있음
    • TiDB도 하나의 옵션임
      Row 기반과 Column 기반 데이터를 모두 지원하지만, MySQL 호환일 뿐 코드 기반은 다름
      그래서 완전한 MySQL 확장은 아님
    • MariaDB는 이미 컬럼형 테이블을 지원하고 있음

  • 이 기능을 MySQL Operator와 결합해 배포하기 얼마나 쉬울지 궁금함

    • 아직 시도해본 적은 없지만, 나중에 mysql-operator와 통합을 테스트해볼 계획임

  • 얼핏 보면 PSQL의 FDW를 DuckDB와 Vector Storage로 더 긴밀히 통합한 버전처럼 보임
    Vespa와도 유사한 느낌인데, 왜 FDW 방식 대신 MySQL 확장을 택했는지 흥미로움

    • 아마도 이미 수백만 줄의 MySQL 코드를 사용 중이었기 때문일 것임

  • 커밋 히스토리가 이상함
    2022년에 2건, 2024~2026년에 몇 건뿐인데, 첫 커밋이 “First commit, Support DuckDB Engine”임

    • 아마 내부 비공개 개발로 진행되다가 공개용으로 최소한의 커밋만 정리했을 가능성이 높음
      내부 버전은 Jira 참조, 제품 정보, 중국어 주석 등으로 복잡했을 수 있음
      그래서 깔끔한 공개용 git 히스토리를 새로 만든 듯함

  • TiDB가 ClickHouse 대신 DuckDB를 썼다면 어땠을지 궁금함

    • DuckDB가 2020년쯤 안정화된 오픈소스로 존재했다면, TiDB는 분명 ClickHouse 대신 DuckDB를 선택했을 것이라 확신함
답변달기