Elasticsearch Senkronizasyonu Nasıl Yapılır? Gerçek Hayatta İşe Yaray­an Yaklaşımlar

Elasticsearch senkronizasyonu, Elasticsearch kullanan hemen herkesin bir noktada karşısına çıkan ama genelde “sonra bakarız” denilen bir konudur. Sen de fark etmişsindir; ilk başta her şey yolunda gider ama veri büyüdükçe, güncellemeler arttıkça işler yavaş yavaş karışmaya başlar.

Bu yazıda, Elasticsearch’i ana veritabanı ile nasıl senkron tutabileceğini, gerçek hayatta işe yarayan yaklaşımlarla, kafa karıştırmadan anlatmaya çalışacağım.

Gelin birlikte bakalım.

Elasticsearch Neden Senkronizasyon Sorunu Yaratır?

Önce temel bir yanlış anlaşılmayı netleştirelim:

Elasticsearch bir primary database değildir.

Yani:

• Verinin asıl kaynağı genellikle PostgreSQL, MySQL gibi bir veritabanıdır

• Elasticsearch ise bu verinin arama ve analiz için kopyasını tutar

Sorun da tam burada başlar. Çünkü Elasticsearch’te bir veriyi “update etmek”, sandığımız kadar basit değildir.

Elasticsearch’te Güncelleme (Update) Neden Pahalı?

Elasticsearch, Lucene üzerine kuruludur ve Lucene’in önemli bir özelliği vardır:
Segment’ler immutable’dır, yani değiştirilemez.

Bunu günlük hayattan bir örnekle düşünelim:

Bir kitap bastırdığını düşün. Kitaptaki tek bir kelimeyi değiştirmek için, aslında kitabın ilgili sayfasını silip, yeni bir sayfa basman gerekiyor.

Elasticsearch’te de durum benzer:

• Eski doküman “silindi” olarak işaretlenir

• Yeni doküman baştan indexlenir

• Analyzer’lar yeniden çalışır

Sonuç?

• Daha fazla CPU kullanımı

• Daha fazla disk I/O

• Performans problemleri

Bu yüzden sık ve küçük güncellemeler, Elasticsearch için oldukça maliyetlidir.

Kaynak:
https://www.elastic.co/blog/found-keeping-elasticsearch-in-sync

Bulk API: Elasticsearch Senkronizasyonunun Temeli

Burada ilk altın kural şudur:

Elasticsearch’e tek tek yazma, batch yaz.

Elasticsearch’in Bulk API’si tam da bu iş için vardır:

• Network maliyetini azaltır

• Segment churn’ü düşürür

• Çok daha stabil bir performans sağlar

Ama sadece Bulk API kullanmak yetmez. Asıl mesele, hangi veriyi ne zaman indexlediğindir.

Yaklaşım 1: Queue Tabanlı Elasticsearch Senkronizasyonu

En yaygın kullanılan yöntemlerden biri queue (kuyruk) tabanlı senkronizasyondur.

Queue Tabanlı Yaklaşım Nasıl Çalışır?

Basitçe anlatayım:

1. Veritabanında bir kayıt değişir

2. Bu kayıt için bir queue entry oluşturulur (id, index adı gibi)

3. Aynı kayıt kısa sürede tekrar değişirse:

   • Yeni bir queue kaydı oluşturulmaz (deduplication)

4. Worker’lar belirli aralıklarla:

   • Queue’dan örneğin 1000 kayıt alır

   • Veriyi veritabanından okur

   • Bulk API ile Elasticsearch’e yazar

Neden Bu Yöntem Seviliyor?

• Elasticsearch yükü ana uygulamadan ayrılır

• Ana akış yavaşlamaz

• Worker sayısıyla yazma hızı kontrol edilir

• Elasticsearch geçici olarak çökse bile sistem çalışmaya devam eder

Özellikle sık update olan domain’ler için oldukça güvenli bir yaklaşımdır.

Ama Bir Sorun Var…

Queue’lar full reindex için hiç iyi değildir.
Milyonlarca kaydı tek tek queue’ya koymak hem pahalı hem karmaşıktır.

Yaklaşım 2: Zaman Aralığı (Range) Bazlı Batch Senkronizasyon

Eğer verin:

• Immutable ise

• Append-only bir yapıdaysa

• Log, event, audit gibi sistemlerden geliyorsa

Queue kullanmadan çok daha sade bir çözüm mümkün.

Range Bazlı Elasticsearch Senkronizasyonu Nasıl Çalışır?

Mantık oldukça basit:

• Worker her X saniyede bir çalışır

• Son çalıştığı zamanı bilir (last_run_time)

• Yeni aralığı hesaplar:

  • last_run_time → now() - 1 saniye

• Bu aralıkta henüz indexlenmemiş verileri alır

• Bulk API ile Elasticsearch’e yazar

• last_run_time güncellenir

“Neden 1 Saniye Geriye Gidiyoruz?”

Çünkü:

• Elasticsearch veriyi varsayılan olarak ~1 saniyede searchable yapar

• Yavaş transaction’ların tamamlanması için küçük bir buffer gerekir

Bu küçük gecikme, veri kaçırma riskini ciddi şekilde azaltır.

Time-Based Index Kullanımı: Küçük Bir Detay, Büyük Kazanç

Range bazlı senkronizasyon yapıyorsan, time-based index kullanmamak büyük fırsat kaybıdır.

Örneğin:

• logs-2025-01

• logs-2025-02

Bu yaklaşım sayesinde:

• Sorgular sadece ilgili index’lere gider

• Eski veriler tek komutla silinir

• Arama performansı artar

Bu konuya daha detaylı girdiğim yazı:
Elasticsearch Index Tasarımı: Zaman Bazlı Yaklaşımlar (çok yakında!)

Hata Yönetimi ve Idempotency (En Çok Atlanan Kısım)

Burayı özellikle vurgulamak istiyorum.

Elasticsearch senkronizasyonu her zaman idempotent olmalıdır.

Yani:

• Aynı batch iki kez çalışırsa sistem bozulmamalı

• Queue tabanlı sistemlerde sadece başarılı kayıtlar silinmeli

• Bulk API’nin partial success dönebileceği unutulmamalı

Bu yaklaşım sayesinde:

• Retry mekanizmaları basitleşir

• Karmaşık state yönetimine gerek kalmaz

Sonuç: Hangi Elasticsearch Senkronizasyonu Ne Zaman?

Toparlayalım:

• Sık update, karmaşık domain → Queue tabanlı senkronizasyon

• Immutable / append-only veri → Range bazlı batch senkronizasyon

• Her durumda → Bulk API + idempotent tasarım

Elasticsearch senkronizasyonu doğru kurgulandığında hem performanslı hem de sürdürülebilir bir sistem elde edersin.

Sonuna kadar okuduysan teşekkür ederim
Eğer sen de Elasticsearch senkronizasyonu konusunda farklı bir yaklaşım denediysen ya da kafana takılan bir nokta varsa, yorumlarda konuşalım.
Birlikte öğrenmek her zaman daha keyifli.

Elasticsearch senkronizasyonu konusu sandığından daha önemli — ama doğru yaklaşımla hiç de korkutucu değil. Eğer Javascript’de Promises yapısını merak ediyorsan bu yazıyı da okuyabilirsin!