PlanetScale'ın Postgres için TIN tam metin arama extension'ı büyük benchmark iddialarıyla GA oldu

TIN nedir

PlanetScale, PostgreSQL için tam metin arama extension'ı olan TIN'ın genel kullanıma açıldığını duyurdu. Şirkete göre tam metin arama, müşterilerinin en çok talep ettiği özellik ve TIN — "Text INdex"ın kısaltması — bunun cevabı. PlanetScale tarafından barındırılan tüm Postgres ve Neki veritabanları için hemen kullanılabilir durumda.

Extension sıradan SQL'e entegre oluyor. Index CREATE INDEX ... ON tablo_adi USING tin(metin_kolon_adi) ile oluşturuluyor ve sorgular yeni ==> operatörünü kullanıyor. PlanetScale'ın örnekleri arasında tin.score(ctid) ile sıralanmış ilk on ürünü döndüren bir e-ticaret araması, sıralama yapmadan eşleşen her belgeyi döndürmesi gereken bir hukuki keşif sorgusu ve fotoğraf etiketleri üzerinde tam bir COUNT(*) yer alıyor.

PlanetScale'a göre ciddi bir metin indexi Boolean, ifade (phrase) ve span sorgularını; terimlerde fuzzy, wildcard ve regular-expression eşleştirmesini; büyük/küçük harf ve aksan katlamasını; hem COUNT(*) hem de BM25 puanlı top-k sorgularını desteklemeli — tüm bunları join'ler, metin ve metin olmayan koşulların karıştığı WHERE cümlecikleri, sürekli güncellemeler, replikasyon, yedekler ve transaction görünürlüğü ile başa çıkarken yapmalı. Şirkete göre Postgres için en az üç metin arama indexi zaten mevcut, ancak hiçbiri tüm gereksinimleri karşılamıyordu.

PlanetScale nasıl benchmarkladı

Performans iddialarını desteklemek için PlanetScale, TIN v1.0.2'yi ParadeDB v0.25.2, pg_textsearch v1.4.0 ve Postgres 18.6'da yerleşik GIN indexi ile test etti. Ana corpus, Stack Exchange gönderilerinin 85 GB'lık bir dışa aktarımıydı — 150 milyon belge — ve 2 ile 15 terimden oluşan alt dizgiler örneklenerek ve her biri conjunction, disjunction veya ifade olarak yorumlanarak oluşturulmuş 1.719 sentetik sorgu ile sorgulandı. Her şey, yerel NVMe depolamalı ve AVX-512 destekli CPU'lu bir AWS i7i.8xlarge instance'ında çalıştı; her motor 8 vCPU ve 32 GB RAM ile sınırlandırılmış bir container içindeydi — PlanetScale'a göre bilinçli olarak küçük, böylece index Postgres buffer'larında durmuyor. Yük, okunan ve yazılan baytları önden ısıtıp takip eden çatallanmış bir ParadeDB Benchmarker'dan geldi. Şirket ayrıca Wikipedia'nın tamamına, 2,3 TB Reddit yorumuna ve araştırma makaleleri, hukuki belgeler, kitaplar ve Enron e-postalarından oluşan 797 GB'lık karma bir corpus'a karşı da test etti.

PlanetScale'ın bildirdiği rakamlar

Stack Exchange corpusu üzerinde index oluşturmada TIN 8 dakika 10 saniyede tamamlandı ve 32 GB bellek sınırı içinde 50,7 GB'lık bir index üretti. ParadeDB 52,1 GB'lık index için 19 dakika 20 saniye aldı ama 64 GB gerektirdi; pg_textsearch 41,5 GB için 26 dakika 49 saniye aldı ve 128 GB gerektirdi; yerleşik GIN 28 GB'lık bir index için 2 saat 9 dakika aldı ve o da 64 GB gerektirdi.

BM25 puanına göre ilk 10 sonucu döndüren karışık conjunction, disjunction ve ifade sorgularında TIN, ParadeDB'nin saniyede işlediği sorgunun 25 katını işledi ve p99 gecikmesi 26 kat daha düşüktü. GIN iş yükünü tamamlayamadı — disjunction sorgularında belleği tüketti — ve pg_textsearch yalnızca disjunction desteklediği için tamamlayamadı. Sıralı conjunction ve ifade sorgularında TIN, ParadeDB'nin 10 katı ve GIN'in 541 katı verimlilik gösterdi; p99 gecikmeleri sırasıyla 6 kat ve 1.356 kat daha düşüktü. TIN dışında yalnızca ParadeDB her benchmarkı tamamladı. PlanetScale ayrıca indexin shared buffer'larda tamamen yerleşik olduğu 8,0 GB'lık Wikipedia corpusu üzerinde bir sayım iş yükü de ölçtü.

Aynı anda okuma ve yazma

Eşzamanlı yazma benchmarkında, bir istemci saniyede 1.000 UPDATE ifadesini hedeflerken top-10 BM25 sonuçlu disjunction sorguları çalıştırıldı. TIN, ParadeDB'nin 57 katı ve pg_textsearch'ün 36 katı sorgu verimliliğini sürdürdü; p99 gecikmeleri sırasıyla 36 kat ve 24 kat daha düşüktü. On dakikalık bir çalışmada TIN 270.279, ParadeDB 185.584 ve pg_textsearch 735 update tamamladı. PlanetScale bu son çöküşü lock starvation'a bağlıyor: sürekli okuma trafiği yazmaların ihtiyaç duydukları kilitleri edinmesini engelledi, bu yüzden yazmalar saniyeler içinde durdu. Şirkete göre ParadeDB'ın yazma kabul etme yaklaşımı, ona okuma verimliliği ve gecikme açısından maliyet getiriyor.

Neden önemli

PlanetScale'ın çerçevesi şöyle: müşterileri bu özelliği en çok bunun için talep ediyor, çünkü Postgres'in mevcut seçenekleri yetersiz kalıyor ve benchmarklar bunun ne kadar yetersiz olduğunu göstermeyi amaçlıyor: yerleşik GIN yolu iş yüklerinin ikisini bile tamamlayamadı. Rakamlar PlanetScale'ın laboratuvarı dışında da tutarsa, transactional arama — bir satır commit edilir edilmez görünen sonuçlar, veritabanıyla birlikte yedeklenen, senkron tutulacak harici bir pipeline gerektirmeyen bir yapı — mütevazı donanımda pratik hale geliyor, çünkü bu sonuçlar büyük bir makineden değil 8 vCPU'luk, 32 GB'lık bir container'dan geliyor.

Göz önünde bulundurulması gereken nokta şu: bunlar satıcı tarafından yürütülmüş benchmarklar; PlanetScale corpus'u seçti, sorguları üretti ve tuning parametrelerini belirledi, ayrıca hiç çalıştıramayan motorlar iş yüklerinin dışında bırakıldı. Şirket yeterince ortam detayı yayınlıyor — instance türü, container limitleri, Postgres ayarları — böylece başkaları da kurulumu yeniden üretebilir ve TIN artık barındırılan Postgres'inde genel kullanıma açık olduğuna göre en hızlı doğrulama, onu gerçek verilerle denemektir.