Elasicsearch Kullanım Tecrübemiz #1

Published in

Apinizer

11 min readNov 11, 2020

Apinizer - Full API Lifecycle Management & Integration Platformumuzun yenileme çalışmalarında 1.versiyondan beri kullanmakta olduğumuz Elasticsearch (v6.3.1) yerine daha uygun ve kullanılabilir bir log veri tabanı olup olmadığını araştırdık.

Bu araştırmaları yaparken gereksinimlerimiz şunlar oldu:

Platformumuzda yaklaşık günlük 15 milyon mesajın request, response ve metrikleriyle beraber kayıt altına alınması gerekmekteydi.
Kayıt altına alınan bu verilerin anlamlandırılması, uygun alanları üzerinde full-text-search arama yapılabilmesi ve metrik verileri ile raporlar ve grafikler oluşturulması gerekliydi. Bu sebeple uygun veri tabanlarını aramaya ve birbirleri ile kıyaslamaya başladık.
Kıyaslama yaparken en önemli nokta, nedense müşterinin donanım kaynaklarının hep kısıtlı olması ve fakat sorguların performanslı çalışmasının istenmesiydi. (¯\_(ツ)_/¯)
Veri kaybının müşterilerimiz için önemli olmadığının da altını çizmek isterim.

Bu kapsamda yaptığımız çalışmaları aşağıda özetlemeye çalıştım.

Seri İçeriği🔵️ Elasticsearch Kullanım Tecrübemiz #1
   Aşama 1: Couchbase & InfluxDb & Elasticsearch hangisi bizim için doğru karar?
   Aşama 2: Bizim için doğru Elasticsearch ayarı nedir?⚪️ Elasticsearch Kullanım Tecrübemiz #2 
   Aşama 3: Performans Testleri⚪️ Elasticsearch Kullanım Tecrübemiz #3
   Aşama 4: Shard ve Disk Boyutu
   Aşama 5: Önemli Kontroller

Aşama 1: Couchbase & InfluxDb & Elasticsearch hangisi bizim için doğru karar?

Couchbase (v6.0.0)

Tune ayarı yapılmadan varsayılan konfigürasyon ile 1 milyon dokümanda en çok kullandığımız SQL/sorguların performansını Couchbase ve Elasticsearch üzerinde test ettik.

Couchbase’in olumlu yanı;

Elasticsearch, match ve aggregation sorgularında, Couchbase ise term ve prefix sorgularında açık bir farkla daha hızlı cevap vermiştir.

Couchbase’in bizim açımızdan olumsuz yanları;

Dokümantasyonun yeterli ve açıklayıcı olmaması,
Community desteğinin yeterli bulunmaması,
Full-text arama yapma ve aggregation sorgularında Couchbase’in performansının Elasticsearch’e göre geride kalması.

Sonuç;

Full-text arama yapma ve aggregation sorguları platformumuzda daha çok kullanılmaktadır ve ekibimizin yeteri kadar Couchbase tecrübesi bulunmamaktadır. Bu sebeble Elasticsearch yerine Couchbase kullanmamızın bizim için bir avantajı olmayacağı görülüp elenmiştir.

InfluxDb (v1.7)

Diğer incelenen veritabanı ise InfluxDb oldu. Yapılan araştırmalar sonucunda write işlemlerinin, disk üzerinde sıkıştırma ve sorgulama performansı olarak Elasticsearch ile kıyaslandığında bariz bir şekilde daha performanslı olması bizi şaşırttı ve InfluxDb’yi kullanmaya başladık. (Bu linke tıklayarak örnek bir benchmark sonuçlarına bakabilirsiniz.) İncelediğimiz süreçte karşılaştığımız ve bizim açımızdan InfluxDb’nin olumsuz yanları şöyle oldu;

Dokümantasyonun yeterli ve açıklayıcı olmaması,
Community desteğinin yeterli bulunmaması,
Metin üzerinde full-text-search yapılamaması,
Açık kaynaklı versiyonunda cluster yapısını desteklememesi.

Sonuç;

Log yoğunluğu fazla olan orta ve büyük ölçekli müşterilerimizde kullandığımız tüm teknolojilerin genişleyebilir olması bizim için önemli bir kriter olduğundan bu eksikliği sebebiyle InfluxDb elendi. Belki bu imkan olsaydı full-text search için hibrit bir çözüm düşünülebilirdi.

