Vector, PostgreSQL'ün yeni JSON'u

• Vektör, iyi araştırılmış bir matematiksel yapıdır; JSON ise bir veri değişim biçimidir
• Ancak veri depolama ve sorgulama dünyasında bu iki veri gösterim biçimi ortak dil haline geldi ve modern uygulama geliştirmede yakında vazgeçilmez unsurlar olacak
• Mevcut eğilim sürerse, vektörler de uygulama geliştirmede JSON kadar önemli hale gelecek
• Üretken yapay zeka çıktılarının depolanması ve sorgulanması için PostgreSQL doğal bir tercih oldu
• Ancak bu yeni bir veri deseni değil. Matematiksel bir kavram olarak vektörler yüzlerce yıldır var
• Vektörün temel veri yapısı olan dizi, çoğu bilgisayar bilimine giriş dersinde öğretilir. PostgreSQL de 20 yılı aşkın süredir Vector işlemlerini destekliyor
• Peki yeni olan ne? Bu tür AI/ML algoritmalarının "erişilebilirliği" ve bazı "gerçek dünya" yapılarının (metin, görsel, video) vektörlerle ifade edilip daha sonra uygulamalarda kullanılmasının ne kadar "kolay mümkün olduğu"
• Ayrıca bu sistemlerin çıktılarının ("embedding") bir veri deposunda saklanması da tamamen yeni sayılmaz; fakat yeni desen, bu verilerin neredeyse gerçek zamanlı olarak tüm uygulamalarda sorgulanıp döndürülebilmesindeki "erişilebilirlik"
• Peki bunun PostgreSQL ile ne ilgisi var?
  • Veri tiplerini verimli biçimde depolayıp sorgulamanın ortak deseni, uygulama geliştirmeyi büyük ölçüde basitleştirdi ve insanların verileri aynı ortamda tutup mevcut araçlarla çalışabilmesini sağladı
  • Bunu 10 yıl önce JSON ile gördük; şimdi de aynı deseni vektör verilerinde görüyoruz

PostgreSQL'de JSON'un kısa tarihi

(Orijinal metne bakın)

Vektörlerin yükselişi: "yeni tür bir JSON"

• Son zamanlarda popülerliği hızla artıyor
• Yaygın kullanım senaryosu, saklanan veri üzerinde bir model kurup bunu vektör formatına dönüştürmek ve ardından "semantic search" için kullanmak
  • Bu durumda, aramaya gelen yeni girdi vektör formatına çevrilir ve ardından veritabanında en benzer öğeler aranır
  • Benzerlik, Öklid/kosinüs uzaklığı gibi uzaklık fonksiyonlarıyla ölçülür ve sonuçlar çoğu zaman k-NN (Nearest Neighbors) ya da en benzer k öğe ile sınırlandırılır
  • Vektörlerin eğitim kümesini kodlamak çok zaman alabileceği için, bunları DB gibi bir yerde cache'lemek ve k-NN sorgularını orada çalıştırmak mantıklıdır
  • Semantic search için sorgulanmaya hazır bir vektör kümesine sahip olmak genellikle kullanıcıya daha iyi deneyim sunduğundan, "vektör veritabanı" ihtiyacı ortaya çıktı
• Vektör depolama PostgreSQL için yeni değil
  • Aslında PostgreSQL çok boyutlu verileri (ör. matrix) depolayabildiğinden bu biraz yanlış adlandırma
  • Temelde PostgreSQL dizileri, iki dizi arasındaki "mesafe"yi hesaplama gibi vektörlere yönelik sınırlı işlevler içeriyor
  • Stored procedure yazılabilir, ancak bu geliştirici açısından biraz daha fazla çalışma gerektirir
• Neyse ki cube veri tipi bu sınırlamaları aşıyor
  • cube 20 yıldan uzun süredir kullanılıyor ve yüksek boyutlu vektörlerle işlem yapmak için tasarlandı
  • cube, Öklid uzaklığı dahil, vektör benzerlik aramasında kullanılan yaygın uzaklık fonksiyonlarının çoğunu içeriyor
  • GiST indeksleriyle verimli K-NN sorguları da yapılabiliyor
  • Ancak cube yalnızca 100 boyuta kadar vektör saklayabiliyor; modern AI/ML sistemleri ise daha yüksek boyutlar gerektiriyor

pgvector: PostgreSQL'de vektör depolamak ve sorgulamak için açık kaynak bir eklenti

