ElasticSearch Hosting Maliyeti/Performans Kalite Analizi (2026)

ElasticSearch (ES) arama altyapısında hız ve güncel veri gereksinimi nedeniyle maliyetler çoğu zaman sürpriz şekilde büyür. 2026’da doğru yaklaşım, "hangi paketi aldım" sorusundan önce "hangi veri modeli, shard tasarımı ve operasyonel yük" sorularını netleştirmektir. Bu rehberde ElasticSearch hosting maliyet/kalite analizini; performans göstergeleri, donanım kaynakları ve operasyonel giderler üzerinden somut bir çerçevede ele alacağız. En sonda da hangi senaryoda VDS, VPS, managed veya dedicated seçeneğinin daha düşük toplam maliyetle daha iyi sonuç verdiğini karar matrisiyle özetleyeceğiz.

ElasticSearch maliyetini asıl belirleyen 6 faktör

ElasticSearch’te aylık bütçeyi belirleyen şey yalnızca aylık sunucu ücreti değildir. Asıl maliyet sürükleyen kalemler şunlardır:

1) Veri hacmi (ingest + index) - Ham veri boyutu tek başına yeterli değildir. Index çoğalma oranı (document sayısı, mapping, analiz pipeline) toplam diski doğrudan etkiler. - Pratikte hesap yaparken “index boyutu = ham veri x çarpan” yaklaşımı kullanılır. Bu çarpan; analiz (analyzer), çok alanlı mapping, n-gram kullanımı gibi özelliklerle artar.

2) Shard sayısı ve shard boyutu - Çok küçük shard’lar disk ve hafıza üstünden overhead yaratır. - Çok büyük shard’lar rebalancing ve recovery sürelerini uzatır. - Shard sayısı doğru değilse aynı CPU/RAM ile daha kötü performans alınır; bu da ölçek maliyetini yükseltir.

3) Arama ve yazma oranı (QPS + indexing rate) - Arama (query) trafiği arttıkça CPU ve cache (özellikle filesystem cache ve query cache) etkilenir. - Indexing hızı arttıkça heap kullanımı, segment üretimi ve merge (birleştirme) maliyeti büyür.

4) I/O karakteri: yazma + okuma + merge - ElasticSearch yalnız “okur” değil; segment oluşturur ve periyodik merge yapar. - Bu nedenle depolama hızından ziyade tutarlı latency (özellikle küçük IO’larda) ve IOPS kalitesi maliyeti belirleyen ana faktör olur.

5) Heap ve GC baskısı (garbage collection) - ES tarafında yanlış tuning; yanlış heap boyutu (JVM heap) veya yoğun fielddata/kıymetli aggregations ile GC duraklamaları (stalls) yaratır. - Bu, “sunucu yetiyor” varsayımını bozar; aynı donanımda gecikme artar.

6) Operasyonel giderler: ölçek, yedekleme, izleme - Yedekleme (backup) yöntemi ve restore süresi maliyeti etkiler. - İzleme/uyarı (observability) kurulmadığında sorunlar geç yakalanır; bu da daha pahalı müdahalelere yol açar.

Donanım kalite sinyalleri: maliyet/performans nasıl okunur?

ES hosting seçerken tek ölçüt “CPU” veya “disk” olmamalıdır. Aşağıdaki göstergeler kaliteyi daha doğru temsil eder.

RAM (Heap + page cache) ve kalite etkisi

• ES için JVM heap doğrudan performansı etkiler; heap aşımı veya GC baskısı gecikmeyi büyütür.
• Ayrıca OS page cache, query performansında kritik olabilir. Çok düşük RAM ile cache hit oranı düşer.
• Bu yüzden “daha çok RAM” her zaman daha ucuz değildir; doğru heap sınırı ve node sayısı önemlidir.

CPU: query yerine düzenli indexing ve merge

• CPU; sadece sorgu işlemede değil, segment merge süreçlerinde de kritiktir.
• Yüksek CPU throttling veya az core ile merge kuyruğu uzarsa disk IO baskısı artar.

Disk: kapasite tek başına yetmez (IOPS/latency)

• NVMe vs SSD karşılaştırması çoğu zaman “IOPS” üzerinden yapılır.
• ES için asıl kritik olan; küçük isteklerde tutarlı latency ve yazma dayanımıdır.

