실행 환경과 성능
실행 환경과 성능 (Environment - environment)
DuckDB가 실행되는 환경은 성능에 분명한 영향을 줘요. 이 페이지는 하드웨어 구성과 운영체제가 성능에 어떤 영향을 미치는지에 집중해요. 최적의 성능을 원한다면 이 페이지의 가이드를 따라가면 돼요.
하드웨어 구성 (Hardware Configuration)
CPU
DuckDB의 공식 지원 아키텍처는 **AMD64 (x86_64)**와 ARM64 (AArch64) CPU 아키텍처예요. DuckDB는 두 아키텍처 모두에서 효율적으로 작동해요.
DuckDB는 LoongArch나 RISC-V 같은 다른 아키텍처로도 컴파일될 수 있어요. 하지만 이 플랫폼들에 대한 성능 보장은 없어요.
메모리 (Memory)
Best practice 스레드당 메모리를 1-4 GB로 맞추는 것을 목표로 하세요.
최소 필요 메모리 (Minimum Required Memory). 경험칙으로, DuckDB는 스레드당 최소 125 MB 메모리가 필요해요. 예를 들어 8개 스레드를 쓴다면 최소 1 GB 메모리가 필요하죠. 메모리가 제한된 환경이라면 스레드 수를 제한하는 걸 고려해 보세요. 예를 들면요.
SET threads = 4;
이상적인 성능을 위한 메모리 (Memory for Ideal Performance). 이상적인 성능에 필요한 메모리 양은 데이터셋 크기와 실행할 쿼리에 따라 달라져요. 의외일 수 있지만, 메모리 요구량에는 쿼리가 더 큰 영향을 미쳐요. 다대다(many-to-many) 테이블에 대한 대규모 조인이 포함된 워크로드는 중간 데이터셋이 커지므로 평가가 메모리에 완전히 들어맞으려면 더 많은 메모리가 필요해요. 근사적으로, 집계(aggregation)가 많은 워크로드는 스레드당 1-2 GB, 조인(join)이 많은 워크로드는 스레드당 3-4 GB 메모리가 필요해요.
메모리보다 큰 워크로드 (Larger-than-Memory Workloads). DuckDB는 디스크로 스필(spill)하여 메모리보다 큰 워크로드도 처리할 수 있어요. 이는 grouping, join, sorting, windowing 연산자의 out-of-core 지원 덕분이에요. 이 경우 영구(persistent) 모드와 인메모리(in-memory) 모드 모두에서 처리 가능한데, 두 모드 모두에서 DuckDB는 여전히 디스크로 스필하기 때문이에요.
로컬 디스크 (Local Disk)
디스크 종류. DuckDB의 디스크 기반 모드는 SSD와 NVMe 디스크에서 가장 잘 작동하도록 설계됐어요. HDD도 지원되지만, 특히 쓰기 작업에서 성능이 낮아져요.
디스크 기반 vs. 인메모리 저장. 반직관적이게도, 디스크 기반 DuckDB 인스턴스가 인메모리 인스턴스보다 더 빠를 수 있어요. 기본 설정이 디스크 기반 저장에는 압축을 적용하는 반면, 인메모리 저장에는 압축을 꺼놓기 때문이에요. 더 자세한 내용은 "워크로드 튜닝하기" 페이지를 참고해요.
파일 시스템. Linux에서는 DuckDB가 XFS 파일 시스템에서 가장 잘 작동하지만 ext4 같은 다른 파일 시스템에서도 잘 작동해요. Windows에서는 NTFS를 권장하고 FAT32는 피하는 게 좋아요.
DuckDB 데이터베이스에는 내장 체크섬이 있어서 데이터 손상을 막기 위한 파일 시스템의 무결성 검사가 필요하지 않아요.
네트워크 연결 디스크 (Network-Attached Disks)
네트워크 연결 디스크를 사용할 때는 각별히 주의해야 해요.
- 디스크에 쓰기 작업을 한다면 디스크가 신뢰성이 있어야 해요. 일반적으로 로컬 연결 디스크와 클라우드의 블록 스토리지가 이에 해당해요.
- 워크로드가 메모리보다 크거나 빠른 데이터 로딩이 중요하다면 빠른 디스크(가급적 빠른 연결의 SSD 또는 NVMe)가 필요해요.
이를 염두에 두고, DuckDB의 네이티브 데이터베이스 포맷을 쓸 때 흔한 두 가지 아키텍처와 관련 고려사항을 살펴볼게요.
클라우드의 블록 스토리지. DuckDB는 AWS EBS 같은 네트워크 기반 클라우드 디스크에서 읽기 전용과 읽기-쓰기 워크로드 모두 잘 작동해요.
네트워크 연결 스토리지 (NAS). 네트워크 연결 스토리지는 읽기 전용 워크로드에는 DuckDB를 지원할 수 있어요. 하지만 네트워크 연결 스토리지(NAS)에서 읽기-쓰기 모드로 DuckDB 네이티브 데이터베이스 포맷을 쓰는 것은 피하는 것이 좋아요. 이런 설정에는 NFS, SMB 같은 네트워크 드라이브, Samba가 있어요. 사용자 보고에 따르면, NAS에서 읽기-쓰기 워크로드를 실행하면 느리고 예측 불가능한 성능과 기반 파일 시스템이 일으키는 가짜 오류가 발생할 수 있어요. DuckDB 네이티브 포맷 대신 DuckLake lakehouse 포맷을 고려해 보세요.
운영체제 (Operating System)
최신 안정 버전의 운영체제를 사용할 것을 권장해요. macOS, Windows, Linux 모두 잘 테스트됐고 높은 성능으로 실행할 수 있어요.
Linux
DuckDB는 최근 약 5년 내에 출시된 모든 주류 Linux 배포판에서 실행돼요. 특별한 선호가 없다면, 안정성과 DuckDB Linux 테스트 스위트 작업의 대부분이 Ubuntu 워커에서 실행된다는 점 때문에 Ubuntu Linux LTS를 권장해요.
glibc vs. musl libc
DuckDB는 glibc와 musl libc 빌드를 모두 배포해요. 하지만 musl libc로 빌드된 DuckDB 바이너리는 성능이 현저히 낮아요. 실제로 컴퓨팅 집약적 워크로드에서는 5배 이상 느려질 수 있어요. 따라서 성능 지향 워크로드에서 DuckDB를 실행할 때는 glibc가 있는 Linux 배포판을 사용하는 게 좋아요.
메모리 할당자 (Memory Allocator)
DuckDB가 jemalloc을 기본 메모리 할당자로 제공하는 시스템에 멀티코어 CPU가 있다면, 할당자의 백그라운드 스레드를 활성화하는 것을 고려해 보세요.