MicrocosmWorksDijital Kozmosu Yenilikçi ve Mimari Olarak Tasarlamak
Hakkındaİletişim
MicrocosmWorksDijital Kozmosu Yenilikçi ve Mimari Olarak İnşa Etmek

Önemli BT çözümleri sunuyoruz. Teknoloji, güvenlik ve işletmelerin güvenilir, yenilikçi BT altyapısı ile büyümesine yardımcı olmaktan tutkuluyuz.

[email protected]
+91 7011868196
New Delhi, India

AI Büyüme Merkezi

AI MerkeziStartup İnovasyonuKurumsal Hızlandırıcı

Çözümler

Tüm ÇözümlerSağlık ve Fitness UygulamalarıAI Video PlatformuAI Ajan Geliştirme

Kaynaklar

ÖngörülerSektör RehberleriKullanım Durumu ŞablonlarıMimari KalıplarVaka Çalışmaları

Şirket

HakkımızdaİletişimÇalışmalarımız

Hizmetler

Dijital DanışmanlıkBulut AltyapısıSaaS GeliştirmeYapay Zeka GeliştirmeVideo Teknolojisi
ERP GeliştirmeZoho ÖzelleştirmeOdoo GeliştirmeSalesforce EntegrasyonuÖzel CRM Geliştirme
QuickBooks EntegrasyonuIoT ÇözümleriBlokzincir Geliştirme
Siber Güvenlik DanışmanlığıIT Desteği - L3

© 2026 MicrocosmWorks. Tüm hakları saklıdır.

Gizlilik PolitikasıHizmet Şartları
Mimari Desenlere Geri Dön
AI / DataEnterprise

Ölçeklenebilir Vektör Veritabanı Mimarisi

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.

June 22, 2026
|
2 topics covered
Bu Mimariyi Tartışın
scalable-vector-database-architecture.webp
AI / Data
Category
Enterprise
Complexity
AI/ML, E-Commerce
Industries
2+
Technologies

Buna Ne Zaman İhtiyacınız Olur

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.

Related Architecture Patterns

Explore more design patterns and system architectures

ai-ml-pipeline-architecture.webp
AI / Data

AI/ML İş Akışı Mimarisi

Modeller kendi başlarına çalışmaz. Modellerinizi eğiten, doğrulayan, dağıtan ve izleyen iş akışı asıl üründür; model sadece bir eserdir.

EnterpriseView
rag-pipeline-architecture.webp

Bu Mimarinin Uygulanmasında Yardıma İhtiyacınız Var mı?

Mimarlarımız, bu deseni kullanarak belirli gereksinimleriniz için sistemler tasarlamanıza ve oluşturmanıza yardımcı olabilir.

İletişime Geçin

Kalıp Genel Bakış

Ö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.

Referans Mimari

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.

Temel Bileşenler
  • Küme Yönetimi: Milvus (ölçek için varsayılanımız) metadata koordinasyonu için etcd ile, segment depolama için MinIO/S3 ve write-ahead logging için Pulsar/Kafka. Alternatif olarak, operasyonel basitlik maliyetten ağır bastığında yönetilen hizmetler (Pinecone, Zilliz Cloud)
  • Shard ve Bölümleme Stratejisi: Veri sınırlarına göre hizalanmış mantıksal bölümler (kiracı başına, belge koleksiyonu başına, zaman penceresi başına). Her bölüm bağımsız olarak aranabilir, böylece tüm indeksi taramadan filtrelenmiş sorgular etkinleştirilir. Paralel sorgu yürütme için düğümler arasında dağıtılmış shard'lar
  • Kademeli Depolama Motoru: Sık sorgulanan koleksiyonlar için sıcak katman (bellek içi HNSW/IVF indeksi). Orta düzeyde sorgu yüküne sahip büyük koleksiyonlar için ılık katman (bellek eşlemeli SSD). Aranabilir ancak daha yüksek gecikmeye tolerans gösteren arşiv koleksiyonları için soğuk katman (S3 destekli). Erişim desenlerine dayalı segment düzeyinde terfi/indirme
  • Otomatik Ölçeklendirme Denetleyicisi: QPS ve P99 gecikme metriklerine göre sorgu düğümlerini ölçeklendiren Kubernetes üzerindeki yatay pod otomatik ölçeklendirici (HPA). Gecikme ihlalinde ölçeklendirme, sürekli düşük kullanımda ölçeklendirme. Sorgu performansını etkilemeden ani yüklemeleri ele almak için alım çalışanları için ayrı ölçeklendirme

Tasarım Kararları ve Takaslar

