Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengatur ukuran cluster DAX Anda

Total kapasitas dan ketersediaan klaster DAX tergantung pada jenis dan jumlah node. Lebih banyak node dalam cluster meningkatkan kapasitas bacanya, tetapi tidak kapasitas tulis. Jenis node yang lebih besar (hingga r5.8xlarge) dapat menangani lebih banyak penulisan, tetapi terlalu sedikit node dapat memengaruhi ketersediaan ketika kegagalan node terjadi. Untuk informasi selengkapnya tentang ukuran cluster DAX Anda, lihat. Panduan pengukuran klaster DAX

Bagian berikut membahas berbagai aspek ukuran yang harus Anda pertimbangkan untuk menyeimbangkan jenis dan jumlah node untuk membuat cluster yang dapat diskalakan dan hemat biaya.

Perencanaan ketersediaan

Saat menentukan ukuran cluster DAX, Anda harus terlebih dahulu fokus pada ketersediaan yang ditargetkan. Ketersediaan layanan berkelompok, seperti DAX, adalah dimensi dari jumlah total node dalam cluster. Karena cluster node tunggal tidak memiliki toleransi untuk kegagalan, ketersediaannya sama dengan satu node. Dalam cluster 10 node, hilangnya satu node memiliki dampak minimal terhadap kapasitas keseluruhan cluster. Kerugian ini tidak berdampak langsung pada ketersediaan karena node yang tersisa masih dapat memenuhi permintaan baca. Untuk melanjutkan penulisan, DAX dengan cepat menominasikan node utama baru.

DAX adalah VPC-based. Ini menggunakan grup subnet untuk menentukan Zona Keter sediaan mana yang dapat di jalankan node dan alamat IP mana yang akan digunakan dari subnet. Untuk beban kerja produksi, kami sangat menyarankan Anda menggunakan DAX dengan setidaknya tiga node di Zona Ketersediaan yang berbeda. Ini memastikan bahwa cluster memiliki lebih dari satu node tersisa untuk menangani permintaan bahkan jika satu node atau Availability Zone gagal. Sebuah cluster dapat memiliki hingga 11 node, di mana satu adalah node utama dan 10 adalah replika baca.

Merencanakan throughput tulis

Semua cluster DAX memiliki node utama untuk permintaan write-through. Ukuran tipe node untuk cluster menentukan kapasitas penulisannya. Menambahkan replika baca tambahan tidak meningkatkan kapasitas tulis cluster. Oleh karena itu, Anda harus mempertimbangkan kapasitas tulis selama pembuatan cluster karena Anda tidak dapat mengubah jenis node nanti.

Jika aplikasi Anda perlu menulis melalui DAX untuk memperbarui cache item, pertimbangkan peningkatan penggunaan sumber daya cluster untuk memfasilitasi penulisan. Menulis melawan DAX menghabiskan sekitar 25 kali lebih banyak sumber daya daripada pembacaan cache-hit. Ini mungkin memerlukan tipe node yang lebih besar daripada untuk cluster read-only.

Untuk panduan tambahan tentang menentukan apakah write-through atau write-around akan bekerja paling baik untuk aplikasi Anda, lihat. Strategi untuk penulisan

Merencanakan throughput baca

Kapasitas baca cluster DAX bergantung pada rasio hit cache beban kerja Anda. Karena DAX membaca data dari DynamoDB ketika cache hilang terjadi, DAX menghabiskan sekitar 10 kali lebih banyak sumber daya cluster daripada cache-hit. Untuk meningkatkan hit cache, ting katkan pengaturan TTL cache untuk menentukan periode di mana item disimpan dalam cache. Namun, durasi TTL yang lebih tinggi meningkatkan kemungkinan membaca versi item yang lebih lama kecuali pembaruan ditulis melalui DAX.

Untuk memastikan bahwa cluster memiliki kapasitas baca yang cukup, skala cluster secara horizontal seperti yang disebutkan diMenskalakan cluster secara horizontal. Menambahkan lebih banyak node menambahkan replika baca ke kumpulan sumber daya, sementara menghapus node mengurangi kapasitas baca. Saat Anda memilih jumlah node dan ukurannya untuk cluster, pertimbangkan jumlah minimum dan maksimum kapasitas baca yang diperlukan. Jika Anda tidak dapat menskalakan cluster secara horizontal dengan tipe node yang lebih kecil untuk memenuhi persyaratan baca Anda, gunakan tipe node yang lebih besar.

Merencanakan ukuran dataset

Setiap jenis node yang tersedia memiliki ukuran memori yang ditetapkan untuk DAX untuk menyimpan data cache. Jika tipe node terlalu kecil, kumpulan data kerja yang diminta aplikasi tidak akan muat dalam memori dan mengakibatkan cache hilang. Karena node yang lebih besar mendukung cache yang lebih besar, gunakan tipe node yang lebih besar dari perkiraan kumpulan data yang perlu Anda simpan dalam cache. Cache yang lebih besar juga meningkatkan rasio hit cache.

Anda mungkin mendapatkan pengembalian yang semakin berkurang untuk item cache dengan beberapa pembacaan berulang. Hitung ukuran memori untuk item yang sering diakses dan pastikan cache cukup besar untuk menyimpan kumpulan data itu.

Menghitung perkiraan persyaratan kapasitas cluster

