Full-Text Search Nedir? — Geleneksel DB vs Arama Motoru

Geleneksel Veritabanı vs Arama Motoru

Bir kütüphaneye girdiğini düşün. Elinde sadece bir bilgi var: "Evrim hakkında bir şeyler okumak istiyorum." Kütüphaneciye sorsun — adam 30 yıldır orada çalışıyor, her kitabın nerede olduğunu, ne anlattığını, hangi bölümde hangi konunun geçtiğini biliyor. Sana üç saniyede beş tane kitap önerir, üstelik en alakalısını en başa koyar.

Şimdi bir de şunu hayal et: Aynı kütüphane, ama kütüphaneci yok. Yerine bir katalog kartı sistemi var. "Evrim" kelimesini tam olarak yazarsan, başlığında "Evrim" geçen kitapları bulursun. Ama "Darwin'in kuramı" yazarsan? Hiçbir sonuç yok. "Evrimsel biyoloji" yazarsan? Yine sıfır. Çünkü katalog kartı sadece tam eşleşme (exact match) yapıyor.

İşte geleneksel veritabanları o katalog kartı sistemi gibidir. Elasticsearch ise o 30 yıllık tecrübeli kütüphaneci.

Geleneksel Veritabanlarının Arama Problemi

SQL LIKE ile Arama — Tanıdık Ama Yetersiz

Çoğumuz kariyerimizin bir noktasında şuna benzer bir SQL yazmışızdır:

SELECT * FROM products 
WHERE name LIKE '%kahve makinesi%';

Bu sorgu çalışır mı? Evet. İşe yarar mı? Kısmen. Ama ciddi problemleri var:

Problem 1: Sadece tam alt-string eşleşmesi yapar

-- Bu çalışır:
SELECT * FROM products WHERE name LIKE '%kahve makinesi%';
-- "Otomatik kahve makinesi deluxe" → ✅ Bulur

-- Ama kullanıcı şunu yazarsa:
SELECT * FROM products WHERE name LIKE '%kahve makinası%';
-- "Otomatik kahve makinesi deluxe" → ❌ Bulamaz (makinası vs makinesi)

SELECT * FROM products WHERE name LIKE '%kahve makine%';
-- "Otomatik kahve makinesi deluxe" → ✅ Bulur (alt-string eşleşir)

SELECT * FROM products WHERE name LIKE '%makine kahve%';
-- "Otomatik kahve makinesi deluxe" → ❌ Bulamaz (sıra farklı)

Kullanıcı "makinası" yazdı diye sonuç sıfır. Gerçek dünyada kabul edilebilir mi? Hayır.

Problem 2: Performans kabusu — Full Table Scan

LIKE '%keyword%' sorgusu, başında % wildcard olduğu için index kullanamaz. Veritabanı, tablodaki her satırı tek tek kontrol etmek zorundadır. 10 milyon ürün varsa, 10 milyon satır taranır.

-- Bu sorgu index kullanabilir (prefix match):
SELECT * FROM products WHERE name LIKE 'kahve%';

-- Bu sorgu index KULLANAMAZ (contains search):
SELECT * FROM products WHERE name LIKE '%kahve%';

1 milyon kayıtta belki tolere edilir. 100 milyon kayıtta? Sorgu 10-30 saniye sürer. Kullanıcı çoktan sayfayı kapatmıştır.

Problem 3: Alakalılık (Relevance) kavramı yok

SQL LIKE sorgusu ya eşleşir ya eşleşmez. İkili (binary) bir sonuç. Ama gerçek arama böyle çalışmaz.

"Java programlama" diye arattığında:

• "Java Programlama Dili — Başlangıç Rehberi" → Çok alakalı

• "Endonezya'nın Java Adasında Programlama Kampı" → Az alakalı

• "JavaScript Programlama" → Kısmen alakalı

SQL sana bu üçünü de aynı öncelikte döndürür. Hangisinin daha alakalı olduğunu bilemez.

