Memilih jumlah serpihan

Setelah memahami persyaratan penyimpanan, Anda dapat menyelidiki strategi pengindeksan. Secara default di OpenSearch Layanan, setiap indeks dibagi menjadi lima pecahan utama dan satu replika (total 10 pecahan). Perilaku ini berbeda dari open source OpenSearch, yang default ke satu pecahan primer dan satu replika. Karena Anda tidak dapat dengan mudah mengubah jumlah serpihan primer untuk indeks yang ada, Anda harus memutuskan tentang jumlah serpihan sebelum mengindeks dokumen pertama Anda.

Tujuan keseluruhan memilih sejumlah pecahan adalah untuk mendistribusikan indeks secara merata di semua node data di cluster. Namun, serpihan ini seharusnya tidak terlalu besar atau terlalu banyak. Pedoman umum adalah mencoba menjaga ukuran pecahan antara 10-30 GiB untuk beban kerja di mana latensi pencarian adalah tujuan kinerja utama, dan 30-50 GiB untuk beban kerja berat tulis seperti analitik log.

Pecahan besar dapat menyulitkan OpenSearch untuk pulih dari kegagalan, tetapi karena setiap pecahan menggunakan sejumlah CPU dan memori, memiliki terlalu banyak pecahan kecil dapat menyebabkan masalah kinerja dan kesalahan memori. Dengan kata lain, pecahan harus cukup kecil sehingga instance OpenSearch Service yang mendasarinya dapat menanganinya, tetapi tidak terlalu kecil sehingga mereka menempatkan tekanan yang tidak perlu pada perangkat keras.

Misalnya, anggap Anda memiliki 66 GiB data. Anda tidak mengharapkan angka itu meningkat dari waktu ke waktu, dan Anda ingin menyimpan serpihan Anda sekitar 30 GiB masing-masing. Oleh karena itu, jumlah serpihan Anda harus kira-kira 66 * 1,1/30 = 3. Anda dapat menggeneralisasi perhitungan ini sebagai berikut:

(Data sumber+ruang untuk tumbuh) * (1 + overhead pengindeksan)/ukuran pecahan yang diinginkan = perkiraan jumlah pecahan primer

Persamaan ini membantu mengimbangi pertumbuhan data dari waktu ke waktu. Jika Anda mengharapkan 66 GiB data yang sama menjadi empat kali lipat selama tahun depan, perkiraan jumlah serpihan adalah (66 + 198) * 1,1/30 = 10. Ingat, Anda belum memiliki data ekstra 198 GiB data. Periksa untuk memastikan bahwa persiapan untuk masa depan ini tidak menciptakan pecahan kecil yang tidak perlu yang menghabiskan sejumlah besar CPU dan memori di masa sekarang. Dalam hal ini, 66 * 1,1 / 10 serpihan = 7,26 GiB per serpihan, yang akan mengonsumsi sumber daya tambahan dan berada di bawah kisaran ukuran yang disarankan. Anda dapat mempertimbangkan middle-of-the-road pendekatan lebih dari enam pecahan, yang membuat Anda memiliki pecahan 12-GiB hari ini dan pecahan 48-GiB di masa depan. Kemudian lagi, Anda mungkin lebih memilih untuk memulai dengan tiga serpihan dan mengindeks ulang data Anda ketika serpihan melebihi 50 GiB.

Masalah yang jauh lebih jarang melibatkan pembatasan jumlah serpihan per simpul. Jika Anda ukuran serpihan Anda tepat, Anda biasanya kehabisan ruang disk lama sebelum menghadapi batas ini. Misalnya, instans m6g.large.search memiliki ukuran disk maksimum 512 GiB. Jika Anda tetap di bawah 80% penggunaan disk dan ukuran serpihan Anda pada 20 GiB, maka dapat menampung sekitar 20 serpihan. Elasticsearch 7. x dan yang lebih baru, dan semua versi OpenSearch, memiliki batas 1.000 pecahan per node. Untuk menyesuaikan pecahan maksimum per node, konfigurasikan cluster.max_shards_per_node pengaturan. Sebagai contoh, lihat Pengaturan cluster.

Mengukur serpihan dengan tepat hampir selalu membuat Anda berada di bawah batas ini, tetapi Anda juga dapat mempertimbangkan jumlah serpihan untuk setiap GiB heap Java. Pada node tertentu, memiliki tidak lebih dari 25 pecahan per GiB heap Java. Misalnya, sebuah m5.large.search instance memiliki tumpukan 4-GiB, sehingga setiap node harus memiliki tidak lebih dari 100 pecahan. Pada hitungan serpihan tersebut, setiap serpihan berukuran sekitar 5 GiB, yang jauh di bawah rekomendasi kami.