Elasticsearch ve Arama Altyapısı Rehberi [2026]

Elasticsearch ve Arama Altyapısı Rehberi

Kullanicilarin bir platformda gecirdigi surenin buyuk bolumu arama ve filtreleme islemleriyle gecer. E-ticaret sitelerinde urun arama, aggregator platformlarda hizmet filtreleme, SaaS uygulamalarinda icerik kesfetme -- tum bu senaryolarda hizli ve dogru sonuc donduren bir arama altyapisi kullanici deneyiminin temel tasiyicisidir. Elasticsearch, Apache Lucene uzerine insa edilmis dagitik bir arama ve analitik motoru olarak bu alanda en yaygin kullanilan cozumdur.

Bu rehberde Elasticsearch ile profesyonel bir arama altyapisi kurmanin tum boyutlarini -- inverted index yapisindan cluster mimarisine, Turkce dil destegindan relevance tuning stratejilerine kadar -- kapsamli sekilde inceliyoruz. Ayrica OpenSearch, Meilisearch ve Algolia gibi alternatifleri de karsilastirarak projenize en uygun cozumu secmenize yardimci oluyoruz.

Inverted Index: Aramanin Temel Yapisi

Geleneksel veritabanlari satirlari sirali olarak tarar. Ancak milyonlarca dokumanda tam metin arama yapmak icin bu yaklasim yetersiz kalir. Elasticsearch'un temelinde bulunan inverted index yapisi, her kelimeyi iceren dokumanlarin listesini tutar. Bu sayede bir arama terimi geldiginde, o terimi iceren tum dokumanlar aninda bulunabilir.

Inverted Index Nasil Calisir

Ornegin uc dokumaniniz olsun: "hizli kargo ile teslimat", "ucretsiz kargo kampanyasi", "hizli teslimat garantisi". Inverted index su sekilde olusur: "hizli" -> [dok1, dok3], "kargo" -> [dok1, dok2], "teslimat" -> [dok1, dok3], "ucretsiz" -> [dok2], "kampanyasi" -> [dok2], "garantisi" -> [dok3]. Kullanici "hizli kargo" arattiginda, her iki terimin kesisimi olan dok1 en yuksek skor ile doner.

Bu yapi, Lucene'in segment bazli mimarisiyle birlesirek hem yazma hem okuma islemlerinde yuksek performans saglar. Her yeni belge eklendiginde kuculuk bir segment olusturulur ve arka planda segmentler birlestirilir (merge).

Cluster Mimarisi ve Temel Kavramlar

Elasticsearch dagitik bir sistem olarak tasarlanmistir. Uretim ortaminda tek bir node yeterli degildir; cluster mimarisini anlamak operasyonel basari icin zorunludur.

Node Turleri

Bir Elasticsearch cluster'i farkli rollere sahip node'lardan olusur. Master node, cluster state yonetimini ustlenir ve index olusturma, silme gibi operasyonlari koordine eder. Data node, gercek veriyi barindiran ve arama sorgularini calistiran node'dur. Coordinating node, istemci isteklerini alip ilgili data node'lara yonlendiren ve sonuclari birlestiren katmandir. Ingest node ise veriyi indeksleme oncesinde donusturmek icin pipeline'lar calistirir.

Shard ve Replica Stratejisi

Her index, bir veya birden fazla shard'a bolunur. Primary shard yazma islemlerini alir; replica shard'lar ise hem yedeklilik hem de okuma performansi saglar. Shard sayisi index olusturulurken belirlenir ve sonradan degistirilemez (reindex gerekir). Genel kural olarak tek bir shard'in boyutu 20-50 GB araliginda tutulmalidir.

Replica sayisi ise dinamik olarak ayarlanabilir. Yuksek okuma trafigi olan ortamlarda replica sayisini artirmak, sorgularin paralel olarak daha fazla node uzerinde calismasini saglar.

Index Tasarimi ve Mapping Stratejileri

Elasticsearch'te mapping, iliskisel veritabanlarindaki sema taniminina karsilik gelir. Dogru mapping tasarimi, hem arama kalitesini hem performansi dogrudan etkiler.

Field Turleri

Text alanlari analiz edilir ve full-text search icin inverted index'e eklenir. Keyword alanlari ise analiz edilmeden saklanir ve exact match, aggregation, siralama islemlerinde kullanilir. Bir alani hem aranabilir hem filtrelenebilir yapmak icin multi-field mapping kullanilir: urun adi hem text hem keyword olarak indekslenir.

Numeric, date, geo_point, nested ve object gibi ozel tur alanlar da farkli kullanim senaryolari icin kritik oneme sahiptir. Ozellikle nested type, ic ice objelerde bagimsiz eslestirme yapmak icin gereklidir ancak performans maliyeti yuksektir.

