Elasticsearch:Evaluasi spesifikasi dan kapasitas penyimpanan

Perhatian

Metode evaluasi dalam topik ini didasarkan pada hasil pengujian aktual dan pengalaman pengguna. Kebutuhan pengguna berbeda-beda tergantung pada struktur data, kompleksitas kueri, volume data, performa, dan laju perubahan data. Oleh karena itu, informasi dalam topik ini hanya bersifat referensi. Kami menyarankan agar Anda mengevaluasi spesifikasi dan kapasitas penyimpanan kluster Elasticsearch berdasarkan data aktual dan skenario bisnis Anda.

Evaluasi kapasitas penyimpanan

Kapasitas penyimpanan kluster Elasticsearch ditentukan oleh faktor-faktor berikut:

• Volume data sumber.

• Jumlah shard replika: Setiap shard utama harus memiliki setidaknya satu shard replika.

• Overhead pengindeksan: Dalam kebanyakan kasus, overhead pengindeksan 10% lebih besar daripada data sumber.

  Misalnya, indeks pemantauan yang digunakan oleh X-Pack untuk analisis anomali menghasilkan overhead pengindeksan. Indeks pemantauan tersebut mencakup jenis-jenis berikut:

  • .monitoring-es-6-*: Jenis indeks ini mengonsumsi banyak kapasitas penyimpanan. Secara default, Elasticsearch hanya menyimpan data indeks yang dibuat dalam tujuh hari terakhir.

  • .monitoring-kibana-6-*: Kapasitas penyimpanan yang dikonsumsi oleh jenis indeks ini meningkat seiring dengan jumlah indeks. Secara default, Elasticsearch hanya menyimpan data indeks yang dibuat dalam tujuh hari terakhir.

  • .watcher-history-3-*: Jenis indeks ini hanya mengonsumsi sedikit kapasitas penyimpanan. Jika indeks semacam ini tidak lagi diperlukan, Anda dapat menghapusnya secara manual.

• Overhead internal kluster Elasticsearch: Operasi internal seperti Penggabungan segmen dan pencatatan log menghasilkan overhead pengindeksan. Ruang penyimpanan sebesar 20% dicadangkan untuk overhead semacam ini.

  Kapasitas penyimpanan yang dikonsumsi oleh log kluster meningkat seiring dengan jumlah kueri dan dorongan data yang diterima oleh kluster Elasticsearch. Log kluster mencakup log run, Log akses, dan slow log. Secara default, Elasticsearch hanya menyimpan log yang dihasilkan dalam tujuh hari terakhir. Durasi ini tidak dapat diubah.

• Ruang penyimpanan yang dicadangkan oleh sistem operasi: Secara default, sistem operasi mencadangkan 5% ruang penyimpanan untuk proses kritis, pemulihan sistem, dan fragmentasi disk.

• Overhead ambang batas keamanan: Elasticsearch mencadangkan setidaknya 15% ruang penyimpanan sebagai ambang batas keamanan.

Kapasitas penyimpanan yang direkomendasikan dihitung menggunakan rumus berikut:

Kapasitas penyimpanan kluster yang direkomendasikan = Volume data sumber × (1 + Jumlah shard replika) × Overhead pengindeksan/(1 - Ruang penyimpanan yang dicadangkan oleh sistem operasi)/(1 - Overhead internal kluster)/(1 - Overhead ambang batas keamanan)
             = Volume data sumber × (1 + Jumlah shard replika) × 1,7
             = Volume data sumber × 3,4

Dari pengaturan shard, hanya jumlah shard replika yang memengaruhi hasil rumus di atas. Menambahkan shard utama tidak meningkatkan penggunaan disk, karena data yang ada hanya didistribusikan ulang ke lebih banyak shard dan total volume data tetap tidak berubah. Menambahkan shard replika meningkatkan penggunaan disk secara proporsional terhadap jumlah replika, karena setiap shard replika menyimpan salinan lengkap data. Hal ini sesuai dengan faktor (1 + Jumlah shard replika) dalam rumus. Oleh karena itu, jika satu shard menjadi terlalu besar, kami menyarankan agar Anda menambah jumlah shard utama alih-alih menambahkan shard replika. Untuk menambah jumlah shard utama, Anda dapat menggunakan API _split untuk memisahkan indeks atau melakukan pengindeksan ulang data.

Evaluasi spesifikasi node dan jumlah node

Data node

• Jumlah maksimum node per kluster = Jumlah vCPU per node × 5.