Network: shard relocation ve node içi replikasyon

• Node ekleme/çıkarma veya arıza durumunda replikasyon ve relocation trafiği oluşur.
• Yüksek gecikme (RTT) burada recovery sürelerini uzatır; toplam maliyet “downtime + ek kaynak” olarak yansır.

ElasticSearch hosting modelleri: VDS/VPS, dedicated ve managed

ES’i barındırma seçenekleri arasında maliyet kalitesini belirleyen fark, operasyonel sorumluluktur. Aşağıdaki tabloda temel ayrım net olsun diye özetledim.

VDS/VPS ile maliyet optimizasyonu nasıl yapılır?

VDS veya VPS kullanırken ES’in maliyetini düşüren en kritik adımlar şunlardır: - Shard sayısını veri büyümesine göre planlamak (aşırı shard overhead’ı pahalıdır). - Mapping’i gereksiz alan çoğaltmadan yapmak (özellikle multi-field ve n-gram/edge n-gram). - Index lifecycle yönetimi ile eski indexleri arşivlemek. - Segment merge ve refresh ayarlarını yük profilinize göre yapmak.

Managed modelde kalite nasıl ölçülür?

Managed hizmette kaliteyi “CPU/RAM kaç”tan önce “SLA + limitler + gözlemlenebilirlik” belirler. - İnceleme: İşlem limitleri (node başına maksimum storage, thread pool limitleri vb.) ve reindex/restore performansı. - İzleme: Sağlayıcının metrikleri (heap, JVM GC, query latency percentiles) hangi seviyede sunduğu. - Yedekleme: RPO/RTO hedefleri ve restore süresi.

Maliyet hesap çerçevesi: somut bir kontrol listesi

Aşağıdaki kontrol listesi, hangi hosting modelinin daha düşük toplam maliyetle daha iyi sonuç verdiğini anlamanıza yardımcı olur. Burada “tek fiyat” yaklaşımı yerine toplam maliyeti (TCO) hedefleyin.

1) Beklenen veri hacmini netleştirin

• Günlük ingest (MB/gün) veya belge sayısı (doc/day) nedir?
• Ortalama index büyüme çarpanı nedir (tahmini)?
• Saklama süresi kaç ay? (7 gün, 30 gün, 12 ay gibi)

Örnek mantık: Saklama süresi uzadıkça disk maliyeti domine eder.

2) Query profilini çıkarın

• Arama türü: keyword arama mı, full-text mi?
• Aggregation yoğun mu? (grafik/analitik ekranlar)
• Autocomplete kullanımı var mı? (genellikle daha fazla n-gram maliyeti)

Net karar sinyali: Aggregation ve autocomplete yoğunluğu CPU + heap üzerinde daha belirleyicidir.

3) Shard tasarımını doğru hedefleyin

• Hedef shard boyutu aralığı (kılavuz olarak) recovery ve overhead dengesini etkiler.
• Node başına shard sayısı sınırlarını aşmayın.

4) Yedekleme ve restore gerçek süresini test edin

• Yedekleme yöntemi: snapshot (snapshot/restore) mi, dosya bazlı kopya mı?
• Restore süresi: “bunu en kötü senaryoda kaç saatte ayağa kaldırırım?”

5) İzleme maliyetini ihmal etmeyin

• Hangi metrikler olmadan “kalite” ölçemezsiniz? Örn: p95/p99 query latency, indexing latency, JVM heap utilization, GC süreleri.
• İzleme yoksa tuning denemeleri kör olur; bu da maliyet üretir.

ElasticSearch kalitesini sağlayan teknik ayarlar (hosting bağımsız)

Hosting seçseniz bile kaliteyi belirleyen bazı ayarlar vardır. Bu bölüm “hangi hosting daha iyi” sorusuna doğrudan bağlanır; çünkü yanlış ayarlar aynı kaynakla daha kötü performans üretir.

Shard/replica dengesini yük profilinize göre kurun

• Replica sayısı okuma performansını iyileştirebilir ama yazma maliyetini artırır.
• Arama ağırlıklı senaryolarda replica dikkatli artırılır, indexing yoğun senaryolarda gereksiz replica sayısı azaltılır.