Elasticsearch (v7.9.2)

Sonuç olarak; cluster yapısına izin vermesi, kolay yönetilmesi, full-text arama yapma imkanına sahip olması, sorgularının performanslı çalışması, çok detaylı dökümantasyon ve etkin community desteği olmasından dolayı açık kaynak kodlu olan Elasticsearch kullanımını bir kez daha seçtik (biraz da sempatimiz vardı 😄). Ayrıca gördük ki attığımız taş, ürküttüğümüz kuşa değmeyecekti.

Aşama 2: Bizim için doğru Elasticsearch ayarı nedir?

Bu aşamada, “Elasticsarch’ün performansını artırmak ve verimli kullanmak için hangi işlemler yapılmalı?” sorusuna cevap aramak için literatüre baktık. Yaptığımız araştırmalar sonucu aşağıdaki maddelerin uygulanmasına karar verdik:

➡️ Indeks yönetimini Indeks Yaşam Döngüsü poliçeleri ile otomatikleştirme

Yenileme çalışmalarından önce Apinizer’da indeksler “date math” tanımıyla günlük oluşturulmaktaydı. Böylelikle son 5 günün verilerinde arama yapma, son 1 ayın dokümanlarını yedekleme, indekse bakım yapma gibi işlemler daha kolay yönetilmekteydi.

Date math yönetimiyle oluşturulan örnek bir indeks adı; 
# <indeksin_statik_adı{date_math_tanımı|istege_bagli_olarak_time_zone} 
# <apiproxylogs{now/d{yyyMMdd}} 
# Şuan ki zaman 26.12.2019 ise bugünün dokümanlarının tutulacağı indeks adi: apiproxylogs20191226

Bu yaklaşım yerine, Elasticsearch veri saklama süresine göre indeksleri otomatik olarak Index Lifecycle Management (ILM) poliçeleri ile yönetme imkanı verdiği için bunu uygulamaya karar verdik. ILM poliçesi sayesinde indekslere rollover (yeni indeks oluşturma), merge (indeksin segment sayısını düşürme), shrink (indeksin shard sayısını azaltma), delete (indeksi silme) vs. işlemleri uygulanır. Bu işlemleri otomatik hale getirmek için Curator kullanılabilir. Fakat bizim platformumuzda tüm bileşenler embedded kullanıldığından ve hepsini biz yönettiğimiz için ayrıca yeni bir cephe açmak istemedik. 😊

# ILM poliçesini manuel oluşturmak için yapılan örnek bir istek;
PUT _ilm/policy/apinizer-log-ilm-policy
{
 "policy": {
  "phases": {
   "hot": {
    "actions": {
     "rollover": {
      "max_age": "1d",
      "max_size": "30gb",
      "max_docs": 15000000
      }
     }
    },
   "warm": {
    "actions": {
     "readonly": {},
     "allocate": {
      "number_of_replicas": 0
     },
     "shrink": {
      "number_of_shards": 1
     },
    "forcemerge": {
     "max_num_segments": 1
     }
    }
   },
   "cold": {
    "min_age": "30d",
    "actions": {}
   }
  }
 }
}# Poliçe adına göre bilgilerini çağırma;
GET _ilm/policy/apinizer-log-ilm-policy# Indekse uygulanan poliçe süreçlerinin kontrol etme;
GET indeks_adi/_ilm/explain

ILM, zaman tabanlı (time-series) ya da metrik verilere hot-warm-cold mimarisi uygulayarak indeksleri yönetir. Indeksler yaşlandıkça bu fazlardan geçer ve fazlardaki aksiyonlar gerçekleştirilir. Genellikle poliçe, indekse template ile eklenir. Böylece yeni indekse, poliçe otomatik olarak uygulanır. Template’de verilen indeks deseni (index_pattern) ile eşleşen istek yapıldığında indekse template ve poliçe uygulanmış olur.

min_age, indeksin faza girmesi için kullanılan parametredir. Bu değer geçilmeden faza girilemez. Log verilerin tutulduğu indeksimiz de 3 tane faz işletiyoruz. Şöyle ki;

1.Hot faz:

Bu fazda, indekslere aktif olarak create/update/search işlemleri uygulanır.

Rollover

Bu eylem, disk kullanımını iyileştirmek için indeks belirli bir boyuta (max_size), doküman sayısına (max_docs) veya bir yaşa (max_age) eriştiğinde yeni bir indekse yazma işlemini başlatır. Buradaki değerlerin neye göre atandığı 3. yazı serisinde yer almaktadır.