• pgvector ile vektörler saklanabilir ve çeşitli uzaklık metrikleriyle (Öklid, kosinüs, iç çarpım vb.) k-NN sorguları yapılabilir
• Şu anda pvector, vektör indeksleme için IVR FLAT yöntemini uygulayan tek bir indeks olan ivfflat ile geliyor
• İndekslenmiş vektör verisini sorgulamak, normal veriyi sorgulamaktan farklı olabilir
• Yüksek boyutlu vektörlerde en yakın komşu aramasının maliyeti nedeniyle, birçok vektör indeksleme yöntemi doğru yanıta "yeterince yakın" olan "yaklaşık" bir yanıt bulur
• Bu da "ANN (Approximate Nearest Neighbor)" arama alanına yol açtı
• İnsanların ANN sorgularında baktığı iki ana boyut, performans ile "recall" (ilgili sonuçların geri dönme yüzdesi) arasındaki dengedir
  • ivfflat örneğinde, ivfflat indeksini oluştururken kaç listenin dahil edileceğine karar verilir
  • Her liste bir "merkez"i temsil eder ve bu merkezler k-means algoritmasıyla hesaplanır
  • Tüm merkezler belirlendikten sonra ivfflat, her vektörün en yakın olduğu merkezi saptar ve bunu indekse ekler
  • Vektör verisi sorgulanırken, ivfflat.probes değişkenine göre kaç merkezin kontrol edileceğine karar verilir
  • ANN performans/recall ödünleşimi burada görülebilir. Daha fazla merkez ziyaret edildikçe sonuçlar daha doğru olur, ancak performans düşer

PostgreSQL'de vektörleri daha iyi desteklemek için sonraki adımlar

• Resmi JSON tipinin desteklendiği PostgreSQL 9.2 döneminde olduğu gibi, vektör verisini PostgreSQL'de saklama yöntemlerinin henüz erken aşamasındayız
• PostgreSQL ve pgvector şimdiden iyi, ama çok daha iyi hale gelecek
• pgvector halihazırda yaygın AI/ML veri senaryolarını işleyebiliyor. Birçok kullanıcı bunu zaten dağıtıma almış durumda
• Sonraki adım, iyileştirme ve genişletmeye yardımcı olmak; bunların çoğu da zaten sürüyor
  • Daha fazla paralelleştirme eklemek
  • 2 binin üzerinde boyuta sahip vektörler için destek
  • Hesaplama hızını artırmak için donanım hızlandırmadan yararlanmak
• PostgreSQL'i bir vektör "veritabanı" olarak kullanma konusunda büyük beklenti var
• JSON'un geçmişinde görüldüğü gibi, PostgreSQL topluluğu bunu genişletilebilir ve güvenli bir şekilde desteklemenin yolunu bulacaktır

[atempest]

Genel kullanım açısından güçlü olabilir ama sonuçta belirleyici olan şey hız değil mi diye düşünüyorum.
Saf(?) vector DB'lere kıyasla göze batacak kadar yavaş olacak gibi görünüyor....

[nicewook]

Pinecone gibi vektör veritabanları varken neden PostgreSQL’den bu kadar umut beklendiğini merak ediyorum. @@

[tkwlsrl]

Benim deneyimime göre en erişilebilir olan PostgreSQL'di.

Pinecone, ChromaDB ya da Weaviate gibi çözümleri kullanırken, her veritabanını kullanabilmek için standartlaşmış bir yapı yoktu.

Yani her veritabanı için farklı bir SDK kullanmak gerekiyordu ve kullanım şekilleri de farklıydı; bu yüzden kodu her veritabanı için yeniden yazmak zorunda kalıyorduk. Ayrıca resmi SDK'ların desteklediği diller de sınırlıydı, bu yüzden bazen dili değiştirmek bile gerekiyordu.

Elbette PostgreSQL'de vektör kullanmaya çalışırken de durum biraz benzer, ama en azından mevcut SQL söz dizimine biraz daha bilgi eklemek yettiği için yaklaşması daha kolaydı.

Şu anda vektör veritabanlarının hızını karşılaştırdığımızda PostgreSQL oldukça yavaş tarafta kalıyor. Umarım yakında biraz geliştirilir. haha

[xguru]

Muhtemelen mesele, "her şeyi destekleyen tek bir DB kurup/yönetmenin daha rahat olması" + "diğer özelliklerle entegrasyonun kolay olması" gibi bir şeydir.
Instance sayısı arttıkça giderek daha uğraştırıcı oluyor..

[nicewook]

Aha, anladım.
Demek Redis'in oraya buraya bir şeyler eklemesinin sebebi de buymuş. Baş sallıyorum.

[iolothebard]

Başlangıcı da sonucu da... tensör...

[xguru]

Yazının yazarı Jonathan Katz, PostgreSQL Core Team üyesidir.