• Volume maksimum data yang dapat disimpan oleh setiap node dalam kluster Elasticsearch bervariasi tergantung skenario bisnis:

  • Skenario umum: Kapasitas penyimpanan maksimum per node = Ukuran memori per node (GiB) × 30.

  • Skenario kueri seperti akselerasi atau agregasi pada kueri data: Kapasitas penyimpanan maksimum per node = Ukuran memori per node (GiB) × 10.

  • Skenario logging seperti impor data log atau analitik offline: Kapasitas penyimpanan maksimum per node = Ukuran memori per node (GiB) × 50.

Tabel berikut mencantumkan jumlah maksimum node dan kapasitas penyimpanan maksimum per node untuk berbagai spesifikasi node.

Total kapasitas penyimpanan kluster Elasticsearch dihitung menggunakan rumus berikut: Total kapasitas penyimpanan kluster Elasticsearch = Kapasitas penyimpanan per node × Jumlah node. Anda dapat menentukan spesifikasi setiap node berdasarkan kapasitas penyimpanan maksimum per node dan jumlah maksimum node.

• Untuk volume data kecil yang menghasilkan I/O disk tinggi, evaluasi spesifikasi berdasarkan kemampuan I/O alih-alih hanya kapasitas penyimpanan. Kasus khas adalah indeks yang berisi sekitar 10 juta dokumen pendek, menempati sekitar 3 GB secara total, dan terutama dikueri berdasarkan pencocokan eksak, pencocokan awalan, atau agregasi. Dalam kasus ini, kapasitas penyimpanan bukan hambatan utama, dan kebutuhan terhadap vCPU serta memori bersifat moderat. Namun, setiap kueri menyentuh banyak Kata kunci dan segmen, yang menghasilkan pembacaan acak yang sering pada disk. Oleh karena itu, I/O disk menentukan latensi kueri yang dapat Anda capai. Kami menyarankan agar Anda mengevaluasi dua hal berikut secara bersamaan:

  • Spesifikasi node: pilih spesifikasi dengan Rasio CPU-memori 1:2, dan gunakan minimal 4 vCPU dan 16 GiB memori untuk setiap node data. Node dengan 4 vCPU dan 16 GiB memori mendukung hingga 160 GiB data dalam skenario kueri, yang memberikan ruang cukup untuk volume data sebesar ini. Spesifikasi di bawah nilai ini menyisakan sedikit cache halaman untuk indeks, sehingga kluster membaca lebih banyak data dari disk.

  • Penyimpanan: atur Jenis Penyimpanan ke Standard SSD saat Anda membeli kluster atau meningkatkan konfigurasi kluster. Standard SSD menyediakan IOPS tinggi dan waktu tanggapan singkat, serta cocok untuk analitik dan pencarian online. IOPS dan throughput yang dapat dicapai oleh sebuah node ditentukan oleh jenis penyimpanan dan spesifikasi node, bukan oleh jumlah shard utama. Menambahkan shard utama pada indeks seukuran ini tidak meningkatkan kemampuan I/O yang tersedia.

Node master khusus

Jika kluster Elasticsearch Anda berisi banyak node data, kami menyarankan agar Anda mengaktifkan node master khusus untuk memastikan stabilitas kluster.

Anda dapat merujuk pada petunjuk berikut untuk menentukan spesifikasi node master khusus untuk kluster Elasticsearch Anda:

• Spesifikasi default: 2 vCPU dan 8 GiB memori

• Spesifikasi jika jumlah node data melebihi 10: 4 vCPU dan 16 GiB memori

• Spesifikasi jika jumlah node data melebihi 30: 8 vCPU dan 32 GiB memori

• Spesifikasi jika jumlah node data melebihi 50: 16 vCPU dan 64 GiB memori

Node klien

Jika Anda menggunakan node klien independen, Anda dapat melakukan operasi reduce pada hasil evaluasi. Dalam hal ini, jika terjadi Pengumpulan sampah (GC) parah pada tahap reduce, node data tidak akan terpengaruh.

Jika Anda mengaktifkan node klien, kami menyarankan agar Anda mengonfigurasi node klien dan node data berdasarkan rasio 1:5 dan memilih spesifikasi dengan Rasio CPU-memori 1:4 atau 1:8 untuk node klien. Anda harus membeli minimal dua node klien. Misalnya, jika Anda mengonfigurasi 10 node data dengan spesifikasi 8 vCPU dan 32 GiB memori, kami menyarankan agar Anda mengonfigurasi 2 node klien dengan spesifikasi 8 vCPU dan 32 GiB memori.

