Elasticsearch:Teknik özellikleri ve depolama kapasitesini değerlendirin

Dikkat edilmesi gerekenler

Bu konuda sunulan değerlendirme yöntemleri, gerçek test sonuçlarına ve kullanıcı deneyimlerine dayanarak elde edilmiştir. Farklı kullanıcıların veri yapısı, sorgu karmaşıklığı, veri hacmi, performans ve veri değişiklikleri konusunda farklı gereksinimleri olabilir. Bu konu yalnızca referans amaçlıdır. Elasticsearch kümeniz için teknik özellikleri ve depolama kapasitesini gerçek verilerinize ve iş senaryolarınıza göre değerlendirmenizi öneririz.

Depolama alanı değerlendirmesi

Bir Elasticsearch kümesinin depolama alanı aşağıdaki faktörler tarafından belirlenir:

• Kaynak veri hacmi.

• Çoğaltma parçası sayısı: Her birincil parçanın en az bir çoğaltma parçası olmalıdır.

• Dizinleme ek yükleri: Çoğu durumda dizinleme ek yükleri, kaynak verilerinkinden %10 daha fazladır.

  Örneğin, X-Pack tarafından istisna analizi için kullanılan izleme dizinleri dizinleme ek yükleri oluşturur. İzleme dizinleri aşağıdaki türleri içerir:

  • .monitoring-es-6-*: Bu tür dizin büyük miktarda depolama alanı tüketir. Varsayılan olarak Elasticsearch yalnızca son yedi gün içinde oluşturulan dizin verilerini saklar.

  • .monitoring-kibana-6-*: Bu tür dizin tarafından tüketilen depolama alanı miktarı, dizin sayısıyla birlikte artar. Varsayılan olarak Elasticsearch yalnızca son yedi gün içinde oluşturulan dizin verilerini saklar.

  • .watcher-history-3-*: Bu tür dizin yalnızca küçük miktarda depolama alanı tüketir. Bu tür dizinlere artık ihtiyaç duyulmuyorsa dizinleri manuel olarak silebilirsiniz.

• Elasticsearch kümesinin dahili ek yükleri: Parça birleştirme ve günlük kaydı gibi dahili işlemler dizinleme ek yükleri oluşturur. Bu ek yükler için depolama alanının %20'si ayrılmıştır.

  Küme günlükleri tarafından tüketilen depolama alanı miktarı, Elasticsearch kümesinin aldığı sorgu ve veri gönderimi sayısıyla birlikte artar. Küme günlükleri çalışma günlüklerini, erişim günlüklerini ve yavaş günlükleri içerir. Varsayılan olarak Elasticsearch yalnızca son yedi gün içinde oluşturulan günlükleri saklar. Süre değiştirilemez.

• İşletim sistemi tarafından ayrılan depolama alanı: Varsayılan olarak işletim sistemi, kritik işlemler, sistem kurtarma ve disk parçalanması için depolama alanının %5'ini ayırır.

• Güvenlik eşiği ek yükleri: Elasticsearch, güvenlik eşiği olarak depolama alanının en az %15'ini ayırır.

Önerilen depolama alanı aşağıdaki formül kullanılarak hesaplanır:

Recommended storage space of the cluster = Volume of source data × (1 + Number of replica shards) × Indexing overheads/(1 - Storage space reserved by the operating system)/(1 - Internal overheads of the cluster)/(1 - Security threshold overheads)
             = Volume of source data × (1 + Number of replica shards) × 1.7
             = Volume of source data × 3.4

Parça ayarları arasında yalnızca çoğaltma parçası sayısı yukarıdaki formülün sonucunu etkiler. Birincil parça eklemek disk kullanımını artırmaz çünkü mevcut veriler yalnızca daha fazla parça arasında yeniden dağıtılır ve toplam veri hacmi değişmez. Çoğaltma parçası eklemek, her çoğaltma parçası verinin tam bir kopyasını depoladığından disk kullanımını çoğaltma sayısıyla orantılı olarak artırır. Bu durum, formüldeki (1 + Çoğaltma parçası sayısı) çarpanına karşılık gelir. Bu nedenle tek bir parça çok büyük hale gelirse çoğaltma parçası eklemek yerine birincil parça sayısını artırmanızı öneririz. Birincil parça sayısını artırmak için dizini bölmek üzere _split API'sini kullanabilir veya verileri yeniden dizine ekleyebilirsiniz.

