KiviDB 1.1.0 릴리스: Redis 호환 Rust 데이터베이스, Redis 대비 9배 처리량 및 내장 벡터 검색
TL;DR
KiviDB 1.1.0은 Rust로 작성된 Redis/Valkey의 드롭인 대체품으로, 모든 CPU 코어를 활용하며 32코어 서버에서 21M 파이프라인 GET/s(≈Redis 8 대비 9배, Dragonfly 대비 2.3배)를 달성하고, Redis-Stack 스타일의 전문(full-text) 및 벡터 검색을 내장하고 있습니다.
KiviDB란?
KiviDB는 Redis 프로토콜(RESP2 및 RESP3)을 사용하는 빠르고 멀티스레드 인메모리 키-값 저장소입니다. 기존 Redis 클라이언트나 redis-cli와 코드 변경 없이 사용할 수 있으며, 전문, 태그, 숫자 및 ANN 벡터 쿼리(FLAT 및 HNSW)를 위한 네이티브 FT.* 명령을 추가합니다.
- 프로토콜 호환성 – 모든 표준 Redis 명령이 작동합니다. 지원되는 하위 집합은
COMMANDS.md를 참조하세요. - 검색 통합 –
FT.CREATE,FT.SEARCH,FT.HYBRID등이 Redis Stack처럼 동작합니다. - 선택적 Lua 및 TLS – Cargo 기능
lua및tls로 활성화됩니다. - 기본 수신 포트 – 6380(Redis는 기본적으로 6379를 사용하므로 둘 다 나란히 실행할 수 있습니다).
- 라이선스 – AGPL-3.0 전용. KiviDB를 네트워크 서비스로 사용하는 것은 애플리케이션에 AGPL을 부과하지 않습니다.
성능 하이라이트
모든 벤치마크는 2026년 10월에 두 대의 AWS Graviton3 베어메탈 c7gn.metal 인스턴스(64 vCPU, 서버에 32코어 사용)에서 실행되었습니다. 각 엔진은 격리된 환경에서 테스트되었습니다.
키-값 처리량 및 지연 시간
| 작업 | KiviDB 1.1.0 | Dragonfly 2.0.2 | Redis 8.10 | Redis Cluster(32샤드) |
|---|---|---|---|---|
| GET, 파이프라인 ×16 | 21.2M ops/s | 9.1M | 2.4M | 4.7M |
| SET, 파이프라인 ×16 | 19.2M ops/s | 8.5M | 2.0M | 4.7M |
| GET, 파이프라인 없음 | 3.07M ops/s | 3.35M | 1.32M | 1.46M |
| SET, 파이프라인 없음 | 3.12M ops/s | 3.38M | 1.54M | 1.46M |
| p99 지연 시간(GET/SET, 파이프라인 ×16) | 0.36ms / 0.42ms | 0.88ms / 1.07ms | 2.2ms / 2.7ms | – |
| 키당 메모리 | 177B | 134B | 178B | 183B |
KiviDB의 샤딩된 코어별 설계는 Redis의 단일 스레드 I/O 모델과 달리 모든 코어가 요청을 처리할 수 있게 합니다.
벡터 검색(ANN) 성능
벤치마크는 118만 벡터, 25차원 Glove 데이터셋(HNSW, M=16, EF_CONSTRUCTION=256)에서 redis/vector-db-benchmark 스위트를 사용했습니다. 100개의 클라이언트 스레드가 64개 벡터 배치를 업로드한 후 다양한 ef 값으로 쿼리를 실행했습니다.
| 지표 | KiviDB 1.1.0 | Dragonfly 2.0.2 | Redis 8.10(쿼리 엔진) |
|---|---|---|---|
| 쿼리/s(ef=64, recall@10) | 59.3k (0.943) | 41.3k (0.912) | 31.8k (0.912) |
| 쿼리/s(ef=128) | 50.7k (0.961) | 40.3k (0.937) | 28.9k (0.937) |
| 쿼리/s(ef=256) | 31.5k (0.989) | 36.2k (0.979) | 21.1k (0.979) |
| 쿼리/s(ef=512) | 18.7k (0.998) | 29.8k (0.995) | 13.7k (0.995) |
| 수집 및 인덱스 구축 시간 | 31초 | 13초 | 38초 |
| 수집 후 메모리 | 1.66GB | 1.13GB | 1.07GB |
KiviDB는 낮은
ef값에서 높은 재현율 쿼리에 탁월하며, Dragonfly는 인덱스를 더 빠르게 구축하고 메모리를 덜 사용합니다.
핵심 아키텍처 장점
- 샤딩된 코어별 설계 – 각 작업자 스레드는 분리된 키스페이스 조각을 소유하여 잠금 경합을 제거하고 진정한 병렬 처리를 가능하게 합니다.
- Rust 안전성 및 성능 – 2024 에디션으로 컴파일되며, 가능한 경우
io_uring을 활용합니다(Tokio로 폴백). - 내장 검색 – 외부 모듈이 필요 없으며,
FT.*명령이 코어 바이너리의 일부입니다. - 영속성 옵션 – 스냅샷(
dump.kdb) 및 선택적 Append-Only File(AOF)로 거의 실시간 내구성을 제공합니다.
빠른 시작 가이드
# 공식 Docker 이미지 가져오기(기본 변형)
docker run -d -p 6380:6380 kividb/kividb
# 서버가 살아있는지 확인
redis-cli -p 6380 PING # → PONG
벡터 인덱스 생성(Redis-Stack 구문)
redis-cli -p 6380 FT.CREATE idx ON HASH PREFIX 1 doc: \
SCHEMA vec VECTOR HNSW 10 TYPE FLOAT32 DIM 128 \
DISTANCE_METRIC COSINE M 16 EF_CONSTRUCTION 128
벡터 저장
해시 필드에 원시 리틀엔디언 FLOAT32 바이트를 저장합니다(예: HSET doc:1 vec <binary>). 형식은 Redis Stack 및 redis-py/NumPy 블롭과 일치합니다.
KNN 쿼리(Dialect 2)
redis-cli -p 6380 FT.SEARCH idx '*=>[KNN 10 @vec $q]' \
PARAMS 2 q <binary-blob> DIALECT 2
전체 명령 참조는 COMMANDS.md에 있습니다.
영속성 세부 사항
- 스냅샷(
dump.kdb)은 인덱싱 후SAVE/BGSAVE실행 시 키, 인덱스 스키마 및 HNSW 그래프를 캡처합니다. - AOF(
--aof)는 모든 쓰기를 추가합니다. 재시작 시 AOF가 재생되어 스냅샷 로딩을 건너뛰고 진실의 원천이 됩니다. - 시작 시 인덱스 재구축 중 대부분의 명령은 그래프가 준비될 때까지
LOADING을 반환합니다.PING및INFO는 계속 작동합니다.
빌드 변형
| 변형 | Cargo 기능 | 추가되는 것 |
|---|---|---|
default |
없음 | 코어 서버만 |
lua |
lua |
Lua 스크립팅(EVAL, SCRIPT, …) |
tls |
tls |
TLS 리스너 및 노드 간 TLS |
full |
lua,tls |
Lua 및 TLS 모두 |
빌드 예시:
cargo build --release # 기본
cargo build --release --features lua # Lua 포함
cargo build --release --features tls # TLS 포함
cargo build --release --features lua,tls # 전체
Linux 빌드는 커널이 허용할 때 자동으로 io_uring을 사용하며, 그렇지 않으면 Tokio로 폴백합니다(--io-model auto).
구성 하이라이트
주요 플래그(기본값은 괄호 안):
--port 6380– 수신 포트.--bind 0.0.0.0– 주소. 설정 시 보호 모드가 비활성화됩니다.--protected-mode yes– 기본적으로 켜져 있으며, 비밀번호나 바인드 주소가 구성되지 않으면 루프백 클라이언트만 허용됩니다.--threads 0– 자동으로cores-2선택(최소 2).--aof– Append-Only File 영속성 활성화.--maxmemory 0– 무제한 메모리. 상한을 적용하려면 설정.--cluster-enabled no– 선택적 클러스터 모드로,port+10000에 별도 버스가 있습니다.- TLS 옵션(
--tls-port,--tls-cert-file등)은tls기능으로 빌드할 때 사용할 수 있습니다.
모든 플래그는 Redis 스타일 구성 파일(기본적으로 /etc/kividb/kividb.conf) 또는 명령줄로 제공할 수 있습니다. 명령줄이 파일 값을 재정의합니다.
Docker 사용법
# 최신 이미지 가져오기(기본 변형)
docker pull kividb/kividb:latest
docker run -p 6380:6380 kividb/kividb
- 컨테이너는 Docker가 네트워크를 외부에 노출하므로 기본적으로
--protected-mode no로 실행됩니다. 보호 모드를 다시 활성화하고 비밀번호를 설정하려면 자체 플래그를 전달하세요. - AOF 영속성의 경우:
docker run -p 6380:6380 \
-v $(pwd)/data:/home/kividb \
ghcr.io/kividbio/kividb \
--aof --requirepass "change-me"
- Docker 내부에서
io_uring을 허용하려면--security-opt seccomp=unconfined를 추가하세요(프로덕션 사용 전 보안 영향을 이해하세요).
커뮤니티 피드백(Hacker News)
- 벤치마크 재현성 – 작성자가 독립 검증을 위한 Terraform 스크립트와 부하 생성기 코드가 포함된
kivi-benchmark저장소를 공유했습니다. (@murtazayusuf의 댓글) - 부하 생성기 한계 – 한 댓글 작성자는 5M ops/s 이상을 달성하려면 여러 부하 생성기 호스트가 필요한 경우가 많다고 언급했습니다. KiviDB의 21M ops/s는 클라이언트 병목이 아닌 서버 용량을 반영할 가능성이 높습니다. (@falconBrisk47의 댓글)
- 기능 비교 요청 – 사용자들이 Valkey 벤치마크와 Apache KVrocks와의 비교를 요청했지만, 현재 릴리스 노트에는 포함되지 않았습니다.
- AI 참여 – 유지관리자가 설계 결정에 광범위한 AI 지원을 확인했지만, 핵심 엔지니어링은 인간이 주도했습니다. (@ghm2180의 댓글)
- 메모리 사용량 – 수집 중 메모리 사용량에 대한 질문은 아직 답변되지 않았습니다. 게시된 표는 키당 메모리(177B)와 수집 후 벡터 메모리(118만 벡터에 대해 1.66GB)를 보여줍니다.
라이선스 및 상업 옵션
KiviDB는 AGPL-3.0 전용으로 릴리스됩니다. 수정되지 않은 KiviDB를 네트워크 서비스로 실행하는 것은 독점 애플리케이션에 AGPL 의무를 부과하지 않습니다. KiviDB 자체를 수정하고 호스팅 서비스로 제공하는 경우 수정된 소스를 사용자에게 제공해야 합니다.
AGPL 조건을 수용할 수 없는 조직을 위해 KIVIDB PRIVATE LIMITED는 상업 라이선스를 제공합니다. 문의는 support@kividb.io로 보낼 수 있습니다.
얻을 수 있는 곳
- GitHub 저장소 – https://github.com/kividbio/kividb
- Docker Hub / GHCR –
kividb/kividb:latest(또한v1.1.0,v1.1.0-lua,v1.1.0-tls,v1.1.0-full) - 릴리스 바이너리 – Linux x86_64, Linux aarch64, macOS(Intel 및 Apple Silicon) 타르볼. Debian/RPM 패키지도 제공됩니다.
- 벤치마크 스위트 – https://github.com/kividbio/kivi-benchmark 성능 수치 재현용.
빠른 참조 명령
# 서버 시작(기본 변형)
./kividb
# TLS로 시작(`tls` 기능 필요)
./kividb --port 6380 --tls-port 6381 \
--tls-cert-file cert.pem --tls-key-file key.pem
# AOF 영속성 활성화
./kividb --aof --requirepass "s3cr3t"
# 클러스터 모드로 실행
./kividb --cluster-enabled yes --cluster-node-timeout 15000
모든 벤치마크 수치는 단일 통제 환경의 스냅샷입니다. 실제 성능은 하드웨어, 워크로드 및 구성에 따라 달라집니다.