Mimari ve çalışma modeli
Vektör veritabanı seçimi yalnız ANN benchmark'ındaki sorgu süresine dayanmaz. Recall, metadata filtresi, güncelleme/silme, tenant izolasyonu, yedekleme, tutarlılık, işletim becerisi ve toplam veri hacmi birlikte değerlendirilir. Aynı embedding ve mesafe metriğiyle brute-force altın sonucu kalite referansıdır.
HNSW grafik tabanlı aramada yüksek recall ve hızlı sorgu sağlayabilir; yapı belleği ve build maliyeti büyüyebilir. IVFFlat vektörleri kümelere/lists ayırır, probes ayarıyla hız-recall dengesi kurar ve genellikle daha hafif build sunar. Davranış, ürün uygulaması ve veri dağılımına göre değişir.
Metadata filtresi retrieval güvenliğinin parçasıdır. Tenant veya belge sınıfı filtresi ANN sonrasında uygulanırsa eksik sonuç veya yetkisiz adayın işlenmesi riski doğar. Filtre selectivity'si, payload/scalar index ve iterative scan desteği gerçek sorgu karışımıyla test edilir.
- 1Embedding ve brute-force referans
- 2Index build ve metadata şeması
- 3Filtreli ANN sorgusu
- 4Recall, latency ve bakım ölçümü
Tasarım parametreleri
- Recall hedefi
- Brute-force top-k ile karşılaştırıp kritik sorgularda örneğin recall@10 ≥ %95 eşiği koyun.
- Filtre seçiciliği
- %50, %10, %1 ve %0,1 kalan veri oranlarında latency ve recall ölçün.
- Yazma profili
- Günlük ekleme, silme ve yeniden embedding oranını index maintenance/vacuum maliyetiyle ölçün.
- Bellek bütçesi
- Vektör, graph/list yapısı, metadata index, cache ve replikayı ayrı kapasite kalemleri yapın.
Hesap ve uygulama örneği
On milyon 1.536 boyutlu float32 vektör yalnız ham değerlerde yaklaşık 61,4 GB'tır. ID, metadata, indeks, WAL/replica ve çalışma payı eklenince bunun birkaç katı gerekebilir. Quantization belleği düşürür fakat recall ve reranking etkisi aynı veriyle ölçülmelidir.
HNSW ef_search 40'ta recall@10 %91 ve p95 18 ms; ef_search 120'de %97 ve 34 ms veriyorsa seçim 40/120 etiketi değil SLO ve kritik hata maliyetidir. %0,1 tenant filtresinde sonuç sayısı düşüyorsa filter-aware plan ayrıca ayarlanır.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
vector-bench load --vectors 10000000 --dims 1536 --filters tenant,doctype
vector-bench run --indexes hnsw,ivfflat --k 10 --filter-selectivity 0.5,0.1,0.01,0.001
vector-bench compare --ground-truth exact --metrics recall,p95,qps,memoryHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Filtreli sorgu az sonuç dönüyor | ANN adayları filtre sonrası tükeniyor veya filtre indeksi yoktur. | Aday/probe/ef ayarlarını ve filtre öncesi-sonrası sayıları brute-force sonuçla karşılaştırın. |
| Yeni veride recall düşüyor | Küme dağılımı değişmiş veya index yeniden eğitim/build istiyordur. | Zaman dilimlerine göre recall ölçüp centroid/list veya graph bakımını inceleyin. |
| Silme sonrası disk büyüyor | Tombstone, vacuum/compaction veya snapshot politikası alanı geri kazanmıyor. | Canlı kayıt, index boyutu, silinmiş oran ve bakım işlerini karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Embedding sürümü ve mesafe metriğini koleksiyon şemasında sabitleyin.
- Brute-force referans sorgu setini saklayın.
- Filtre seçiciliği dilimlerinde recall ve p95 ölçün.
- Ekleme, silme ve reindex sırasında üretim etkisini test edin.
- Tenant yetkisini sorgu filtresinde ve erişim katmanında doğrulayın.
- Yedekleme, restore ve indeks yeniden kurma sürelerini ölçün.
İlgili kavramlar
İndeks ve sorgu planı
İndeks, uygun sorgularda taranacak veriyi azaltabilir; her yeni indeks yazma, bakım ve depolama maliyeti getirir. Sütun sırası, seçicilik, filtre ve sıralama gereksinimi birlikte değerlendirilir. Sorgu yavaşlığını yalnız indeks yokluğuna bağlamayın: yanlış tahmin, kilit beklemesi, disk gecikmesi veya gereksiz veri taşıma da neden olabilir. Temsilî sorgunun yürütme planını ve gerçek satır sayılarını inceleyin. Değişikliğin okuma kazancını, yoğun yazma sırasında oluşturduğu maliyetle birlikte ölçün; üretimde kontrolsüz bakım işlemleri başlatmayın.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
IOPS ve blok boyutu
IOPS saniyedeki I/O işlem sayısını, MB/s ise taşınan veri miktarını anlatır. Aynı IOPS sayısı farklı blok boyutlarında çok farklı bant genişliği üretir. Örneğin 10.000 işlem/s × 4 KiB yaklaşık 39,1 MiB/s eder. Okuma/yazma oranı, rastgele veya sıralı erişim ve veri koruma mekanizması sonucu değiştirir. Bir benchmark sonucunu üretim uygulamasına doğrudan taşımak yerine gerçek blok dağılımını ve eşzamanlılığı ölçün. Diskin yüksek IOPS göstermesi, uygulama yanıtının iyi olduğu anlamına gelmez; gecikme de birlikte incelenmelidir.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.