10 bin vektörde gömme araması kolaydır. 100 milyon vektörde, 100 ms'nin altında P99 ile bu bir altyapı sorunudur — ve bu kalıp bunu çözüyor.

RAG hattınız veya öneri sisteminiz, geliştirme aşamasında birkaç bin vektörle harika çalışır. Şimdi 50 milyon gömüye sahipsiniz, sorguların 100 ms'nin altında gecikmeye ihtiyacı var, indeks büyümeye devam ediyor ve belleği hızla tüketiyorsunuz. Yatay olarak ölçeklenebilen, belleği verimli yöneten (her şeyin RAM'de yaşamasına gerek yok), sorgu performansını düşürmeden alım sırasında eşzamanlı yazmaları işleyen ve esasen bir arama indeksi olan şey için ayda 10 bin dolar altyapı maliyeti olmayan bir vektör veritabanı mimarisine ihtiyacınız var.
Explore more design patterns and system architectures
Mimarlarımız, bu deseni kullanarak belirli gereksinimleriniz için sistemler tasarlamanıza ve oluşturmanıza yardımcı olabilir.
İletişime GeçinÖlçeklenebilir vektör veritabanı mimarisi, üretim ölçeğinde vektör aramasını çalıştırma zorluklarını ele alır: düğümler arası indeks bölümleme (sharding), kademeli depolama (bellekte sıcak segmentler, SSD'de ılık, S3'te soğuk), yük dengeleme ile sorgu yönlendirme ve sorgu yüküne ve indeks boyutuna dayalı otomatik ölçeklendirme. Bu kalıp, dağıtım topolojisini, kapasite planlamasını, yazma/okuma izolasyonunu ve maliyet optimizasyonunu kapsar. RAG ve öneri sistemlerini ölçekli olarak uygulanabilir kılan altyapı katmanıdır.
Mimari, vektör veritabanı düğümlerini sorgu düğümleri (okuma yolu) ve veri düğümleri (yazma yolu) arasında ayrım yapan bir kümelenmiş topolojide dağıtır. Bir alım hattı, sorgu gecikmesini etkilememek için yazma arabelleği ile gömü oluşturmayı ve toplu upsert işlemlerini yönetir. Bir sorgu yönlendiricisi, shard düzeyinde paralellik ile okuma replikaları arasında aramaları dağıtır. Kademeli depolama, nadiren erişilen segmentleri bellekten SSD'ye ve S3'e taşır, şeffaf sorgu zamanı yüklemesiyle. Otomatik ölçeklendirme, sorgu QPS'sine ve P99 gecikmesine göre replika sayısını ayarlar.
| Katman | Teknolojiler |
|---|---|
| Vektör Veritabanı | Milvus (dağıtılmış), Qdrant (tek düğüm/küçük küme), Pinecone (yönetilen) |
| Depolama Arka Ucu | MinIO / S3 (segment depolama), SSD (ılık katman), RAM (sıcak katman) |
| Koordinasyon | etcd (Milvus metadata), Pulsar/Kafka (write-ahead log) |
| Gömü Modelleri | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| Altyapı | Gömü için GPU düğümleri, sorgu için bellek optimize edilmiş düğümleri olan Kubernetes (EKS/GKE) |
| İzleme | Grafana + Milvus metrik dışa aktarıcı, özel P99/recall kontrol panelleri |
| Kullanım Durumları | Kaçınılması Gereken Durumlar |
|---|---|
| Vektör sayısı 5M'yi aşıyor ve büyüyor, yatay ölçeklendirme gerektiriyor | 1M'den az vektörünüz var — mevcut PostgreSQL üzerindeki pgvector yeterlidir |
| 100 ms'nin altında P99 sorgu gecikmesi zorunlu bir gereksinimdir | 500 ms ve üzeri sorgu gecikmesi kabul edilebilir — daha basit seçenekler işe yarar |
| Birden çok uygulama/kiracı vektör altyapısını paylaşıyor | Tek bir koleksiyona sahip tek bir uygulama — yönetilen bir hizmet kullanın |
| Maliyet optimizasyonu kademeli depolama gerektiriyor (her şey RAM'de değil) | Bütçeniz tamamen yönetilen hizmetlere izin veriyorsa ve satıcının fiyatlandırması ölçeğinizde işe yarıyorsa |
MW, vektör veritabanı altyapısını "ilk günden doğru boyutta, ölçüldüğünde ölçeklendir" yaklaşımıyla tasarlar. Kapasite planlamasına, vektör sayısı, boyutluluk, indeks türü ve hedef gecikme gibi kesin verilere dayanarak başlarız — tahmine değil. Kubernetes üzerindeki Milvus dağıtımlarımız, segment sayısını, bellek kullanımını, sorgu gecikmesi yüzdeliklerini ve geri çağırma (recall) tahminlerini izleyen Grafana kontrol panelleri içerir. İş saatlerinde 10 kat trafik artışlarını yöneten ve gece boyunca ölçeği küçülten otomatik ölçeklenen Milvus kümeleri uyguladık, böylece altyapı maliyetini statik kaynak sağlamaya kıyasla %40-60 oranında azalttık.
LLM'nize özel ayarlama yapmadan verilerinize erişim sağlayın. RAG, genel amaçlı dil modelleri ile alana özel bilgi arasındaki boşluğu doldurur.
MicrocosmWorks, ekibin zaten PostgreSQL kullandığı durumlarda, yeni bir altyapı bileşeni eklemekten kaçındığı ve hibrit SQL-plus-vector sorgularını doğal olarak desteklediği için 5-10 milyondan az vektöre sahip projeler için genellikle pgvector'ı önerir. 10 milyon vektörün üzerinde veya yüksek eşzamanlılıkta 50ms altı p99 latency gerektiğinde, Qdrant, Weaviate veya Milvus gibi amaca yönelik bir vektör veritabanı, optimize edilmiş indeksleme algoritmaları ve GPU hızlandırmalı arama sayesinde önemli ölçüde daha iyi performans sağlar. Müşterilerin bu kararı, mimari inceleme sırasında gerçek sorgu modellerini ve büyüme projeksiyonlarını kıyaslayarak vermelerine yardımcı oluyoruz.
MicrocosmWorks, vektör veritabanı kümelerini, vektörleri düğümler arasında dağıtan ve verimli arama için anlamsal olarak ilişkili verileri aynı yerde tutan hash tabanlı veya metadata tabanlı sharding stratejileriyle tasarlar. Arama isteklerini ilgili shard'lara dağıtan ve sonuçları küresel bir top-K aggregation kullanarak birleştiren sorgu yönlendirme katmanları uyguluyor, düzinelerce shard'da bile 100ms altı gecikme süresini koruyoruz. İzleme panellerimiz, veri setiniz büyüdükçe hotspot'ları önlemek için shard dengesini, sorgu dağıtımını ve replication lag'ini takip eder.
MicrocosmWorks, vektör depolamasını 4-8 kat sıkıştırmak için skaler niceleme (float32'yi int8'e düşürme) ve ürün nicelemesi uygular. Bu sayede, geri çağırmada (recall) genellikle %2'den az bir bozulma yaşanır. Bu durumu, üretime dağıtmadan önce gerçek sorgu iş yükünüz üzerinde A/B testi ile doğrularız. Ayrıca, nicelenmiş vektörlerin ilk aday geri çağırmayı sağladığı ve tam hassasiyetli vektörlerin yalnızca en iyi sonuçların nihai yeniden sıralaması için kullanıldığı iki aşamalı bir geri çağırma yaklaşımı uyguluyoruz. Bu hibrit strateji, müşterilerin yüz milyonlarca vektörü maliyetin çok küçük bir kısmına depolamasını sağlarken, sıkıştırılmamış işlemden ayırt edilemez bir arama kalitesini korur.
MicrocosmWorks, vektör veritabanlarını yazma dayanıklılığı için senkron replikasyonlu çoklu kopya (multi-replica) yapılandırmalarında konuşlandırır ve hata toleransı ile yük dengeleme (load balancing) için okuma kopyalarını (read replicas) erişilebilirlik bölgelerine (availability zones) dağıtır. Bir düğüm (node) arızasının 10 saniyeden az okuma erişilemezliği ve sıfır veri kaybıyla (data loss) sonuçlanmasını sağlamak için, sağlık kontrolü odaklı lider seçimi ile otomatik yük devretme (automated failover) yapılandırırız. Altyapı-kod olarak (infrastructure-as-code) şablonlarımız, her bir vektör veritabanı motoruna özel olarak hazırlanmış önceden yapılandırılmış yedekleme programları (backup schedules), belirli bir zamana kurtarma (point-in-time recovery) ve olağanüstü durum kurtarma (disaster recovery) runbook'larını içerir.
MicrocosmWorks, her uygulama veya gömme modelinin uygun dizin yapılandırmalarına sahip kendi izole koleksiyonunu aldığı ve maliyet verimliliği için temel küme altyapısını paylaştığı çoklu koleksiyonlu vektör veritabanı dağıtımları tasarlar. Uygulama bağlamına göre istekleri doğru koleksiyona yönlendiren ve eşleşen modelle sorgu gömme gibi koleksiyona özgü ön işleme uygulayan birleşik bir sorgu ağ geçidi uyguluyoruz. Bu çok kiracılı vektör veritabanı yaklaşımı, uygulama başına ayrı kümeler çalıştırmaya kıyasla altyapı maliyetlerini genellikle %40-60 oranında azaltır.