Anda dapat memperkirakan kebutuhan kapasitas total beban kerja Anda untuk membantu Anda memilih ukuran dan jumlah node cluster yang sesuai. Untuk melakukan estimasi ini, hitung permintaan variabel yang dinormalisasi per detik (Normalized RPS). Variabel ini mewakili total unit kerja yang dibutuhkan aplikasi Anda untuk didukung oleh cluster DAX, termasuk hit cache, kesalahan cache, dan penulisan. Untuk menghitung RPS Normalisasi, gunakan input berikut:

Dengan menggunakan rumus berikut, Anda dapat menghitung RPS Normalisasi.

Normalized RPS = (ReadRPS_CacheHit * Size) + (ReadRPS_CacheMiss * Size * 10x_ReadMissFactor) + (WriteRequestRate * 25x_WriteFactor * Size * DaxNodeCount)

Misalnya, pertimbangkan nilai input berikut:

Dengan mengganti nilai-nilai ini dalam rumus, Anda dapat menghitung RPS Normalisasi sebagai berikut.

Normalized RPS = (50,000 Cache Hits/Sec * 2KB) + (1,000 Cache Misses/Sec * 2KB * 10) + (100 Writes/Sec * 25 * 2KB * 3)

Dalam contoh ini, nilai yang dihitung dari Normalized RPS adalah 135.000. Namun, nilai RPS Normalisasi ini tidak memperhitungkan menjaga pemanfaatan cluster di bawah 100% atau kehilangan node. Kami menyarankan Anda memperhitungkan kapasitas tambahan. Untuk melakukan ini, tentukan yang lebih besar dari dua faktor pengganda: pemanfaatan target atau toleransi kehilangan simpul. Kemudian, kalikan RPS Normalisasi dengan faktor yang lebih besar untuk mendapatkan permintaan target per detik (Target RPS).

Dengan menggunakan rumus berikut, Anda dapat menghitung RPS Target.

Target RPS = Normalized RPS * CEILING(TargetUtilization, NodeLossTolerance)

Misalnya, untuk menghitung RPS Target, pertimbangkan nilai-nilai berikut:

Dengan mengganti nilai-nilai ini dalam rumus, Anda dapat menghitung RPS Target sebagai berikut.

Target RPS = 135,000 * CEILING(1.43, 1.5)

Dalam contoh ini, karena nilainya NodeLossTolerance lebih besar dariTargetUtilization, kita menghitung nilai Target RPS denganNodeLossTolerance. Ini memberi kita Target RPS sebesar 202.500, yang merupakan jumlah total kapasitas yang harus didukung oleh cluster DAX. Untuk menentukan jumlah node yang Anda perlukan dalam sebuah cluster, petakan RPS Target ke kolom yang sesuai dalam tabel Memperkirakan kapasitas throughput cluster berdasarkan jenis node berikut. Untuk contoh RPS Target 202.500 ini, Anda memerlukan tipe node dax.r5.large dengan tiga node.

Memperkirakan kapasitas throughput cluster berdasarkan jenis node

Dengan menggunakanTarget RPS formula, Anda dapat memperkirakan kapasitas cluster untuk berbagai jenis node. Tabel berikut menunjukkan perkiraan kapasitas untuk cluster dengan 1, 3, 5, dan 11 jenis node. Kapasitas ini tidak menggantikan kebutuhan untuk melakukan pengujian beban DAX dengan data dan pola permintaan Anda sendiri. Selain itu, kapasitas ini tidak menyer takan instance tipe-t karena kurangnya kapasitas CPU tetap. Unit untuk semua nilai dalam tabel berikut adalah Normalized RPS.

Karena batas maksimum 1 juta NPS (operasi jaringan per detik) untuk setiap node, node tipe dax.r5.8xlarge atau lebih besar tidak berkontribusi kapasitas cluster tambahan. Jenis node yang lebih besar dari 8xlarge mungkin tidak berkontribusi pada kapasitas throughput total cluster. Namun, jenis node tersebut dapat membantu untuk menyimpan kumpulan data kerja yang lebih besar dalam memori.

Penskalaan kapasitas tulis di cluster DAX

Setiap penulisan ke DAX mengkonsumsi 25 permintaan yang dinormalisasi pada setiap node. Karena ada batas 1 juta RPS untuk setiap node, cluster DAX dibatasi hingga 40.000 penulisan per detik, tidak memperhitungkan penggunaan baca.

Jika kasus penggunaan Anda membutuhkan lebih dari 40.000 penulisan per detik dalam cache, Anda harus menggunakan cluster DAX terpisah dan membagi penulisan di antara mereka. Mirip dengan DynamoDB, Anda dapat melakukan hash kunci partisi untuk data yang Anda tulis ke cache. Kemudian, gunakan modulus untuk menentukan pecahan mana untuk menulis data.

Contoh berikut menghitung hash dari string input. Kemudian menghitung modulus nilai hash dengan 10.

def hash_modulo(input_string):
    # Compute the hash of the input string
    hash_value = hash(input_string)

    # Compute the modulus of the hash value with 10
    bucket_number = hash_value % 10

    return bucket_number

#Example usage
if _name_ == "_main_":
    input_string = input("Enter a string: ")
    result = hash_modulo(input_string)
    print(f"The hash modulo 10 of '{input_string}' is: {result}.")