Elasticsearch'e Postgres Tabanlı Güçlü Rakip: ParadeDB ve pg_search ile Tek Veritabanında Arama Devrimi

Elasticsearch'e Postgres Tabanlı Güçlü Rakip: ParadeDB ve pg_search ile Tek Veritabanında Arama Devrimi

Elasticsearch'e Postgres Tabanlı Güçlü Rakip: ParadeDB ve pg_search ile Tek Veritabanında Arama Devrimi

Modern web uygulamaları geliştirirken karşılaştığımız en büyük zorluklardan biri, kullanıcılara hızlı ve akıllı bir arama (full-text search) deneyimi sunmaktır. Yıllardır bu alandaki altın standart Elasticsearch veya OpenSearch oldu. Ancak bu güçlü araçların beraberinde getirdiği çok büyük bir problem var: Veri Senkronizasyonu ve Altyapı Karmaşıklığı.

Ana veritabanınız olarak PostgreSQL kullanırken, arama özellikleri için yanına bir de Elasticsearch kümesi kurduğunuzda macera başlar. Verileri anlık olarak Elasticsearch'e taşımak için CDC (Change Data Capture) araçları kurmak, Debezium veya Logstash yapılandırmak, ağ gecikmeleriyle boğuşmak ve çift yazma (dual-write) hatalarını yönetmek tam bir kabusa dönüşebilir.

İşte tam bu noktada sahneye ParadeDB ve onun kalbini oluşturan pg_search eklentisi çıkıyor. ParadeDB, PostgreSQL'i harici hiçbir araca ihtiyaç duymadan, doğrudan yüksek performanslı bir arama motoruna dönüştürüyor.


Elasticsearch Çilesine Son: Neden ParadeDB?

Geleneksel mimaride, arama yapmak için veriyi başka bir yere taşımak zorundaydık. ParadeDB ise felsefe olarak "Veriyi arama motoruna taşımak yerine, arama motorunu verinin olduğu yere (Postgres) getir" yaklaşımını benimsiyor.

İşte ParadeDB ve pg_search eklentisinin çözdüğü temel problemler:

1. Senkronizasyon (Sync) Derdi Yok

Veritabanınıza yeni bir satır eklendiğinde, güncellendiğinde veya silindiğinde, bu değişiklik anında arama indeksine yansır. ACID güvencesiyle, veritabanınızda ne varsa arama sonuçlarında da tam olarak o yer alır. Senkronizasyon gecikmesi (lag) tamamen tarih olur.

2. Düşük Altyapı ve Lisans Maliyeti

Ayrı bir Elasticsearch kümesi (cluster) yönetmek; ekstra sunucu maliyeti, bellek (RAM) tüketimi ve bakım personeli demektir. ParadeDB, mevcut PostgreSQL sunucunuzun kaynaklarını kullanarak bu maliyeti neredeyse sıfıra indirir.

3. Tek Sorgu Dili: Sadece SQL

Elasticsearch'ün karmaşık JSON tabanlı Query DSL dilini öğrenmek ve bakımını yapmak zordur. ParadeDB ile arama sorgularınızı bildiğiniz ve sevdiğiniz standart SQL ile yazarsınız. JOIN işlemleri, aggregations (gruplamalar) ve filtrelemeler doğrudan SQL içinde çalışır.


pg_search Arkasındaki Güç: Tantivy ve Rust

PostgreSQL'in kendi içinde zaten tsvector ve tsquery ile temel bir arama desteği (GIN indeksleri ile) sunduğunu biliyoruz. Peki pg_search'ü bundan ayıran ne?

pg_search, Rust diliyle yazılmış, Lucene'in en güçlü alternatifi olarak kabul edilen Tantivy arama motoru kütüphanesini temel alır. Tantivy, inanılmaz derecede hızlıdır ve bellek tüketimi konusunda son derece cimridir.