2.Warm Faz:

Bu fazdaki eylemler artık güncellemenin yapılmadığı, sadece sorgu çalıştırılan indekslere uygulanır.

Readonly

Bu fazla çalışan diğer eylemlerin gerçekleştirimi için indekse yazma işlemi kapatılmalıdır. Çünkü kullanım performansı daha da kötüye gidebilir.

# Bu işlemin manuel olarak yapmak için gönderilen istek:
PUT indeks_adi/_settings
{
 "index": {
  "blocks.read_only": true
 }
}

Allocate

Bu fazda oluşacak indeksin replica shard sayısını, indeks için belirtilmiş olan template’den değil, bu eylem ayarında atanan değerden alır.

Force Merge

Segmentler yani inverted indeksler disk üzerindeki fiziksel dosyalardır. Sorgular inverted indeks üzerinde yapılıp, sonuclar shard’a gönderilir. Çok fazla segmentin olması ya da büyük boyuttaki shardlar sorgu süresinin uzamasına sebep olabilir. Force merge API, bir veya daha fazla indeksin bulunduğu shardları birleşmeye zorlar, birleşme işlemi sonucu segment sayısı azalır. Bu işlem sırasında silinen dokümanlar tamamen kaldırılır ve disk alanında boş yerler oluşur. Çünkü silinen dökümanlar segment üzerinde silindi olarak işaretlenir, fiziksel olarak kaldırılmaz. Yapılan bir araştırmada, 2.2 gb boyuta sahip indeks birleştirilikten sonra yaklaşık 510.9 mb’a düşmüştür. Bu da ciddi anlamda diskten yer kazanılabileceği anlamına gelir.

Normalde bu işlemi, Elasticsearch otomatik olarak gerçekleştirir. Ama bazen manuel olarak da tetiklenmesi gerekebilir. Çünkü merge işlemi, hem kaynak kullanımını iyileştirir, hem de merge edilen indeksler üzerinde daha etkili bir yapı sunduğu için arama hızının artmasını sağlar. Eğer bu işlem manuel yapılacaksa write işlemi bitmiş indeksler üzerinde uygulanmasına dikkat edilmelidir. Eğer bu işlem manuel olarak yönetilecekse, işlem sırasında da çok fazla kaynak tüketilebileceği için node’un CPU ve diski az kullandığı zamanlarda yapılmalıdır.

# Bu işlemin manuel olarak yapmak için gönderilen istek:
POST indeks_adi/_forcemerge?max_num_segments=1# Merge işlemindeki segmentleri izlemek için:
GET _cat/segments/indeks_adi?v

Shrink

Disk kullanımını iyileştirmek için mevcut bir indeksteki shard sayısı azaltılarak yeni bir indeks oluşturulabilir. Örneğin, 8 shard’ı bulunan bir indeks, 1 shard’a indirilebilir.

3.Cold Faz:

Indeks üzerinde update işlemleri yapılmaz, sorgulamanın da çok nadir yapıldığı aşamadır. Dolayısıyla sorgular daha yavaş çalışır. Burada indeks, daha az performanslı ve maaliyeti düşük donanıma taşınabilir.

4.Delete Faz:

İhtiyaç olmayan indeks kalıcı olarak silinir. Trace loglarının tutulduğu indekse bu fazı uyguladık. Çünkü bu indekslerde hem daha çok veri tutulmakta hem de verilere ihtiyaç süresi daha kısa olmaktaydı. Disk alanından yer açmak için bu fazı etkinleştirdik.

# Örnek bir ILM poliçesinin delete faz kısmı;
# Burada şu noktaya dikkat edilmelidir; rollover olduktan 30 günden sonra indeksi siler. min_age değeri indeksin oluşturulduğu zamanı değil, rollover zamanı baz alır."delete": {
 "min_age": "30d",
  "actions": {
   "delete": {}
 }
}

➡️ Indeksin zaman alanına göre sıralı tutulması

Her bir shard, bir Lucene Indeksine denk gelir. Her Lucene indeksinin içinde de segmentler yer alır. Yeni bir indeks oluşturulduğunda segmentlerin hangi sırayla shard’da olacağı konfigüre edilebilir çünkü varsayılan olarak Lucene herhangi bir sıralama yapmaz. Sıralama kriteri baz alınarak bir sorgu isteği gönderildiğinde de sorguyla eşleşen tüm dokümanları geri getirerek üzerinde istenen sıralama işlemini uygular.

