피드로 돌아가기
Quack: DuckDB 클라이언트-서버 프로토콜
GeekNewsGeekNews
Database

Quack: DuckDB 클라이언트-서버 프로토콜

6천만 행 4.94초 전송, DuckDB 인프로세스를 넘어선 Quack 프로토콜 설계

neo2026년 5월 14일11advanced

Context

DuckDB의 인프로세스 아키텍처는 낮은 API 호출 지연 시간을 제공하나, 여러 프로세스 간 상태 동기화와 동시 작성 제약이라는 한계 존재. 기존의 Arrow Flight SQL이나 PostgreSQL 우회 방식은 잦은 프로토콜 왕복과 직렬화 오버헤드로 인해 대량 데이터 전송 효율이 저하됨.

Technical Solution

  • HTTP 기반 요청-응답 모델 채택을 통한 로드밸런싱 및 방화벽 호환성 확보와 DuckDB-Wasm의 네이티브 연결 지원
  • WAL 파일에서 검증된 내부 직렬화 프리미티브를 활용한 application/duckdb MIME 타입 정의로 데이터 타입 전송 최적화
  • 쿼리 실행과 결과 fetch를 단일 왕복(Single Round-trip)으로 처리하는 설계를 통한 네트워크 지연 시간 최소화
  • 외부 표준(Arrow) 제약을 탈피한 자체 직렬화 구조 설계를 통해 신규 데이터 타입 및 프로토콜 메시지의 즉각적 배포 가능성 확보
  • 사용자 정의 콜백 함수를 통한 인증 및 권한 부여 모델 구축으로 LDAP 등 외부 인증 시스템과의 유연한 연동 지원

Impact

  • 대량 전송: 6천만 행(76GB CSV 상당) 데이터 전송 시 4.94초 기록 (Arrow Flight 17.40s, PostgreSQL 158.37s 대비 압도적 성능)
  • 처리량: 8스레드 기준 초당 약 5,434 tx/s의 append 성능 달성
  • 지연 시간: 동일 가용 영역 내 평균 ping 0.280ms 환경에서 최적화된 전송 효율 확인

Key Takeaway

범용 데이터 도구로 확장하기 위해서는 표준 인터페이스의 편의성보다 내부 데이터 구조에 최적화된 전용 프로토콜 설계가 성능 극대화의 핵심임.


1. 고성능 데이터 전송 설계 시 표준 프로토콜(Arrow 등)의 왕복 횟수(Round-trip) 제약을 분석하고 필요 시 자체 직렬화 도입 검토

2. 대규모 데이터셋 전송 시 행 기반(Row-based)보다 내부 메모리 구조를 그대로 반영한 직렬화 방식 채택

3. 보안 요구사항과 인프라 복잡도 간의 Trade-off를 고려하여 localhost 바인딩 및 리버스 프록시를 통한 SSL 종료 전략 수립

원문 읽기