Vector Databases

pgvector Performansını Optimize Etme: Üretim Yükleri İçin İndeksleme Stratejileri ve Sorgu İnce Ayarı

pgvector aracılığıyla PostgreSQL'e vektör arama yeteneklerini entegre etmek, Geri Bildirimle Artırılmış Üretim (RAG) sistemlerinin ve benzerlik arama uygulamalarının dağıtımını demokratikleştirmiştir. Ancak, kavram kanıtı prototipinden yüksek verimli bir üretim ortamına geçiş, performans darboğazlarını ortaya çıkarabilir. Naif bir uygulama, yavaş sorgulara, yüksek gecikme sürelerine ve gereksiz CPU yüküne yol açabilir. Bu yazı, akıllı indeksleme stratejileri ve sorgu ince ayarı yoluyla pgvector performansının nasıl optimize edileceğini incelemektedir.

İndeksleme Manzarasını Anlamak

pgvector şu anda iki birincil indeksleme yöntemini desteklemektedir: HNSW (Hiyerarşik Gezinilebilir Küçük Dünya) ve IVFFlat (Düz Öbekleme ile Ters Dosya). Doğru indeksi seçmek, performans için yapabileceğiniz en etkili karardır.

HNSW, genellikle çoğu üretim kullanım durumu için önerilir. Veri seti büyüdükçe IVFFlat'e kıyasla üstün geri çağırma oranları ve daha hızlı sorgu süreleri sunar. Daha fazla bellek tüketir ve oluşturulması daha uzun sürse de, grafik yapısını verimli bir şekilde gezinme yeteneği, düşük gecikme süresi gereksinimleri için idealdir. Buna karşılık, IVFFlat bellek açısından daha hafiftir ve daha hızlı oluşturulur ancak daha fazla disk G/Ç gerektirir ve liste sayısı önemli ölçüde artırılmadıkça genellikle daha düşük geri çağırma sunar. Belleğin kısıtlı olduğu veya veri setlerinin statik ve orta boyutta olduğu senaryolar için en uygunudur.

Optimize Edilmiş İndekslerin Oluşturulması

İndeks oluştururken, mesafe metriği ve belirli parametrelerin seçimi, aramanın kalitesini belirler. BERT veya OpenAI'nin text-embedding-3-small gibi modellerden türetilen metin gömme vektörleri için kosinüs mesafesi genellikle standarttır. İşte optimize edilmiş bir HNSW indeksi oluşturma yöntemi:


CREATE INDEX CONCURRENTLY embedding_idx 
ON documents 
USING hnsw (embedding vector_cosine_ops);

Bununla birlikte, varsayılan ayarlar nadiren üretim için optimaldir. m parametresi, grafik oluşturma sırasında oluşturulan çift yönlü bağlantı sayısını kontrol ederken, ef_construction indeks oluşturma sırasında arama kalitesini etkiler. Yüksek kaliteli sonuçlar için ef_construction değerini artırmayı düşünün:


CREATE INDEX CONCURRENTLY embedding_idx 
ON documents 
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

m ve ef_construction için daha yüksek değerler, bellek kullanımını ve oluşturma süresini artırır ancak geri çağırma doğruluğunu önemli ölçüde iyileştirir.

Sorgu Performansının İncelenmesi

İyi optimize edilmiş bir indeksle bile, arama parametreleri incelenmezse sorgu performansı bozulabilir. hnsw_ef_search ayarı, arama algoritması için bir bütçe gibi davranır. Varsayılan olarak 40 olarak ayarlanmıştır ve hız ile doğruluk arasında denge kurar. Üretim yükleri için, kabul edilebilir gecikme sürenize ve istenen geri çağırma oranınıza göre bunu ince ayar yapmalısınız.

Yüksek p99 gecikme yaşıyorsanız, hnsw_ef_search değerini azaltmayı deneyin. Uygulamanız neredeyse mükemmel geri çağırma doğruluğu gerektiriyorsa, bunu artırın. Bunu oturum düzeyinde ayarlayabilirsiniz:


SET hnsw.ef_search = 128;
SELECT * 
FROM documents 
ORDER BY embedding <#> '[0.1, 0.2, ..., 0.1]'::vector
LIMIT 10;

Ölçekleme İçin Pratik Düşünceler

Veri setiniz yüz milyonlarca vektörü aştığında, tablolarınızı bir vektör olmayan sütuna (örneğin bir kiracı kimliği veya tarih) göre bölmeyi düşünün. Bu, daha küçük ve daha odaklanmış indeksler oluşturmanıza olanak tanır ve grafik gezinme üst yükünü azaltır. Ayrıca, indeks oluşturmalarla ilişkili ağır yazma yükünü yönetebilmek için veritabanı sunucunuzun yeterli paylaşılan belleğe (shared_buffers) ve yapılandırılmış WAL düzeyi ayarlarına sahip olduğundan emin olun.

Sonuç

pgvector optimizasyonu tek seferlik bir kurulum değil, yinelemeli bir süreçtir. Dengeli performans profili nedeniyle HNSW ile başlayın, gecikme süresi ve doğruluk SLA'larınıza uyacak şekilde ef_construction ve ef_search değerlerini ince ayar yapın ve bellek kullanımı ile sorgu hızı arasındaki ödemeleri izleyin. Bu stratejileri uygulayarak, PostgreSQL içindeki vektör arama gücünden performans veya güvenilirlikten ödün vermeden yararlanabilirsiniz.

Share: