Bilim
Elasticsearch Veri Tekrarı Nasıl Engellendi?
Yüz milyonlarca belge içeren bir Elasticsearch kümesinde veri güncellendiğinde gereksiz tekrar indeksleme işlemleri çok yüksek kaynak tüketimine neden oluyordu.
Hexcore
3 dk
25 Haziran 2026
Büyük ölçekli veri yönetimi yapan platformlar için verilerin zamanla güncellenmesi kaçınılmaz bir süreçtir. Özellikle yüz milyonlarca belge barındıran tek bir büyük küme (cluster) üzerinde çalışan sistemlerde, bu güncelleme süreçleri beklenenden çok daha fazla kaynak tüketebilmektedir. Bizim karşılaştığımız temel sorun da buydu: Kaynak verilerimizde meydana gelen küçük değişiklikler bile, Elasticsearch içinde gereksiz ve zorunlu olmayan yeniden indekslemelere neden oluyordu.
Problem, veri kaynağımız ile indekste kullandığımız alanlar arasındaki uyumsuzluktan kaynaklanıyordu. Örneğin, bir kaydın 50 farklı alanı olabilir ancak bu alandan yalnızca 10 tanesi arama için kritik ve Elasticsearch'a yansıtılıyordur. Geriye kalan 40 alan değiştiği anda bile sisteme gelen güncelleme sinyali, ilgili belgenin tamamının yeniden indekslenmesini tetikliyordu. Oysa dışarıdan bakıldığında veya içerikteki arama motoru metninde hiçbir fark kalmamıştı. Bu durum milyonlarca doküman için gün içinde çok yüksek sayıda ve tamamen gereksiz işlem oluşturuyor, kümemizin yükünü gereksiz yere artırıyor.
Güncelleme olaylarını bildiren sistemler (örneğin Couchbase gibi veritabanları) hangi spesifik alanların değiştiği bilgisini vermediği için biz de zorunlu olarak her gelen sinyali tam bir yeniden indeksleme fırsatı olarak elemek zorunda kalıyorduk. Bu sürekli ve fazlalık içeren döngü, işlem gücümüzün boş yere harcanmasına, indeksi takip eden gecikme metriklerinde (index lag) gereksiz yükselmelere neden oluyordu.
Bu boşa giden kaynakları önlemek için Redis ve XXHash isimli güçlü araçları kullanarak akıllı bir ön kontrol mekanizması geliştirdik. Amaç, gelen güncellemenin gerçekten Elasticsearch indeksi ile ilgili alanları değiştirdiğini mi yoksa sadece gereksiz yan verileri mi güncellediğini anlık olarak tespit etmekti.
Yeni bir belge indekslenmeden hemen önce, yalnızca Elasticsearch içinde tanımlı olan ve aranabilir alıntıların kritik alt kümesini çıkarıyoruz. Ardından bu alt kümedeki verileri belirli kurallara göre düzenleyip (canonical JSON formatında seri hale getirerek) XXHash algoritması ile eşsiz bir parmak izi oluşturuyoruz. Bu yöntem, çok hızlı sonuç vermesi ve çarpışma olasılığının düşük olması sayesinde yüksek hacimli işlemler için idealdir.
Bu parmak izini (hash) hafızada saklamak için Redisi bir depolama katmanı olarak kullanıyoruz. Bellekte tutulan anahtar (key), belge kimliği, değeri ise hesaplanan XXHash değeridir. Bir güncelleme sinyali geldiğinde indeksleme servisi yeni veriler üzerinden taze bir hash üretir ve bu hash'i Redis üzerindeki eski hash ile karşılaştırır. Eğer iki hash eşleşiyorsa, Elasticsearch içinde yeniden indekslemeye gerek yoktur; ilgili işlem güvenle atlanır.
Yeni bir güncelleme tespit edildiğinde ise indeksleme servisi normal prosedürü işletmeye devam eder ve işlemin tamamlanmasının ardından yeni hash değerini Redis'e kalıcı olarak kaydeder. Bu anlık kontrol mekanizması, Redisin milisaniyelik hızı sayesinde saniyeler içinde karar verebiliyor.
Mimarimizdeki önemli bir kararlardan biri sistemin hata toleransını sağlamaktı. Eğer Redis anlık olarak erişilemez duruma gelirse (mesela sunucu çökerse), biz her zaman 'güvenli' tarafta kalmayı seçtik: yani gereksiz olsa bile indeksi güncellemek. Bu, kritik bir güncel veriyi kaybetme riskini ortadan kaldırır; çünkü Redis sadece hızlı bir doğrulama katmanıdır ve nihai veri kaynağı hala doğrudur.
Mali ve operasyonel açıdan bu çözüm devrim niteliğindedir. Boşa giden yeniden indeksleme işlemlerinin yüzdesini büyük ölçüde azaltarak Elasticsearch üzerindeki işlemci yükünü (CPU) yarı yarıya düşürdük. Gereksiz süreçler ortadan kalkınca indekse yeni verilerin girme hızı arttı ve sistem daha az segment oluşturdu, bu da arama hızının düştüğü noktaların aksine performansın yükselmesini sağladı.
Bazıları 'böyle bir kontrol işi performansı düşürmez mi?' diye sorabilir. Yanıtımız açık: Tam tersi. Gereksiz indeksleme döngülerini kesmek, tüm transformasyon süreçleri ve ağ trafiği maliyetini sıfırladığı için büyük ölçekli sistemlerde darboğazları aşmanın en etkili yoludur.
Topluluk yargısını şekillendirmek için fikrini tek bir sinyalle belirt.
Henüz yorum yapılmamış. İlk yorumu sen yap!
E-posta adresiniz yayımlanmayacaktır. Gerekli alanlar (*) ile işaretlenmiştir.