turbopuffer v3'e geçiyor: vektör dizini ikincil dizine dönüşüyor

Sunucu tarama sistemi turbopuffer'ın blogunda 30 Eylül'de „RIP, vector database“ başlıklı bir yayın yayımlandı. Şirket mühendisi Dan Harrison yeni depolama mimarisi turbopuffer v3'ü anlattı: belgeler ve dizinler artık ANN vektör adresine bağlanmayacak, vektör dizini ikincil role geçecek ve ana dizin işlevi yeni bir yapıya devredilecek.

Şirketin açıklamasına göre, değişiklik metin, regex ve vektör dahil her tür aramayı hızlandıracak ve turbopuffer üzerinde çok daha fazla SQL isteğinin hızlı bir şekilde yerine getirilmesini sağlayacak.

v1'den v2'ye

turbopuffer sunucu tarafı vektör veritabanı olarak başladı: bir belge yalnızca ID ve vektörden oluşuyordu, verilerin asıl hali nesnel depolamada saklanıyor, hız ise NVMe diskleri ve bellek ön belleği tarafından sağlanıyordu. Vektörler hiyerarşik kümeler halinde yerleştiriliyordu: önce SPANN ile, daha sonra şirketin artımlı dizinleme için seçtiği SPFresh ile. İlk müşteriler arasında Cursor ve Notion vardı. İkinci nesil, nitelik tabanlı filtreleme ve BM25 metin araması ekledi; ardından regex araması, fuzzy eşleştirme, seyrek vektörler ve agregasyonlar geldi. Motor arama dışı görevlerde de kullanılıyor, örneğin Linear'ın eşitleme sisteminde. Arama yetenekleri büyürken depolama düzeni vektör dizinine dayalı kaldı ve bu durum GROUP BY ile agregasyon planlarını sınırlıyordu.

Üç sorun

Yayında vektör dizinine dayalı depolama düzeninin üç eksikliği adlandırılıyor. Birincisi, depolamada veri çoğaltma: belgenin tam içeriği vektör adresinde saklanır; bu yüzden çok vektörlü temsiller, örneğin belge gömme veya late interaction, aynı verileri her vektörde yeniden oluşturur. İkincisi, yazma çoğaltma: SPFresh kümeleri her yazma, güncelleme veya silme işleminde yeniden düzenlenir ve nitelikler ile ters dizinler de aynı adrese bağlı olduğundan, tek bir vektörün güncellenmesi yüzlerce niteliği ve onların dizinlerini taşıyabilir. Üçüncüsü, vektörleştirme sınırı: modern motorlar değerleri bloklar halinde işler (DuckDB 2 048 satır kullanır, ClickHouse yaklaşık 65 bin, Lucene bloklarında 256 belge vardır), turbopuffer'ın ANN kümeleri ise en iyi şekilde 100-200 belgeyle çalışır; bu nedenle daha büyük bloklar isteyen planlar bu sınırı aşamaz.

Örnek olarak şirket kendi metin aramasını gösterir: postingleri sabit bloklara (yaklaşık 256) bölmek dizini 10 kat küçülttü ve istekleri 20 kat hızlandırdı.

Sıradaki ne

v3 henüz ortama alınmadı. Eylül'de şirket önemli bir eşiğe ulaştı: v3'te CI testlerinin %100'ü başarıyla geçiyor. Ekip şimdi doğruluktan hıza geçiyor ve kıyaslamaları önümüzdeki haftalarda turbopuffer.com/v3 adresinde herkese açık olarak yayımlayacak; böylece v3 ortama alınmadan önce verimlilik paralelliğine ulaşacak ve onu aşacak.

turbopuffer'e göre sistem 1 trilyondan fazla belgeye ev sahipliği yapıyor, saniyede 10 milyondan fazla yazma işliyor ve saniyede 25 binden fazla isteği karşılıyor. Önceki mimari için şirket vektör aramasını 100 milyardan fazla vektöre sahip ayrı dizinlere kadar taşıdı: p99 okuma süresi 200 milisaniyeydi, hız ise saniyede 1000'den fazlaydı.