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 데이터베이스의 진화 방향을 세 단계로 봄
기존 OLTP 엔진에 OLAP 엔진을 통합하고 쿼리를 포워딩함
두 엔진이 공통 스토리지 레이어를 사용하도록 재설계함
결국 엔진을 완전히 병합해, 오래된 레코드를 자동으로 압축·보관하고 필요 시 원격 스토리지에서 불러오는 구조로 발전함
오래된 데이터 조회만 약간 느려질 뿐, 나머지는 완전히 통합된 쿼리 경험을 제공함
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 확장은 아님
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 데이터베이스의 진화 방향을 세 단계로 봄
오래된 데이터 조회만 약간 느려질 뿐, 나머지는 완전히 통합된 쿼리 경험을 제공함
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도 꽤 다재다능함
연결이 두 개 필요하긴 하지만 꽤 잘 작동함
ClickHouse처럼 빠른 count만 필요한데, 전체 동기화 과정을 거쳐야 하는 게 번거로움
TimeSeries는 특정 용도에 최적화되어 있어서 일반적인 사용에는 어려움이 있음
Row 기반과 Column 기반 데이터를 모두 지원하지만, 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를 썼다면 어땠을지 궁금함