Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Praktik terbaik untuk merancang dan menggunakan kunci partisi secara efektif di DynamoDB
Kunci primer yang secara unik mengidentifikasi setiap item dalam tabel Amazon DynamoDB bisa sederhana (hanya kunci partisi) atau komposit (kunci partisi dikombinasikan dengan kunci urutan).
Anda harus mendesain aplikasi Anda untuk aktivitas seragam di semua kunci partisi dalam tabel dan indeks sekundernya. Anda dapat menentukan pola akses yang diperlukan aplikasi Anda, serta unit baca dan tulis yang diperlukan setiap tabel dan indeks sekunder.
**catatan**
Kapasitas adaptif berlaku untuk mode sesuai permintaan dan kapasitas yang disediakan.
Setiap partisi dalam tabel DynamoDB dirancang untuk memberikan kapasitas maksimum 3.000 unit baca per detik dan 1.000 unit tulis per detik. Satu unit baca mewakili satu operasi baca yang sangat konsisten per detik, atau dua operasi baca yang akhirnya konsisten per detik, untuk item berukuran hingga 4 KB. Satu unit tulis mewakili satu operasi tulis per detik untuk item berukuran hingga 1 KB.
Anda harus memperhitungkan ukuran item saat mengevaluasi batas throughput partisi untuk tabel Anda. Misalnya, jika tabel memiliki ukuran item 20 KB, satu operasi baca yang konsisten akan mengkonsumsi 5 unit baca. Ini berarti Anda dapat secara bersamaan mendorong 600 operasi baca yang konsisten per detik pada satu item tersebut sebelum mencapai batas partisi. Total throughput di semua partisi dalam tabel dapat dibatasi oleh throughput yang disediakan dalam mode yang disediakan, atau oleh batas throughput tingkat tabel dalam mode sesuai permintaan. Lihat [Kuota Layanan](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html) untuk informasi selengkapnya.
**Topics**
+ [
# Merancang kunci partisi untuk mendistribusikan beban kerja Anda di DynamoDB
](bp-partition-key-uniform-load.md)
+ [
# Menggunakan sharding tulis untuk mendistribusikan beban kerja secara merata di tabel DynamoDB Anda
](bp-partition-key-sharding.md)
+ [
# Mendistribusikan aktivitas menulis secara efisien selama pengunggahan data di DynamoDB
](bp-partition-key-data-upload.md)
# Merancang kunci partisi untuk mendistribusikan beban kerja Anda di DynamoDB
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 I/O permintaan secara efektif dapat membuat partisi “panas” yang mengakibatkan pelambatan dan menggunakan kapasitas yang disediakan I/O 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](workbench.Modeler.md).
# Menggunakan sharding tulis untuk mendistribusikan beban kerja secara merata di tabel DynamoDB Anda
Salah satu cara untuk mendistribusikan penulisan dengan lebih baik di seluruh ruang kunci partisi di Amazon DynamoDB adalah dengan memperluas ruang tersebut. Hal ini dapat dilakukan dengan berbagai cara. Anda dapat menambahkan angka acak pada nilai kunci partisi untuk mendistribusikan item di antara partisi. Atau, Anda dapat menggunakan angka yang dihitung berdasarkan sesuatu yang Anda kueri.
## Pembagian menggunakan akhiran acak
Salah satu strategi untuk mendistribusikan beban lebih merata di seluruh ruang kunci partisi adalah dengan menambahkan angka acak ke akhir nilai kunci partisi. Kemudian Anda mengacak penulisan di ruang yang lebih besar.
Misalnya, untuk kunci partisi yang menunjukkan tanggal hari ini, Anda dapat memilih nomor acak antara `1` dan `200` dan menggabungkannya sebagai akhiran untuk tanggal. Ini menghasilkan nilai kunci partisi seperti `2014-07-09.1`, `2014-07-09.2`, dan sebagainya, melalui `2014-07-09.200`. Karena Anda mengacak kunci partisi, penulisan ke tabel pada setiap hari tersebar merata di sejumlah partisi. Hal ini menghasilkan paralelisme yang lebih baik dan throughput keseluruhan yang lebih tinggi.
Namun, untuk membaca semua item pada hari tertentu, Anda harus mengkueri item untuk semua akhiran lalu menggabungkan hasilnya. Misalnya, Anda akan terlebih dahulu mengeluarkan permintaan `Query` untuk nilai kunci partisi `2014-07-09.1`. Kemudian mengeluarkan `Query` lainnya untuk `2014-07-09.2`, dan seterusnya, melalui `2014-07-09.200`. Terakhir, aplikasi Anda harus menggabungkan hasil dari semua permintaan `Query` tersebut.
## Pembagian menggunakan akhiran terhitung
Strategi pengacakan dapat meningkatkan throughput tulis secara signifikan. Namun, sulit untuk membaca item tertentu karena Anda tidak mengetahui nilai akhiran mana yang digunakan saat menulis item tersebut. Untuk mempermudah membaca item satu per satu, Anda dapat menggunakan strategi yang berbeda. Alih-alih menggunakan angka acak untuk mendistribusikan item di antara partisi, gunakan angka yang dapat Anda hitung berdasarkan sesuatu yang ingin Anda kueri.
Pertimbangkan contoh sebelumnya, yaitu tabel menggunakan tanggal hari ini dalam kunci partisi. Sekarang anggaplah setiap item memiliki atribut `OrderId` yang dapat diakses, dan Anda sering kali perlu mencari item berdasarkan ID urutan selain tanggal. Sebelum aplikasi Anda menulis item ke tabel, aplikasi Anda dapat menghitung akhiran hash berdasarkan ID urutan dan menambahkannya ke tanggal kunci partisi. Penghitungannya dapat menghasilkan angka antara 1 dan 200 yang terdistribusi cukup merata, mirip dengan yang dihasilkan strategi acak.
Perhitungan sederhana mungkin sudah cukup, seperti produk nilai titik kode UTF-8 untuk karakter dalam ID urutan, modulo 200, \$1 1. Nilai kunci partisi kemudian akan menjadi tanggal yang digabungkan dengan hasil penghitungan.
Dengan strategi ini, penulisan tersebar merata di seluruh nilai kunci partisi, serta di partisi fisik. Anda dapat dengan mudah melakukan operasi `GetItem` untuk item dan tanggal tertentu karena Anda dapat menghitung nilai kunci partisi untuk nilai `OrderId` tertentu.
Untuk membaca semua item pada hari tertentu, Anda masih harus `Query`setiap kunci `2014-07-09.N` (dengan `N` adalah 1–200), dan aplikasi Anda kemudian harus menggabungkan semua hasilnya. Manfaatnya adalah Anda menghindari satu nilai kunci partisi "panas" yang mengambil semua beban kerja.
**catatan**
Untuk strategi yang lebih efisien yang dirancang khusus untuk menangani data deret waktu volume tinggi, lihat [Data deret waktu](bp-time-series.md).
# Mendistribusikan aktivitas menulis secara efisien selama pengunggahan data di DynamoDB
Biasanya, ketika Anda memuat data dari sumber data lain, Amazon DynamoDB mempartisi data tabel Anda pada beberapa server. Anda akan mendapatkan performa yang lebih baik jika mengunggah data ke semua server yang dialokasikan secara bersamaan.
Contoh, misalkan Anda ingin mengunggah pesan pengguna ke tabel DynamoDB yang menggunakan kunci primer komposit dengan `UserID` sebagai kunci partisi dan `MessageID` sebagai kunci urutan.
Saat mengunggah data, salah satu pendekatan yang dapat Anda lakukan adalah mengunggah semua item pesan untuk setiap pengguna, satu per satu:
****
| UserID | MessageID |
| --- | --- |
| U1 | 1 |
| U1 | 2 |
| U1 | ... |
| U1 | ... hingga 100 |
| U2 | 1 |
| U2 | 2 |
| U2 | ... |
| U2 | ... hingga 200 |
Masalahnya dalam kasus ini adalah Anda tidak mendistribusikan permintaan tulis ke DynamoDB di seluruh nilai kunci partisi Anda. Anda mengambil satu nilai kunci partisi pada satu waktu dan mengunggah semua itemnya sebelum melanjutkan ke nilai kunci partisi berikutnya dan melakukan hal yang sama.
Di balik layar, DynamoDB mempartisi data di tabel Anda di beberapa server. Untuk sepenuhnya menggunakan semua kapasitas throughput yang disediakan untuk tabel, Anda harus mendistribusikan beban kerja ke nilai kunci partisi Anda. Dengan mengarahkan pekerjaan unggahan dalam jumlah yang tidak merata ke item yang semuanya memiliki nilai kunci partisi yang sama, Anda tidak sepenuhnya menggunakan semua sumber daya yang telah disediakan DynamoDB untuk tabel Anda.
Anda dapat mendistribusikan pekerjaan unggahan Anda menggunakan kunci urutan untuk memuat satu item dari setiap nilai kunci partisi, kemudian item lain dari setiap nilai kunci partisi, dan seterusnya:
****
| UserID | MessageID |
| --- | --- |
| U1 | 1 |
| U2 | 1 |
| U3 | 1 |
| ... | ... |
| U1 | 2 |
| U2 | 2 |
| U3 | 2 |
| ... | ... |
Setiap unggahan dalam urutan ini menggunakan nilai kunci partisi yang berbeda, sehingga lebih banyak server DynamoDB sibuk secara bersamaan dan meningkatkan performa throughput Anda.