Dokümanlar sıralandığında, sorgu isteğinde örneğin ‘size:20’ denildiğinde sıralama belli olduğu için Elasticsearch her segmentteki ilk 20 dokümana bakar ve eşleşen sonuçları birleştirerek getirir.

Diğer bir örnek: date tipindeki alan üzerinden (bizde @timestamp alanı), date-range filter sorgusunda belirli tarih aralığına göre listeleyerek cluster’daki tüm veri kümesi yerine daha küçük bir veri kümesi üzerinde sorgulama yapılacaktır. Bu, sorgunun daha hızlı çalışmasını sağlar. Uygulamamızda sorgularımızı @timestamp alanına göre yaptığımız için bu alana göre azalan sıralama (descending) yapılmasını öngördük.

# Manuel olarak indeks sıralama isteği:
PUT indexadi
{
 "settings" : {
  "index" : { 
   "sort.field" : "@timestamp",
   "sort.order" : "desc"
  }
 },
 "mappings": {
  "properties": {
   "@timestamp": {
    "type": "date"
    }
   }
  }
}

➡️ Dokümandaki alan adlarının kısaltılması

Disk boyutundan yer kazanmak için örneğin ‘apiProxyName’ gibi alan adlarının ‘apn’ gibi kısaltılarak indekslenmesine karar verdik. Yaklaşık 2.7 kb boyutuna sahip bir dokümanımızın alan adları kısaltılarak, aynı dokümanın boyutu 2.1 kb’a düşürülmüştür. Alan adlarında kısaltma yapılan indeks ile alan adlarında kısaltma yapılmayan indekse 1 milyon doküman eklendiğinde, iki indeks arasında 658 mb’lık fark olmuştur.

➡️ Daha küçük sayısal veri tipini kullanma

Disk alanının kullanımını önemli derece etkilediği için sayısal tipteki alanlar için veri tipi olarak en düşük yer tutan tip kullanılacaktır. Durum 3, başlığı altında detayları yer almaktadır.

➡️ String tipindeki alanın indekslenmesi

Mapping dışında bir string tipini tutan alan indekslendiğinde hem text hem de keyword tipinde tutulur. Eğer alan üzerinde full-text araması yapılacaksa analyzer işlemi uygulanacağı için bu alana text tipi verilmelidir. Eğer id, hata tipi gibi analyzer işleminden geçmesi gerekmeyen alanlar varsa tipi keyword olmalıdır. Bu durum disk kullanımını iyileştirir. Eğer dinamik olarak gelen alanlar varsa dynamic template oluşturarak string bir değere varsayılan veri tipi ataması yapılabilir.

➡️ Match sorgusu yerine Filter sorgusu kullanma

Match sorguları yaparken sonucun evet/hayır olarak cevaplanması yetiyor ise ‘filter’ sorgusu kullanılmalıdır. Hem de filtre sorgusunun sonuçları cachelenir. Yoksa sorgu, relevancy score değeri hesaplanarak sonuçlanır. Bu da arama performasını etkilemektedir.

# Aşağıdaki istek ile node query cache kontrol edilebilir
GET indeks_adi/_stats?filter_path=indices.**.query_cache

➡️ Sorgunun cachelenmesi için rounded date math değerlerini kullanma

Mesela now değeri dinamik olarak değiştiği için cachelenmez. Ama bir saat önceki verileri isterken rounded tarih kullanarak sorgu cache’den çalıştırılabilir. Varsayalım ki, range query üzerinde mevcut zamandan (16:31:29) bir saat öncesi üzerinde arama yapmak için ‘now-1h’ yerine ‘now-1h/m’ tanımıyla arama yapılsın. 15:31:00–16:31:59 zaman aralığındaki tüm değerleri eşleştirir. Aynı dakikada bu arama yapıldığında ‘query cache’ sorgunun hızlı çalışmasını sağlar. Biz de sorgularımızı buna göre tekrar oluşturduk/düzenledik.

PUT indeks_adi/_search
{
  "query": {
   "constant_score": {
    "filter": {
     "range": {
       "created": {
        "gte": "now-1h/m",
        "lte": "now/m"
     }
    }
   } 
  }
 }
}'

➡️ Aggregation sorgusunun cachelenmesini