Düğüm teknik özelliklerinin ve düğüm sayısının değerlendirilmesi

Veri düğümleri

• Küme başına maksimum düğüm sayısı = Düğüm başına vCPU sayısı × 5.

• Bir Elasticsearch kümesindeki her düğümün depolayabileceği maksimum veri hacmi iş senaryosuna göre değişir:

  • Genel senaryolar: Düğüm başına maksimum depolama alanı = Düğüm başına bellek boyutu (GiB) × 30.

  • Veri sorgularında hızlandırma veya toplama gibi sorgu senaryoları: Düğüm başına maksimum depolama alanı = Düğüm başına bellek boyutu (GiB) × 10.

  • Günlük verisi içe aktarma veya çevrimdışı analizler gibi günlük kaydı senaryoları: Düğüm başına maksimum depolama alanı = Düğüm başına bellek boyutu (GiB) × 50.

Aşağıdaki tabloda farklı düğüm teknik özellikleri için maksimum düğüm sayısı ve düğüm başına maksimum depolama alanı listelenmektedir.

Bir Elasticsearch kümesinin toplam depolama alanı aşağıdaki formül kullanılarak hesaplanır: Bir Elasticsearch kümesinin toplam depolama alanı = Düğüm başına depolama alanı × Düğüm sayısı. Her düğümün maksimum depolama alanına ve maksimum düğüm sayısına göre her düğümün teknik özelliklerini belirleyebilirsiniz.

• Yoğun disk G/Ç'si oluşturan küçük veri hacimleri için teknik özellikleri yalnızca depolama kapasitesine değil G/Ç yeteneğine göre değerlendirin. Tipik bir örnek, yaklaşık 10 milyon kısa belge içeren, toplamda yaklaşık 3 GB yer kaplayan ve öncelikli olarak tam eşleşme, ön ek eşleşmesi veya toplama ile sorgulanan bir dizindir. Bu durumda depolama kapasitesi darboğaz değildir ve vCPU ile bellek gereksinimleri orta düzeydedir. Ancak her sorgu çok sayıda terime ve parçaya dokunduğundan diskte sık rastgele okuma işlemi gerçekleşir. Bu nedenle ulaşılabilen sorgu gecikme süresini disk G/Ç'si belirler. Aşağıdaki iki öğeyi birlikte değerlendirmenizi öneririz:

  • Düğüm teknik özellikleri: vCPU/bellek oranı 1:2 olan teknik özellikleri seçin ve her veri düğümü için en az 4 vCPU ve 16 GiB bellek kullanın. 4 vCPU ve 16 GiB belleğe sahip bir düğüm, sorgu senaryolarında 160 GiB'a kadar veriyi destekler ki bu da bu büyüklükteki bir veri hacmi için yeterli boşluk bırakır. Bu değerin altındaki teknik özellikler dizin için çok az sayfa önbelleği bırakır ve küme ardından diskten daha fazla veri okur.

  • Depolama: Bir küme satın alırken veya kümenin yapılandırmasını yükseltirken Storage Type öğesini Standard SSD olarak ayarlayın. Standard SSD yüksek IOPS ve kısa yanıt süresi sağlar ve çevrimiçi analizler ile arama için uygundur. Bir düğümün ulaşabileceği IOPS ve aktarım hızı, birincil parça sayısına değil depolama türüne ve düğüm teknik özelliklerine bağlıdır. Bu boyuttaki bir dizine birincil parça eklemek mevcut G/Ç yeteneğini artırmaz.

Ayrılmış master düğümler

Elasticsearch kümeniz çok sayıda veri düğümü içeriyorsa küme kararlılığını sağlamak için ayrılmış master düğümleri etkinleştirmenizi öneririz.

Elasticsearch kümeniz için ayrılmış master düğümlerinin teknik özelliklerini belirlemek üzere aşağıdaki talimatlara bakabilirsiniz:

