Cara Kerja Kunci Partisi DynamoDB

partition key Anda adalah sebuah alamat. DynamoDB melakukan hash pada kunci itu dan hash memutuskan mesin fisik mana yang menyimpan item tersebut. Pilih kuncinya dengan baik dan penyebaran beban; pilih dengan buruk dan satu server terkena panasnya.

Bagaimana cara kerja kunci partisi DynamoDB?

DynamoDB menjalankan partition key Anda melalui fungsi hash internal, dan hash tersebut memutuskan partisi fisik mana yang menyimpan item. Hash menentukan penempatan; kuncinya tidak diurutkan atau diindeks seperti kolom SQL. Pilih kunci berkardinalitas tinggi dan beban tersebar di banyak partisi; pilih yang berkardinalitas rendah dan satu partisi akan menyerap semua panas.

• Kuncinya di-hash, bukan diurutkan. DynamoDB menjalankan kunci partisi Anda melalui sebuah hash internal untuk memilih partisi. Dua nilai yang berdekatan tidak berada di dekat masing-masing nilai lainnya di disk.
• Partisi adalah unit penyimpanan sebenarnya. Masing-masing partisi memiliki kapasitas sekitar 10 GB, 3.000 baca satuan/detik dan 1.000 satuan tulis/detik. Lalu lintas Anda dibagi berapa banyak partisi kunci Anda tersebar.
• Tombol pintas adalah pijakannya. Menyalurkan sebagian besar permintaan pada satu nilai kunci partisi dan Anda melakukan throttle pada partisi itu sementara sisa tabel tidak digunakan.
• Kunci berkardinalitas tinggi menang. Semakin jelas, kunci yang dipukul secara merata akan memberi nilai pada Anda miliki, semakin banyak partisi yang menyerap beban.

Mulailah dengan apa yang sebenarnya dilakukan kunci tersebut

Berasal dari SQL, kunci utama adalah kolom yang diurutkan dan diindeks, Anda JOIN dan ORDER OLEH aktif. Di DynamoDB, kunci partisi (terkadang disebut kunci hash) berfungsi sesuatu yang berbeda: ia memutuskan penempatan.

DynamoDB memasukkan kunci partisi ke dalam fungsi hash internal. Peta keluaran ke keyspace, dan keyspace tersebut dibagi menjadi beberapa rentang — masing-masing rentang dimiliki oleh a partisi fisik. Partisi itu adalah penyimpanan nyata pada node nyata.

Jadi kunci partisi menjawab satu pertanyaan: mesin manakah yang menyimpan item ini? The sort key, jika ada, hanya pesan item di dalam mesin itu. Ini diputar tidak ada bagian dalam penempatan.

Ikuti satu penulisan melalui hash

Katakanlah Anda menjalankan SaaS yang menyerap pembacaan perangkat. Tabel Anda SensorReadings menggunakan kunci partisi deviceId dan kunci pengurutan readingTs. Anda menulis bacaan untuk deviceId = "vac-7741".

Jalur yang diperlukan untuk menulis — dari kunci Anda ke disk tempat penulisannya:

Penulisan untuk vac-7741 di-hash ke suatu titik di keyspace, titik itu termasuk jangkauan P2, dan item mendarat di P2 — dipesan di sana oleh readingTs.

Hal yang perlu diinternalisasikan: "vac-7741" dan "vac-7742" terpisah satu karakter, tapi hash mereka tidak berhubungan. Mereka hampir pasti hidup di tempat yang berbeda partisi. Tidak ada "terdekat" di ruang kunci partisi.

Ini adalah ide hashing konsisten yang diwarisi DynamoDB dari desain aslinya — makalah Amazon Dynamo 2007 ("Dynamo: Nilai Kunci Amazon yang Sangat Tersedia Store") menyebarkan kunci ke seluruh node dengan melakukan hashing secara tepat sehingga tidak ada satu node pun yang menjadi a kotakttleneck.

Tempelkan daftar nilai kunci partisi di bawah ini untuk melihat bagaimana hash menyebarkannya ember. Himpunan berkardinalitas tinggi menyebar secara merata; gunakan kembali satu nilai dan semuanya bertumpuk ke dalam satu keranjang — hot partition akan dibahas di bagian selanjutnya.

Ini adalah hash pengajaran untuk intuisi, bukan hash internal DynamoDB yang sebenarnya — itu fungsi sebenarnya, ruang kunci, dan batas partisi adalah internal AWS. Gunakan untuk membangun kesan penyebaran vs kemiringan, bukan untuk memprediksi partisi fisik mana yang menjadi kunci mendarat.

Hormati batasan keras partisi

Partisi fisik terbatas. Sesuai Panduan Pengembang AWS DynamoDB, masing-masing bertahan sekitar:

