EElasticsearch Handbook

İLERİ

Shard Stratejisi

Shard boyutu ve sayısı, cluster performansını doğrudan etkiler. Yanlış shard stratejisi en yaygın ES performans sorunlarından biridir.

Kod örneği tercihiBu sayfadaki istemci örneklerini birlikte değiştirir.

Seviye: İleri+ — Bu bölüm production deneyimi gerektirir.

Hayır Over-Sharded 10 shard x 2GB = 20GB index Çok fazla overhead Coordinating cost yüksek Memory waste, slow aggs Evet Optimal (10-50GB/shard) P0 (25GB) Primary P1 (25GB) Primary R1 (replica) R0 (replica) 2 shard x 25GB = 50GB Hızlı recovery, düşük overhead Dikkat: Under-Sharded P0 (200GB) Tek devasa shard Recovery çok yavaş (saatler) Parallelism yok Hotspot, rebalance imkansız

Karar Rehberi

DurumÖneriÖrnek veya gerekçe
Çok shard (>5/index) Uygun: Time-series (ILM rollover) Günlük log index'leri
Az shard (1-2) Uygun: Küçük-orta index Ürün kataloğu (20GB)
Custom routing Uygun: Multi-tenant isolation Tenant-per-shard SaaS
Shrink Uygun: ILM warm phase Log index consolidation
Split Uygun: Beklenmedik büyüme Viral ürün patlaması
Allocation awareness Uygun: Multi-AZ cluster Cross-AZ HA

Altın Kurallar

Kural Değer Neden
Shard boyutu 10-50 GB <10GB: overhead, >50GB: recovery yavaş
Shard/node Max 20 shard/GB heap 30GB heap = max 600 shard
Index boyutu Shard sayısı x shard boyutu 100GB index = 2-5 shard
Time-series Rollover: 50GB veya 7 gün ILM ile otomatik
Replica Min 1 (production) HA + read throughput
# Shard allocation awareness (rack-based)
curl -X PUT "http://localhost:9200/_cluster/settings" -H "Content-Type: application/json" -d'
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "rack_id",
    "cluster.routing.allocation.awareness.force.rack_id.values": "rack1,rack2"
  }
}'

# Index shard sayısını belirleme
curl -X PUT "http://localhost:9200/products-v2" -H "Content-Type: application/json" -d'
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "routing.allocation.require.data": "hot"
  }
}'

# Split index (shard artırma)
curl -X POST "http://localhost:9200/products/_split/products-split" -H "Content-Type: application/json" -d'
{
  "settings": { "index.number_of_shards": 6 }
}'

# Shrink index (shard azaltma)
curl -X POST "http://localhost:9200/products/_shrink/products-shrunk" -H "Content-Type: application/json" -d'
{
  "settings": {
    "index.number_of_shards": 1,
    "index.number_of_replicas": 1
  }
}'
// Shard health monitoring
public async Task<ShardHealthReport> GetShardHealthAsync()
{
    var response = await _client.Cluster.HealthAsync(h => h.Level(Level.Shards));

    return new ShardHealthReport(
        response.ActiveShards,
        response.RelocatingShards,
        response.UnassignedShards,
        response.ActivePrimaryShards);
}

Örnek: E-ticaret platformunda 10M ürün = ~20GB. Ideal: 2 primary shard (10GB each) + 1 replica = 4 total shard. Günlük 50M log event = ILM rollover 50GB/7 gün ile otomatik yönetim.