• Varsayılan teknik özellikler: 2 vCPU ve 8 GiB bellek

• Veri düğümü sayısı 10'u aşarsa teknik özellikler: 4 vCPU ve 16 GiB bellek

• Veri düğümü sayısı 30'u aşarsa teknik özellikler: 8 vCPU ve 32 GiB bellek

• Veri düğümü sayısı 50'yi aşarsa teknik özellikler: 16 vCPU ve 64 GiB bellek

İstemci düğümleri

Bağımsız istemci düğümleri kullanırsanız değerlendirme sonucunda bir azaltma işlemi gerçekleştirebilirsiniz. Bu durumda azaltma aşamasında ciddi garbage collection (GC) meydana gelse bile veri düğümleri etkilenmez.

İstemci düğümlerini etkinleştirirseniz istemci düğümlerini ve veri düğümlerini 1:5 oranına göre yapılandırmanızı ve istemci düğümleri için vCPU/bellek oranı 1:4 veya 1:8 olan teknik özellikleri seçmenizi öneririz. En az iki istemci düğümü satın almalısınız. Örneğin teknik özellikleri 8 vCPU ve 32 GiB bellek olan 10 veri düğümü yapılandırırsanız teknik özellikleri 8 vCPU ve 32 GiB bellek olan 2 istemci düğümü yapılandırmanızı öneririz.

Parça değerlendirmesi

Parça sayısı ve her parçanın boyutu bir Elasticsearch kümesinin kararlılığını ve performansını etkiler. Bir Elasticsearch kümesindeki tüm dizinler için parçaları uygun şekilde planlamalısınız. Bu, çok sayıda parçanın küme performansını etkilemesini veya karmaşık iş senaryolarında eşit olmayan yüklerin oluşmasını önlemeye yardımcı olur. Örneğin bir Elasticsearch kümesindeki bir dizin için parça planlaması uygun değilse düğümlerin disk kullanımında önemli farklılıklar ve düğümler arasında eşit olmayan CPU yükleri oluşabilir.

Alibaba Cloud, parçaları planlamanız için size aşağıdaki yönergeleri sağlar. Bu yönergeler yalnızca referans amaçlıdır.

• Her parçada depolanan veri hacmi

  • Her parçada en fazla 30 GiB veri depolamanızı öneririz. Özel durumlarda her parçada en fazla 50 GiB veri depolayabilirsiniz.

  • Günlük analitiği senaryolarında veya son derece büyük dizinler gerektiren senaryolarda her parçanın en fazla 100 GiB veri depoladığından emin olun.

