全部产品
Search

搜索本产品

    Elasticsearch：Evaluasi spesifikasi dan kapasitas penyimpanan

    文档中心

    Elasticsearch：Evaluasi spesifikasi dan kapasitas penyimpanan

    更新时间：Feb 28, 2026

    Rencanakan kapasitas penyimpanan, spesifikasi node, dan tata letak shard untuk kluster Alibaba Cloud Elasticsearch sebelum pembelian atau perubahan konfigurasi.

    Referensi cepat: Dengan satu shard replika per shard utama, sediakan sekitar 3,4× volume data sumber Anda dalam total penyimpanan. Misalnya, data sumber sebesar 100 GiB memerlukan sekitar 340 GiB penyimpanan kluster.

    Metode evaluasi dalam dokumen ini didasarkan pada hasil pengujian dunia nyata dan pengalaman operasional. Kebutuhan aktual dapat berbeda tergantung pada struktur data, kompleksitas kueri, volume data, perubahan data, dan tujuan performa. Validasi estimasi dengan beban kerja representatif sebelum menetapkan konfigurasi akhir.

    Rumus kapasitas penyimpanan

    Dengan pengaturan bawaan satu shard replika per shard utama, total penyimpanan kluster kira-kira 3,4× volume data sumber. Pengali ini memperhitungkan faktor-faktor overhead berikut:

    FaktorOverheadDeskripsi
    Shard replika2x (dengan 1 replika)Setiap shard utama memiliki setidaknya satu shard replika
    Overhead pengindeksanBiasanya 10%Ruang yang digunakan oleh struktur indeks di luar data sumber
    Overhead internal20% dicadangkanPenggabungan segmen, logging, dan operasi internal lainnya
    Ruang cadangan OS5% dicadangkanProses kritis, pemulihan sistem, dan fragmentasi disk
    Ambang batas keamananMinimal 15% dicadangkanRuang kosong minimum yang dipertahankan oleh Elasticsearch

    Rumus sederhana:

    Penyimpanan kluster = Data sumber x (1 + Jumlah replika) x 1,7
                = Data sumber x 3,4  (ketika replika = 1)

    Rumus lengkap:

    Penyimpanan kluster = Data sumber
                  x (1 + Jumlah replika)
                  x Faktor overhead pengindeksan
                  / (1 - Cadangan OS)
                  / (1 - Overhead internal)
                  / (1 - Ambang batas keamanan)

                = Data sumber x (1 + Jumlah replika) x 1,1 / 0,95 / 0,80 / 0,85
                = Data sumber x (1 + Jumlah replika) x 1,7
    Penting

    Pengali 3,4× mengasumsikan satu replika. Sesuaikan rumus dengan jumlah replika aktual Anda.

    Contoh perhitungan: Data sumber 200 GiB

    Skenario: Data sumber 200 GiB, satu shard replika per shard utama.

    Penyimpanan kluster = 200 GiB x (1 + 1) x 1,7
                = 200 x 2 x 1,7
                = 680 GiB

    Penyimpanan yang dikonsumsi di luar rumus

    Selain faktor-faktor dalam rumus, item-item berikut juga mengonsumsi penyimpanan:

    • Indeks pemantauan X-Pack — Digunakan untuk analisis pengecualian:

      • .monitoring-es-6-*: Mengonsumsi penyimpanan signifikan. Secara bawaan menyimpan data 7 hari terakhir.

      • .monitoring-kibana-6-*: Bertambah seiring jumlah indeks. Secara bawaan menyimpan data 7 hari terakhir.

      • .watcher-history-3-*: Mengonsumsi penyimpanan minimal. Hapus secara manual jika tidak lagi diperlukan.

    • Log kluster — Termasuk log run, log akses, dan log lambat. Secara bawaan disimpan selama 7 hari terakhir. Periode retensi ini tidak dapat diubah. Volume log meningkat seiring jumlah kueri dan dorongan data yang diterima kluster.

    Spesifikasi dan jumlah node

    Node data

    Dua aturan menentukan skala maksimum per node data:

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

    • Penyimpanan maksimum per node = Memori per node (GiB) × pengali spesifik skenario

    SkenarioPengaliPenggunaan umum
    UmumMemori x 30Beban kerja baca/tulis campuran
    KueriMemori x 10Akselerasi, agregasi
    LoggingMemori x 50Impor log, analitik offline

    Tabel berikut menunjukkan jumlah maksimum node dan penyimpanan maksimum per node untuk setiap spesifikasi:

    SpesifikasiMax nodesUmumKueriLogging
    2 vCPU, 4 GiB10120 GiB40 GiB200 GiB
    2 vCPU, 8 GiB10240 GiB80 GiB400 GiB
    4 vCPU, 16 GiB20480 GiB160 GiB800 GiB
    8 vCPU, 32 GiB40960 GiB320 GiB1,5 TiB
    16 vCPU, 64 GiB801,9 TiB640 GiB3 TiB

    Total penyimpanan kluster = Penyimpanan per node × Jumlah node

    Pilih spesifikasi node berdasarkan penyimpanan maksimum per node dan jumlah maksimum node untuk spesifikasi target Anda.

    • Jumlah node data memengaruhi jumlah total shard. Selesaikan evaluasi shard di bawah sebelum menetapkan spesifikasi node.

    • Untuk kueri yang banyak melakukan agregasi, pilih spesifikasi dengan rasio vCPU-memori 1:2 dan aktifkan node klien.

    Contoh perhitungan: Data log 2 TiB

    Skenario: Data log 2 TiB, kasus penggunaan logging, satu replika.

    1. Hitung penyimpanan yang dibutuhkan: 2 TiB × 3,4 = 6,8 TiB

    2. Pilih spesifikasi node: 8 vCPU, 32 GiB (maksimum logging: 1,5 TiB per node)

    3. Hitung jumlah node: 6,8 TiB / 1,5 TiB ≈ 5 node (dibulatkan ke atas)

    4. Verifikasi batas node: 5 node < 40 node maksimum. Valid.

    Node master khusus

    Aktifkan node master khusus untuk kluster dengan banyak node data guna menjaga stabilitas kluster. Pilih spesifikasi berdasarkan jumlah node data Anda:

    Jumlah node dataSpesifikasi node master khusus
    Default2 vCPU, 8 GiB
    Lebih dari 104 vCPU, 16 GiB
    Lebih dari 308 vCPU, 32 GiB
    Lebih dari 5016 vCPU, 64 GiB
    Jika kluster memiliki banyak indeks dan shard, atau data sering berubah, pilih spesifikasi lebih tinggi untuk node master khusus.

    Node klien

    Node klien (coordinating node dalam Elasticsearch) menangani fase reduce dari kueri terdistribusi. Node klien khusus mengisolasi dampak garbage collection (GC) dari node data.

    PanduanNilai
    Rasio node klien terhadap node data1:5
    Rasio vCPU-memori node klien1:4 atau 1:8
    Jumlah minimum node klien2

    Contoh: Untuk 10 node data dengan masing-masing 8 vCPU, 32 GiB, konfigurasikan 2 node klien dengan masing-masing 8 vCPU, 32 GiB.

    Evaluasi shard

    Shard adalah unit penyimpanan dasar dari indeks Elasticsearch, diklasifikasikan menjadi shard utama dan shard replika. Untuk informasi lebih lanjut, lihat Shard and replica shard.

    Perencanaan shard yang tepat mencegah degradasi performa, penggunaan disk yang tidak merata, dan beban CPU yang tidak seimbang di seluruh node. Rencanakan shard berdasarkan volume data per indeks, pertumbuhan data yang diharapkan, spesifikasi node, dan apakah indeks temporary perlu dihapus atau digabung secara berkala.

    Panduan ukuran shard

    SkenarioUkuran maksimum shard
    Beban kerja umum30 GiB (hingga 50 GiB dalam kasus khusus)
    Analitik log atau indeks sangat besar100 GiB

    Jumlah shard per indeks

    Tentukan jumlah shard berdasarkan volume data:

    • Volume data besar, throughput tulis tinggi: Konfigurasikan beberapa shard utama per indeks dengan satu replika per shard utama.

    • Volume data kecil, throughput tulis rendah: Konfigurasikan satu shard utama per indeks dengan satu atau lebih shard replika.

    Konfigurasi shard bawaan bervariasi berdasarkan versi:

    • V7.X dan seterusnya: 1 shard utama, 1 shard replika per indeks

    • Sebelum V7.X: 5 shard utama, 1 shard replika per indeks

    Penyeimbangan beban dengan indeks kecil: Jika volume data per indeks kurang dari 30 GiB, gunakan satu shard utama dengan beberapa replika untuk mendistribusikan beban di seluruh node. Misalnya, indeks 20 GiB pada kluster 5-node dapat menggunakan 1 shard utama dan 4 shard replika.

    Panduan distribusi shard

    • Jaga jumlah total shard sama dengan jumlah node data, atau kelipatan bulatnya.

    • Tempatkan maksimal 5 shard per indeks pada satu node.

    Total shard per node

    Hitung jumlah maksimum shard yang dapat ditampung oleh satu node data:

    Ukuran klusterRumus
    Spesifikasi kecil (atau volume data < 1 TiB)Shard per node = Memori (GiB) × 30
    Spesifikasi besarShard per node = Memori (GiB) × 50

    • Batas maksimum shard per node bawaan pada kluster V7.X adalah 1.000. Jangan ubah batas ini. Jika diperlukan lebih banyak shard, tambahkan node saja.

    • Shard berlebihan meningkatkan overhead performa dan dapat menghabiskan file handle, menyebabkan titik kegagalan kluster. Konfigurasikan shard berdasarkan kebutuhan bisnis aktual.

    Untuk panduan lebih lanjut, lihat How to size your shards.

    Praktik terbaik penskalaan dan maintenance

    • Mulai dari estimasi, lalu iterasi. Rumus dalam dokumen ini memberikan estimasi awal. Validasi dengan beban kerja representatif dan sesuaikan jika diperlukan.

    • Hapus indeks kedaluwarsa. Jika Auto Indexing diaktifkan, gunakan index lifecycle management (ILM) atau skrip API Elasticsearch untuk menghapus indeks kedaluwarsa. Untuk detailnya, lihat Use ILM to manage Heartbeat indexes.

    • Bebaskan memori heap. Segera hapus indeks kecil atau tidak terpakai untuk membebaskan memori heap.

    • Pantau kesehatan shard. Jika volume data per shard pada indeks yang ada melebihi batas yang direkomendasikan, lakukan reindex data. Untuk detailnya, lihat Use the reindex API to migrate data. Reindexing data mempertahankan kontinuitas layanan tetapi memakan waktu.

    Referensi