Elasticsearch ile Tam Metin Arama Katmanı Kurma Rehberi

Elasticsearch neden ilişkisel veritabanı aramasının yerini alır?

Bir uygulamada arama kutusu genellikle önce veritabanındaki LIKE sorgusuyla başlar. Küçük tablolarda iş görür, ama kullanıcı yazım hatası yaptığında, kelimenin çekimli halini yazdığında ya da birkaç kelimeyi farklı sırada girdiğinde sonuç gelmez. Ayrıca sonuçların hangisinin daha ilgili olduğuna dair bir sıralama mantığı da yoktur. Tam metin arama motorları bu sorunu metni önceden işleyip aranabilir parçalara bölerek çözer.

Elasticsearch, ters indeks (inverted index) yapısını kullanan dağıtık bir arama ve analitik motorudur. Her kelime için hangi dokümanlarda geçtiğini tutar, böylece arama sırasında tüm kayıtları taramak yerine doğrudan ilgili dokümanlara gider. Veri JSON doküman olarak saklanır, erişim ise HTTP üzerinden REST arayüzüyle yapılır. Bu yüzden hangi programlama dilinden olursa olsun aynı şekilde konuşulabilir.

Bu becerinin hedefi, ürün kataloğu, haber arşivi, yardım merkezi ya da iç doküman havuzu gibi bir içerik kümesi üzerinde kullanıcıya hızlı, toleranslı ve iyi sıralanmış sonuç veren bir arama katmanı kurmaktır. Elasticsearch ana veritabanının yerine geçmez; asıl verinin yanında, aramaya özel bir kopya olarak çalışır.

İndeks, mapping ve doküman: veri nasıl modellenir?

Arama kalitesinin yarısı, veri modelleme aşamasında belirlenir. Elasticsearch'te doküman bir indekse yazılır ve indeksin mapping tanımı her alanın nasıl saklanacağını söyler. Metin alanları analiz edilir ve tam metin aramaya girer. Anahtar kelime alanları ise olduğu gibi saklanır; filtreleme, gruplama ve tam eşleşme için kullanılır. Aynı alanı hem aranabilir metin hem de filtrelenebilir değer olarak kullanmak gerekiyorsa alan ayrı ayrı biçimlerde tanımlanır.

İyi bir mapping için şu soruları sırayla yanıtlamak gerekir: • Kullanıcı hangi alanlarda metin arayacak: başlık, açıklama, etiketler? • Hangi alanlarla daraltacak: kategori, marka, durum, tarih aralığı? • Hangi alanlarla sıralayacak: popülerlik, tarih, fiyat? • Hangi alanlar yalnızca gösterim için taşınıyor ve aramaya hiç girmemeli?

Dinamik mapping'e bırakmak başlangıçta kolaydır, ama alan tipleri yanlış tahmin edildiğinde sonradan değiştirmek zorlaşır. Mevcut bir alanın tipi değiştirilemez; yeni mapping ile yeni bir indeks oluşturup veriyi yeniden yüklemek gerekir. Bu yüzden üretime çıkmadan önce mapping'i açıkça tanımlamak ve indekse bir takma ad (alias) üzerinden erişmek, sonraki geçişleri kesintisiz yapmayı sağlar.

Metin analizi ve Türkçe dil desteği nasıl çalışır?

Bir doküman indekslenirken metin analizörden geçer. Analizör genellikle birkaç aşamadan oluşur: karakter filtreleri, kelimeleri ayıran bir tokenizer ve kelimeleri dönüştüren token filtreleri. Küçük harfe çevirme, gereksiz sık kelimeleri atma (stop word) ve kök bulma bu filtrelerle yapılır. Sorgu zamanında da aynı analiz kullanıcının yazdığı metne uygulanır; böylece indeksteki metin ile arama ifadesi aynı biçimde karşılaşır.

Türkçe, eklemeli bir dil olduğu için bu aşama özel dikkat ister. Kullanıcı "kitaplar" yazdığında "kitap" geçen dokümanı da görmek ister. Bunun için Türkçeye uygun kök bulma ve stop word listesi içeren bir analizör tanımlanır. Büyük-küçük harf dönüşümünde noktalı ve noktasız i harfleri ayrı bir tuzaktır: "IŞIK" ile "ışık" ya da "İstanbul" ile "istanbul" aynı kelime sayılmazsa eşleşme kaybolur. Bu nedenle küçük harfe çevirme adımının Türkçe kurallarını bildiğinden emin olunmalıdır.

Analiz sonucunu tahmin etmek yerine, analizörün bir metni hangi parçalara ayırdığını doğrudan sorgulayan analiz arayüzüyle denemek gerekir. Örnek cümleler girip çıkan token'lara bakmak, "neden bu doküman bulunmuyor" sorusunun en hızlı yanıtıdır.

Hangi sorgu türü ne zaman kullanılır?

Elasticsearch sorguları Query DSL adı verilen JSON yapısıyla yazılır. Başlangıçta bilinmesi gereken birkaç yapı vardır: • Match sorgusu: analiz edilmiş metin üzerinde tam metin arama yapar. Arama kutusunun temelidir. • Multi-match sorgusu: aynı ifadeyi birden fazla alanda arar; başlıkta geçen eşleşmeye açıklamadakinden fazla ağırlık vermek için alan başına katsayı verilir. • Term sorgusu: analiz edilmeden, olduğu gibi eşleşme arar; kategori ya da durum gibi anahtar kelime alanlarında kullanılır. • Bool sorgusu: must, should, must_not ve filter bölümlerini birleştirir. Gerçek uygulamalarda arama genellikle bu sorguyla kurulur. • Range sorgusu: tarih ve sayısal aralıkları süzer.