• Parça sayısı

  • Elasticsearch kümeniz için parça atamadan önce depolamak istediğiniz veri hacmini değerlendirmenizi öneririz.

    • Toplam veri hacmi büyükse Elasticsearch kümenizin iş yüklerini azaltmak için yazılacak veri miktarını azaltmalısınız. Bu durumda her dizin için birden fazla birincil parça ve her birincil parça için bir çoğaltma parçası yapılandırmanızı öneririz.

    • Hem toplam veri hacmi hem de yazmak istediğiniz veri hacmi küçükse her dizin için bir birincil parça ve her birincil parça için bir veya daha fazla çoğaltma parçası yapılandırmanızı öneririz.

    Not

    • Varsayılan olarak V7.X veya sonraki sürümlere sahip bir Elasticsearch kümesi, her dizin için bir birincil parça ve her birincil parça için bir çoğaltma parçası ile yapılandırılır. Varsayılan olarak V7.X'ten önceki bir Elasticsearch kümesi, her dizin için beş birincil parça ve her birincil parça için bir çoğaltma parçası ile yapılandırılır.

    • Depolamanız gereken veri hacmi 30 GiB'tan azsa her dizin için bir birincil parça ve birincil parça için birden fazla çoğaltma parçası yapılandırabilirsiniz. Bu, yük dengelemesi sağlar. Örneğin her dizinin boyutu 20 GiB'tır ve Elasticsearch kümeniz beş veri düğümü içerir. Bu durumda her dizin için bir birincil parça ve her birincil parça için dört çoğaltma parçası yapılandırabilirsiniz.

  • Parça sayısını veri düğümü sayısına veya veri düğümü sayısının tam katına eşit tutmanızı öneririz.

  • Bir düğümdeki bir dizin için en fazla beş parça yapılandırmanızı öneririz.

  • Tek bir düğümdeki tüm dizinler için toplam parça sayısını aşağıdaki formüllerden birini kullanarak hesaplamınızı öneririz:

    • Küçük teknik özelliklere sahip kümeler için: Tek bir veri düğümündeki parça sayısı = Veri düğümünün bellek boyutu × 30

    • Büyük teknik özelliklere sahip kümeler için: Tek bir veri düğümündeki parça sayısı = Veri düğümünün bellek boyutu × 50

    Not

    • Parça sayısını hesaplarken veri hacmini de dikkate almalısınız. Veri hacmi 1 TiB'tan azsa parça sayısını küçük teknik özelliklere sahip kümeler için formülü kullanarak hesaplamınızı öneririz.

    • Varsayılan olarak bir Elasticsearch V7.X kümesinde tek bir düğümdeki maksimum parça sayısı 1.000'dir. Maksimum sayıyı değiştirmemenizi öneririz. Tek bir düğümdeki parça sayısını değiştirmek isterseniz kümeyi kullanmadan önce düğüm sayısını artırabilirsiniz.

    • Parçaları iş gereksinimlerinize göre yapılandırmanızı öneririz. Daha fazla birincil parça daha fazla performans ek yükü oluşturur. Elasticsearch kümenizdeki her dizin için aşırı derecede fazla parça yapılandırırsanız dosya tanıtıcıları tükenebilir. Sonuç olarak Elasticsearch kümenizde arızalar oluşabilir.

Yukarıdaki yönergeler tek bir dizin için geçerlidir. Kümeniz birden fazla iş dizini depoluyorsa dizinlerin veri hacmi ve büyüme oranı farklı olduğundan tüm dizinlere tek bir değer uygulamak yerine her dizin için birincil parça sayısını ayrı ayrı planlayın. Her dizin için aşağıdaki adımları uygulayın:

1. Dizinin planlama girişlerini toplayın. Her dizinin mevcut depolama boyutunu elde etmek için GET _cat/indices?v&bytes=b komutunu çalıştırın, ardından dizinin günlük artışını ve saklama süresini tahmin ederek saklama süresi sonunda beklenen veri hacmini elde edin. Kümedeki veri düğümü sayısını, veri düğümü başına bellek boyutunu ve dizinin kullandığı çoğaltma parçası sayısını kaydedin.

2. Parça başına depolama boyutuna göre temel birincil parça sayısını hesaplayın. Dizinin beklenen veri hacmini 30 GiB'a bölün ve sonucu yukarı yuvarlayın. Özel durumlarda bölen olarak 50 GiB kullanabilirsiniz. Günlük analitiği senaryolarında veya son derece büyük dizinler gerektiren senaryolarda 100 GiB kullanabilirsiniz. Dizinin beklenen veri hacmi 30 GiB'tan az kalıyorsa dizin için bir birincil parça bırakın ve bunun yerine dizindeki sorguların düğümlere yayılması için çoğaltma parçaları ekleyin.

3. Parça sayısını veri düğümü sayısıyla hizalayın. Birincil parça sayısı × (1 + Çoğaltma parçası sayısı) formülü kullanılarak hesaplanan dizinin toplam parça sayısı, veri düğümü sayısına veya veri düğümü sayısının tam katına eşit olacak şekilde temel değeri ayarlayın. Daha küçük bir parça gelecekteki büyüme için yer bıraktığından aşağı yuvarlamak yerine yukarı yuvarlamak tercih edilir.

