Elasticsearch Index Design: Mapping, Sharding and Data Modeling

Introduction

Elasticsearch cluster kurmak başlangıçtır.

Gerçek zorluk:

veriyi doğru modellemek ve doğru index tasarlamaktır

Bu bölümde:

• index yapısı
• mapping tasarımı
• analyzer kullanımı
• shard planlama
• veri modelleme

production perspektifiyle ele alınacaktır.

What is an Index?

Elasticsearch’te index, klasik veritabanındaki “table” değildir.

Gerçekte:

Index = Distributed Lucene Engine

Bir index:

• birden fazla shard’a bölünür
• her shard bağımsız bir Lucene index’tir
• shard’lar farklı node’lara dağıtılır
• query’ler shard’lar üzerinde paralel çalışır

Bu yüzden:

Index tasarımı sadece veri modeli değil, cluster davranışıdır

Mapping: Schema Design

Mapping, Elasticsearch’te veri tiplerini ve indexleme davranışını belirler.

Örnek:

PUT news_articles
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "fields": {
          "keyword": { "type": "keyword" }
        }
      },
      "content": { "type": "text" },
      "author": { "type": "keyword" },
      "publication_date": { "type": "date" },
      "tags": { "type": "keyword" }
    }
  }
}

Why Mapping is Immutable?

Elasticsearch’te mapping büyük ölçüde immutable’dır.

Aşağıdakiler değiştirilemez:

• field type (text → keyword)
• analyzer
• field structure

Bu yüzden:

Mapping değişikliği = reindex

Critical Rule

“Mapping hatası production’da en pahalı hatadır.”

Gerçek senaryo

author alanı yanlışlıkla text olarak tanımlandı:

"author": { "type": "text" }

Sonuç:

• aggregation çalışmaz
• sorting yanlış olur
• fix edilemez

Çözüm:

• yeni index oluştur
• tüm veriyi reindex et

Production etkisi:

• saatler sürebilir
• disk maliyeti artar
• riskli operasyon

Field Type Decision Framework

Field type seçimi rastgele yapılmaz.

Aşağıdaki karar mekanizması kullanılmalıdır:

1. Full-text search var mı?
→ Evet → text
2. Exact match / filter / aggregation var mı?
→ Evet → keyword
3. Her ikisi de var mı?
→ Multi-field (text + keyword)
4. Sorting yapılacak mı?
→ keyword zorunlu

Text vs Keyword (Deep Understanding)

text

• analyzer’dan geçer
• tokenize edilir
• full-text search içindir

Örnek:

"Elasticsearch Cluster Design"
→ ["elasticsearch", "cluster", "design"]

keyword

• tokenize edilmez
• exact match içindir
• aggregation ve sorting için kullanılır

Best Practice: Multi-field

"title": {
  "type": "text",
  "fields": {
    "keyword": { "type": "keyword" }
  }
}

Bu yapı:

• search (text)
• aggregation (keyword)

ikisini birlikte sağlar.

Analyzer Logic

Analyzer, text veriyi indexlenebilir hale getirir.

3 aşama:

1. character filter
2. tokenizer
3. token filter

Custom Analyzer Example

PUT my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "custom_text_analyzer": {
          "tokenizer": "standard",
          "filter": ["lowercase", "stop"]
        }
      }
    }
  }
}

Production Insight

Default analyzer çoğu zaman yeterli değildir.

Özellikle:

• dil bazlı içerik (Turkish, English)
• search quality beklentisi

durumlarında:

analyzer tuning zorunludur

Sharding Strategy

Shard, Elasticsearch’ün en kritik bileşenidir.

Her index:

• primary shard’lara bölünür
• her primary shard’ın replica’sı olabilir

Shard Size Rule

1 shard ≈ 20–50 GB

Neden?

Küçük shard:

• fazla metadata overhead
• memory tüketimi artar

Büyük shard:

• recovery yavaş
• rebalancing zor
• latency artar

Shard Count Trade-off

Az shard:
+ düşük overhead
- düşük paralellik

Çok shard:
+ yüksek paralellik
- yüksek memory kullanımı
- cluster yönetimi zor

Replica Logic

Replica shard:

• high availability sağlar
• read throughput artırır

Örnek:

3 primary + 1 replica = 6 shard

Why Replica Matters?

Node kaybı durumunda:

• replica → primary olur
• sistem çalışmaya devam eder

Hot Shard Problem (Critical)

Yanlış shard dağılımı ciddi problemlere yol açar.

Gerçek senaryo

Shard routing key:

user_id

Ama bazı user’lar çok fazla veri üretir:

Sonuç:

• veri tek shard’da yoğunlaşır
• o shard “hot shard” olur

Belirti:

• tek node yüksek CPU
• latency artışı
• dengesiz cluster

Bad Mapping Scenarios

Yanlış

"title": { "type": "keyword" }

→ search çalışmaz

Yanlış

"author": { "type": "text" }

→ aggregation bozulur

Doğru

"title": {
  "type": "text",
  "fields": {
    "keyword": { "type": "keyword" }
  }
}

Dynamic Mapping Risk

PUT index
{
  "mappings": {}
}

Risk:

• field tipleri otomatik belirlenir
• kontrol kaybolur
• yanlış mapping oluşur

Data Modeling Strategy

Elasticsearch relational değildir.

JOIN yoktur.

Bu yüzden:

Denormalization zorunludur

Example

Relational:

user → post → comment

Elasticsearch:

{
  "user": "john",
  "post": "...",
  "comments": [...]
}

Key Design Principles

• query-first düşün
• aggregation ihtiyaçlarını önceden belirle
• mapping’i explicit tanımla
• shard sayısını başta doğru seç
• reindex maliyetini hesaba kat