Cara Kerja Perutean Permintaan DynamoDB

Setiap baca atau tulis yang Anda kirim akan mengenai armada router permintaan tanpa kewarganegaraan terlebih dahulu. Router melakukan hash pada partition key Anda, memetakan hash tersebut ke node penyimpanan yang dimilikinya data kunci itu, dan meneruskan permintaan ke sana. Satu lompatan itulah yang menjadi alasan pencarian kunci biayanya sama apakah meja itu berisi seribu item atau satu miliar.

Bagaimana cara kerja perutean permintaan DynamoDB?

DynamoDB merutekan setiap permintaan melalui armada router permintaan stateless yang melakukan hash pada partition key Anda, memetakan hash ke node penyimpanan tunggal yang memiliki partisi tersebut, dan meneruskan proses baca atau tulis di sana. Perutean adalah fungsi murni dari hash kunci, sehingga biaya satu pencarian tetap sama, baik tabel tersebut menampung seribu atau satu miliar item.

• Router permintaan adalah pintu depan. Ini adalah armada tanpa kewarganegaraan yang membawa Anda permintaan, melakukan hash pada kunci partisi, dan merutekannya ke node penyimpanan yang menyimpannya partisi — tanpa pemindaian, tidak diperlukan pengetahuan tabel lengkap.
• Kunci partisi menentukan segalanya. Perutean adalah fungsi murni dari hash kunci partisi — kunci yang sama selalu dirutekan ke partisi pemiliknya, jadi GetItem adalah O(1), bukan O(ukuran tabel).
• Satu primer, dua sekunder. Tulisan mendarat di node primer partisi, yang mengakui kuorum (dua dari tiga replika) telah bertahan.
• Kunci yang buruk mengalahkan desain. Corong kunci berkardinalitas rendah atau "hot" partition lalu lintas ke satu node — peruteannya baik-baik saja, kunci Anda adalah masalahnya.

Mulailah dengan pemecahan masalah perutean

Berasal dari SQL, Anda membayangkan perencana kueri: ia membaca statistik, memilih indeks, mungkin scan. Biayanya berskala sesuai dengan banyaknya data yang disentuhnya. Model itu tidak cocok penyimpanan nilai kunci yang harus menjawab dalam satu digit milidetik dalam ukuran berapa pun.

Jawaban DynamoDB adalah menjadikan pencarian satu item sebagai alamat langsung, bukan a pencarian. Kunci partisi adalah masukan ke fungsi hash yang menghitung dimana data secara fisik hidup — bukan kolom yang Anda filter. Tidak ada statistik, tidak ada perencana.

Itulah perdagangan yang Anda terima ketika Anda beralih dari pemikiran relasional: Anda menyerah fleksibilitas kueri ad-hoc dan dapatkan pengalamatan waktu konstan sebagai imbalannya.

Penuhi permintaan router