pg_search eklentisi sayesinde PostgreSQL; * BM25 Skorlama Algoritması (Elasticsearch'ün kullandığı modern alaka düzeyi skorlaması), * Fuzzy Search (Yazım hatası toleranslı arama), * Stemming ve Tokenization (Kelime köklerini bulma ve parçalama), * Faceting (Kategori bazlı filtreleme ve sayma)

gibi gelişmiş arama motoru özelliklerine doğrudan yerleşik olarak sahip olur.


Pratik Uygulama: pg_search Nasıl Kullanılır?

Gelin, pg_search eklentisinin nasıl çalıştığına basit bir örnekle göz atalım.

1. Eklentiyi Aktif Etme ve Tablo Oluşturma

Öncelikle eklentimizi aktifleştiriyoruz ve örnek bir ürünler tablosu oluşturuyoruz:

-- Eklentiyi aktif et
CREATE EXTENSION IF NOT EXISTS pg_search;

-- Örnek tablo oluştur
CREATE TABLE urunler (
    id SERIAL PRIMARY KEY,
    baslik VARCHAR(255),
    aciklama TEXT,
    kategori VARCHAR(100),
    fiyat NUMERIC
);

-- Örnek veriler ekle
INSERT INTO urunler (baslik, aciklama, kategori, fiyat) VALUES
('Apple iPhone 15 Pro', '128 GB Titanyum akıllı telefon, harika kamera.', 'Elektronik', 65000),
('Apple MacBook Pro M3', '16 GB RAM, 512 GB SSD taşınabilir bilgisayar.', 'Elektronik', 85000),
('Deri Ceket', 'Hakiki kuzu derisi, siyah renkli şık ceket.', 'Giyim', 4500);

2. Arama İndeksi (BM25) Oluşturma

Sıra geldi arama motorunun gücünü kullanmaya. urunler tablosundaki baslik ve aciklama alanlarında arama yapabilmek için bir pg_search indeksi oluşturuyoruz:

CALL paradedb.create_bm25(
    index_name => 'urun_arama_indeksi',
    schema_name => 'public',
    table_name => 'urunler',
    key_field => 'id',
    fields => '{
        "baslik": {"tokenizer": {"type": "en_stem"}},
        "aciklama": {"tokenizer": {"type": "en_stem"}}
    }'
);

3. Arama Sorgusu Çalıştırma

Artık arama yapabiliriz! Örneğin, içinde "phone" geçen veya yazım hatasıyla "iphne" yazılan ürünleri arayalım:

SELECT id, baslik, aciklama, paradedb.score(id) AS skor
FROM urunler
WHERE id = ANY(
    SELECT id FROM paradedb.search(
        index_name => 'urun_arama_indeksi',
        query => 'baslik:iphne~1 OR aciklama:phone'
    )
)
ORDER BY skor DESC;

Buradaki ~1 ifadesi, 1 harfe kadar yazım hatasına (Levenshtein distance) izin verdiğimizi belirtir. Sonuçlar, alaka düzeyine (BM25 skoruna) göre sıralanmış olarak anında dönecektir.


Karşılaştırma: Elasticsearch vs. ParadeDB (pg_search)

Özellik Elasticsearch / OpenSearch ParadeDB (pg_search)
Mimari Ayrı bir servis/küme gerekir PostgreSQL eklentisidir
Veri Senkronizasyonu CDC, Logstash veya uygulama katmanı gerekir Gerekmez (Gerçek zamanlı)
Sorgu Dili Karmaşık JSON Query DSL Standart SQL
Kaynak Tüketimi Yüksek (JVM, RAM canavarı) Düşük (Rust tabanlı Tantivy hızı)
Vektör Arama (AI) Var Var (pgvector ile entegre)
İşlemsel Tutarlılık Esnek (Eventual Consistency) Tam ACID Uyumluluğu

Hibrid Arama (Hybrid Search) ve Yapay Zeka Desteği

Modern arama motorları sadece anahtar kelime araması (BM25) yapmıyor; aynı zamanda anlamsal (semantic) arama da yapıyor. ParadeDB, PostgreSQL ekosisteminin gücünden yararlanarak pgvector eklentisiyle kusursuz bir şekilde entegre olur.

Böylece tek bir SQL sorgusu ile hem klasik metin aramasını (BM25) hem de vektör aramasını (Semantic Search) birleştirerek Hibrid Arama gerçekleştirebilirsiniz. Bu, kullanıcılara arama çubuğunda "akıllı arama" deneyimi sunmanın en modern ve efektif yoludur.


Sonuç: ParadeDB'yi Ne Zaman Tercih Etmelisiniz?

Eğer: * Hali hazırda ana veritabanı olarak PostgreSQL kullanıyorsanız, * Küçük veya orta ölçekli bir ekipseniz ve Elasticsearch'ün bakım/maliyet yükünden kaçınmak istiyorsanız, * Verilerinizin anlık olarak aranabilir olmasını istiyorsanız (gerçek zamanlı arama), * Arama sorgularını yazarken SQL'in gücünden ve esnekliğinden vazgeçmek istemiyorsanız,

ParadeDB ve pg_search sizin için biçilmiş kaftandır.

Elbette petabaytlarca veriyi analiz eden, devasa log analitiği yapan ve yüzlerce düğümden (node) oluşan bir sistem yönetiyorsanız Elasticsearch hala güçlü bir seçenektir. Ancak modern web uygulamalarının %95'i için ParadeDB, karmaşıklığı öldüren ve performansı zirveye çıkaran devrimsel bir alternatiftir.

Siz de projelerinizde veritabanı karmaşıklığını azaltmak ve arama performansını artırmak istiyorsanız, ParadeDB'ye mutlaka bir şans verin!