Full-Text Index Denemeleri — MySQL, PostgreSQL

Modern veritabanları bu sorunu fark etti. MySQL'de FULLTEXT index, PostgreSQL'de tsvector/tsquery çözümleri var:

-- MySQL Full-Text Search
ALTER TABLE products ADD FULLTEXT(name, description);
SELECT * FROM products 
WHERE MATCH(name, description) AGAINST('kahve makinesi' IN NATURAL LANGUAGE MODE);

-- PostgreSQL Full-Text Search
SELECT * FROM products 
WHERE to_tsvector('turkish', name || ' ' || description) 
      @@ to_tsquery('turkish', 'kahve & makinesi');

Bu çözümler LIKE '%...%' den çok daha iyi. Ama hâlâ sınırları var:

Full-Text Search Nedir?

Full-Text Search, bir metnin içeriğini anlayarak arama yapma tekniğidir. "Anlayarak" derken kasıt şu:

1. Tokenization: Metni kelimelere (token) ayırır → "Kahve makinesi fiyatları" → ["kahve", "makinesi", "fiyatları"]

2. Normalization: Kelimeleri standart forma getirir → "Makinesi" → "makine", "Fiyatları" → "fiyat"

3. Stemming/Lemmatization: Kök bulma → "koşuyordum" → "koş"

4. Inverted Index: Her kelime için hangi dokümanlarda geçtiğini bir indekste saklar

5. Relevance Scoring: Sonuçları alakalılığa göre sıralar

Basit Bir Örnek

Üç dökümanımız olsun:

Döküman 1: "Java programlama dili öğrenme rehberi"
Döküman 2: "JavaScript ile web programlama"
Döküman 3: "Java adasında kahve üretimi"

Kullanıcı "Java programlama" diye aratıyor.

SQL LIKE yaklaşımı:

• Döküman 1: ✅ (ikisi de geçiyor)

• Döküman 2: ❌ ("Java" yok, "JavaScript" var — eşleşmez)

• Döküman 3: ❌ ("programlama" yok)

• Sonuç: 1 döküman, sıralama yok

Full-Text Search yaklaşımı:

• Döküman 1: Skor 2.8 → "Java" var ✅, "programlama" var ✅, ikisi de başlıkta → yüksek skor

• Döküman 2: Skor 1.2 → "programlama" var ✅, "Java" yok ama "JavaScript" kısmen eşleşebilir

• Döküman 3: Skor 0.9 → "Java" var ✅, "programlama" yok → düşük skor

• Sonuç: 3 döküman, alakalılık sırasıyla

Bu fark, kullanıcı deneyimini kökten değiştirir.

Elasticsearch — Full-Text Search Motoru

Elasticsearch, Apache Lucene üzerine inşa edilmiş, dağıtık, RESTful bir arama ve analitik motorudur.

Bu cümleyi parçalayalım:

Apache Lucene Üzerine İnşa Edilmiş

Lucene, Java ile yazılmış açık kaynaklı bir arama kütüphanesidir. Doug Cutting tarafından 1999'da yaratıldı. Elasticsearch, Lucene'in gücünü alıp üstüne dağıtık mimari, REST API ve kullanım kolaylığı ekler.

Düşün ki Lucene bir motor. Çok güçlü ama çıplak bir motor. Elasticsearch, o motorun etrafına şasi, direksiyon, vites, klima koyup sana kullanıma hazır bir araba sunar.

Dağıtık (Distributed)

Tek bir makineye sığmayan veriyi birden fazla makineye yayabilir. 1 TB verin var mı? 5 makineye 200'er GB dağıt. Bir makine çökerse veri kaybolmaz — kopyalar (replica) diğer makinelerde.

RESTful

Her işlem HTTP üzerinden yapılır. Özel bir client kütüphanesine ihtiyacın yok (ama varlar ve kullanışlılar). cURL ile bile her şeyi yapabilirsin:

# Bir döküman ekle
curl -X POST "localhost:9200/products/_doc" -H 'Content-Type: application/json' -d'
{
  "name": "Kahve Makinesi",
  "price": 2500,
  "description": "Tam otomatik espresso makinesi"
}'

# Arama yap
curl -X GET "localhost:9200/products/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "name": "kahve"
    }
  }
}'

Arama ve Analitik Motoru

Elasticsearch sadece arama yapmaz. Verinin üzerinde aggregation (toplama/gruplama) işlemleri de yapabilir:

• Kategoriye göre ürün sayısı

• Aylık ortalama fiyat trendi

• En çok aranan 10 kelime

• Şehirlere göre sipariş dağılımı

Bu onu hem bir arama motoru hem de bir analitik platform yapar.

Elasticsearch Nerede Kullanılır?

1. E-Ticaret Araması

Amazon, eBay, Trendyol, Hepsiburada gibi platformlar. Kullanıcı "kırmızı elbise" yazdığında:

• "Kırmızı" renk filtresini anlama

• "Elbise" kategorisini anlama

• Yazım hatalarını tolere etme ("kırmzı" → "kırmızı")

• Sonuçları relevance + popülerlik + stok durumuna göre sıralama

// Elasticsearch ile e-ticaret araması
GET /products/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "name": "kırmızı elbise" } }
      ],
      "filter": [
        { "term": { "in_stock": true } },
        { "range": { "price": { "gte": 100, "lte": 1000 } } }
      ]
    }
  },
  "sort": [
    { "_score": "desc" },
    { "popularity": "desc" }
  ]
}

2. Log Analizi ve Monitoring

Günde milyarlarca log satırı üreten sistemlerde (Netflix, Uber, LinkedIn):

• Uygulama loglarını merkezi bir yerde toplama

• Hata oranlarını gerçek zamanlı izleme

• "Son 1 saatte 500 hatası veren endpoint'ler" gibi sorgular

• Kibana dashboard'larıyla görselleştirme