Refresh ve indexing ayarlarını kontrol edin

• Her doküman yazımında refresh yapmak pahalıdır.
• Batch indexing yaklaşımı maliyet düşürür.

Mapping’i disiplinle yönetin

• Kullanılmayan alanları indexlemeyin.
• Çok alanlı mapping (multi-field) doğru kullanılmazsa index şişer.

Merge/segment davranışını gözleyin

• Merge kuyruğu uzuyorsa disk IO ve CPU birlikte baskılanır.
• Burada “disk büyük” tek başına yetmez; tutarlı latency şarttır.

Hangi durumda hangi hosting seçeneği daha mantıklı? (net karar matrisi)

Aşağıdaki matris, teknik ekip ve trafik profiline göre daha düşük toplam maliyet hedefler.

Senaryo A: Tek ürün, orta trafik, ekip teknik

• Tercih: Kendi kurulumlu VDS
• Neden: Tuning ve shard/mapping optimizasyonunu siz yaptığınız için aynı bütçeyle daha fazla performans elde edilir.
• Şart: İzleme + düzenli bakım (yedek, reindex, index lifecycle) süreci olmalı.

Senaryo B: Hızlı devreye alma, operasyon yükünü azaltma

• Tercih: Managed ElasticSearch
• Neden: Restore, ölçekleme ve temel sağlık kontrolleri sağlayıcı tarafından standartlaştırılır.
• Şart: Sağlayıcının metrikleri ve limitleri şeffaf olmalı.

Senaryo C: Yüksek ve dalgalı trafik + büyüme planı net

• Tercih: Dedicated veya managed (dalga başına ölçek)
• Neden: Recovery/relocation süreleri daha öngörülebilir olur.
• Şart: Node ekleme/çıkarma senaryosunda ağ gecikmesi ve storage davranışı test edilmelidir.

Senaryo D: Düşük bütçe, ama büyüme bekleniyor

• Tercih: İlk aşamada VDS, ölçekleyince managed/dedicated
• Neden: İlk maliyeti kontrol altında tutup, büyüdüğünüzde operasyon yükünü azaltmak daha rasyoneldir.
• Şart: Shard tasarımını büyümeye uygun yapın; yanlış shard ile migrasyon maliyeti büyür.

NetKıyas’ta arama yaparken bakmanız gereken kriterler

NetKıyas tarzı karşılaştırmalarda ES için “paket özellikleri” kadar “performansı etkileyen altyapı” da önem taşır. Aşağıdaki filtreler pratikte belirleyicidir:

• Storage türü: NVMe/SSD ve IOPS/latency bilgisi
• Kaynak izolasyonu: Tek tenant mı, oversell var mı?
• RAM ve CPU garantisi: vCPU oversubscription var mı?
• Backup: snapshot destek var mı, yedekleme sıklığı ve restore süresi
• Network: bant genişliği ve egress/ingress maliyetleri
• İzleme: temel metrikler ve log erişimi (varsa)

Not: ElasticSearch performansının kritik kısmı çoğu zaman IO tutarlılığıdır. Bu nedenle “disk kapasitesi” ve “kâğıt üstü IOPS” yerine mümkünse gerçek test verisini esas alın.

Sonuç: Aksiyona dönüşen yaklaşım

ElasticSearch hosting maliyet/kalite analizini en hızlı netleştiren adım, veri hacmi + query profili + shard hedefiyle başlayıp sonra barındırma modelini seçmektir. Eğer teknik ekip var ve izleme/backup disiplini kurabiliyorsanız VDS ile maliyeti aşağıda tutup performansı tuning ile yükseltirsiniz. Operasyon yükünü minimize etmek istiyorsanız managed ElasticSearch daha düşük riskle devreye alınır; fakat metrik/limit/restore performansını sözleşmeli ve ölçülebilir biçimde doğrulayın. Şimdi ilk aksiyon olarak; saklama sürenizi, günlük ingest’inizi ve p95/p99 arama gecikmesi hedefinizi yazın; ardından bu hedefleri NetKıyas karşılaştırmalarında storage + RAM + network + yedekleme kriterleriyle eşleştirin.