Evaluasi shard

Jumlah shard dan ukuran setiap shard memengaruhi stabilitas dan performa kluster Elasticsearch. Anda harus merencanakan shard dengan tepat untuk semua indeks dalam kluster Elasticsearch. Hal ini membantu mencegah banyaknya shard memengaruhi performa kluster atau menyebabkan beban tidak merata dalam skenario bisnis kompleks. Misalnya, jika perencanaan shard untuk suatu indeks dalam kluster Elasticsearch tidak tepat, perbedaan signifikan dalam penggunaan disk node dan beban CPU yang tidak merata di antara node dapat terjadi.

Alibaba Cloud menyediakan panduan berikut untuk Anda merencanakan shard. Panduan ini hanya untuk referensi.

• Volume data yang disimpan pada setiap shard

  • Kami menyarankan agar Anda menyimpan tidak lebih dari 30 GiB data pada setiap shard. Dalam kasus khusus, Anda dapat menyimpan tidak lebih dari 50 GiB data pada setiap shard.

  • Dalam skenario analitik log atau skenario yang memerlukan indeks sangat besar, pastikan setiap shard menyimpan tidak lebih dari 100 GiB data.

• Jumlah shard

  • Sebelum mengalokasikan shard untuk kluster Elasticsearch Anda, kami menyarankan agar Anda mengevaluasi volume data yang ingin Anda simpan.

    • Jika total volume data besar, Anda harus mengurangi jumlah data yang akan ditulis untuk mengurangi beban kerja kluster Elasticsearch Anda. Dalam hal ini, kami menyarankan agar Anda mengonfigurasi beberapa shard utama untuk setiap indeks dan satu shard replika untuk setiap shard utama.

    • Jika baik total volume data maupun volume data yang ingin Anda tulis kecil, kami menyarankan agar Anda mengonfigurasi satu shard utama untuk setiap indeks dan satu atau lebih shard replika untuk setiap shard utama.

    Catatan

    • Secara default, kluster Elasticsearch versi V7.X atau lebih baru dikonfigurasi dengan satu shard utama untuk setiap indeks dan satu shard replika untuk setiap shard utama. Secara default, kluster Elasticsearch versi sebelum V7.X dikonfigurasi dengan lima shard utama untuk setiap indeks dan satu shard replika untuk setiap shard utama.

    • Jika volume data yang perlu Anda simpan kurang dari 30 GiB, Anda dapat mengonfigurasi satu shard utama untuk setiap indeks dan beberapa shard replika untuk shard utama tersebut. Hal ini mencapai penyeimbangan beban. Misalnya, ukuran setiap indeks adalah 20 GiB, dan kluster Elasticsearch Anda berisi lima node data. Dalam hal ini, Anda dapat mengonfigurasi satu shard utama untuk setiap indeks dan empat shard replika untuk setiap shard utama.

  • Kami menyarankan agar Anda menjaga jumlah shard sama dengan jumlah node data atau kelipatan bulat dari jumlah node data.

  • Kami menyarankan agar Anda mengonfigurasi maksimal lima shard untuk suatu indeks pada satu node.

  • Kami menyarankan agar Anda menghitung jumlah total shard untuk semua indeks pada satu node menggunakan salah satu rumus berikut:

    • Untuk kluster dengan spesifikasi kecil: Jumlah shard pada satu node data = Ukuran memori node data × 30

    • Untuk kluster dengan spesifikasi besar: Jumlah shard pada satu node data = Ukuran memori node data × 50

    Catatan

    • Saat menghitung jumlah shard, Anda juga harus mempertimbangkan volume data. Jika volume data kurang dari 1 TiB, kami menyarankan agar Anda menghitung jumlah shard menggunakan rumus untuk kluster dengan spesifikasi kecil.

    • Secara default, jumlah maksimum shard pada satu node dalam kluster Elasticsearch V7.X adalah 1.000. Kami menyarankan agar Anda tidak mengubah jumlah maksimum tersebut. Jika Anda ingin mengubah jumlah shard pada satu node, Anda dapat menambah jumlah node sebelum menggunakan kluster.

    • Kami menyarankan agar Anda mengonfigurasi shard berdasarkan kebutuhan bisnis Anda. Lebih banyak shard utama menghasilkan overhead performa yang lebih besar. Jika Anda mengonfigurasi jumlah shard yang terlalu besar untuk setiap indeks dalam kluster Elasticsearch Anda, handle file dapat habis. Akibatnya, Titik kegagalan dapat terjadi pada kluster Elasticsearch Anda.

