Cara Kerja Request Routing DynamoDB

Setiap pembacaan atau tulisan yang Anda kirim mengenai armada request router stateless terlebih dahulu. Sebuah router meng-hash partition key Anda, memetakan hash ke storage node yang memiliki data key itu, dan meneruskan request ke sana. Satu lompatan itulah mengapa pencarian key berbiaya sama baik tabel menampung seribu Item atau semiliar.

Bagaimana cara kerja request routing DynamoDB?

DynamoDB merutekan setiap request melalui armada request router stateless yang meng-hash partition key Anda, memetakan hash ke storage node tunggal yang memiliki partition tersebut, dan meneruskan operasi baca atau tulis ke sana. Routing adalah fungsi murni dari hash key, sehingga satu pencarian berbiaya sama baik tabel menampung seribu item maupun semiliar.

• Request router adalah pintu depan. Ia adalah armada stateless yang mengambil request Anda, meng-hash partition key, dan merutekannya ke storage node yang menampung partition itu — tanpa pemindaian, tanpa perlu pengetahuan tabel-penuh.
• Partition key menentukan segalanya. Routing adalah fungsi murni dari hash partition key. Key yang sama, node yang sama, setiap kali — jadi GetItem itu O(1), bukan O(ukuran tabel).
• Satu primary, dua secondary. Sebuah tulisan mendarat di primary node partition, yang mereplikasi ke dua secondary di seluruh Availability Zone sebelum ia durabel.
• Key buruk mengalahkan desainnya. Sebuah partition key ber-cardinality-rendah atau "panas" menyalurkan lalu lintas ke satu node — routing-nya baik-baik saja, key Anda-lah masalahnya.

Mulai dengan masalah yang dipecahkan routing

Datang dari SQL, Anda membayangkan sebuah query planner: ia membaca statistik, memilih index, mungkin memindai. Biayanya menskala dengan seberapa banyak data yang disentuhnya. Model itu tidak pas untuk key-value store yang harus menjawab dalam milidetik satu-digit pada ukuran apa pun.

Jawaban DynamoDB adalah membuat pencarian satu-Item sebuah alamat langsung, bukan pencarian. Partition key bukan kolom yang Anda filter — ia adalah input ke fungsi hash yang menghitung di mana data secara fisik tinggal. Tanpa statistik, tanpa planner.

Itulah pertukaran yang Anda terima saat beralih dari pemikiran relasional: Anda melepas fleksibilitas query ad-hoc dan mendapat pengalamatan bertenaga-konstan sebagai gantinya.

Kenalan dengan request router

Saat sebuah request tiba, ia tidak langsung menuju penyimpanan. Ia mengenai sebuah request router — armada stateless berskala horizontal yang menjadi muka seluruh layanan. (Sesi AWS re:Invent "DynamoDB Deep Dive" menjelaskan armada front-end ini.)

Router melakukan tiga hal dan tidak menampung data miliknya sendiri:

• Mengautentikasi dan mengotorisasi request terhadap IAM.
• Meng-hash partition key untuk menemukan partition yang memilikinya.
• Meneruskan request ke storage node untuk partition itu.

Karena router stateless, layanan menambahkan lebih banyak darinya di bawah beban. Tak satu pun darinya menjadi bottleneck dan tak satu pun menjadi titik kegagalan tunggal — properti yang sama yang dibangun paper Amazon Dynamo 2007 di sekitar sistem aslinya.

Ikuti satu pembacaan melalui router

Ambil sebuah tabel telemetri untuk armada drone. Item di-key oleh DroneId (partition key) dan ReadingTs (sort key), dengan atribut seperti BatteryPct dan AltitudeM.

Anda meminta pembacaan terbaru untuk satu drone:

PK = "DRONE#A19F"
SK begins_with "2026-06-23"

Berikut apa yang dilakukan router dengannya. Pengantar di bawah menelusuri request dari atas ke bawah — bacalah sebagai satu aliran ke bawah.

Router meng-hash DRONE#A19F, memetakannya ke partition yang memiliki key itu, dan meneruskan pembacaan ke primary storage node partition itu, yang mengembalikan Item.

Wawasan kuncinya: hash menunjuk ke satu partition dari berapa pun yang dimiliki tabel. Router tidak pernah melihat partition lain, jadi menambah drone — dan partition — tidak memperlambat pencarian ini.

Ketahui apa sebenarnya sebuah partition

Sebuah partition adalah unit penyimpanan dan throughput. Masing-masing dibatasi (kira-kira 10 GB dan sebuah irisan tetap dari read/write capacity), dan DynamoDB memecah sebuah partition saat ia melampaui salah satu batas. Setiap Item dengan partition key tertentu tinggal di partition yang sama, itulah yang membuat sebuah Query atas satu partition key murah.

Setiap partition direplikasi ke tiga storage node yang tersebar di seluruh Availability Zone: satu primary dan dua secondary.

Sebuah tulisan masuk ke primary, yang mereplikasi ke secondary sebelum mengonfirmasi durabilitas. Sebuah pembacaan strongly-consistent dirutekan ke primary sehingga ia mencerminkan tulisan terbaru. Sebuah pembacaan eventually-consistent bisa dilayani oleh secondary yang belum menyusul — separuh biaya, mungkin basi.

Sebut footgun-nya: partition key panas

Routing hanya sebaik partition key Anda. Hash menyebar key secara merata, jadi jika key Anda punya cardinality tinggi dan lalu lintas merata, beban tersebar di seluruh node. Patahkan salah satu properti dan Anda mendapat sebuah hot partition.

Misalkan Anda meng-key telemetri itu berdasarkan Region alih-alih DroneId. Kini setiap drone di us-east-1 berbagi satu partition key — jadi setiap pembacaan dan tulisan mereka di-hash ke node yang sama. Router melakukan tugasnya dengan sempurna; Anda hanya menyalurkan seluruh armada ke kapasitas satu partition.

Anda tak bisa menyaksikan router memilih sebuah node, tapi Anda bisa merancang key yang dirutekan dengan baik. Saat Anda membangun sebuah key condition di Expression Builder, partition key yang Anda taruh di kiri PK = … adalah nilai persis yang akan di-hash router — menjaga nilai itu ber-cardinality-tinggi adalah yang menjaga pembacaan tetap di node terpisah.

Bagaimana ini terkait kembali ke pola akses Anda

Request routing adalah mekanisme yang membuat aturan single-table design tidak bisa ditawar: Anda memodelkan di sekitar partition key karena partition key adalah alamatnya. Ia juga mengapa sebuah Query mengalahkan Scan — sebuah Query mengenai satu partition melalui router, sementara sebuah Scan menjelajahi setiap partition secara berurutan.

Index sekunder mendapat partition-nya sendiri dan routing-nya sendiri: sebuah GSI dirutekan oleh partition key-nya sendiri, independen dari tabel basis, itulah mengapa sebuah GSI bisa panas bahkan saat tabel tidak.

Langkah berikutnya

Rancang key yang dirutekan ke banyak node, bukan satu. Sketsakan condition PK = … di Expression Builder untuk melihat persis nilai mana yang di-hash, lalu unduh DynoTable untuk menjalankan query itu terhadap tabel Anda sendiri dan menyaksikan partition key mana yang sebenarnya membawa lalu lintas Anda.