Databricks, Lakebase Postgres’a Tam Metin ve Vektör Aramasını Getiriyor

Databricks 28 Eylül 2026’da, Lakebase Search’ı tanıttı, Lakebase Postgres veritabanı için yerleşik bir arama motoru ve iki uzantı aracılığıyla sunulmaktadır: lakebasevektör yaklaşık en yakın komşu araması için ve lakebasetext BM25 tam metin araması için. Her iki uzantı da AWS ve Azure’da genel olarak kullanılabilir.

Bu uzantılar, geliştiricilerin operasyonel verilerin yanında doğrudan Postgres içinde anlamsal, anahtar kelime ve hibrit arama çalıştırmasına olanak tanır. Databricks, geleneksel OLTP sistemlerinin, düşük gecikme süresi ve yüksek doğruluklu geri getirme gerektiren ve genellikle büyük paralel aramalar yürüten AI ajanlarının arama taleplerine uygun olarak tasarlanmadığını, ve bu sorunun şimdiye kadar çözümünün, bir bağımsız arama motorunu bir ETL hattı aracılığıyla birincil veritabanına bağlamayı gerektirdiğini söyledi. Şirket, Lakebase Search’ı yüzlerce beta müşterisinin geri bildirimleriyle birlikte inşa ettiğini belirtti.

Benchmark Sonuçları ve Conexiom Dağıtımı

Databricks, lakebase_vector‘ın VectorDBBench 100M benchmark’ında bir sonraki en iyi sistemin iki katı verim sağladığını, bu benchmark’ın LAION veri kümesini kullandığını ve autoscaling’den elde edilecek ek tasarruflardan önce, pgvector kullanan bir bulut Postgres sağlayıcısına göre dört kat daha ucuz olduğunu söyledi. Şirket, %97 hatırlama oranında 71 milisaniye P99 gecikme süresi rapor etti; bu, motorun gerçek en yakın komşuları %97 oranında başarılı bir şekilde geri getirdiği anlamına geliyor ve pgvector ile DiskANN’in yalnızca tek bir büyük örnek üzerinde test edildiğini belirtti.

Databricks ayrıca Conexiom’dan bir müşteri sonucunu raporladı; Conexiom, önceki pgvector kurulumunun yarı hesaplama ayak izinde 100 milyondan fazla satır üzerinde BM25 hibrit araması gerçekleştiriyor. Şirket, Conexiom’un altyapı maliyetlerinin üç kat azaldığını ve pgvector’a göre beş kat artan bir verim sağladığını belirtti.

“Lakebase Search, pgvector üzerine bize tamamen yeni bir ölçeklenebilirlik seviyesi sağlıyor ve aynı sunucusuz veritabanında BM25’i açıyor,” dedi Conexiom’da AI/ML mimarı Jordan Voves. “Verileri ölçekli bir şekilde ajanlarımıza bağlamak için Lakebase’i kullanıyoruz.”

Tasarımın Arkasındaki Pgvector Sınırlamaları

Databricks, pgvector’ün Lakebase Postgres’te en çok kurulan uzantı olduğunu ve ölçekli olarak kullanan müşterilerden gözlemlenen üç tekrarlayan sorun noktasını tanımladığını söyledi.

İlk sorun, kullanım yerine veri hacmiyle ölçeklenen maliyettir. pgvector, HNSW indeksini veritabanı belleğinde tutar ve HNSW araması rastgele erişimli grafik geçişine dayandığından, indeks diske taşındığında ve sorgular rastgele okuma zincirlerine dönüştüğünde performans 10 ila 50 kat düşer. 768 boyutlu float32 vektör, grafik bağlantıları ve Postgres ek yükü dahil edildiğinde yaklaşık 3,3 kilobayt bellek tüketir; bu nedenle 100 milyon satır için bir indeksin yerinde kalması yaklaşık 330 gigabayt RAM gerektirir ve sorgular ona dokunup dokunmadığına bakılmaksızın tam olarak tahsis edilir.

İkinci sorun indeks bakımınıdır. Bir derleme diske taşındığında, pgvector indeksinin standart bir bulut örneğinde inşa edilmesi neredeyse 50 saat sürdü, Databricks belirtti ve yazma işlemleri aynı darboğazdan etkilenir çünkü bir vektör eklemek, rastgele erişimli geçiş ve birkaç grafik katmanının değiştirilmesini gerektirir. HNSW’nin küresel yeniden dengelemesi olmadığı için, arama kalitesini geri kazanmak tam bir REINDEX çalıştırmayı gerektirir; bu işlem tabloyu kilitler ve üretim yazmalarını durdurur.