Aggregation sorgusu çalıştırıldığında, sonuçların cachelenmesi arama performansını iyileştirir. Bunun için şunlara dikkat edilmelidir; Sorgudan hit değeri dönmemesi için ‘size:0’ değeri verilmelidir. Yoksa hit değeri olan sorgu cachelenmez. İsteğin gövdesi değişmemelidir. Ve varsa sorguda rounded date bilgisi kullanılmalıdır.

# Aşağıdaki ile shard query cache kontrol edilebilir
GET indeks_adi/_stats?filter_path=indices.**.request_cache

➡️ Shard & Replica sayısının ayarlanması

Indeksin replica sayısının ayarlanması kritik bir noktadır. Çünkü avantajı olduğu gibi dezavantajı da olabilir. Replicalar, shard’ın kopyası olduğu için hem verinin erişilebilir olmasını hem de sorguların daha performanslı olmasını sağlar. Dezavantajı ise; indekslenen aynı verilerin replicaya alınması indeksleme hızını ve arama performansını düşürür. Bunun için ideal bir değer verilmesi önerilmektedir.

Mesela 2 node bulunan cluster’da 2 shard ve 0 replicaya sahip indeks ile 2 shard ve 2 replicaya sahip başka bir indeks, oluşturulduğunu varsayalım. Node başına shard sayısı az olan indeks üzerinde daha hızlı işlem yapılır. Ama replica 0 olan indekste de 1 node hata verdiğinde veri kaybı yaşanabilir. (Tekrar hatırlatmak isterim ki, veri kaybı müşterimiz için önemli değildir.)

Burada belirleyici daha çok müşteri ve veri büyüme hızımız oldu. Default olarak shard sayısına 1, replika sayısına 0 dedik. Bu sayede, indeks yaşam döngüsünde faz değişimleri esnasında yapılacak olan shrink işleminin performansını oldukça optimize ettik.

# Bu işlemin manuel olarak yapmak için gönderilen istek:
PUT indeks_adi
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 0
    }
  }
}'

➡️ Indeks yenilenme süre aralığı

Indeks yenilenme süresi index.refresh_interval özelliği eklenerek ayarlanır ve varsayılan değeri 1 saniyedir. Bu değer artırıldığında, merge/create operasyonlarının maaliyetini düşürür. Bu değer verilirken yenileme yapıldıktan sonra dokümanlar üzerinde arama yapılacağı unutulmamalıdır. Bu değerin artırılması segment sayısının azalmasına ve arama için I/O maaliyetinin azaltılmasına yardımcı olur. Her refreshde veriler değiştiğinden önbekllekleme geçersiz olacaktır. Elasticsearch’in önbelleği daha verimli kullanmasını da sağlayabilir. Biz yenilenme süre aralığını 15 saniye olarak belirlesek de, kullanıcının gerçek zamanlı olarak veri analizine ihtiyacı olabileceği için konfigure edilebilir hale getirdik.

# Aşağıdaki istekten kaç segment olduğu ve merge/refresh için ne kadar zaman harcandığı kontrolleri yapılabilir.
GET indeks-adi/_stats?filter_path=indices.**.refresh,indices.**.segments,indices.**.merges

✌ ⭐️ Ek olarak;

Bu başlık altında, dikkat ettiğimiz bazı durumlar ve bizim koşullarımıza uymasa da faydalı bulduğumuz ve sonrasında yararlanabiliriz diye düşündüğümüz diğer ayarlar yer almaktadır.

