Elasticsearch:Evaluasi spesifikasi dan kapasitas penyimpanan

Perhatian

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

Evaluasi storage space

Storage space kluster Elasticsearch ditentukan oleh faktor-faktor berikut:

• Volume data sumber.

• Jumlah replica shard: Setiap primary shard harus memiliki setidaknya satu replica shard.

• 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 storage space dalam jumlah besar. Secara default, Elasticsearch hanya menyimpan data indeks yang dibuat dalam tujuh hari terakhir.

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

  • .watcher-history-3-*: Jenis indeks ini hanya mengonsumsi storage space dalam jumlah kecil. Jika indeks semacam ini tidak lagi diperlukan, Anda dapat menghapusnya secara manual.

• Overhead internal kluster Elasticsearch: Operasi internal seperti segment merging dan logging menghasilkan overhead pengindeksan. 20% storage space dicadangkan untuk overhead tersebut.

  Jumlah storage space yang dikonsumsi oleh log kluster meningkat seiring dengan bertambahnya jumlah kueri dan dorongan data yang diterima oleh kluster Elasticsearch. Log kluster mencakup run log, access log, dan slow log. Secara default, Elasticsearch hanya menyimpan log yang dihasilkan dalam tujuh hari terakhir. Durasi tersebut tidak dapat diubah.

• Storage space yang dicadangkan oleh sistem operasi: Secara default, sistem operasi mencadangkan 5% storage space untuk proses kritis, pemulihan sistem, dan fragmentasi disk.

• Overhead ambang batas keamanan: Elasticsearch mencadangkan minimal 15% storage space sebagai ambang batas keamanan.

Storage space yang direkomendasikan dihitung menggunakan rumus berikut:

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

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 pada skenario bisnis:

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

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

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

Tabel berikut mencantumkan jumlah maksimum node dan storage space maksimum per node untuk berbagai spesifikasi node.

Total storage space kluster Elasticsearch dihitung menggunakan rumus berikut: Total storage space kluster Elasticsearch = Storage space per node × Jumlah node. Anda dapat menentukan spesifikasi setiap node berdasarkan storage space maksimum per node dan jumlah maksimum node.

Node master terdedikasi

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

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

• Spesifikasi default: 2 vCPU dan 8 GiB memori

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

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

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

Client node

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

Jika Anda mengaktifkan client node, kami menyarankan agar Anda mengonfigurasi client node dan data node berdasarkan rasio 1:5 serta memilih spesifikasi dengan rasio vCPU-memori 1:4 atau 1:8 untuk client node. Anda harus membeli minimal dua client node. Misalnya, jika Anda mengonfigurasi 10 data node dengan spesifikasi 8 vCPU dan 32 GiB memori, kami menyarankan agar Anda mengonfigurasi 2 client node 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 guna mencegah terlalu banyak shard yang memengaruhi performa kluster atau menyebabkan beban tidak merata dalam skenario bisnis kompleks. Misalnya, perencanaan shard yang tidak tepat untuk suatu indeks dapat menyebabkan perbedaan signifikan dalam penggunaan disk dan beban CPU yang tidak merata di antara node.

Alibaba Cloud menyediakan panduan berikut untuk Anda merencanakan shard. Panduan ini hanya sebagai 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 volume data total 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 primary shard untuk setiap indeks dan satu replica shard untuk setiap primary shard.

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

    Catatan

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

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

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

  • 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 data node = Ukuran memori data node × 30

    • Untuk kluster dengan spesifikasi besar: Jumlah shard pada satu data node = Ukuran memori data node × 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 primary shard menghasilkan overhead performa yang lebih besar. Jika Anda mengonfigurasi jumlah shard yang terlalu besar untuk setiap indeks dalam kluster Elasticsearch Anda, file handle dapat habis. Akibatnya, faults dapat terjadi pada kluster Elasticsearch Anda.

Untuk informasi selengkapnya tentang evaluasi shard, lihat How to size your shards.

Referensi

• Untuk mengetahui spesifikasi node yang didukung di berbagai wilayah dan versi, atau untuk membeli kluster Elasticsearch, lihat buy page.

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

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

• Anda dapat menyesuaikan item seperti spesifikasi node, storage space 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 Upgrade cluster configuration dan Downgrade a cluster.

• Anda hanya dapat menentukan jumlah primary shard 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 Create an index.

• 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 Use the reindex API to migrate data between Alibaba Cloud Elasticsearch clusters.

  Catatan

  Pengindeksan ulang data dapat memastikan kelangsungan layanan tetapi memakan waktu.

• Untuk informasi tentang cara mengatasi beban tidak seimbang pada kluster Elasticsearch, lihat Unbalanced loads on a cluster.

• Untuk informasi tentang cara mengatasi distribusi data panas yang tidak merata pada node, lihat Uneven distribution of hot data on nodes.

• Jika Anda mengaktifkan fitur Auto Indexing, kami menyarankan agar Anda menggunakan fitur index lifecycle management (ILM) atau skrip API Elasticsearch untuk menghapus indeks lama. Untuk informasi selengkapnya tentang fitur ILM, lihat Manage Heartbeat data with ILM.

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

Alasan perbedaan penyimpanan indeks

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

• 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 inverted index 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.

• Tipe bidang dan pengaturan pemetaan berbeda: Bidang text membangun inverted index, 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 total konsumsi penyimpanan.

• 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.