Milvus vs. Pinecone vs. Qdrant vs. pgvector
pgvector, zaten PostgreSQL'iniz varsa ve ~200ms gecikmeye tahammül edebiliyorsanız 1M vektörden az için uygundur. Pinecone, sıfır operasyonel yük isteyen ve fiyatlandırmayı kabul edebilen ekipler için (iyi ölçeklenir ancak 10M vektörü geçince pahalılaşır). Qdrant, iyi tek düğüm performansına sahip temiz bir API için. Milvus, ciddi ölçek için — gerçek dağıtılmış mimariye, kademeli depolamaya ve üretim sınıfı sharding'e sahip tek açık kaynak seçeneğidir. MW, 5M'den fazla vektör için Milvus'u ve yönetilen basitliği önceliklendiren ekipler için Pinecone'u varsayılan olarak kullanır.
HNSW vs. IVF_FLAT vs. IVF_PQ
HNSW (Hierarchical Navigable Small World), düşük gecikmede en iyi geri çağırmayı (recall) sağlar ancak en çok belleği kullanır (RAM'de tam vektörler). IVF_FLAT vektörleri kümelendirir ve yalnızca ilgili kümelerde arama yapar — hız ve bellek arasında iyi bir denge. IVF_PQ (Product Quantization), büyük bellek tasarrufu için vektörleri sıkıştırır ancak geri çağırmayı %3-8 oranında azaltır. MW, 10M vektörün altındaki koleksiyonlar için HNSW kullanır ve bellek maliyetinin önemli olduğu daha büyük koleksiyonlar için PQ iyileştirmesi (tam vektörlere karşı en iyi adayları yeniden puanlama) ile IVF_PQ'ya geçer.
Yazma İzolasyonu
Alım sırasında eşzamanlı yazmalar, çoğu vektör veritabanında sorgu gecikmesini düşürür. MW, yazma yolunu ayırır: yeni vektörler bir write-ahead log'da arabelleğe alınır, periyodik olarak mühürlü segmentlere boşaltılır ve düşük trafik zamanlarında aranabilir indekse birleştirilir. Gerçek zamanlı alım gerektiren sistemler için (örn. canlı belge işleme), farklı kaynak tahsisleri ile ayrı alım ve sorgu düğüm havuzları dağıtırız.
Maliyet Optimizasyonu
Vektör veritabanları bellek açısından yoğundur. 1536 boyutlu gömülere sahip 100M vektörlük bir koleksiyon, HNSW modunda ~600GB RAM'e ihtiyaç duyar. MW maliyeti şu yollarla optimize eder: (a) mümkün olduğunda boyutluluk azaltma (Matryoshka embeddings, PCA), (b) niceleme (skaler veya ürün niceleme), (c) soğuk segmentleri RAM'den çıkarmak için kademeli depolama ve (d) gömü boyutlarını doğru boyutlandırma — 1536 abartılı olduğunda 768 boyut genellikle yeterlidir.

Teknoloji Seçimleri

KatmanTeknolojiler
Vektör VeritabanıMilvus (dağıtılmış), Qdrant (tek düğüm/küçük küme), Pinecone (yönetilen)
Depolama Arka UcuMinIO / S3 (segment depolama), SSD (ılık katman), RAM (sıcak katman)
Koordinasyonetcd (Milvus metadata), Pulsar/Kafka (write-ahead log)
Gömü ModelleriOpenAI 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)
İzlemeGrafana + Milvus metrik dışa aktarıcı, özel P99/recall kontrol panelleri

Ne Zaman Kullanmalı / Ne Zaman Kaçınmalı

Kullanım DurumlarıKaçınılması Gereken Durumlar
Vektör sayısı 5M'yi aşıyor ve büyüyor, yatay ölçeklendirme gerektiriyor1M'den az vektörünüz var — mevcut PostgreSQL üzerindeki pgvector yeterlidir
100 ms'nin altında P99 sorgu gecikmesi zorunlu bir gereksinimdir500 ms ve üzeri sorgu gecikmesi kabul edilebilir — daha basit seçenekler işe yarar
Birden çok uygulama/kiracı vektör altyapısını paylaşıyorTek 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

Yaklaşımımız

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.

İlgili Şablonlar

  • AI Müşteri Destek Temsilcisi — Destek yanıtları için bilgi altyapısını güçlendiren vektör araması
  • AI Belge İşleme Hattı — Çıkarılan belge içeriğinin gömülmesi ve indekslenmesi
  • AI Odaklı Kişiselleştirilmiş Öğrenme Platformu — İçerik önerileri için vektör benzerliği

İlgili Vaka Çalışmaları

  • Milvus Otomatik Ölçeklendirme — Kubernetes HPA ve S3 destekli kademeli depolamaya sahip üretim Milvus kümesi
  • Belge Zekası — Yerel belge alımı ve analizi için vektör araması
Related Technologies
AI GeliştirmeBulut Çözümleri
AI / Data

RAG Boru Hattı Mimarisi

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.

AdvancedView
multi-tenant-saas-architecture.webp
Application

Çok Kiracılı SaaS Mimarisi

Tek bir kod tabanı, yüzlerce kiracı, sıfır veri sızıntısı — her ölçeklenebilir SaaS işinin temeli.

AdvancedView

Sıkça Sorulan Sorular

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.