Panduan di atas berlaku untuk satu indeks. Jika kluster Anda menyimpan beberapa indeks bisnis, indeks tersebut berbeda dalam volume data dan laju pertumbuhan, sehingga rencanakan jumlah shard utama untuk setiap indeks secara terpisah alih-alih menerapkan satu nilai untuk semua indeks. Lakukan langkah-langkah berikut untuk setiap indeks:

1. Kumpulkan input perencanaan indeks. Jalankan perintah GET _cat/indices?v&bytes=b untuk mendapatkan ukuran penyimpanan saat ini dari setiap indeks, lalu perkirakan peningkatan harian dan periode retensi indeks untuk mendapatkan volume data yang diharapkan pada akhir periode retensi. Catat jumlah node data dalam kluster, ukuran memori per node data, dan jumlah shard replika yang digunakan oleh indeks.

2. Hitung jumlah dasar shard utama berdasarkan ukuran penyimpanan per shard. Bagi volume data yang diharapkan dari indeks dengan 30 GiB dan bulatkan ke atas hasilnya. Dalam kasus khusus, Anda dapat menggunakan 50 GiB sebagai pembagi. Dalam skenario analitik log atau skenario yang memerlukan indeks sangat besar, Anda dapat menggunakan 100 GiB. Jika volume data yang diharapkan dari indeks tetap kurang dari 30 GiB, pertahankan satu shard utama untuk indeks tersebut dan tambahkan shard replika, sehingga kueri pada indeks tersebar di beberapa node.

3. Selaraskan jumlah shard dengan jumlah node data. Sesuaikan nilai dasar sehingga jumlah total shard indeks, yang dihitung menggunakan rumus Jumlah shard utama × (1 + Jumlah shard replika), sama dengan jumlah node data atau kelipatan bulat dari jumlah node data. Pembulatan ke atas lebih disukai daripada pembulatan ke bawah, karena shard yang lebih kecil memberikan ruang untuk pertumbuhan di masa depan.

4. Verifikasi hasil terhadap batas per node. Setiap node harus menyimpan tidak lebih dari lima shard dari indeks yang sama. Jumlah total shard dari semua indeks pada satu node data tidak boleh melebihi nilai yang dihitung menggunakan rumus untuk spesifikasi kluster Anda: Ukuran memori node data × 30 untuk kluster dengan spesifikasi kecil, atau Ukuran memori node data × 50 untuk kluster dengan spesifikasi besar. Untuk kluster versi V7.X, pertahankan jumlah shard pada satu node di bawah 1.000. Jika jumlah shard yang direncanakan dari semua indeks melebihi batas ini, kurangi jumlah shard dari indeks yang memiliki volume data paling kecil, gabungkan indeks yang dipisah berdasarkan waktu tetapi jarang dikueri, atau tambahkan node data.

Sebagai contoh, suatu indeks diharapkan menyimpan 300 GiB data pada akhir periode retensinya, kluster berisi 6 node data, dan indeks menggunakan 1 shard replika. Jumlah dasar shard utama adalah 300 GiB/30 GiB = 10. Untuk membuat jumlah total shard menjadi kelipatan bulat dari 6, tingkatkan jumlah shard utama menjadi 12. Indeks tersebut kemudian memiliki 24 shard secara total, setiap shard menyimpan sekitar 25 GiB data, dan setiap node data menyimpan 4 shard dari indeks tersebut. Ketiga panduan tersebut terpenuhi.

Setelah menyelesaikan perhitungan untuk setiap indeks, terapkan rencana tersebut. Anda hanya dapat menentukan jumlah shard utama saat membuat indeks. Untuk indeks yang sudah ada dan shard-nya terlalu besar, gunakan API _split untuk memisahkan indeks atau lakukan pengindeksan ulang data, dan gunakan Templat indeks untuk menerapkan nilai yang direncanakan pada indeks yang dibuat nanti.

Jika penggunaan disk atau pemanfaatan CPU masih berbeda signifikan di antara node setelah rencana diterapkan, shard dari satu atau beberapa indeks besar tetap terkonsentrasi pada beberapa node. Anda dapat mengidentifikasi indeks dan node yang menyebabkan ketidakseimbangan tersebut dan menyeimbangkan ulang shard berdasarkan Beban tidak seimbang pada kluster.

Untuk informasi selengkapnya tentang evaluasi shard, lihat Cara menentukan ukuran shard Anda.

Referensi