Ketika partisi melebihi 10 GB, atau throughput yang Anda sediakan memerlukan lebih banyak ruang, DynamoDB membaginya — rentang keyspace dibagi dan item didistribusikan ulang melintasi lebih banyak partisi. Ini otomatis; kamu tidak memicunya.

Pemisahan dapat mengukir kumpulan item satu kunci partisi pada kunci pengurutan batas, sehingga beban kunci yang sibuk dapat tersebar ke lebih banyak partisi. Pemisahan yang luar biasa can't rescue adalah satu item panas, kunci pengurutan yang terus meningkat, atau tabel dengan sebuah LSI - yang menyematkan koleksi ke satu partisi.

Beri nama jebakannya: partisi panas

Partisi panas adalah senjata klasik. Itu terjadi ketika satu kunci partisi nilai (atau sekelompok kecil nilai tersebut) menyerap sebagian besar lalu lintas.

Kegagalan nyata: Anda mengganti SensorReadings ke kunci partisi region dengan nilai-nilai seperti "us-east", "eu-west". Tiga wilayah berarti tiga nilai utama — paling banyak — tiga partisi melakukan pekerjaan nyata. Banting "us-east" dengan membaca dan itu throttles pada 3.000 RCU sementara total kapasitas yang disediakan tabel masih belum terpakai.

Kapasitas adaptif DynamoDB memperhalus hal ini — ia dapat menggeser throughput yang tidak terpakai menuju partisi yang sibuk, dan isolasi satu kunci yang sangat panas ke partisinya sendiri partisi. AWS merinci hal ini di re:Invent "Pola Desain Tingkat Lanjut untuk DynamoDB" sesi menyelam mendalam. Namun kapasitas adaptasi memberi waktu, bukan kekebalan: a satu item panas, kunci pengurutan yang terus meningkat, atau LSI masih membatasi satu kunci pada a partisi tunggal. Desain untuk penyebaran; jangan bersandar pada jaring pengaman.

Pilih kunci berkardinalitas tinggi

Cara mengatasinya adalah kardinalitas — jumlah nilai kunci yang berbeda, dan seberapa meratanya lalu lintas menghantam mereka.

• Kardinalitas rendah (region, status, true/false): sedikit partisi, konsentrasi lalu lintas, Anda melakukan throttle lebih awal.
• Kardinalitas tinggi (deviceId, userId, ID pesanan): banyak nilai yang di-hashing di banyak partisi, beban menyebar, ruang kepala bertambah.

Berasal dari SQL Anda akan dengan senang hati mengindeks kolom status dan memfilternya. Sebagai sebuah Kunci partisi DynamoDB itu jebakan — tidak bisa menyebar. Pertahankan kardinalitas rendah atribut sebagai filter atau sebagai kunci pengurutan indeks sekunder, tidak pernah sebagai hal yang menentukan penempatan.

Ketika kunci yang secara alami bagus masih miring — segelintir penyewa ikan paus melampaui kunci tersebut rest — tambahkan sufiks untuk menyebarkan satu nilai logis di N partisi, mis. tenantId#3 untuk jalur tulis yang terpecah. Anda menggabungkan kembali saat dibaca.

Untuk menargetkan item dalam partisi setelah kunci Anda tersebar, Anda akan menulis a KeyConditionExpression pada tombol sortir. Anda dapat merakitnya sendiri skema di pembuat ekspresi DynamoDB sebelum memasukkannya ke dalam kode:

deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"

Itu membaca jendela bulan Juni satu perangkat dari satu partisi — Query, bukan a Pindai. Kunci partisi menyematkan mesin; kunci sortir kondisi mempersempit barisan.

Jebakan dan langkah selanjutnya

• Jangan memilih kunci berdasarkan apa yang terbaca dengan baik di SQL. Pilih berdasarkan apa spreads. Kardinalitas pertama, kenyamanan kueri kedua.
• Jangan berasumsi bahwa total kapasitas tabel adalah milik Anda per kunci. Throughput adalah milik Anda per partisi; satu nilai panas dapat melakukan throttle sementara tabel terlihat menganggur.
• Jangan bertengkar. Ini otomatis dan didorong oleh hash — tugas Anda adalah memberikannya kunci yang cukup berbeda untuk disebarkan.

Setelah kunci Anda tersebar dengan rapi, keputusan selanjutnya adalah bagaimana menata item di dalamnya partisi — lihat desain meja tunggal — dan ketika a indeks sekunder adalah alat yang tepat untuk akses kedua pola.

Unduh DynoTable dan jalankan GROUP BY melalui kunci partisi Anda di SQL Workbench untuk melihat kunci mana yang menumpuk item sebelum diubah menjadi partisi panas.