Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Bagian kunci partisi pada kunci primer tabel menentukan partisi logis tempat data tabel disimpan. Pada gilirannya, hal ini akan memengaruhi partisi fisik yang mendasarinya. Desain kunci partisi yang tidak mendistribusikan permintaan I/O secara efektif dapat membuat partisi “panas” yang mengakibatkan throttling dan menggunakan kapasitas I/O yang disediakan secara tidak efisien.
Penggunaan optimal throughput yang disediakan pada tabel tidak hanya tergantung pada pola beban kerja masing-masing item, tetapi juga pada desain kunci partisi. Ini tidak berarti bahwa Anda harus mengakses semua nilai kunci partisi untuk mencapai tingkat throughput yang efisien, atau bahkan persentase nilai kunci partisi yang diakses harus tinggi. Artinya, semakin banyak nilai kunci partisi berbeda yang diakses oleh beban kerja Anda, semakin banyak permintaan tersebut akan tersebar di seluruh ruang yang dipartisi. Secara umum, Anda akan menggunakan throughput yang disediakan lebih efisien karena rasio nilai kunci partisi yang diakses ke jumlah total nilai kunci partisi meningkat.
Berikut ini adalah perbandingan efisiensi throughput yang disediakan dari beberapa skema kunci partisi umum.
Nilai kunci partisi |
Keseragaman |
|---|---|
User ID, aplikasi memiliki banyak pengguna. |
Baik |
Kode status, hanya ada beberapa kemungkinan kode status. |
Buruk |
Tanggal pembuatan item, dibulatkan ke periode waktu terdekat (misalnya, hari, jam, atau menit). |
Buruk |
ID Perangkat, setiap perangkat mengakses data pada interval yang relatif sama. |
Baik |
ID Perangkat, meskipun ada banyak perangkat yang dilacak, salah satunya jauh lebih populer daripada yang lainnya. |
Buruk |
Jika tabel tunggal hanya memiliki sejumlah kecil nilai kunci partisi, pertimbangkan untuk mendistribusikan operasi tulis Anda di nilai kunci partisi yang lebih berbeda. Dengan kata lain, susun elemen kunci primer untuk menghindari satu nilai kunci partisi "panas" (banyak diminta) yang memperlambat performa secara keseluruhan.
Misalnya, pertimbangkan tabel dengan kunci primer komposit. Kunci partisi mewakili tanggal pembuatan item, dibulatkan ke hari terdekat. Kunci urutan adalah pengidentifikasi item. Pada hari tertentu, katakanlah 2014-07-09, semua item baru ditulis ke nilai kunci partisi tunggal (dan partisi fisik yang sesuai).
Jika tabel seluruhnya masuk ke dalam satu partisi (dengan mempertimbangkan pertumbuhan data Anda dari waktu ke waktu), dan jika persyaratan throughput baca dan tulis aplikasi Anda tidak melebihi kemampuan baca dan tulis dari satu partisi, aplikasi Anda tidak akan mengalami throttling yang tidak terduga sebagai akibat dari pembuatan partisi.
Untuk menggunakan NoSQL Workbench untuk DynamoDB guna membantu memvisualisasikan desain kunci partisi Anda, lihat Membangun Model Data dengan NoSQL Workbench.