// Son 1 saatte 500 hatası veren logları bul
GET /app-logs-2025.01/_search
{
  "query": {
    "bool": {
      "must": [
        { "term": { "status_code": 500 } }
      ],
      "filter": [
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  },
  "aggs": {
    "errors_by_endpoint": {
      "terms": { "field": "endpoint.keyword", "size": 10 }
    }
  }
}

3. İçerik Arama

Wikipedia, Medium, Stack Overflow gibi içerik platformları:

• Milyonlarca makale/soru içinde arama

• Otomatik tamamlama (autocomplete)

• "Bunu mu demek istediniz?" önerileri

• Eşanlamlı kelimelerle arama ("araba" → "otomobil", "vasıta")

4. Güvenlik ve SIEM

Siber güvenlik olaylarını (event) toplama ve analiz etme:

• Elastic SIEM ile tehdit tespiti

• Anomali algılama

• Compliance raporlama

• Real-time alerting

5. Coğrafi Arama (Geo Search)

Harita tabanlı uygulamalar:

• "Bana en yakın 5 restoran"

• "İstanbul Kadıköy'de 2 km yarıçapında eczaneler"

• Teslimat bölgesi hesaplama

// Yakınımdaki restoranlar
GET /restaurants/_search
{
  "query": {
    "geo_distance": {
      "distance": "2km",
      "location": {
        "lat": 40.9906,
        "lon": 29.0297
      }
    }
  },
  "sort": [
    {
      "_geo_distance": {
        "location": { "lat": 40.9906, "lon": 29.0297 },
        "order": "asc",
        "unit": "km"
      }
    }
  ]
}

Elasticsearch vs Alternatifler

Elasticsearch vs Apache Solr

İkisi de Lucene tabanlı. Uzun yıllar kıyasıya rekabet ettiler.

2024-2025 itibarıyla Elasticsearch, pazar payı ve ekosistem açısından açık ara önde.

Elasticsearch vs Veritabanı Full-Text

Elasticsearch vs Typesense, Meilisearch, OpenSearch

Son yıllarda yeni oyuncular da sahneye çıktı:

• Typesense: Çok hızlı, kurulumu kolay, ama daha az özellik. Küçük-orta projeler için mükemmel.

• Meilisearch: Frontend-first, anında arama, kolay API. Prototipleme ve küçük projeler için ideal.

• OpenSearch: Elasticsearch'in AWS tarafından fork'lanmış hali. Büyük ölçüde uyumlu. AWS ekosistemiyle entegre.

Elasticsearch hâlâ en zengin özellik setine, en büyük topluluğa ve en geniş entegrasyon ağına sahip.

Elasticsearch'ün Temel Özellikleri

1. Near Real-Time (Neredeyse Gerçek Zamanlı)

Bir dökümanı index'lediğinde, yaklaşık 1 saniye sonra aranabilir hale gelir. Bu "refresh interval" ayarıyla kontrol edilir.

// Index ayarlarını kontrol et
GET /my-index/_settings

// Refresh interval'i değiştir
PUT /my-index/_settings
{
  "index": {
    "refresh_interval": "5s"
  }
}

2. Schemaless (Şema Gerektirmez — Ama Kullanmalısın)

Elasticsearch'e veri gönderirken önceden şema tanımlamak zorunlu değil. Otomatik algılar (dynamic mapping). Ama production'da kesinlikle şema tanımlamalısın — yoksa başın ağrır. Bunu ilerideki derslerde detaylıca göreceğiz.

3. RESTful API

Her işlem standart HTTP metotlarıyla:

• PUT → Oluştur / Güncelle

• POST → Oluştur / Ara

• GET → Oku

• DELETE → Sil

4. JSON Tabanlı

Hem veri hem sorgular JSON formatında. Programlama dilinden bağımsız, evrensel format.

5. Dağıtık ve Ölçeklenebilir

Otomatik shard dağılımı, replica yönetimi, node keşfi. Tek komutla cluster'a yeni node ekleyebilirsin.

6. Çoklu Veri Tipi Desteği

Text, keyword, integer, float, date, boolean, geo_point, geo_shape, nested, object, IP, completion ve daha fazlası.

Java ile Elasticsearch — İlk Bakış

Bu kursun ilerleyen bölümlerinde Java ile Elasticsearch'ü detaylı göreceğiz. Ama şimdiden bir fikir vermesi için basit bir örnek:

import co.elastic.clients.elasticsearch.ElasticsearchClient;
import co.elastic.clients.elasticsearch.core.SearchResponse;
import co.elastic.clients.elasticsearch.core.search.Hit;
import co.elastic.clients.json.jackson.JacksonJsonpMapper;
import co.elastic.clients.transport.rest_client.RestClientTransport;
import org.apache.http.HttpHost;
import org.elasticsearch.client.RestClient;

import java.util.Map;

class Main {
    public static void main(String[] args) throws Exception {
        // Elasticsearch client oluştur
        RestClient restClient = RestClient.builder(
            new HttpHost("localhost", 9200)
        ).build();

        ElasticsearchClient client = new ElasticsearchClient(
            new RestClientTransport(restClient, new JacksonJsonpMapper())
        );

        // Basit bir arama yap
        SearchResponse<Map> response = client.search(s -> s
            .index("products")
            .query(q -> q
                .match(m -> m
                    .field("name")
                    .query("kahve makinesi")
                )
            ),
            Map.class
        );

        // Sonuçları yazdır
        System.out.println("Toplam sonuç: " + response.hits().total().value());
        for (Hit<Map> hit : response.hits().hits()) {
            System.out.println("Skor: " + hit.score() + " → " + hit.source());
        }

        restClient.close();
    }
}

Bu kod Elasticsearch'e bağlanır, "products" index'inde "kahve makinesi" araması yapar ve sonuçları skorlarıyla birlikte yazdırır. Şimdilik sadece yapının nasıl göründüğünü anla — detayları Bölüm 8'de işleyeceğiz.

Relevance Scoring — Neden Önemli?

Arama motorlarının en kritik özelliği alakalılık sıralamasıdır. Elasticsearch, her döküman için bir skor (score) hesaplar. Bu skor, dökümanın arama sorgusuna ne kadar uygun olduğunu gösteren bir sayıdır.

BM25 Algoritması

Elasticsearch 5.0'dan itibaren varsayılan scoring algoritması BM25'tir (Best Matching 25). Öncesinde TF-IDF kullanılıyordu.

BM25 üç temel faktörü değerlendirir:

1. Term Frequency (TF) — Kelime Sıklığı

Aranan kelime dökümanda ne kadar çok geçiyorsa, skor o kadar yüksek. Ama doğrusal değil — azalan getiri yasası geçerli. "Kahve" kelimesi bir dökümanda 3 kez geçmesiyle 30 kez geçmesi arasındaki fark, 0 kez ile 3 kez geçmesi kadar büyük değildir.

2. Inverse Document Frequency (IDF) — Ters Döküman Sıklığı

Aranan kelime ne kadar nadir ise, o kadar değerli. "ve", "bir", "ile" gibi kelimeler her yerde geçer — bunları bulmak kolay, dolayısıyla düşük değerli. Ama "Elasticsearch" kelimesi nadir — onu içeren döküman daha değerli.

3. Field Length — Alan Uzunluğu

Kısa bir başlıkta geçen kelime, 10.000 kelimelik bir makalede geçen aynı kelimeden daha değerli. Çünkü kısa alanda geçmesi, o dökümanın gerçekten o konuyla ilgili olduğunun güçlü bir sinyali.

Skor Açıklama Örneği

Elasticsearch'den bir sonucun neden o skoru aldığını sorabilirsin:

// Explain API ile skor açıklaması
GET /products/_explain/1
{
  "query": {
    "match": {
      "name": "kahve makinesi"
    }
  }
}

Yanıt, skorun nasıl hesaplandığını adım adım gösterir. Debug yaparken çok işe yarar.

// Arama sonuçlarında explain görmek için
GET /products/_search
{
  "explain": true,
  "query": {
    "match": {
      "name": "kahve makinesi"
    }
  }
}

Full-Text Search'ün Perde Arkası — Text Analysis

Elasticsearch bir metni index'lerken şu adımlardan geçirir:

1. Character Filtering

Metin üzerinde karakter seviyesinde dönüşümler. Örneğin HTML tag'lerini kaldırma:

Girdi:  "<p>Kahve <b>makinesi</b> fiyatları</p>"
Çıktı:  "Kahve makinesi fiyatları"

2. Tokenization

Metni token'lara (genellikle kelimelere) ayırma:

Girdi:  "Kahve makinesi fiyatları"
Çıktı:  ["Kahve", "makinesi", "fiyatları"]

3. Token Filtering

Her token üzerinde dönüşümler — küçük harfe çevirme, kök bulma, stop-word kaldırma:

Girdi:  ["Kahve", "makinesi", "fiyatları"]
Çıktı:  ["kahve", "makine", "fiyat"]

Bu sürecin tamamına analysis denir ve Bölüm 5'te derinlemesine ele alacağız.

Analyze API ile Test

Elasticsearch'ün bir metni nasıl analiz ettiğini görebilirsin:

// Varsayılan analyzer ile test
GET /_analyze
{
  "analyzer": "standard",
  "text": "Kahve Makinesi Fiyatları 2025"
}

// Yanıt:
{
  "tokens": [
    { "token": "kahve",      "position": 0 },
    { "token": "makinesi",   "position": 1 },
    { "token": "fiyatları",  "position": 2 },
    { "token": "2025",       "position": 3 }
  ]
}

Dikkat: Standard analyzer Türkçe kök bulma yapmaz. Türkçe için özel analyzer gerekir — bunu da ilerleyen derslerde göreceğiz.

Elasticsearch Kullanmamalı mıyım?

Elasticsearch her derde deva değil. Şu durumlarda kullanmamalısın:

❌ Primary Database Olarak

Elasticsearch bir arama motorudur, birincil veritabanı değildir. ACID transaction desteği yoktur. Verin asıl kaynağını (source of truth) PostgreSQL, MySQL veya MongoDB gibi bir veritabanında tut; Elasticsearch'ü arama katmanı olarak kullan.

[Kullanıcı] → [API] → [PostgreSQL] (kaynak — source of truth)
                           ↓ (sync)
                     [Elasticsearch] (arama katmanı)

❌ Sık Güncellenen Veriler İçin (Heavy Write)

Elasticsearch, update işlemini aslında sil + yeniden yaz olarak yapar (immutable segments). Saniyede binlerce güncelleme yapıyorsan, performans sorunları yaşarsın.

❌ Join-Ağırlıklı İlişkisel Sorgular İçin

SQL'deki gibi JOIN yapısı Elasticsearch'te doğrudan yoktur. İlişkisel veri modeline sıkı sıkıya bağlıysan, geleneksel RDBMS daha uygun.

❌ Küçük Veri Setleri İçin

10.000 kayıtlık bir tablon varsa ve basit arama yetiyorsa, Elasticsearch overhead yaratır. PostgreSQL full-text search gayet yeterli.

✅ Kullan:

• Milyonlarca/milyarlarca kayıtta hızlı arama

• Fuzzy search, autocomplete, synonym gibi gelişmiş arama özellikleri

• Log analizi, monitoring, SIEM

• Aggregation tabanlı analitik dashboard'lar

• Geo-spatial sorgular

• Near real-time arama gereksinimleri

Elasticsearch'ün Kısa Tarihi

Shay Banon'un hikayesi ilham verici: Eşinin yemek tarifleri arayabilmesi için başladığı proje, bugün Fortune 500 şirketlerinin %80'inden fazlasının kullandığı bir platforma dönüştü.

Pratik: Zihninde Bir Elasticsearch Projesi Tasarla

Henüz Elasticsearch kurmadık ama zihinsel bir egzersiz yapalım. Bir e-kitap platformu düşün:

Gereksinimler:

• 500.000 kitap

• Başlık, yazar, açıklama, kategori, yayın tarihi, dil, sayfa sayısı, fiyat

• Kullanıcı arama yapacak: "Türk edebiyatı roman 2024"

• Autocomplete: "suc" yazınca "Suç ve Ceza" önerisi

• Filtreler: Kategori, dil, fiyat aralığı, yayın yılı

• Sıralama: Alakalılık, fiyat, yayın tarihi, popülerlik

Elasticsearch ile çözüm taslağı:

// 1. Index oluştur (mapping ile)
PUT /books
{
  "mappings": {
    "properties": {
      "title":        { "type": "text", "analyzer": "turkish" },
      "author":       { "type": "text", "fields": { "keyword": { "type": "keyword" } } },
      "description":  { "type": "text", "analyzer": "turkish" },
      "category":     { "type": "keyword" },
      "language":     { "type": "keyword" },
      "pages":        { "type": "integer" },
      "price":        { "type": "float" },
      "publish_date": { "type": "date" },
      "popularity":   { "type": "integer" },
      "suggest":      { "type": "completion" }
    }
  }
}

// 2. Kitap ekle
POST /books/_doc
{
  "title": "Suç ve Ceza",
  "author": "Fyodor Dostoyevski",
  "description": "Bir üniversite öğrencisinin işlediği cinayetin psikolojik derinliklerini...",
  "category": "Roman",
  "language": "tr",
  "pages": 672,
  "price": 45.00,
  "publish_date": "2023-01-15",
  "popularity": 9500,
  "suggest": {
    "input": ["Suç ve Ceza", "Dostoyevski", "Suç"]
  }
}

// 3. Arama yap
GET /books/_search
{
  "query": {
    "bool": {
      "must": [
        { "multi_match": { 
            "query": "Türk edebiyatı roman",
            "fields": ["title^3", "description", "category^2"] 
          }
        }
      ],
      "filter": [
        { "range": { "publish_date": { "gte": "2024-01-01" } } }
      ]
    }
  },
  "sort": [
    { "_score": "desc" },
    { "popularity": "desc" }
  ]
}

Bu sorgunun her parçasını ilerleyen derslerde tek tek öğreneceksin. Şimdilik sadece büyük resmi gör.

Best Practices — İlk Günden Bilmen Gerekenler

✅ Elasticsearch'ü arama katmanı olarak kullan — Primary database yapma

✅ Veri senkronizasyonunu planlayarak başla — DB → ES nasıl sync olacak?

✅ Mapping tanımla — Dynamic mapping'e güvenme, önceden şema belirle

✅ Türkçe analyzer kur — Varsayılan analyzer Türkçe kök bulma yapmaz

✅ Alias kullan — Doğrudan index adına değil, alias üzerinden çalış (esneklik sağlar)

✅ Monitoring kur — Cluster health, shard durumu, disk kullanımı izle

Yaygın Hatalar ve Yanılgılar

❌ "Elasticsearch veritabanımın yerine geçer"

Hayır. Elasticsearch transaction desteği olmayan bir arama motorudur. Veri kaybı riski taşır. Primary database olarak kullanma.

❌ "Her şeyi Elasticsearch'e atarım, o halleder"

Elasticsearch'e arama yapacağın veriyi at. Tüm veritabanını kopyalaman gerekmez. Sadece aranacak ve filtrelenecek alanları index'le.

❌ "Schema/Mapping tanımlamaya gerek yok, otomatik algılar"

Dynamic mapping başlangıçta kolaylık sağlar ama production'da kesinlikle explicit mapping tanımla. Yoksa string alanlar hem text hem keyword olarak ikili index'lenir — gereksiz disk ve memory kullanımı.

❌ "SQL biliyorum, Elasticsearch da benzerdir"

Benzer değildir. Elasticsearch'ün veri modeli, sorgu dili ve davranışları RDBMS'den temelden farklı. SQL zihniyetiyle yaklaşırsan hayal kırıklığına uğrarsın. JSON tabanlı Query DSL'i öğrenmen gerekiyor.

❌ "Bir tane sunucu yeter"

Development için yeter. Production'da minimum 3 node önerilir (1 master + 2 data veya 3 master-eligible). Tek node'da replica oluşturulamaz, cluster durumu "yellow" kalır.

Özet

• Full-Text Search, metin içeriğini anlayarak arama yapma tekniğidir — SQL LIKE sorgusunun çok ötesinde

• Elasticsearch, Lucene tabanlı, dağıtık, RESTful bir arama ve analitik motorudur

• BM25 algoritması ile her sonuca bir alakalılık skoru verir — en uygun sonuç en başta

• E-ticaret, log analizi, içerik arama, güvenlik ve geo-search gibi birçok alanda kullanılır

• Elasticsearch bir arama katmanıdır, primary database değildir — source of truth başka yerde tutulmalı

• Text analysis (tokenization, normalization, stemming) sayesinde "makinesi", "makinası", "makine" aynı sonucu döner

• Küçük veri setleri ve basit aramalar için PostgreSQL FTS yeterli olabilir — Elasticsearch her zaman şart değil

Bir sonraki derste Elasticsearch ekosistemini (Elastic Stack) tanıyacağız — Kibana, Logstash, Beats ve hepsinin birlikte nasıl çalıştığını göreceğiz.