4. Sonucu düğüm başına sınırlara göre doğrulayın. Her düğüm aynı dizinin en fazla beş parçasını depolamalıdır. Bir veri düğümündeki tüm dizinlerin toplam parça sayısı, küme teknik özellikleriniz için formül kullanılarak hesaplanan değeri aşmamalıdır: Küçük teknik özelliklere sahip kümeler için Veri düğümünün bellek boyutu × 30 veya büyük teknik özelliklere sahip kümeler için Veri düğümünün bellek boyutu × 50. V7.X kümesi için tek bir düğümdeki parça sayısını 1.000'in altında tutun. Tüm dizinlerin planlanan parçalarının toplamı bu sınırları aşarsa veri hacmi en küçük olan dizinlerin parça sayısını azaltın, zamanla bölünen ancak nadiren sorgulanan dizinleri birleştirin veya veri düğümü ekleyin.

Örneğin bir dizinin saklama süresi sonunda 300 GiB veri depolaması bekleniyorsa küme 6 veri düğümü içerir ve dizin 1 çoğaltma parçası kullanır. Temel birincil parça sayısı 300 GiB/30 GiB = 10'dur. Toplam parça sayısını 6'nın tam katı yapmak için birincil parça sayısını 12'ye çıkarın. Dizin daha sonra toplamda 24 parçaya sahiptir, her parça yaklaşık 25 GiB veri depolar ve her veri düğümü dizinin 4 parçasını depolar. Üç yönergenin tamamı karşılanır.

Her dizin için hesaplamayı tamamladıktan sonra planı uygulayın. Birincil parça sayısını yalnızca bir dizin oluştururken belirtebilirsiniz. Zaten mevcut olan ve parçaları çok büyük olan bir dizin için dizini bölmek üzere _split API'sini kullanabilir veya verileri yeniden dizine ekleyebilir ve bir dizin şablonu kullanarak planlanan değeri daha sonra oluşturulan dizinlere uygulayabilirsiniz.

Plan yürürlüğe girdikten sonra disk kullanımı veya CPU kullanımı hala düğümler arasında önemli ölçüde farklılık gösteriyorsa bir veya daha fazla büyük dizinin parçaları birkaç düğümde yoğunlaşmış demektir. Dengesizliğe neden olan dizini ve düğümü tanımlayabilir ve Kümede dengeli olmayan yükler bölümüne göre parçaları yeniden dengeleyebilirsiniz.

Parça değerlendirmesi hakkında daha fazla bilgi için bkz. How to size your shards.

Başvuru kaynakları

• Farklı bölgelerde ve sürümlerde desteklenen düğüm teknik özelliklerini öğrenmek veya bir Elasticsearch kümesi satın almak için satın alma sayfasına bakın.

• Farklı teknik özelliklere ve sürümlere sahip Elasticsearch kümelerine yönelik stres testi sonuçlarına başvurarak farklı düğüm teknik özelliklerinin performansını öğrenebilirsiniz. Daha fazla bilgi için Performans dizinindeki konulara bakın.

• Standart Sürüm ile Kernel-enhanced Edition küme türleri arasındaki farklar ve her küme sürümündeki özellik değişiklikleri hakkında bilgi için bkz. Sürüm özellikleri.

• Mevcut bir Elasticsearch kümesi için değerlendirme sonucuna göre düğüm teknik özellikleri, düğüm depolama alanı ve düğüm sayısı gibi öğeleri ayarlayabilirsiniz. İşlemlerin nasıl gerçekleştirileceği ve ilgili dikkat edilmesi gerekenler hakkında bilgi için bkz. Küme yapılandırmasını yükseltin ve Kümeyi düşürün.

• Bir dizin için birincil parça sayısını yalnızca dizini oluştururken belirtebilirsiniz. Dizin oluşturulduktan sonra dizin için sayıyı değiştiremezsiniz. Bir dizin oluşturma hakkında bilgi için bkz. Dizin oluşturun.

• Mevcut bir dizin için her parçada depolanan veri hacmi önerilen hacmi aşıyorsa dizin için verileri yeniden dizine eklemenizi öneririz. Daha fazla bilgi için bkz. Alibaba Cloud Elasticsearch kümeleri arasında veri geçişi yapmak için reindex API'sini kullanın.

  Not

  Verileri yeniden dizine eklemek hizmet sürekliliğini sağlayabilir ancak zaman alıcıdır.

• Bir Elasticsearch kümesinde dengeli olmayan yükleri çözme hakkında bilgi için bkz. Kümede dengeli olmayan yükler.

