ParadeDB, PlanetScale'ın TIN'ine Postgres tam metin arama hızlandırımlarıyla yanıt verdi

ParadeDB, iki hafta önce büyük performans kazanımlarını gösteren benchmark'larla ParadeDB'nin kendi arama işlevselliğine göre yayınlamış olan, Postgres için bir tam metin arama extension'ı olan PlanetScale'ın TIN'ine ayrıntılı teknik bir yanıt yayınladı. Ming Ying imzalı ParadeDB blog yazısına göre TIN, PlanetScale'ın çalıştırdığı her benchmark'ta ParadeDB 0.25'ten en az sekiz kat daha hızlı ölçülmüştü. İki haftalık profil çıkarma ve optimizasyonun ardından ParadeDB, BM25 sıralamalı Top K sorguları için bu açığı kapattığını — ve bunu kapatma biçiminin, TIN'in neden daha hızlı olduğuna dair PlanetScale'ın açıklamasını da temelsiz bıraktığını söylüyor.

Belge tanımlayıcıları üzerindeki anlaşmazlık

ParadeDB'nin index'i, belgeleri ekleme sırasına göre atanan kompakt ardışık sayılarla tanımlayan Tantivy adlı arama kütüphanesi tarafından destekleniyor. Postgres ise satırları, bir satırın veritabanının blok tabanlı depolamasındaki fiziksel konumunu işaret eden ctid değerleri üzerinden bulur. ParadeDB iki sistemi köprülediği için, Tantivy belge ID'leri ile Postgres ctid'leri arasında bir eşleme tutmak zorundadır.

PlanetScale'ın lansman yazısı, TIN'in avantajının büyük kısmını bu eşlemeyi ortadan kaldırmaya bağlamıştı: index'ini doğrudan ctid'ler üzerinden anahtarlayan TIN, çeviri adımını atlıyor ve verimli bitmap işlemleri ile görünürlük kontrolleri çalıştırabiliyor. ParadeDB, mantığın COUNT sorguları için geçerli olduğunu kabul ediyor; bu sorgularda milyonlarca eşleşmenin her biri görünürlük kontrolü gerektiriyor ve çeviri maliyeti birikiyor. Ancak BM25 Top K sorguları için ParadeDB şüpheciydi, çünkü motoru ctid aramalarını zaten nihai sonuçlar bir araya gelene kadar geciktiriyor — ilk 10 sorgusu yalnızca on arama gerektiriyor ve bu, mertebeler farkındaki bir açığı açıklamak için profilde fazlasıyla küçük kalıyor.

Fieldnorm yerelliğinin düzeltilmesi

İlk optimizasyon, ParadeDB'nin fieldnorm'ları — belge uzunluğunu kodlayan ve BM25'in skorları normalize etmesini sağlayan tek baytlık değerleri — nasıl okuduğuna odaklandı. Sayfa erişimlerinin arkasındaki veri yapılarına bağlayan yeni bir ParadeDB özelliği, 28,7 milyonluk belgeye sahip Hacker News veri seti üzerinde tek terimli bir sorguda fieldnorm'ların sayfa okumalarının yüzde 83'ünü oluşturduğunu gösterdi — geri kalan her şey için yaklaşık 300 sayfaya karşılık kabaca 1.500 sayfa.

Sorun yerellikti. Tantivy, fieldnorm'ları belge ID'si ile indekslenen, postings listelerinden ayrı tek bir paylaşılan dizide saklar; bu nedenle bir terimi skorlamak o dizi içinde zıplamak anlamına gelir. Bu düzen Tantivy'nin alışıldık memory-map'li ortamında ucuzdur, ancak Postgres içinde bu, sorgu başına yüzlerce farklı sayfaya dokunmak anlamına geliyordu. ParadeDB'nin çözümü, her postings listesinin yanına aynı sırada bir fieldnorm dizisi saklamak oldu; böylece ikisi de sıralı okunuyor. Fieldnorm sayfa erişimleri yaklaşık 1.500'den 30'a düştü. Bunun bedeli depolamadır: bir belgenin fieldnorm'u artık içerdiği her farklı terim için tekrarlanıyor ve bu, Hacker News index'ini yaklaşık yüzde 9 büyüttü; yine de ParadeDB, gerçek corpus'larda çoğu terimin kısa postings listelerine sahip olduğunu belirtiyor.

Blockmax WAND'da algoritmik bir darboğaz

İkinci düzeltme çok terimli disjunction sorgularını ele aldı. Fieldnorm değişikliğinden sonra bu tür sorgularda buffer okumaları kabaca yüzde 80 düştü, ancak sorgu süreleri yalnızca yaklaşık yüzde 5 azaldı — bu da kalan darboğazın I/O değil, algoritmik olduğunun işaretiydi. Profil çıkarma, sürenin çoğunu Blockmax WAND döngüsünde, yani arama motorlarının sıralı sorguları işlerken postings parçalarını atlamak için kullandığı standart teknikte konumlandırdı. Top K optimizasyonlarına odaklanan yazı, COUNT iyileştirmelerini ikinci bir bölümde söz veriyor.

Karşılaştırma nasıl yapıldı

ParadeDB, öncesi-sonrası benchmark'ını PlanetScale'ın testleriyle aynı 150 milyonluk belgeye sahip StackExchange veri seti, harness ve makine tipleri üzerinde yeniden çalıştırdı; ancak TIN açık kaynak değil ve PlanetScale'ın platformunda çalıştı. ParadeDB ayrıca, özgün karşılaştırmadaki bazı benchmark yapılandırma ayarlarının tamamen adil olmadığını, ayrıntıların bir takip yazısında verileceğini söylüyor. Yazı, PlanetScale ekibine mühendisliği için kredi veriyor ve PlanetScale'ın tam da bu tür testler için ParadeDB'nin geliştirdiği benchmarker aracını benimsediğini belirtiyor.

Neden önemli

Bu karşılıklı yazışma, Postgres yerlisi arama mühendisliği için canlı bir vaka çalışması. ParadeDB, rakibin mimarisinin temelden üstün olduğunu kabul etmek yerine, sayfa düzeyinde profil çıkarmayı kullanarak mertebeler farkındaki bir açığı iki somut, düzeltilebilir soruna dönüştürdü — ve iki hafta içinde kapattı. Postgres içinde BM25 araması çalıştıran ekipler için bu rekabet, bu tür extension'ların yapabileceklerinin taban çizgisini hızla yükseltiyor. Ayrıca benchmark iddialarının nasıl okunması gerektiğini de gösteriyor: mimari açıklamalar, biri gerçek iş yükünü profile edene kadar geçerliliğini korur ve yapılandırma tercihleri, tasarım kararları kadar sonuçları çarpıtabilir. Son olarak, TIN kapalı kaynaklı ve ParadeDB açık kaynaklı olduğundan, gelecekteki karşılaştırmaların bağımsız doğrulanması, her iki ekibin artık kullandığı benchmarker gibi paylaşılan araçlara bağlı olacak.