← Kursa Dön
📄 Text · 30 min

Elasticsearch Mülakat Rehberi ve Cheatsheet

Giriş — Son Silahın

Bu ders diğerlerinden farklı. Burası öğretmek için değil, hatırlamak için. Mülakat öncesi gece son bir kez göz gezdireceğin, production'da "şu komut nasıldı?" dediğinde açacağın, masana yapıştıracağın sayfa.

50 gerçek mülakat sorusu, günlük kullanım cheatsheet'i, REST API quick reference, troubleshooting flowchart — hepsi bir arada.


BÖLÜM A: 50 Mülakat Sorusu ve Cevapları

🟢 Junior Seviye (1-15)

1. Elasticsearch nedir? Geleneksel veritabanından farkı ne?

Elasticsearch, Apache Lucene üzerine kurulu, dağıtık, RESTful bir arama ve analiz motorudur. RDBMS'den farkları:

  • Inverted index kullanır (RDBMS B-tree kullanır)

  • Full-text search için optimize edilmiştir

  • Schema-less çalışabilir (dynamic mapping)

  • Dağıtık mimari — otomatik sharding ve replication

  • Near real-time — ~1 saniye içinde aranabilir (refresh interval)

  • SQL'de LIKE '%keyword%' yavaştır; ES'te inverted index ile milisaniyeler

2. Inverted index nedir?

Bir kitabın arkasındaki indeks gibi. Normal index: "Sayfa 42 → elasticsearch kelimesi var". Inverted index: "elasticsearch → Sayfa 42, 78, 156'da geçiyor". Her kelime hangi dokümanlarda geçiyorsa onlara pointer tutar. Bu yüzden full-text search O(1)'e yakın hızda çalışır.