• Untuk mengetahui spesifikasi node yang didukung di berbagai Wilayah dan versi, atau untuk membeli kluster Elasticsearch, lihat halaman pembelian.

• Anda dapat merujuk pada hasil pengujian stres pada kluster Elasticsearch dengan spesifikasi dan versi berbeda untuk mengetahui performa berbagai spesifikasi node. Untuk informasi selengkapnya, lihat topik dalam direktori Performa.

• Untuk informasi tentang perbedaan antara tipe kluster Edisi Standar dan Edisi Kernel-enhanced, serta perubahan fitur di setiap versi kluster, lihat Fitur versi.

• Anda dapat menyesuaikan item seperti spesifikasi node, kapasitas penyimpanan node, dan jumlah node untuk kluster Elasticsearch yang sudah ada berdasarkan hasil evaluasi. Untuk informasi tentang cara melakukan operasi tersebut dan tindakan pencegahan terkait, lihat Peningkatan konfigurasi kluster dan Menurunkan spesifikasi kluster.

• Anda hanya dapat menentukan jumlah shard utama untuk suatu indeks saat membuat indeks tersebut. Setelah indeks dibuat, Anda tidak dapat mengubah jumlah tersebut untuk indeks tersebut. Untuk informasi tentang cara membuat indeks, lihat Membuat indeks.

• Jika volume data yang disimpan pada setiap shard untuk indeks yang sudah ada melebihi volume yang direkomendasikan, kami menyarankan agar Anda melakukan pengindeksan ulang data untuk indeks tersebut. Untuk informasi selengkapnya, lihat Gunakan API reindex untuk migrasi data antar kluster Alibaba Cloud Elasticsearch.

  Catatan

  Pengindeksan ulang data dapat memastikan kelangsungan layanan tetapi memakan waktu.

• Untuk informasi tentang cara mengatasi beban tidak seimbang pada kluster Elasticsearch, lihat Beban tidak seimbang pada kluster.

• Untuk informasi tentang cara mengatasi distribusi tidak merata data panas pada node, lihat Distribusi tidak merata data panas pada node.

• Jika Anda mengaktifkan fitur Auto Indexing, kami menyarankan agar Anda menggunakan fitur manajemen siklus hidup indeks (ILM) atau skrip API Elasticsearch untuk menghapus indeks kedaluwarsa. Untuk informasi selengkapnya tentang fitur ILM, lihat Kelola data Heartbeat dengan ILM.

• Kami menyarankan agar Anda menghapus indeks kecil secara tepat waktu untuk membebaskan memori heap.

Alasan perbedaan penyimpanan indeks

Ukuran penyimpanan dapat sangat bervariasi antar indeks. Bagian-bagian berikut menjelaskan alasan umum perbedaan tersebut dan metode troubleshooting.

• Pengaturan alat analisis berbeda: Alat analisis ngram memecah teks menjadi banyak kombinasi karakter kecil, yang menghasilkan token jauh lebih banyak daripada alat analisis standard. Hal ini menghasilkan Indeks terbalik yang lebih besar. Misalnya, untuk dokumen yang sama, indeks yang menggunakan alat analisis ngram dengan min_gram=1 dan max_gram=4 dapat berukuran sekitar 3,4 kali lebih besar daripada indeks yang sama yang menggunakan alat analisis standard.

• Jenis bidang dan pengaturan Pemetaan berbeda: Bidang text membangun Indeks terbalik, sedangkan bidang keyword tidak. Konfigurasi Pemetaan yang berbeda secara langsung memengaruhi penggunaan penyimpanan.

• Jumlah replika berbeda: Nilai parameter number_of_replicas yang lebih tinggi meningkatkan konsumsi penyimpanan total.

• Pengaturan kompresi berbeda: Pengaturan best_compression menggunakan algoritma DEFLATE. Algoritma ini menawarkan rasio kompresi lebih tinggi daripada algoritma LZ4 default, tetapi dengan sedikit penurunan performa baca/tulis.

Untuk menyelidiki perbedaan penyimpanan, lakukan langkah-langkah berikut:

• Jalankan perintah GET _cat/indices?v&bytes=b untuk melihat ukuran penyimpanan setiap indeks.

• Jalankan perintah POST <index>/_disk_usage?run_expensive_tasks=true untuk menganalisis distribusi penyimpanan tingkat bidang dan mengidentifikasi bidang yang paling banyak mengonsumsi ruang.

FAQ

Bagaimana cara menentukan apakah kluster saya memerlukan peningkatan konfigurasi, dan apakah I/O disk merupakan risiko?