Parent-child ilişkili dokümanlar üzerinde arama yapma ve nested aggregation sorgusu sorgulama süresini artırabilir. Bu durumlardan uzak durduk. Veri yapımızın tasarımını buna göre modelledik.
Büyük boyuttaki dokümanlar üzerinde işlem yapılıyor ve dokümandaki birkaç alanın geri dönmesi yeterli ise arama performansının optimizasyonu için “stored_fields” mapping parametresi kullanılabilir.
Stop words (a, the, ve, vs.) sorgunun patlamasına sebep olabilir. Mesela “fox” olarak arama yapıldığında onlarca yüzlerce doküman gelebilir. Ama “the fox” olarak arama yapıldığında “the” kelimesini tüm dokümanlar içebileceği için tüm sistemi yavaşlatabilir. Stop words üzerinde aramayı durdurmak için Stop Token Filter kullanılabilir.
Bulk isteklerini yaparak aynı anda tek dokümanın bulunduğu istek yerine birden fazla dokümanın bulunduğu istek daha yüksek performans sağlamaktadır. Çünkü istek başına düşen yükü azaltır. Eğer bulk gibi tek istekte yüklü indeksleme yaparken indeksleme hızını artırmak isteniyorsa index.refresh_interval özelliğine -1 değeri atanabilir. Ama bu durum geçici olmalı, çünkü veri kaybına yol açabilir.
Force Merge API’yi çağırdıktan sonra eğer replica shardlar varsa cluster recovery hızını iyileştirmek için Synced Flush API çağırılır. Bu API, bir veya daha fazla indeks üzerinde synced olarak flush işlemini gerçekleştirir. Synced flush, devam eden indeksleme işleminde de gerçekleştirilebilir. Time-based indekslerde, seyrek olarak güncellenen ve çok sayıda indekse sahip cluster’lar için önerilmektedir.
Eğer enumerable bir veri tipi (örneğin US, Euro vs. değeri atanan region alanı) üzerinden sorgular filtreleniyorsa, indeks bu alanın değerlerine göre birden çok indekse bölünebilir. Böylece arama isteğinden filter sorgusu kaldırılmış olur. Eğer birden fazla indeks üzerinde sorgulama yapılmak istenirse wildcard’lardan yararlanılabilir.
Filtre sorgusunun değeri enumerable değilse ve indeks birden fazla shard’a sahipse custom routing kullanılabilir. Mesela sorguların userId değeri üzerinden filtrelenmeye ihtiyacı var. Her alıcı için indeksi bölmek imkansız. Aynı userId ile indeksleme yapıldığında aynı shard’a dokümanın yerleştirilmesi için routing kullanılabilir. Dolayısıyla sorgular routing key ile eşleşen shard içinde çalışır. Birden fazla shard’a sahip indeksler için yapılacak kontroller; 1-Id ya da routing key ile indeksleme yapıldığında shard üzerinde dokümanlar eşit olarak yerleştirildiğinden emin olunmalıdır. Yoksa bir shard’ın diğerinden büyük olması okuma/yazma işlemlerinin yavaş çalışmasına neden olur. 2-index.routing_partition_size ayarına dikkat edilir. Farklı nodelar üzerinde dağıtılan shardların eşit dağıtıldığından emin olunmalıdır. Yoksa diğer düğümlere göre fazla shard olan node, diğer düğümlere göre daha fazla yük alır.
Çok fazla girdi-çıktı işlemleri varsa kaynak tüketimi artacağı için hızlı donanımlar tercih edilmelidir. Spinning disk yerine SSD kullanmak gibi. (Saniyede 10k isteğin handle edildiği donanımlara bakmak için tıklayınız.)
query_string ve multi_match gibi bazı sorgular yavaş çalışmaktadır. Bu yüzden, mümkün olduğunca az alan üzerinde arama yapılabilir.
index:false özelliği sadece histogram yapılacak ise kullanılabilir. Sorgu cevaplandığında bu değerin fetch edilmesi için alan, source parametresinin includes dizisine atanmalıdır. Bu durum disk boyutundan kazanç sağlamaktadır.
Terms aggregation, range aggregation’a göre daha hızlı çalışmaktadır. Mesela ‘price’ alanına 0–2000, 2000–5000, 5000-~ değerleri üzerinden range sorgulama yapılıyor olsun. Bunun yerine ‘price_range’ adında bir alan ekleyip price değerinin aralığını tutsak, böylece range sorguya gerek kalmaz, ‘price_range’ alanı üzerinden terms aggregation çalıştırılabilir.
Eğer alan üzerinde aggregation, sort, script yapılmayacaksa ve sorgular çalıştırıldığında fetch edilmeyecek ise disk boyutunu iyileştirmek için doc_values:false parametresi eklenebilir.
index.codec:best_compression özelliği ile _source yer alan alanların sıkıştırılması disk alanını iyileştirmek için kullanılabilir. Fakat arama hızını düşüreceği için dikkatli kullanılmalıdır.
Sorgu hızını düşürebileceği için scriptlerden kaçınılması tavsiye edilmiştir. Eğer ihtiyaç varsa painless ya da expression script dili kullanılabilir.

👉 Bir sonraki yazıda, performans testlerimizden ve çıkardığımız sonuçlardan bahsettik.