Ketika permintaan tiba, permintaan itu tidak langsung masuk ke penyimpanan. Itu memenuhi permintaan router — armada tanpa kewarganegaraan dengan skala horizontal yang memimpin seluruh layanan. (Makalah USENIX ATC '22 DynamoDB describes armada router permintaan ini.)

Router melakukan tiga hal dan tidak menyimpan datanya sendiri:

• Mengautentikasi dan mengotorisasi permintaan terhadap IAM.
• Hash kunci partisi untuk menemukan partisi pemiliknya.
• Meneruskan permintaan ke node penyimpanan untuk partisi tersebut.

Karena router tidak memiliki kewarganegaraan, layanan menambahkan lebih banyak router yang sedang dimuat. Tak satu pun dari itu mereka adalah bottleneck dan tidak ada satu pun titik kegagalan — properti yang sama Makalah Amazon Dynamo 2007 membangun sistem asli.

Ikuti satu pembacaan melalui router

Ambil tabel telemetri untuk armada drone. Item dikunci oleh DroneId (partition kunci) dan ReadingTs (kunci pengurutan), dengan atribut seperti BatteryPct dan AltitudeM.

Anda meminta pembacaan satu drone mulai tanggal 23 Juni:

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

Diagram di bawah menelusuri permintaan dari atas ke bawah — membacanya sebagai satu aliran ke bawah.

Router melakukan hash DRONE#A19F, memetakannya ke partisi yang memiliki kunci tersebut, dan meneruskan pembacaan ke node penyimpanan utama partisi tersebut, yang mengembalikan item.

Hash menunjuk pada one partisi dari berapa pun tabelnya memiliki. Router tidak pernah melihat partisi lain, jadi tambahkan drone — dan partisi — tidak memperlambat pencarian ini.

Ketahui apa sebenarnya partisi itu

Partisi adalah unit penyimpanan dan throughput. Masing-masing dibatasi (kira-kira 10 GB dan kapasitas baca/tulis tetap), dan DynamoDB membagi partisi ketika melampaui batas mana pun. Setiap item dengan kunci partisi tertentu dimulai pada satu item partisi; split-for-heat nantinya dapat mengukir koleksi itu berdasarkan rentang tombol sortir (kecuali sebuah LSI atau kunci semacam monoton menyematkannya), yang masih membuat Query berakhir satu kunci partisi murah.

Setiap partisi direplikasi ke tiga node penyimpanan yang tersebar di Ketersediaan Zona: satu primer dan dua sekunder.

Penulisan masuk ke pemilihan pendahuluan, yang mengakui penulisan sekali mencapai kuorum (dua dari tiga replika) telah bertahan. Pembacaan strongly consistent dirutekan ke pembacaan utama jadi itu mencerminkan tulisan terbaru. Pembacaan eventually consistent dapat disajikan oleh perusahaan sekunder yang belum mengejar ketinggalan — setengah biayanya, mungkin sudah basi.

Beri nama footgun: kunci partisi panas

Perutean hanya sebaik kunci partisi Anda. Hash menyebarkan kunci secara merata, jadi jika kunci Anda memiliki kardinalitas tinggi dan lalu lintas merata, beban tersebar di seluruh kunci node. Hancurkan salah satu properti dan Anda mendapatkan partisi panas.

Katakanlah Anda memasukkan telemetri itu dengan Region, bukan DroneId. Sekarang setiap drone masuk us-east-1 berbagi satu kunci partisi — jadi hash baca dan tulisnya sama slot keyspace dan tumpuk ke dalam satu koleksi item. Router melakukan tugasnya dengan sempurna; Anda baru saja menyalurkan seluruh armada pada kapasitas satu partisi.

Anda tidak dapat melihat router memilih sebuah node, tetapi Anda dapat mendesain kunci yang merutekan dengan baik. Saat Anda membangun kondisi kunci di Pembuat Ekspresi, kunci partisi yang Anda masukkan di sebelah kiri PK = … adalah nilai persis yang akan di-hash oleh router — simpan nilai tersebut nilai kardinalitas tinggi adalah apa yang terus dibaca pada node terpisah.

Bagaimana hal ini terkait dengan pola akses Anda

Perutean permintaan adalah mekanisme yang membuat desain tabel tunggal aturan yang tidak dapat dinegosiasikan: Anda memodelkan kunci partisi karena kunci partisi adalah alamatnya. Itu juga mengapa Query mengalahkan Scan — Query mencapai satu partisi melalui router, sementara Scan berjalan di setiap partisi partisi secara berurutan.

Indeks sekunder mendapatkan partisi dan rutenya sendiri: a GSI dirutekan oleh kunci partisinya sendiri, independen dari meja dasar, itulah sebabnya GSI bisa tetap panas meskipun mejanya tidak.

Langkah selanjutnya

Rancang kunci yang merutekan ke banyak node, bukan satu. Buat sketsa kondisi PK = … di Pembuat Ekspresi untuk melihat nilai yang mana akan di-hash, lalu unduh DynoTable untuk menjalankan kueri tersebut terhadap file Anda memiliki tabel dan melihat dengan tepat apa yang dikembalikan oleh setiap kondisi kunci.