Evaluasi kluster dengan urutan berikut. Metrik resource memberi tahu Anda apakah kluster mendekati batas kapasitasnya, dan event kluster memberi tahu Anda apakah I/O disk telah menjadi hambatan.

Langkah 1: Periksa apakah metrik resource berada pada level tinggi

Pada halaman detail instans, klik Cluster Monitoring dan lihat tab Basic Monitoring. Atur rentang waktu menjadi 1 hari hingga 7 hari, lalu periksa Node CPU Utilization(%), Node Disk Utilization(%), Node HeapMemory Utilization(%), dan Node load_1m. Jika suatu metrik tetap di atas 80% selama jam kerja, atau jika load_1m tetap mendekati atau di atas jumlah vCPU per node, kluster beroperasi mendekati batas kapasitasnya. Dalam hal ini, performa tulis dan kueri serta stabilitas kluster dapat terpengaruh meskipun tidak ada peringatan kritis yang dipicu, dan Anda harus mempertimbangkan untuk meningkatkan konfigurasi kluster. Status kluster dan metrik QPS tulis dan kueri pada tab yang sama membantu Anda memastikan apakah beban berasal dari peningkatan traffic atau perubahan pola kueri.

Basic Monitoring menyediakan tujuh metrik: status kluster, QPS indeks kluster, QPS kueri kluster, pemanfaatan CPU node, penggunaan disk node, pemanfaatan memori heap node, dan load_1m node. Tidak tersedia grafik IOPS terpisah atau grafik throughput disk, jadi jangan gunakan grafik pemantauan untuk menentukan apakah disk mencapai batas I/O-nya.

Langkah 2: Identifikasi risiko I/O disk berdasarkan event kluster

Klik Event Center di panel navigasi kiri, lalu filter event berdasarkan rentang waktu, ID instans, dan tingkat keparahan event. Event berikut menunjukkan bahwa kemampuan I/O konfigurasi penyimpanan saat ini telah menjadi hambatan: disk I/O performance bottleneck, high disk I/O utilization, dan disk throughput throttling. Jika event semacam ini terjadi berulang kali, atau jika disertai dengan peningkatan latensi kueri atau permintaan yang ditolak, kluster memiliki risiko hambatan I/O, meskipun pemanfaatan CPU dan pemanfaatan memori heap normal. Jika event menunjukkan bahwa kluster telah memasuki status read-only, segera tangani, karena penulisan sudah diblokir. Batas atas IOPS dan throughput yang memicu event ini ditentukan oleh jenis penyimpanan dan spesifikasi node kluster.

Langkah 3: Kurangi tekanan dalam jangka pendek

• Optimalkan kueri: persempit rentang waktu kueri, hindari kueri wildcard dan agregasi high-cardinality pada indeks besar, serta hapus atau gabungkan indeks yang kecil atau tidak lagi dikueri untuk membebaskan memori heap.

• Kurangi jumlah shard replika untuk indeks yang tidak memerlukan throughput baca tinggi. Setiap shard replika menyimpan salinan lengkap data, sehingga menghapus satu shard replika mengurangi penggunaan disk dan overhead penulisan.

• Tingkatkan distribusi shard berdasarkan panduan dalam bagian "Evaluasi shard" topik ini. Anda hanya dapat menentukan jumlah shard utama saat membuat indeks. Untuk indeks yang sudah ada, gunakan API _split untuk memisahkan indeks atau lakukan pengindeksan ulang data, alih-alih berharap dapat mengubah jumlah shard utama indeks yang sedang Berjalan.

Langkah 4: Skalakan kluster untuk pertumbuhan jangka panjang

Jika metrik tetap pada level tinggi setelah optimasi di atas, atau jika volume data terus meningkat, tingkatkan konfigurasi kluster. Anda dapat meningkatkan spesifikasi node, menambahkan node data, atau memperluas kapasitas penyimpanan per node berdasarkan Peningkatan konfigurasi kluster, dan evaluasi ulang spesifikasi target berdasarkan bagian "Evaluasi spesifikasi node dan jumlah node" topik ini. Jika I/O disk—bukan vCPU atau memori—merupakan hambatan, evaluasi jenis penyimpanan yang menyediakan IOPS lebih tinggi saat merencanakan peningkatan. Jika kluster Anda menggunakan spesifikasi developer, perhatikan bahwa layanan terganggu selama peningkatan dan kluster tidak dapat diturunkan kembali ke spesifikasi developer setelahnya.