Üçüncü sorun, tek bir sorgunun paralelleştirilememesidir. Bir pgvector sorgusu tek bir Postgres arka uç süreci tarafından yürütülür, bu da HNSW indeks taramasının hiçbir paralelleştirme olmadan kalmasına neden olur. Hatırlamayı artırmak daha fazla grafik düğümünü ziyaret etmeyi gerektirir; bu da rastgele bellek okumaları ve mesafe karşılaştırmaları ekleyerek gecikmeyi artırır ve saniyedeki sorgu sayısını azaltır, bu yüzden verimliliği ölçeklendirmek veritabanı bağlantılarını veya okuma kopyalarını eklemeyi gerektirir.

Lakebase_vector Nasıl Oluşturulur

Lakebase Postgres, depolamayı işlemden ayırır: kalıcı veriler düşük maliyetli bulut nesne depolama alanında bulunurken, RAM ve yerel NVMe, aktif çalışma kümesini tutan kısa ömürlü önbellekler olarak hizmet verir. Bu temelin üzerine Databricks iki tekniği birleştirdi.

Hiyerarşik IVF kümeleme, vektörleri bitişik bloklar halinde depolanan kümelere gruplar. Bir sorgu, küme merkezlerini bellekte puanlar, ardından yalnızca umut vaat eden birkaç bloğu büyük sıralı okumalar şeklinde okur; çok sayıda rastgele atlama yerine. RaBitQ yöntemiyle ikili kantitleme, her vektörü yaklaşık bir bit/dimension seviyesine sıkıştırır; bu, float32’den yaklaşık 32 kat daha küçüktür, böylece sorgular adayları kısa listeye almak için kompakt kodları tarar ve sadece bu kısa listeyi tam hassasiyetli vektörlerle yeniden sıralar.

Tasarım durum bilgisiz olduğu için sıfıra ölçeklenebilir ve kullanılmadığında kullanıcılar yalnızca depolama için ödeme yapar. Databricks, 100 milyon vektör, 768 boyutlu bir veri kümesinde ölçek-sıfır sonrası ilk sorgu için ölçülen P90’un 1,13 saniye olduğunu raporladı ve 100 milyon vektörün tek bir Lakebase Compute Unit üzerinde hizmet verilebileceğini söyledi.

İndeks oluşturma, küme merkezlerini tek seferde küçük bir rastgele örnek üzerinde eğitir; ardından her vektör en yakın merkezine atanır, nicelleştirilir ve bağımsız bir işlem olarak uygun bloğa yazılır, böylece iş mevcut çekirdek sayısına göre yayılır. Databricks, LTAP mimarisinin indeks oluşturma işlemlerini birincil veritabanından Spark gibi dağıtık motorlara taşıdığını, böylece oluşturma süresini dakikalara indirdiğini ve bu yetenek üzerine daha fazlasının geleceğini söyledi. Koşullar blok taraması sırasında uygulandığı için, filtreli sorgular adayların aşırı çekilmesini önler ve geri çağırma oranını yüksek tutar; ayrıca tek bir sorgu CPU çekirdekleri arasında paralel çalışır.

BM25 Metin Araması ve Hibrit Sorgular

Databricks, standart Postgres tsvector aramasının bütün veri kümesi çapında bağlam eksikliği olduğunu belirtti. lakebase_text, terimleri küresel ters belge frekansı kullanarak puanlar; nadir ve yüksek niyetli terimlere daha fazla, yaygın dolgu kelimelerine ise daha az ağırlık verir. Ayrıca indeks içinde ilerlerken puan üst sınırlarını kontrol eder ve top‑K sonucunu etkileyemeyecek bütün gönderi bloklarını atar; bu, şirketin tsvector ve GIN indekslerine göre daha hızlı olduğunu söylediği anlamına gelir.

İki uzantının birleştirilmesi, Postgres içinde yerel hibrit aramayı etkinleştirir: tek bir sorgu sıradan SQL filtre koşullarını uygulayabilir, canlı operasyonel tabloları birleştirebilir ve anlamsal vektör puanlamasını BM25 anahtar kelime alakalılığıyla birleştirebilir. Databricks, sistemin bir satırdan bir milyar vektöre ve saniyede bir sorgudan binlerce sorguya manuel yeniden tahsis gerektirmeden ölçeklendiğini ve tasarımın, iş akışları birkaç saniye içinde binlerce eşzamanlı getirme isteği tetikleyebilen AI ajanları için tasarlandığını belirtti.

Databricks, operasyonel ve arama verilerini tek bir veritabanında birleştirmek isteyen kullanıcılar için Lakebase Search’i konumlandırırken, Databricks AI Search, kutudan çıkar çıkmaz çalışan yönetilen getirme motoru olarak kalmaktadır. Lakebase Search, AWS ve Azure üzerinde genel olarak kullanılabilir; mevcut Lakebase kullanıcıları uzantıları etkinleştirebilir ve yeni kullanıcılar Lakebase’e kaydolabilir.