• Düğümlerde sıcak verilerin eşit olmayan dağılımını çözme hakkında bilgi için bkz. Düğümlerde sıcak verilerin eşit olmayan dağılımı.

• Otomatik Dizin Oluşturma özelliğini etkinleştirirseniz eski dizinleri silmek için dizin yaşam döngüsü yönetimi (ILM) özelliğini veya bir Elasticsearch API betiğini kullanmanızı öneririz. ILM özelliği hakkında daha fazla bilgi için bkz. ILM ile Heartbeat verilerini yönetin.

• Yığın belleğini serbest bırakmak için küçük dizinleri zamanında silmenizi öneririz.

Dizin depolama farklarının nedenleri

Depolama boyutu dizinler arasında önemli ölçüde farklılık gösterebilir. Aşağıdaki bölümlerde bu farklılıkların yaygın nedenleri ve sorun giderme yöntemleri açıklanmaktadır.

• Farklı çözümleyici ayarları: ngram çözümleyicisi metni birçok küçük karakter kombinasyonuna böler; bu da standard çözümleyicisine kıyasla önemli ölçüde daha fazla belirteç oluşturur. Bu durum daha büyük bir ters dizine yol açar. Örneğin aynı belgeler için ngram çözümleyicisi kullanan ve min_gram=1 ile max_gram=4 ayarlarına sahip bir dizin, standard çözümleyicisi kullanan aynı dizinden yaklaşık 3,4 kat daha büyük olabilir.

• Farklı alan türleri ve eşleme ayarları: Bir text alan türü, alan değerini birden fazla belirtece tokenlaştırarak ters dizin oluşturur. Bir keyword alan türü tokenlaştırma gerçekleştirmez; bunun yerine alan değerinin tamamını ters dizinde tek bir terim olarak dizine ekler ve tam eşleşmeyi (term sorguları), sıralamayı ve toplamaları destekler. Farklı eşleme yapılandırmaları depolama tüketimini doğrudan etkiler.

• Farklı çoğaltma sayısı: number_of_replicas parametresi için daha yüksek bir değer toplam depolama tüketimini artırır.

• Farklı sıkıştırma ayarları: best_compression ayarı DEFLATE algoritmasını kullanır. Bu algoritma default LZ4 algoritmasına kıyasla daha yüksek bir sıkıştırma oranı sunar ancak okuma/yazma performansında hafif bir düşüş pahasına bunu gerçekleştirir.

Depolama farklılıklarını araştırmak için aşağıdaki adımları uygulayın:

• Her dizinin depolama boyutunu görüntülemek için GET _cat/indices?v&bytes=b komutunu çalıştırın.

• Alan düzeyindeki depolama dağılımını analiz etmek ve en çok yer kaplayan alanları tanımlamak için POST <index>/_disk_usage?run_expensive_tasks=true komutunu çalıştırın.

SSS

Kümemin yapılandırma yükseltmesine ihtiyacı olup olmadığını ve disk G/Ç'sinin risk oluşturup oluşturmadığını nasıl belirlerim?

Kümeyi aşağıdaki sırayla değerlendirin. Kaynak ölçümleri kümenin kapasite sınırına ne kadar yakın olduğunu gösterir ve küme olayları disk G/Ç'sinin zaten darboğaz haline gelip gelmediğini bildirir.

Adım 1: Kaynak ölçümlerinin yüksek düzeyde kalıp kalmadığını kontrol edin

Örnek ayrıntıları sayfasında Cluster Monitoring öğesine tıklayın ve Basic Monitoring sekmesini görüntüleyin. Zaman aralığını 1 gün ve ardından 7 gün olarak ayarlayın; Node CPU Utilization(%), Node Disk Utilization(%), Node HeapMemory Utilization(%) ve Node load_1m öğelerini kontrol edin. Bir ölçüm iş saatleri sırasında %80'in üzerinde kalıyorsa veya load_1m düğüm başına vCPU sayısına yakın ya da ondan yüksek kalıyorsa küme kapasite sınırına yakın çalışıyor demektir. Bu durumda kritik bir uyarı tetiklenmese bile yazma ve sorgu performansı ile küme kararlılığı etkilenebilir ve kümenin yapılandırmasını yükseltmeyi düşünmeniz gerekir. Aynı sekmedeki Küme durumu ile yazma ve sorgu QPS ölçümleri, yükün bir trafik artışından mı yoksa sorgu desenindeki bir değişikliğden mi kaynaklandığını doğrulamanıza yardımcı olur.