Dynamic Mapping ve Strict Mode

Varsayilan olarak Elasticsearch, yeni alanlari otomatik olarak mapping'e ekler (dynamic mapping). Uretim ortamlarinda bu davranis beklenmeyen alan patlamalarina yol acabilir. Strict mode ile sadece tanimlanmis alanlar kabul edilir ve beklenmedik veri yapisi degisikliklerinin onde gecilmesi saglanir.

Index Template ve Component Template

Birden fazla index icin ortak mapping ve ayarlar tanimlanacaksa index template kullanilir. Component template'ler ise yeniden kullanilabilir mapping parcalaridir; ornegin tarih alanlari, konum alanlari ve meta alanlari icin ayri component template'ler tanimlanarak farkli index template'lerde birlestirilir. Bu yaklasim, buyuk olcekli sistemlerde mapping yonetimini standartlastirir ve tekrar eden tanimlarin onune gecer.

Turkce Dil Destegi: Analyzer ve Tokenizer

Turkce, sondan eklemeli (agglutinative) yapisiyla Ingilizce'den cok farkli bir morfolojiye sahiptir. "Arabalarimizdan" kelimesini "araba" kokunue indirgemek, Turkce arama kalitesi icin zorunludur.

Custom Turkish Analyzer

Elasticsearch'un yerlesik turkish analyzer'i temel duzeyde stemming yapar. Ancak profesyonel bir Turkce arama deneyimi icin ozel analyzer zinciri olusturulmalidir. Bu zincir su bilesenlerden olusur: lowercase filter ile buyuk-kucuk harf normalizasyonu, turkish_stop filter ile gereksiz kelimelerin (ve, ile, bir, bu) cikarilmasi, turkish_stemmer ile kok bulma ve asciifolding filter ile Turkce karakterlerin ASCII karsiliklarina donusturulmesi.

ASCII folding ozellikle onemlidir cunku kullanicilar cogu zaman "cay" yerine "cay", "guzel" yerine "guzel" yazarlar. Her iki yazimi da eslestirmek icin orijinal ve ASCII-folded versiyonlar ayri alanlarda indekslenebilir.

Synonym ve Fuzziness

Kullanicilarin farkli terimlerle ayni seyi aramasi yaygindir: "cep telefonu", "akilli telefon", "mobil telefon". Synonym filter ile bu terimlerin esdeger oldugu tanimlanir. Fuzzy search ise yazim hatalarini tolere eder; "elastiksearch" yazildiginda "elasticsearch" sonuclari donebilir. Fuzziness degeri genellikle AUTO olarak ayarlanir ve kelime uzunluguna gore edit distance belirlenir.

Relevance Tuning: Dogru Sonucu One Cikarmak

Arama sonuclarinin siralanmasi, kullanici memnuniyetini dogrudan belirler. Elasticsearch varsayilan olarak BM25 algoritmasini kullanir.

BM25 Algoritmasinin Temelleri

BM25, bir terimin dokumandaki sikligini (TF), tum dokumanlar arasindaki nadirligi (IDF) ve dokuman uzunlugunu hesaba katar. Kisa bir urun basliginda gecen terim, uzun bir aciklama metninde gecen ayni terimden daha yuksek skor alir.

Field Boosting

Tum alanlar esit oneme sahip degildir. Urun basliginda gecen eslesme, aciklama metnindekinden daha onemlidir. Multi-match sorgularinda field boosting ile bu agirliklar ayarlanir. Ornegin baslik alani 3x, kategori 2x, aciklama 1x agirlikla degerlendirilir.

Function Score ile Ozel Siralama

Saf metin benzerliginin otesinde, is mantigi da siralamaya katilmalidir. Function score sorgulari ile su faktorler eklenebilir: urunun populeritesi (satis adedi, goruntulenme), yenilik tarihi (decay function ile eski iceriklerin skorunun dusurulmesi), kullanici konumuna yakinlik (geo_distance), stok durumu ve kampanya onceligi.

Bu faktorlerin metin skoru ile nasil birlestirilecegi (multiply, sum, replace, min, max) dikkatle ayarlanmalidir. Genellikle multiply modu ile metin relevance'i korunurken is faktorleri carpan olarak uygulanir.

Autocomplete ve Oneri Mekanizmalari

Kullanici henuz yazmaya baslarken onerilerin gosterilmesi, arama deneyiminin en kritik parcasidir. Elasticsearch bu senaryo icin birden fazla yaklasim sunar.

Completion Suggester

FST (Finite State Transducer) veri yapisi kullanan completion suggester, bellekte calisir ve milisaniye altinda sonuc doner. Prefix bazli eslestirme yapar ve ozellikle urun adi, kategori adi gibi tanimli deger kumelerinde etkilidir.