Önemli ayrım, puanlamaya katılan sorgu ile yalnızca eleyen filtre arasındadır. "Ayakkabı" aramasında metin eşleşmesi puanı etkilemeli, ama "stokta var" koşulu yalnızca süzmelidir. Bu tür koşullar bool sorgusunun filter bölümüne konur; hem sonuç değişmez hem de Elasticsearch bu koşulları önbelleğe alabilir.

Yazım hatalarına tolerans için fuzzy eşleşme, yazarken öneri için prefix tabanlı ve completion tabanlı yaklaşımlar, sonuç sayfasındaki kategori sayıları için ise aggregation yapıları kullanılır. Facet'li bir e-ticaret arama sayfasının sol menüsündeki marka ve kategori listeleri bu aggregation'lardan gelir.

İlgililik puanlaması ve sıralama nasıl ayarlanır?

Elasticsearch her eşleşen dokümana bir ilgililik puanı verir. Varsayılan hesaplama, bir kelimenin dokümanda ne kadar sık geçtiğini, koleksiyonda ne kadar nadir olduğunu ve alanın ne kadar kısa olduğunu birlikte hesaba katan BM25 yaklaşımıdır. Başlıkta geçen nadir bir kelime, uzun bir açıklamada geçen yaygın bir kelimeden daha yüksek puan alır. Çoğu içerik için bu varsayılan sonuçlar makul bir başlangıç verir.

İş gereksinimi ise sıralamaya metin dışı sinyaller katmayı ister. Örneğin yeni içeriği öne çıkarmak, satışı yüksek ürünü yukarı almak ya da stoğu bitmiş ürünü aşağı itmek gerekebilir. Bunun için function score ve alan değerine dayalı boost yapıları kullanılır. Burada dikkat edilmesi gereken hata, popülerlik gibi bir sinyali o kadar ağır koymaktır ki metin eşleşmesi anlamsız hale gelir. Kullanıcı bir şey aradığında alakasız ama popüler bir sonuç görüyorsa denge bozulmuştur.

Ayarlama boyunca somut bir yöntem gerekir. Gerçek kullanıcı sorgularından bir örnek liste hazırlanır, her sorgu için beklenen ilk sonuçlar yazılır ve her ayar değişikliğinden sonra bu liste yeniden denenir. Böylece bir sorgunun düzelmesi, başka bir sorguyu sessizce bozmaz. Arama günlüklerinde sonuç dönmeyen sorgular da ayrı bir iyileştirme kaynağıdır: eş anlamlı sözcük listesi (synonym) çoğu zaman bu sorgulardan çıkar.

Veri senkronizasyonu ve üretime çıkış

Elasticsearch ikincil bir kopya olduğu için ana veritabanı ile arasındaki tutarlılık ayrı bir tasarım konusudur. Yaygın yaklaşımlar şunlardır: • Uygulama kodu kayıt kaydedilirken aynı anda indeksi de günceller. Basittir, ama indeks yazımı başarısız olursa indeks ile veritabanı birbirinden ayrışır. • Değişiklikler bir kuyruğa ya da olay akışına yazılır ve ayrı bir tüketici indeksi besler. Hata durumunda yeniden denemek kolaydır. • Periyodik tam yükleme, küçük ve az değişen veri kümeleri için yeterli olabilir; yeni indeks oluşturulur, hazır olunca alias değiştirilir.

Silinen kayıtların indeksten de kalkması sık unutulan bir noktadır; aksi halde kullanıcı artık var olmayan bir içeriğe tıklar. Silme olayını da senkronizasyon akışına açıkça dahil etmek gerekir.

Üretimde ise küme boyutlandırması, shard sayısının veri hacmine göre seçilmesi, replika ile yedeklilik, yavaş sorguların kaydı ve kümenin izlenmesi öne çıkar. Çok fazla küçük shard açmak, tek bir büyük shard kullanmak kadar sorun yaratabilir. Güvenlik tarafında kümenin doğrudan internete açılmaması, kimlik doğrulama ve rol bazlı erişimin açık olması beklenir. Arama gecikmesi ve hata oranı gibi göstergeler panoya alınmadan sistem yayına verilmemelidir.

Sık yapılan hatalar ve Mindset programında bu beceri

Başlangıçta sık görülen hatalar şunlardır: mapping'i hiç tanımlamadan dinamik tahmine güvenmek, Türkçe için analizör ayarlamayı atlamak, filtreleri puanlayan sorguların içine koymak, ana veritabanı yerine Elasticsearch'ü tek gerçek kaynak saymak ve ilgililik ayarını tek bir örnek sorguya bakarak yapmak. Bunların hepsi, küçük bir test sorgu listesi ve açık bir veri akışı şemasıyla önlenebilir.

Mindset kataloğunda bu beceriyi çalışan eğitim, "Full-Text Search ve Arama Motoru Entegrasyonu (Elasticsearch)" başlığını taşıyor. Modül başlıkları arama temelleri ve indeks yapısı, metin analizi ve Türkçe dil desteği, sorgu türleri ve filtreleme, ilgililik puanlama ve sıralama, veri senkronizasyonu ve toplama, son olarak ölçüm, performans ve üretim konularını kapsıyor. Aramayı değil, log verisini analiz etmeyi hedefleyen okurlar için "Elastic Stack (ELK) ile Merkezi Log Analizi" başlıklı eğitim, aynı motoru farklı bir kullanım biçimiyle ele alıyor.