Basic Monitoring yedi ölçüm sağlar: küme durumu, küme dizini QPS, küme sorgusu QPS, düğüm CPU kullanımı, düğüm disk kullanımı, düğüm yığın belleği kullanımı ve düğüm load_1m. Ayrı bir IOPS grafiği veya disk aktarım hızı grafiği sağlamaz; bu nedenle diskin G/Ç sınırına ulaşıp ulaşmadığını belirlemek için izleme grafiklerini kullanmayın.

Adım 2: Küme olaylarına göre disk G/Ç risklerini belirleyin

Sol gezinme bölmesinde Event Center öğesine tıklayın ve olayları zaman aralığına, örnek kimliğine ve olay önem derecesine göre filtreleyin. Aşağıdaki olaylar mevcut depolama yapılandırmasının G/Ç yeteneğinin bir darboğaz haline geldiğini gösterir: disk I/O performance bottleneck, high disk I/O utilization ve disk throughput throttling. Böyle bir olay tekrar tekrar meydana geliyorsa veya artan sorgu gecikme süresi ya da reddedilen isteklerle birlikte görülüyorsa CPU kullanımı ve yığın belleği kullanımı normal olsa bile kümede bir G/Ç darboğazı riski vardır. Olay kümenin salt okunur duruma geçtiğini belirtiyorsa yazmalar zaten engellendiğinden hemen müdahale edin. Bu olayları tetikleyen IOPS ve aktarım hızı üst sınırları, kümenin depolama türüne ve düğüm teknik özelliklerine bağlıdır.

Adım 3: Kısa vadede baskıyı hafifletin

• Sorguları optimize edin: Sorgu zaman aralığını daraltın, büyük dizinlerde joker karakter ve yüksek kardinaliteli toplama sorgularından kaçının ve yığın belleğini serbest bırakmak için küçük veya artık sorgulanmayan dizinleri silin ya da birleştirin.

• Yüksek okuma aktarım hızı gerektirmeyen dizinler için çoğaltma parçası sayısını azaltın. Her çoğaltma parçası verinin tam bir kopyasını depoladığından bir çoğaltma parçasını kaldırmak hem disk kullanımını hem de yazma ek yüklerini azaltır.

• Bu konunun "Parça değerlendirmesi" bölümündeki yönergelere göre parça dağılımını iyileştirin. Birincil parça sayısını yalnızca bir dizin oluştururken belirtebilirsiniz. Zaten mevcut olan bir dizin için çalışan bir dizinin birincil parça sayısını değiştirmeyi beklemek yerine dizini bölmek üzere _split API'sini kullanabilir veya verileri yeniden dizine ekleyebilirsiniz.

Adım 4: Uzun vadeli büyüme için kümeyi ölçeklendirin

Önceki optimizasyonlardan sonra ölçümler yüksek düzeyde kalmaya devam ediyorsa veya veri hacmi artmaya devam ediyorsa kümenin yapılandırmasını yükseltin. Küme yapılandırmasını yükseltin bölümüne göre düğüm teknik özelliklerini artırabilir, veri düğümü ekleyebilir veya düğüm başına depolama alanını genişletebilir ve bu konunun "Düğüm teknik özelliklerinin ve düğüm sayısının değerlendirilmesi" bölümüne göre hedef teknik özellikleri yeniden değerlendirebilirsiniz. Darboğaz vCPU'lar veya bellek yerine disk G/Ç'si ise yükseltmeyi planlarken daha yüksek IOPS sağlayan bir depolama türünü değerlendirin. Kümeniz geliştirici teknik özellikleri kullanıyorsa yükseltme sırasında hizmetin kesintiye uğradığını ve kümenin daha sonra geliştirici teknik özelliklerine geri düşürülemeyeceğini unutmayın.