Edge N-gram Tokenizer

Daha esnek bir autocomplete icin edge n-gram tokenizer kullanilir. "Elasticsearch" kelimesi "el", "ela", "elas", "elast" seklinde tokenize edilir. Bu sayede kelimenin basindan itibaren herhangi bir noktada eslestirme yapilabilir. Search analyzer olarak standard kullanilirken, index analyzer olarak edge n-gram kullanilir.

Search-as-You-Type

Elasticsearch 7.x ile gelen search_as_you_type field type'i, edge n-gram ve shingle analizini otomatik olarak yapar. Hem prefix hem infix eslestirmeyi destekler ve autocomplete senaryolari icin en kolay cozumdur.

Faceted Search ve Aggregation

Modern arama arayuzleri sadece sonuc listesi sunmaz; kategorilere, fiyat araliklarina, ozelliklere gore filtreleme panelleri (facet) gosterir. Elasticsearch'un aggregation framework'u bu islevselligin temelini olusturur.

Terms Aggregation

Bir alandaki benzersiz degerleri ve her birinin dokuman sayisini dondurur. Kategori filtreleri, marka listeleri, renk secenekleri gibi facet'ler bu yapiyla olusturulur.

Range Aggregation

Fiyat araliklari, tarih dilimleri gibi sayisal facet'ler icin range aggregation kullanilir. Histogram aggregation ile esit aralikli gruplama da mumkundur.

Nested Aggregation

Birden fazla facet'in birlikte calismasi icin aggregation'lar ic ice yuvalanir. Ornegin once kategoriye, sonra her kategori icinde marka dagilimina bakilabilir. Post-filter ile secili facet'ler sonuc listesini etkilerken diger facet'lerin sayilari guncellenir.

Performans Optimizasyonu

Buyuk olcekli arama altyapilarinda performans, surekli izlenmesi ve iyilestirilmesi gereken bir alandir.

Indexing Performansi

Toplu veri yuklemelerinde bulk API kullanilmalidir. Refresh interval varsayilan 1 saniyedir; toplu indexleme sirasinda gecici olarak devre disi birakilabilir. Replica sayisi da toplu yukleme sirasinda sifira indirilerek yazma performansi arttirilabilir.

Query Performansi

Filter context kullanimina oncelik verilmelidir cunku filter sorguları skor hesaplamaz ve cache'lenebilir. Bool sorgularinda filter clause'u, must clause'undan daha performanslidir. Gereksiz script sorgularindan kacinilmali, mumkun olan her yerde native query DSL tercih edilmelidir.

Cache Stratejisi

Elasticsearch uc katmanli cache kullanir: node query cache (filter sonuclarini cache'ler), shard request cache (aggregation sonuclarini cache'ler) ve fielddata cache (sort ve aggregation icin). Bu cache'lerin boyutlarinin izlenmesi ve gecersiz kilma (invalidation) stratejilerinin belirlenmesi onemlidir.

Olceklendirme Stratejileri

Trafik ve veri buyudukce arama altyapisinin yatay olarak olceklenmesi gerekir.

Yatay Olceklendirme

Yeni data node'lar eklenerek shard'lar otomatik olarak yeniden dagitilir (rebalancing). Hot-warm-cold mimarisi ile sik erisilen veriler hizli disk kullanan hot node'larda, eski veriler daha yavas warm ve cold node'larda tutulur. ILM (Index Lifecycle Management) ile index'ler otomatik olarak fazlar arasinda tasiniir.

Cross-Cluster Search

Birden fazla cluster uzerinde tek bir sorgu calistirmak icin cross-cluster search (CCS) kullanilir. Cografi olarak dagitik sistemlerde veya farkli is birimleri icin ayri cluster'lar isletildiginde bu yaklasim tercih edilir.

Index Rollover ve Zaman Bazli Indeksleme

Log, olay ve zaman serisi verileri icin zaman bazli index stratejisi uygulanir. Index rollover ile belirli bir boyut, dokuman sayisi veya sure esigine ulasildiginda otomatik olarak yeni bir index olusturulur. Index alias'lari bu gecisi uygulamadan seffaf hale getirir; yazma islemi her zaman aktif index'e yonlendirilirken, okuma islemi tum ilgili index'leri kapsar. Bu strateji ozellikle yuksek hacimli veri alan platformlarda indeksleme performansini korur ve eski verilerin temizlenmesini kolaylastirir.

Monitoring ve Operasyonel Yonetim

Elasticsearch cluster'inin saglikli calismasini izlemek icin birden fazla metrik takip edilmelidir.

Temel Metrikler

