KiviDB, yerleşik vektör aramasıyla Rust tabanlı Redis alternatifi olarak duyuruldu

Rust tabanlı bir Redis alternatifi kamuoyuna açıldı

Rust ile yazılmış açık kaynak bir in-memory veritabanı olan KiviDB, 19 Ekim'de Hacker News'in ana sayfasında göründü ve kendini Redis ile Valkey'e hızlı bir alternatif olarak tanıttı. Projenin GitHub dokümantasyonuna göre, Redis'in hat protokolünü hem RESP2 hem de RESP3 varyantlarıyla konuşuyor; böylece mevcut Redis client'ları, kütüphaneleri ve redis-cli herhangi bir değişiklik gerektirmeden bağlanabiliyor.

Ana mimari fark yürütmede (execution) yatıyor. Redis ve Valkey komutları I/O thread'leri ayrı tutarak tek bir thread üzerinde çalıştırırken, KiviDB in-memory key-value deposunu kullanılabilir her çekirdek arasında paylaştırıyor. Dragonfly benzer bir her-çekirdek, shared-nothing yaklaşımı benimsiyor; KeyDB ise işi birkaç thread üzerine yayıyor.

Projenin en çok vurguladığı yetenek arama. Redis Stack tarzı FT.* komutları çekirdek sunucuda geliyor; BM25 tam metin arama, tag ve sayısal filtreler ile hash alanları üzerinde FLAT veya HNSW indeks seçeneği sunan approximate-nearest-neighbour vektör aramasını kapsıyor.

Proje tarafından yayınlanan benchmark'lar

Proje, AWS Graviton3 bare-metal makinelerde koşturulan Ekim 2026 tarihli benchmark sonuçlarını yayınlıyor: 64 vCPU'ya sahip ve 32 çekirdeğe kısıtlanmış bir c7gn.metal sunucu, projenin kendi script'leriyle yönlendirilen memtier_benchmark kullanılarak birebir aynı ikinci bir makine tarafından yükleniyor. Pipelined GET'lerde (pipeline derinliği 16, 300 bağlantı, 100 baytlık 10 milyon anahtar) KiviDB 1.1.0'un saniyede 21,2 milyon işlem servis ettiği bildiriliyor; Dragonfly 2.0.2 için 9,1 milyon, Redis 8.10 için 2,4 milyon ve 32 shard'lı bir Redis Cluster için 4,7 milyon — kabaca Redis'in 9 katı, Dragonfly'nun 2,3 katı ve öne çıkan iddiayla örtüşüyor. Bildirilen p99 gecikmesi GET için 0,36 ms, SET için 0,42 ms; Dragonfly'nun 0,88/1,07 ms değerinin yarısından az ve Redis'in 2,2/2,7 ms değerinin oldukça altında.

Pipeline kullanılmadığında fark epey daralıyor: Dragonfly orada saniyede biraz daha fazla GET servis etti, 3,07 milyona karşı 3,35 milyon. KiviDB ayrıca anahtar başına Dragonfly'dan daha fazla bellek kullanıyor, 134'e karşı 177 bayt; ancak Redis'in 178 değeriyle aynı seviyede. Projenin kendisi de sonuçların ortama bağlı olduğunu ve rakamlarının bir garanti değil tek bir kontrollü ölçümü temsil ettiğini hatırlatıp kullanıcıları kendi donanımlarında test etmeye teşvik ediyor.

Vektör araması dengeleri

Standart glove-25-angular iş yükünde (1,18 milyon vektör, 25 boyut, M=16 ve EF_CONSTRUCTION=256 ile HNSW) KiviDB daha düşük arama çabasında öndeydi: ef 64'te 0,943 recall@10 ile saniyede 59.300 sorgu; Dragonfly 41.300, Redis'in sorgu motoru ise 31.800. Daha yüksek ef değerlerinde sıralama tersine dönüyor — ef 512'de Dragonfly saniyede 29.800 sorgu servis ederken KiviDB 18.700'de kaldı — ve Dragonfly ayrıca indeksi daha hızlı kurdu (31 saniyeye karşı 13 saniye) ve sonrasında daha az bellek kullandı (1,66 GB'a karşı 1,13 GB). KiviDB'nin recall değeri test edilen her ef ayarında biraz daha yüksekti; bu da ham iş hacmi karşılaştırmasını nüanslı hale getiriyor.

Kullanım Redis Stack geleneklerini izliyor: vektörler hash alanlarında little-endian FLOAT32 blob olarak saklanıyor ve KNN sorguları Dialect 2 ve isimlendirilmiş binary parametrelerle FT.SEARCH üzerinden çalışıyor; böylece mevcut client'lar ve rehberler büyük ölçüde geçerli kalıyor.

Operasyonel ayrıntılar

KiviDB varsayılan olarak Redis'in 6379 portu yerine 6380 portunu dinliyor; böylece mevcut bir Redis kurulumunun yanında çalışabiliyor; korumalı mod Redis'teki gibi varsayılan olarak açık. Kalıcılık, yerleşik snapshot'lar (dump.kdb) ve isteğe bağlı bir append-only dosya ile sağlanıyor. Dikkat çekici bir ayrıntı: snapshot'lar indeks şemalarını ve HNSW graflarını da içeriyor, böylece yeniden başlatma sonrası arama kalitesi kapanmadan önceki duruma denk oluyor. Indeksler açılışta yeniden kurulurken komutların çoğu LOADING hatası döndürüyor.

Lua script'leri (EVAL, SCRIPT, FUNCTION, FCALL) ve TLS varsayılanlar değil, derleme zamanı Cargo özellikleri; TLS içermeyen bir build, TLS portu istendiğinde başlamayı reddediyor. Linux'ta sunucu çekirdek destekliyorsa io_uring kullanıyor, aksi halde Tokio'ya geri düşüyor. Derleme için stabil bir Rust toolchain gerekiyor — projenin test ettiği en eski sürüm Rust 1.89 — ve Docker imajları Docker Hub ile GitHub Container Registry'de yayınlanıyor. Proje AGPL-3.0-only lisansıyla lisanslı ve KiviDB'yi veritabanı olarak kullanmanın uygulamanızı AGPL kapsamına sokmadığını belirtiyor.

Neden önemli

Redis uyumlu alan kalabalık — projenin kendi karşılaştırma tablosu Valkey, Dragonfly ve KeyDB'yi listeliyor — ama KiviDB nadiren bir araya gelen üç özelliği birleştiriyor: her-çekirdek yürütme, Rust'tan gelen bellek güvenliği ve ayrı bir modül ya da veritabanı gerektirmeyen yerleşik tam metin artı vektör araması. Arama ve yapay zeka özellikleri ekleyen ekipler için aynı protokol ve client'lar üzerinden HNSW sorguları ile BM25 araması da servis eden bir cache, altyapıyı epey basitleştirebilir. Uyarılar da gerçek: bu bir v1.1.0 projesi, benchmark'lar proje tarafından kendisi koşturulmuş, Dragonfly ingest hızı, bellek ayak izi ve yüksek doğruluklu sorgu iş hacminde net üstünlükler koruyor ve AGPL lisansı bazı şirketleri durdurabilir. Bir sürüm olarak bu bir hüküm değil, kendi iş yükünüzde ölçmeye bir davet — ki proje tam olarak bunu istiyor.