Partition fisik DynamoDB

Sebuah partition fisik adalah unit tempat DynamoDB sebenarnya menyimpan data Anda: sebuah irisan SSD, direplikasi di seluruh Availability Zone, menampung satu irisan ruang key Anda. Tabel Anda adalah hal logis. Partition adalah tempat byte — dan batas throughput — benar-benar tinggal.

Bagaimana cara kerja partition DynamoDB?

DynamoDB menyimpan tabel Anda di seluruh partition fisik — irisan SSD yang direplikasi di seluruh Availability Zone. Setiap partition mentok pada ~10 GB, 3.000 read unit/detik, dan 1.000 write unit/detik. Hash dari partition key Anda menentukan partition mana tempat sebuah item mendarat, dan DynamoDB memecah partition secara otomatis seiring tumbuh atau memanas.

• Setiap partition mentok pada ~10 GB penyimpanan, 3.000 read unit/detik, dan 1.000 write unit/detik. Plafon itu per partition, bukan per tabel.
• Hash partition key Anda memilih partition. Item dengan key yang sama mendarat bersama; satu hot key berarti satu hot partition.
• DynamoDB memecah partition untuk Anda — pada ukuran, dan pada panas berkelanjutan — tapi ia tak bisa memperbaiki key yang menyalurkan semua lalu lintas ke satu tempat.
• Throttle padahal kapasitas masih ada adalah tanda-tandanya. Sebuah error ProvisionedThroughputExceeded sementara tabel Anda di pemakaian 5% berarti satu partition tunggal mentok.

Bagaimana sebuah Item menemukan partition-nya

DynamoDB memberi makan nilai partition-key Anda melalui fungsi hash internal. Output hash memilih partition fisik. Key yang sama masuk, partition yang sama keluar — setiap kali.

Datang dari SQL, tak ada analoginya. Tak ada index B-tree yang Anda setel, tak ada shard key yang Anda tetapkan dengan tangan. Penempatan adalah hash yang tidak Anda kontrol dan tak pernah Anda lihat.

Item yang berbagi sebuah partition key membentuk sebuah item collection, disimpan bersama dan diurutkan berdasarkan sort key. Itulah yang membuat sebuah Query pada satu key murah — ia membaca satu rentetan bersebelahan pada satu partition. (Lihat Query vs Scan.)

Ambil sebuah penyimpanan match-event untuk sebuah game. Key tabelnya adalah arenaId (partition) dan eventKey (sort):

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

Setiap event untuk arena 7f3a di-hash ke partition yang sama dan menumpuk dalam urutan sort-key. Bagus untuk "baca timeline match ini." Sebuah liabilitas jika satu arena itu mendapat semua lalu lintas.

Tiga plafon yang ditegakkan setiap partition

Sebuah partition tunggal dirancang untuk menyajikan paling banyak:

Sumber: panduan AWS Best practices for designing partition keys.

Ukuran Item menskalakan matematikanya. Sebuah Item 20 KB berbiaya 5 read unit per pembacaan strongly-consistent, jadi satu partition menyajikan ~600 pembacaan semacam itu/detik sebelum ter-throttle — bukan 3.000. Bulatkan biaya tulis ke atas per 1 KB, biaya baca ke atas per 4 KB.

Jebakannya: ini adalah batas partition, bukan batas tabel. Tabel Anda bisa diprovisioning untuk 40.000 WCU dan tetap ter-throttle, karena semua tulisan menghantam satu partition yang mentok di 1.000.

Bagaimana partition memecah

DynamoDB menambah partition secara otomatis dalam dua kasus. Anda tidak pernah menjalankan perintah.

Pecah pada ukuran. Saat sebuah partition terisi menuju ~10 GB, DynamoDB memecah rentang key-nya menjadi dua dan memindahkan separuh Item ke partition baru. Penyimpanan tumbuh secara transparan; pembacaan dan tulisan Anda terus bekerja sepanjang waktu.

Pecah untuk panas. Saat sebuah partition menerima lalu lintas berkelanjutan mendekati plafon throughput-nya, DynamoDB memecah rentang key yang panas sehingga setiap separuh mendarat di partition-nya sendiri. AWS menyebut ini mekanisme split-for-heat. Lonjakan throttle singkat yang berhenti dengan sendirinya biasanya berarti sebuah pemecahan baru saja terjadi.

Pemecahan membeli ruang di banyak key, tapi node paling bawah adalah tangkapannya: sebuah pemecahan membagi rentang key, tak pernah satu key tunggal.

Mengapa sebuah hot key mengalahkan pemecah

Inilah footgun-nya. Pemecahan mendistribusikan ulang rentang partition key. Jika lalu lintas Anda terkonsentrasi pada satu nilai key, setiap request di-hash ke partition yang sama, dan tak ada rentang tersisa untuk dibagi.

Jika arena 7f3a adalah final turnamen yang menarik 4.000 tulisan/detik sementara setiap arena lain menganggur, Anda akan ter-throttle pada 1.000 — dan sebuah pemecahan tak bisa membantu, karena semua 4.000 berbagi satu key. Alasan throttle KeyRangeThroughputExceeded yang lebih baru menamai persis ini: rentang key satu partition, bukan tabel, melewati batasnya.

Solusinya ada di model data, bukan slider kapasitas. Write-shard key panas: tambahkan suffix kecil sehingga satu arena logis tersebar di N partition fisik.

arenaId = "ARENA#7f3a#3"   # shard 0..9, dipilih per tulisan

Pembacaan lalu menyebar ke seluruh shard dan menggabung di sisi-klien. Anda bisa membuat prototipe bentuk key dan Query untuk setiap shard dengan DynamoDB Expression Builder sebelum Anda menyentuh satu baris kode aplikasi.

Satu nuansa: pengecualian LSI

Ada satu kasus di mana penyimpanan memang dibatasi per partition key. Tanpa Local Secondary Index, sebuah item collection auto-memecah ke sebanyak partition yang dibutuhkannya — miliaran nilai sort-key tak masalah.

Tambahkan sebuah LSI, dan seluruh collection untuk satu partition key harus muat dalam satu partition 10 GB tunggal, karena LSI berbaginya. Itulah tebing per-PK yang dibahas di GSI vs LSI — alasan lain mengapa kebanyakan tim meraih GSI.

Merancang agar partition tetap dingin

Tuas yang sebenarnya Anda kontrol adalah partition key. Pilih satu dengan banyak nilai berbeda relatif terhadap jumlah baris, sehingga lalu lintas tersebar merata. (Lebih banyak pola di single-table design.)

• Key ber-cardinality-tinggi. Sebuah key per-pengguna atau per-tenant mengalahkan key per-hari atau per-status yang dihantam semua orang sekaligus.
• Waspadai hot key yang diketahui. Sebuah nilai "turnamen saat ini" atau "hari ini" adalah risiko konsentrasi sebelum Anda mengapal, bukan sesudah.
• Shard hot key yang tak terhindarkan. Saat satu key harus mengambil lalu lintas berlebihan, sebuah suffix adalah jalan keluar darurat standar.

Throttle padahal kapasitas masih ada adalah sinyal Anda bahwa satu partition panas. Periksa Item yang bermasalah dan latih tata letak key ter-shard di DynoTable — arahkan ke tabel Anda sendiri, temukan key yang di-overload, dan modelkan solusinya sebelum ia membangunkan Anda.