Cluster health (green, yellow, red) durumu surekli izlenmelidir. JVM heap kullanimi yuzde 75'i gecmemelidir. Search latency (p50, p95, p99) ve indexing rate metrikleri performans bozulmasini erken tespit ettirir. Shard sayisi cluster basina 1000'in altinda tutulmaya calisilmalidir; fazla shard master node uzerinde yuk olusturur.

Araclari

Kibana'nin Stack Monitoring ozelligi, cluster metriklerini gorsel olarak sunar. Elasticsearch Exporter ile Prometheus ve Grafana entegrasyonu saglanabilir. Alerting kurallariyla disk dolulugu, heap basinci, sorgu gecikmesi gibi kosullarda bildirim tetiklenir.

Alternatif Cozumler

Elasticsearch her senaryo icin en uygun cozum olmayabilir. Alternatifler farkli guc ve zaafiyetlere sahiptir.

OpenSearch

AWS tarafindan Elasticsearch 7.10 fork'u olarak gelistirilir. Lisans kisitlamasi olmayan acik kaynak bir secenektir ve Elasticsearch ile buyuk olcude uyumludur. AWS ekosisteminde calisanlar icin dogal bir tercih olabilir.

Meilisearch ve Typesense

Her ikisi de kurulumu ve kullanimi Elasticsearch'a gore cok daha basit olan modern arama motorlaridir. Ozellikle kucuk-orta olcekli projeler, MVP'ler ve hizli prototipleme icin idealdir. Typo-tolerance ve instant search ozellikleri yerlesik olarak gelir.

Algolia

Yonetilen (managed) bir arama hizmeti olarak altyapi yonetimi gerektirmez. Sorgu basina fiyatlandirma modeli vardir. Hizli entegrasyon ve zengin UI bilesenleri sunar, ancak buyuk olcekte maliyet avantaji azalir.

Smart Maple olarak aggregator platformlar ve e-ticaret projeleri icin arama altyapisi tasarlarken, projenin olcegine ve teknik gereksinimlerine gore bu alternatifleri de degerlendiriyoruz.

E-ticaret ve Aggregator Platformlarinda Arama

Arama altyapisi, ozellikle cok sayida kayit iceren platformlarda kullanici deneyiminin belirleyicisidir.

E-ticaret Senaryolari

Urun arama, kategori filtreleme, fiyat araligi facet'leri, stok durumuna gore filtreleme, benzer urun onerileri ve "bunu mu demek istediniz" (did-you-mean) ozellikleri standart beklentilerdir. Ayrica kullanicinin arama gecmisine dayali kisisellestirilmis siralama da rekabet avantaji saglar.

Aggregator Platform Senaryolari

Birden fazla kaynaktan gelen verilerin birlestirilerek aranabilir hale getirilmesi gerekir. Farkli veri semaları normalize edilmeli, coklama (deduplication) uygulanmali ve kaynak bazinda agirliklandirma yapilabilmelidir. Konum bazli arama ve filtreleme de aggregator platformlarda siklikla gereken bir yetenektir.

SaaS Uygulamalarinda Arama

SaaS platformlarinda kullanicilar kendi verilerini arar: musteriler, siparisler, belgeler, destek talepleri. Multi-tenant mimaride her kiracinin verisi izole edilmeli ve arama sonuclari sadece o kiracinin kayitlarini icermelidir. Bu izolasyon, index-per-tenant veya routing-based-filtering yaklasimlariyla saglanabilir. Kucuk kiracilarda routing bazli filtreleme daha verimli iken, buyuk kiracilarda ayri index olusturmak performans ve yonetim acisindan avantajli olabilir.

Sonuc ve En Iyi Pratikler

Etkili bir arama altyapisi kurmak, sadece Elasticsearch cluster'i ayaga kaldirmakla bitmez. Mapping tasarimi, analyzer secimi, relevance tuning ve operasyonel izleme bir butun olarak ele alinmalidir. Turkce icerik icin ozel analyzer zincirleri olusturmak, kullanici davranisini A/B testlerle olcmek ve arama metriklerini surekli izlemek basarili bir arama deneyiminin anahtaridir.

Kucuk baslayip olceklenmek her zaman iyi bir stratejidir. Tek node'lu bir gelistirme ortaminda mapping ve analyzer'lari test edin, arama kalitesini olcun ve uretim ortamina gecerken cluster mimarisini ihtiyaca gore buyutun. Arama metriklerini -- sifir sonuc orani, ortalama sorgu suresi, tiklama pozisyonu dagilimi -- surekli izleyerek iyilestirme firsatlarini belirleyin. Arama, kullanicilarin platformunuzla kurdugu ilk temas noktasidir ve bu deneyimin kalitesi platformun genel basarisini dogrudan etkiler.