3. Index, Document ve Field nedir?

  • Index: Benzer dokümanların toplandığı koleksiyon (RDBMS'teki tablo)

  • Document: Tek bir veri kaydı, JSON formatında (RDBMS'teki satır)

  • Field: Doküman içindeki bir alan (RDBMS'teki sütun)

4. Shard ve Replica nedir?

  • Shard: Index'in parçası. Her shard bağımsız bir Lucene index'idir. Paralel arama ve yatay ölçekleme sağlar.

  • Primary shard: Orijinal veri

  • Replica shard: Primary'nin kopyası. HA (yüksek erişilebilirlik) ve okuma performansı sağlar. Primary ve replica aynı node'da olamaz.

  • Shard sayısı index oluşturulduktan sonra değiştirilemez (split/shrink hariç).

5. Query context ile Filter context farkı nedir?

  • Query context: "Bu doküman ne kadar uygun?" — Relevance score (_score) hesaplanır. match, multi_match.

  • Filter context: "Bu doküman uyuyor mu?" — Evet/Hayır. Score hesaplanmaz, cache'lenebilir, daha hızlı. bool.filter, term, range.

Best practice: Scoring gerekmiyorsa filter kullan.

6. `match` ile `term` query farkı nedir?

  • match: Text'i analyzer'dan geçirir, token'lara ayırır, sonra arar. Full-text search için.

  • term: Tam eşleşme, analyzer kullanmaz. Keyword field'lar için (status, category gibi).

Yaygın hata: text field'da term query kullanmak → "Elasticsearch" terimi standard analyzer'dan geçmiş "elasticsearch" olarak index'lenmiş, ama term query "Elasticsearch" olarak arar → bulamaz.

7. `PUT` ile `POST` farkı nedir (indexing)?

  • PUT my-index/_doc/1 {...} — ID belirterek index'le. ID varsa günceller.

  • POST my-index/_doc {...} — ID otomatik oluşturulur (UUID).

8. Mapping nedir? Dynamic mapping nedir?

  • Mapping: Index'teki field'ların tip tanımı (schema). text, keyword, integer, date, geo_point, vb.

  • Dynamic mapping: İlk doküman geldiğinde ES field tiplerini otomatik tahmin eder. "hello" → text + keyword, 42 → long, true → boolean.

  • Production'da explicit mapping kullanın — dynamic mapping yanlış tahmin yapabilir.

9. `text` ile `keyword` field farkı nedir?

  • text: Analyzer'dan geçer, tokenize edilir. Full-text search için. Sorting ve aggregation yapılamaz (fielddata olmadan).

  • keyword: Olduğu gibi saklanır. Exact match, sorting, aggregation için. Max 32KB (ignore_above: 256 varsayılan).

10. Elasticsearch'te güncelleme nasıl çalışır?

Elasticsearch'te gerçek güncelleme yoktur. Update işlemi:

  1. Eski dokümanı oku

  2. Değişiklikleri uygula

  3. Yeni dokümanı index'le

  4. Eski dokümanı "deleted" olarak işaretle

Deleted dokümanlar segment merge sırasında fiziksel olarak silinir.

11. Bulk API nedir, neden kullanılır?

Tek HTTP request'te birden fazla index/update/delete operasyonu. Avantajları:

  • Network overhead azalır (binlerce request yerine tek request)

  • ES internal optimizasyonları devreye girer

  • Önerilen batch size: 5-15 MB veya 1000-5000 doküman

12. Refresh ve Flush farkı nedir?

  • Refresh: In-memory buffer'daki verileri segment'e yazar. Veriler aranabilir olur. Varsayılan: 1 saniye.

  • Flush: Translog'u temizler, segment'leri commit eder. Veri dayanıklılığı (durability) sağlar.

  • Refresh = aranabilirlik, Flush = dayanıklılık.

13. `_source` field nedir?

Dokümanın orijinal JSON'ını saklayan özel field. Arama sonuçlarında dokümanı geri döndürmek için kullanılır. Disable edilebilir ama önerilmez (update, reindex çalışmaz).

14. Analyzer nedir?

Text'i aranabilir token'lara dönüştüren pipeline:

  1. Character filter: HTML strip, mapping

  2. Tokenizer: Standard, whitespace, keyword

  3. Token filter: Lowercase, stemmer, synonym, stop words

Örnek: "The Quick Brown FOX" → standard analyzer → ["the", "quick", "brown", "fox"]

15. `bool` query nasıl çalışır?

4 alt clause'u var:

  • must: AND — hepsi eşleşmeli, score'a katkı yapar

  • should: OR — en az biri eşleşmeli (veya minimum_should_match), score boost

  • must_not: NOT — hiçbiri eşleşmemeli, score'a katkı yapmaz

  • filter: AND gibi ama score hesaplanmaz, cache'lenir


🟡 Orta Seviye (16-35)

16. Shard boyutu ne kadar olmalı?

İdeal: 10-50 GB. Maximum: 65 GB. Çok küçük shard → overhead (memory, cluster state). Çok büyük shard → yavaş recovery, merge sorunları.

17. Node tipleri nelerdir?

TipRolAçıklama
MastermasterCluster yönetimi, shard allocation
Datadata / data_hot / data_warm / data_cold / data_frozenVeri saklama ve arama
Coordinatingrol yokSorgu routing, aggregation merge
IngestingestPipeline ile veri dönüşümü
MLmlMachine learning job'ları

18. Cluster health renkleri ne anlama gelir?

  • GREEN: Tüm primary ve replica shard'lar atanmış

  • YELLOW: Tüm primary'ler OK, bazı replica'lar atanamamış (tek node cluster'da normal)

  • RED: Bazı primary shard'lar atanamamış — veri kaybı riski!

19. ILM (Index Lifecycle Management) nedir?

Index'lerin yaşam döngüsünü 5 phase'de yönetir: Hot → Warm → Cold → Frozen → Delete

Her phase'de action'lar: rollover, shrink, forcemerge, searchable_snapshot, delete. Time-series verileri (log, metrik) için kritik.

20. Data Stream nedir?

Time-series verileri için özel index yapısı. Backing index'ler otomatik yönetilir, rollover otomatik olur. @timestamp zorunlu. Append-only tasarım.

21. Scroll API ile search_after farkı nedir?

  • Scroll: Snapshot alır, tüm sonuçları iteratif döndürür. Ama state tutar — kaynak tüketir. Deprecated trend.

  • search_after: Stateless pagination. Son sonucun sort değerlerini kullanarak sonraki sayfaya gider. PIT (Point in Time) ile kullanımı önerilir.

  • from/size: Basit pagination. from + size > 10000 ise yavaşlar (deep pagination sorunu).

22. Aggregation türleri nelerdir?

  • Metric: avg, sum, min, max, cardinality, percentiles, stats

  • Bucket: terms, histogram, date_histogram, range, filter

  • Pipeline: derivative, moving_avg, cumulative_sum, bucket_sort

  • Composite: Sayfalanabilir aggregation — büyük veri setlerinde tüm bucket'ları iterate etmek için

23. Nested type ne zaman kullanılır?

Array of objects'te her objeyi bağımsız sorgulamak istediğinde. Normal object type'da field'lar flatten edilir — cross-object matching sorunu olur.

// Sorun: "Alice" ve "25" farklı objelerde ama eşleşir
{ "users": [{"name":"Alice","age":30}, {"name":"Bob","age":25}] }
// match: name=Alice AND age=25 → YANLIŞ SONUÇ!

// Çözüm: nested type

24. Heap neden 30.5 GB'ı geçmemeli?

Java Compressed OOPs (Compressed Ordinary Object Pointers). 32 GB altında pointer'lar 32-bit. Üstünde 64-bit'e geçer → aynı veri %30-50 daha fazla heap tüketir. 31 GB heap < 30 GB heap (efektif olarak).

25. Alias nedir, neden kullanılır?

Index'e alternatif isim. Kullanım alanları:

  • Zero-downtime reindex: products-v1 → alias: products. Reindex sonrası alias'ı products-v2'ye çevir.

  • Multi-index arama: logs-* yerine logs-current alias'ı

  • Filtering: Alias'a filter ekleyerek belirli bir veri alt kümesine erişim

26. Ingest pipeline nedir?

Doküman index'lenmeden önce dönüşüm yapan processor zinciri. grok (log parse), date (tarih parse), geoip (IP → lokasyon), set, rename, remove. Logstash'a alternatif — daha hafif.

27. Cross-cluster search (CCS) nedir?

Farklı ES cluster'larını tek sorguda arama. Cluster alias tanımlayarak cluster_a:index-*,cluster_b:index-* şeklinde sorgularsınız. Multi-region veya multi-environment senaryolarda kullanılır.

28. Fielddata nedir? Neden text field'da aggregation yavaştır?

Text field'lar inverted index'te saklanır — aggregation için uygun değil. Fielddata, text field'ı memory'de uninvert eder — çok pahalı (heap tüketir). Çözüm: keyword sub-field kullan.

29. Circuit breaker nedir?

OOM'u (Out of Memory) önleyen güvenlik mekanizması. Fielddata, request, inflight request limitleri var. Limit aşılırsa sorgu reddedilir (HTTP 429). Cluster çökmesini önler.

30. Routing nedir?

Dokümanın hangi shard'a gideceğini belirleyen mekanizma. Formül: shard = hash(routing_value) % number_of_primary_shards. Varsayılan routing value = _id. Custom routing ile ilgili dokümanları aynı shard'a yönlendirebilirsiniz.

31. Segment merge nedir?

Lucene, her refresh'te yeni segment oluşturur. Çok segment = yavaş arama. Merge policy arka planda küçük segment'leri birleştirir. forcemerge ile manuel tetiklenebilir (salt okunur index'lerde).

32. Translog (Transaction Log) nedir?

Her index operasyonu önce translog'a yazılır — crash durumunda veri kaybını önler. Flush operasyonuyla temizlenir. WAL (Write-Ahead Log) prensibiyle çalışır.

33. Hot-Warm-Cold mimarisi nedir?

Farklı donanım tier'larında veri saklama stratejisi:

  • Hot: NVMe SSD, yüksek CPU — aktif yazma ve okuma

  • Warm: SATA SSD/HDD — salt okunur, sık sorgulanan

  • Cold: HDD + object storage — nadiren sorgulanan

  • Frozen: Object storage — arşiv, çok nadiren erişilen

34. Snapshot ve restore nasıl çalışır?

Snapshot: Cluster/index durumunun yedeği. Repository'ye (S3, GCS, NFS) yazılır. Incremental — sadece değişen segment'ler kopyalanır. SLM (Snapshot Lifecycle Management) ile otomatikleştirilebilir.

35. Rolling upgrade nasıl yapılır?

  1. Shard allocation kapat

  2. Synced flush / flush

  3. Bir node'u durdur

  4. Güncelle ve başlat

  5. Allocation aç

  6. GREEN bekle

  7. Sonraki node'a geç (master'ı en sona bırak)


🔴 Senior Seviye (36-50)

36. Elasticsearch'ün yazma yolu (write path) nasıl çalışır?

Client → Coordinating Node → Primary Shard Node
  1. Doküman coordinating node'a gelir
  2. Routing ile primary shard belirlenir
  3. Primary shard node'a yönlendirilir
  4. Primary shard: translog'a yaz + in-memory buffer'a ekle
  5. Replica shard'lara paralel olarak gönder
  6. Tüm in-sync replica'lar onaylarsa → success
  7. Refresh (1s) → segment'e yaz → aranabilir
  8. Flush → translog temizle → commit

37. Elasticsearch'ün okuma yolu (read path) nasıl çalışır?

Client → Coordinating Node → Tüm ilgili shard'lar
  1. Sorgu coordinating node'a gelir
  2. Routing ile ilgili shard'lar belirlenir
  3. Her shard grubundan (primary veya replica) biri seçilir
     (adaptive replica selection — en hızlısı)
  4. Her shard kendi Lucene index'inde arar
  5. Sonuçlar coordinating node'da merge edilir
  6. Top-N sonuç döndürülür (two-phase: query then fetch)

38. Relevance scoring (BM25) nasıl çalışır?

BM25 (Best Matching 25) formülü:

  • TF (Term Frequency): Kelime dokümanda ne kadar sık geçiyor? Sık → daha relevant

  • IDF (Inverse Document Frequency): Kelime tüm dokümanlarda ne kadar nadir? Nadir → daha relevant

  • Field length: Kısa field'da eşleşme daha değerli (3 kelimelik title'da "elasticsearch" > 1000 kelimelik body'de)

BM25(q, d) = Σ IDF(qi) × [f(qi,d) × (k1+1)] / [f(qi,d) + k1 × (1-b+b×|d|/avgdl)]

39. Split-brain nedir? Nasıl önlenir?

Ağ bölünmesi sonucu iki ayrı grubun kendini bağımsız cluster sanması. ES 7.x+ ile otomatik önlenir (voting configuration). Önceki versiyonlarda minimum_master_nodes = (master_eligible_count / 2) + 1 ayarı gerekiyordu. Production'da en az 3 master-eligible node kullanın.

40. _seq_no ve _primary_term ne işe yarar?

Optimistic concurrency control için. _seq_no her yazma işleminde artar. _primary_term primary shard değiştiğinde artar. Concurrent update'lerde conflict detection:

PUT my-index/_doc/1?if_seq_no=5&if_primary_term=1
{ "field": "updated_value" }
// seq_no veya primary_term eşleşmezse → 409 Conflict

41. Searchable snapshots nasıl çalışır?

Snapshot'taki index'leri doğrudan aranabilir hale getirir. İki mod:

  • Fully mounted (frozen): Veri tamamen object storage'da, on-demand cache

  • Partially mounted (cold): Shard-level cache, daha hızlı ama daha fazla lokal disk

Maliyet: Hot tier'a göre %90+ disk tasarrufu.

42. Painless scripting ne zaman kullanılır?

ES'in varsayılan scripting dili. Kullanım alanları:

  • script_score ile custom scoring

  • scripted_field ile runtime field

  • update ile conditional güncelleme

  • ingest pipeline ile veri dönüşümü

Dikkat: Script'ler her doküman için çalışır — heavy script = yavaş sorgu.

43. Runtime fields nedir?

Sorgu zamanında hesaplanan field'lar. Index'lenmez, disk kullanmaz. Kullanım: schema değişikliği yapmadan yeni field ekleme. Trade-off: sorgu zamanında CPU kullanır.

GET my-index/_search
{
  "runtime_mappings": {
    "price_with_tax": {
      "type": "double",
      "script": "emit(doc['price'].value * 1.18)"
    }
  },
  "query": { "range": { "price_with_tax": { "gte": 100 } } }
}

44. Data tiering stratejisi nasıl tasarlanır?

Soru 1: Günlük ne kadar veri geliyor?
Soru 2: Her tier'da kaç gün tutulacak?
Soru 3: SLA nedir? (latency, uptime)

Örnek: 100 GB/gün
  Hot:    30 gün × 100 GB = 3 TB → NVMe SSD
  Warm:   60 gün × 100 GB = 6 TB → SATA SSD (forcemerge ile 3-4 TB)
  Cold:   275 gün × 100 GB = 27 TB → S3 (searchable snapshot)
  Frozen: Sınırsız → S3 (minimal cache)
  
ILM policy: rollover → shrink → forcemerge → searchable_snapshot → delete

45. ES cluster'da performans sorunu yaşanıyor. Nasıl debug edersin?

1. GET _cluster/health → RED/YELLOW mı?
2. GET _cat/nodes?v → CPU, heap, disk
3. GET _nodes/hot_threads → Hangi thread'ler meşgul?
4. GET _cat/thread_pool?v → Rejection var mı?
5. GET _nodes/stats/jvm → GC pressure?
6. GET _cat/shards?v → UNASSIGNED shard var mı?
7. GET index/_search?profile=true → Hangi sorgu yavaş?
8. GET _cat/indices?v&s=store.size:desc → En büyük index'ler
9. Slow log aç → Yavaş sorguları yakala
10. GET _cluster/allocation/explain → Neden atanmadı?

46. Elasticsearch ile RDBMS arasında veri senkronizasyonu nasıl yapılır?

Yöntemler:

  • Dual write: Uygulama hem DB'ye hem ES'e yazar. Basit ama consistency riski.

  • CDC (Change Data Capture): Debezium + Kafka → ES. DB binlog'dan okur, gerçek zamanlı senkronize eder.

  • Scheduled reindex: Belirli aralıklarla DB'den ES'e bulk import. Gecikme var ama basit.

  • Logstash JDBC input: Logstash periyodik olarak DB'den çeker.

47. Multi-tenancy nasıl uygulanır?

3 yaklaşım:

  • Index per tenant: tenant-a-products, tenant-b-products. İzolasyon iyi ama çok shard.

  • Shared index + routing: Tek index, custom routing ile tenant verisini aynı shard'a topla. Performans iyi.

  • Filtered alias: Tek index, her tenant için filter'lı alias. Güvenlik + basitlik.

48. Capacity planning nasıl yapılır?

Formül:
  Disk = Günlük_Veri × Retention × (1 + Replica) × 1.3 (overhead)
  Shard = Toplam_Veri / 25GB (hedef shard boyutu)
  Heap = min(RAM × 0.5, 30.5GB)
  Node = Toplam_Disk / Node_Disk_Kapasitesi (min 3 HA)

49. ELK vs EFK vs Elastic Agent — farkları nedir?

  • ELK: Elasticsearch + Logstash + Kibana. Klasik stack. Logstash ağır ama güçlü.

  • EFK: Elasticsearch + Fluentd + Kibana. K8s'te popüler. Fluentd CNCF projesi.

  • Elastic Agent + Fleet: Modern yaklaşım. Tek binary, merkezi yönetim. Beats'in evrimi.

50. Elasticsearch'ün en büyük sınırlamaları nelerdir?

  • Transaction yok: ACID garantisi yoktur. Eventual consistency.

  • Join'ler sınırlı: RDBMS gibi JOIN yapamazsınız. Nested ve parent-child var ama pahalı.

  • Update pahalı: Her update = delete + re-index.

  • Deep pagination yavaş: from + size > 10K sorunlu.

  • Schema değişikliği zor: Mapping değiştirmek reindex gerektirir.

  • Primary shard sayısı sabit: Oluşturulduktan sonra değiştirilemez (split/shrink hariç).

  • Gerçek zamanlı değil: ~1 saniye gecikme (refresh interval).


BÖLÜM B: Günlük Kullanım Cheatsheet

CRUD İşlemleri

# ═══ INDEX ═══
PUT my-index/_doc/1                        # ID ile index'le
POST my-index/_doc                         # Auto-ID ile index'le
PUT my-index/_create/1                     # Sadece oluştur (varsa hata)

# ═══ READ ═══
GET my-index/_doc/1                        # Tek doküman
GET my-index/_doc/1?_source_includes=title  # Sadece belirli field
GET my-index/_mget                         # Çoklu GET
HEAD my-index/_doc/1                       # Var mı? (200/404)

# ═══ UPDATE ═══
POST my-index/_update/1                    # Partial update
POST my-index/_update/1 {"script": ...}    # Script update
POST my-index/_update_by_query             # Bulk update

# ═══ DELETE ═══
DELETE my-index/_doc/1                     # Tek doküman sil
POST my-index/_delete_by_query             # Bulk delete
DELETE my-index                            # Tüm index'i sil (DİKKAT!)

# ═══ BULK ═══
POST _bulk
{"index":{"_index":"my-index","_id":"1"}}
{"title":"Hello"}
{"delete":{"_index":"my-index","_id":"2"}}
{"update":{"_index":"my-index","_id":"3"}}
{"doc":{"title":"Updated"}}

Arama Komutları

// Full-text search
GET my-index/_search
{ "query": { "match": { "title": "elasticsearch guide" } } }

// Exact match (keyword)
GET my-index/_search
{ "query": { "term": { "status": "published" } } }

// Range
GET my-index/_search
{ "query": { "range": { "price": { "gte": 10, "lte": 100 } } } }

// Bool query
GET my-index/_search
{
  "query": {
    "bool": {
      "must": [{ "match": { "title": "elasticsearch" } }],
      "filter": [{ "term": { "status": "published" } }],
      "must_not": [{ "term": { "archived": true } }],
      "should": [{ "match": { "tags": "tutorial" } }]
    }
  }
}

// Multi-match (birden fazla field'da ara)
GET my-index/_search
{ "query": { "multi_match": { "query": "elastic", "fields": ["title^3", "body"] } } }

// Pagination
GET my-index/_search
{ "from": 0, "size": 20, "sort": [{ "date": "desc" }] }

// Source filtering
GET my-index/_search
{ "_source": ["title", "date"], "query": { "match_all": {} } }

// Highlight
GET my-index/_search
{ "query": { "match": { "body": "elasticsearch" } }, "highlight": { "fields": { "body": {} } } }

// Count
GET my-index/_count
{ "query": { "term": { "status": "active" } } }

Aggregation Komutları

// Terms aggregation
GET my-index/_search
{ "size": 0, "aggs": { "by_status": { "terms": { "field": "status" } } } }

// Date histogram
GET my-index/_search
{ "size": 0, "aggs": { "over_time": { "date_histogram": { "field": "date", "calendar_interval": "month" } } } }

// Stats
GET my-index/_search
{ "size": 0, "aggs": { "price_stats": { "stats": { "field": "price" } } } }

// Nested agg (terms + avg)
GET my-index/_search
{
  "size": 0,
  "aggs": {
    "by_category": {
      "terms": { "field": "category" },
      "aggs": {
        "avg_price": { "avg": { "field": "price" } }
      }
    }
  }
}

// Cardinality (unique count)
GET my-index/_search
{ "size": 0, "aggs": { "unique_users": { "cardinality": { "field": "user_id" } } } }

Index Yönetimi

# ═══ INDEX ═══
PUT my-index                               # Index oluştur
DELETE my-index                            # Index sil
POST my-index/_close                       # Index kapat
POST my-index/_open                        # Index aç
POST my-index/_forcemerge?max_num_segments=1  # Segment merge
POST my-index/_refresh                     # Manuel refresh
POST my-index/_flush                       # Manuel flush

# ═══ MAPPING ═══
GET my-index/_mapping                      # Mapping gör
PUT my-index/_mapping                      # Field ekle (var olanı değiştiremezsin)

# ═══ SETTINGS ═══
GET my-index/_settings                     # Settings gör
PUT my-index/_settings                     # Settings güncelle
{ "number_of_replicas": 2 }

# ═══ ALIAS ═══
POST _aliases
{ "actions": [
  { "add": { "index": "my-index-v2", "alias": "my-index" } },
  { "remove": { "index": "my-index-v1", "alias": "my-index" } }
]}

# ═══ REINDEX ═══
POST _reindex
{ "source": { "index": "old" }, "dest": { "index": "new" } }

# ═══ TEMPLATE ═══
PUT _index_template/my-template
{ "index_patterns": ["logs-*"], "template": { "settings": { "number_of_shards": 3 } } }

Cluster Yönetimi

# ═══ CLUSTER ═══
GET _cluster/health                        # Cluster sağlığı
GET _cluster/health?wait_for_status=green  # GREEN bekle
GET _cluster/state                         # Cluster state
GET _cluster/stats                         # Cluster istatistikleri
GET _cluster/settings                      # Cluster ayarları
GET _cluster/allocation/explain            # Allocation açıkla
GET _cluster/pending_tasks                 # Bekleyen görevler

# ═══ NODE ═══
GET _nodes                                 # Tüm node bilgileri
GET _nodes/stats                           # Node istatistikleri
GET _nodes/hot_threads                     # CPU yoğun thread'ler
GET _nodes/stats/jvm                       # JVM metrikleri

# ═══ SHARD ═══
POST _cluster/reroute                      # Manuel shard taşıma
PUT _cluster/settings
{ "persistent": { "cluster.routing.allocation.enable": "all" } }

# ═══ SNAPSHOT ═══
PUT _snapshot/my-repo                      # Repository oluştur
PUT _snapshot/my-repo/snap-1               # Snapshot al
POST _snapshot/my-repo/snap-1/_restore     # Restore et
GET _snapshot/my-repo/snap-1/_status       # Snapshot durumu

BÖLÜM C: _cat API Quick Reference

GET _cat/health?v                  # Cluster sağlığı
GET _cat/nodes?v                   # Node listesi
GET _cat/indices?v&s=store.size:desc   # Index listesi (büyükten küçüğe)
GET _cat/shards?v                  # Shard dağılımı
GET _cat/allocation?v              # Node başına disk kullanımı
GET _cat/recovery?v&active_only    # Aktif recovery
GET _cat/thread_pool?v             # Thread pool durumu
GET _cat/pending_tasks?v           # Bekleyen görevler
GET _cat/plugins?v                 # Yüklü plugin'ler
GET _cat/templates?v               # Index template'ler
GET _cat/aliases?v                 # Alias listesi
GET _cat/count/my-index            # Doküman sayısı
GET _cat/segments/my-index?v       # Segment detayları
GET _cat/fielddata?v               # Fielddata kullanımı
GET _cat/nodeattrs?v               # Node attribute'ları
GET _cat/tasks?v                   # Çalışan task'lar

BÖLÜM D: Performans Checklist

PRE-PRODUCTION CHECKLIST:
═════════════════════════

DONANIM
□ Hot tier'da NVMe SSD var mı?
□ RAM yeterli mi? (heap + page cache)
□ vm.max_map_count = 262144 mi?
□ Swap kapalı mı? (swapoff -a)
□ File descriptors ≥ 65535 mi?

ELASTICSEARCH
□ Heap ≤ 30.5 GB mi?
□ Heap = RAM × %50 mi?
□ Dedicated master node var mı? (5+ node)
□ bootstrap.memory_lock: true mi?

INDEX
□ Shard boyutu 10-50 GB arasında mı?
□ Mapping explicit tanımlı mı?
□ Gereksiz field'lar disabled mı?
□ text + keyword multi-field kullanılıyor mu?

QUERY
□ Filter context kullanılıyor mu? (score gerekmiyorsa)
□ Deep pagination yerine search_after var mı?
□ _source filtering yapılıyor mu?
□ Profiling ile yavaş sorgular tespit edildi mi?

OPERASYON
□ ILM policy tanımlı mı?
□ Snapshot/SLM kurulu mu?
□ Monitoring aktif mi?
□ Slow log açık mı?
□ Circuit breaker ayarları gözden geçirildi mi?

BÖLÜM E: Troubleshooting Flowchart

SORUN: Cluster RED
═══════════════════
GET _cluster/health
  │
  ├── unassigned_shards > 0
  │   └── GET _cluster/allocation/explain
  │       ├── "no valid shard copy" → Veri kaybı!
  │       │   └── Snapshot'tan restore ET
  │       ├── "disk watermark" → Disk dolu
  │       │   └── Eski index sil veya disk ekle
  │       └── "filter" → Node attribute uyuşmuyor
  │           └── Node config kontrol et
  │
  └── Sorun node'da
      └── GET _cat/nodes?v → Node eksik mi?
          └── Node'u başlat veya kaldır

SORUN: Yavaş Arama
═══════════════════
GET my-index/_search?profile=true
  │
  ├── Scoring yavaş → Filter context kullan
  ├── Fetch yavaş → _source filtering ekle
  ├── GC pressure → GET _nodes/stats/jvm
  │   └── Heap > %85 → Shard azalt veya node ekle
  ├── Merge yoğun → Forcemerge yap (read-only index)
  └── Thread pool rejected → GET _cat/thread_pool
      └── Search rejected > 0 → Node ekle

SORUN: Yavaş Indexing
═════════════════════
  ├── Bulk size kontrol → 5-15 MB optimal
  ├── Refresh interval → 30s veya -1 yap (bulk load)
  ├── Replica → Bulk load'da 0, sonra artır
  ├── Mapping → text field gerekli mi? keyword yeter mi?
  └── Pipeline → Ingest pipeline yavaş mı?
      └── Simulate API ile test et

Özet

Bu ders, Elasticsearch yolculuğunuzun "cep rehberi"dir:

  1. 50 mülakat sorusu, junior'dan senior'a kadar gerçek soru ve cevaplarla. Inverted index'ten BM25 scoring'e, ILM'den split-brain'e kadar her konuyu kapsar.

  2. CRUD cheatsheet — indexing, arama, aggregation, cluster yönetimi komutlarının hızlı referansı. Copy-paste hazır.

  3. _cat API referansı — cluster health, node durumu, shard dağılımı, thread pool, recovery — tüm monitoring komutları tek bakışta.

  4. Performans checklist — production'a çıkmadan önce kontrol edilecek her şey: donanım, ES config, index tasarımı, query optimizasyonu, operasyon.

  5. Troubleshooting flowchart — RED cluster, yavaş arama, yavaş indexing — her sorun için adım adım debug rehberi.

  6. Bu sayfayı kaydet, yazdır, masana yapıştır. İhtiyacın olduğunda burada.