Cara kerja internal penyimpanan DynamoDB

DynamoDB adalah tabel hash yang nilainya diurutkan pohon, tersebar di seluruh mesin di tiga Availability Zone. Dua struktur data melakukan hampir semua pekerjaan: sebuah hash di partition key mengambil mesin, pohon B di sort key memesan item di dalamnya.

Bagaimana cara DynamoDB menyimpan data?

DynamoDB menyimpan data Anda sebagai tabel hash terdistribusi raksasa yang nilainya diurutkan dalam pohon B. Hash pada partition key mengambil satu node penyimpanan; B-tree mengurutkan item berdasarkan kunci pengurutan di dalamnya. Setiap penulisan ditujukan kepada pemimpin yang mereplikasi ke dua rekan di tiga Availability Zone, mengakui setelah kuorum (dua dari tiga replika) mencapainya.

• Kunci partisi di-hash, bukan dicari. DynamoDB menjalankan fungsi hash melalui PK Anda untuk menemukan node penyimpanan (atau node, setelah koleksi besar terpecah) menahan partisi itu — lompatan O(1), berapa pun ukuran tabelnya.
• Kunci pengurutan berada di pohon-B. Di dalam partisi, item disimpan di a B-tree diurutkan berdasarkan kunci pengurutan — Urutan byte UTF-8 untuk string, urutan numerik untuk Tombol angka — itulah sebabnya pembacaan rentang (begins_with, between) murah dan Scan tidak.
• Setiap penulisan dilakukan pada kuorum sebelum diterima. Penulisan ditujukan kepada pemimpin, yang mana mereplikasi ke dua rekan di AZ lain dan mengakui kuorum satu kali (dua di antaranya tiga replika) memilikinya — daya tahan dibeli sebelum PutItem Anda kembali.
• Inilah alasan mengapa aturan pola akses ada. Hash-then-tree cepat hanya jika Anda membaca dengan kunci. Tanpa kunci, tanpa jalur cepat — Anda kembali memindai pohon.

Mulailah dengan struktur data, bukan API

Berasal dari SQL, Anda membayangkan tabel sebagai baris pada disk dengan pemilihan perencana kueri indeks. DynamoDB tidak memiliki perencana. Tata letak penyimpanan adalah kontrak — apa cepat dan apa itu footgun, keduanya jatuh langsung dari dua struktur.

Bayangkan sebuah peta raksasa yang terdistribusi. Kuncinya adalah hash dari kunci partisi Anda. Itu value adalah keseluruhan B-tree item yang berbagi nilai tersebut kunci partisi, diurutkan berdasarkan kunci pengurutan.

Yang lainnya — semantik kueri, warnings 10 GB, mengapa kekuatan kunci hilang a Scan - adalah konsekuensi dari satu kalimat itu.

Hash kunci partisi untuk menemukan node

Ketika permintaan tiba, DynamoDB menerapkan fungsi hash internal ke nilai kunci partisi. Hash secara deterministik dipetakan ke satu simpul penyimpanan — partisi fisik yang memiliki item tersebut. AWS mendokumentasikan ini sebagai mekanisme di balik pencarian kunci waktu konstan terlepas dari ukuran tabel.

Itulah langkah O(1). Tabel 10 TB dan tabel 10 KB harganya sama untuk lokasi: hash, lompat, selesai. Tidak ada pemindaian indeks untuk menemukan node, tidak ada statistik, tidak ada rencana.

Tangkapannya adalah sisi lain. Jika Anda tidak menyediakan kunci partisi, DynamoDB memilikinya tidak ada node untuk dilompati — ia harus berjalan di setiap partisi. Itu Scan, dan itu perbedaan antara O(1) dan membaca seluruh tabel.

Permintaan hash ke tepat satu partisi, lalu descends partisi itu sort-key B-tree ke item — dua langkah murah daripada berjalan di meja.

Pesan item dalam pohon B per partisi

Di dalam satu partisi, item bukanlah tumpukan. Mereka ditahan di kunci B-tree dengan tombol pengurutan, diurutkan secara leksikografis. Pencarian B-tree adalah O(log n), dan yang terpenting adalah n adalah item di satu partisi, bukan keseluruhan tabel.

Inilah alasan mengapa pembacaan rentang kunci sortir murah. Ambil telemetri armada tabel tempat pembacaan setiap perangkat berada di bawah satu kunci partisi:

Karena pohon-B diurutkan, "semua pembacaan antara pukul 08:00 dan 09:00" adalah pohon descent ke nilai awal ditambah perjalanan berurutan — bukan filter untuk setiap nilai membaca perangkat yang pernah dikirim. Anda hanya membaca rentang yang cocok.

Urutan itu juga menjadi alasan mengapa kueri begins_with(SK, "READING#2026-06-23") cepat sedangkan pemfilteran pada atribut non-kunci tidak. Pohon itu dapat mencari dengan SK; itu tidak dapat mencari dengan hal lain. Untuk menyusun kondisi utama tersebut dengan aman, bangunlah kondisi tersebut di DynamoDB Expression Builder saja daripada string gabungan tangan:

KeyConditionExpression  PK = :pk AND begins_with(SK, :day)

Replikasi setiap penulisan ke tiga AZ

Partisi bukanlah satu mesin. Masing-masing direplikasi di tiga node di dalamnya tiga Availability Zone — desain kuorum berbasis pemimpin yang dirinci pada tahun 2022 Kertas USENIX ATC DynamoDB (kertas Amazon Dynamo 2007 adalah penamaan dan nenek moyang filsafat, bukan model replikasi ini).

Satu node adalah pemimpin untuk partisi tersebut. Sebuah tulisan ditujukan kepada pemimpin, yang mana menulis secara lokal dan mereplikasi ke dua rekannya. Pemimpin melakukan tugas tulis satu kali a kuorum node yang tahan lama memilikinya — jadi ketahanan di seluruh AZ dibayar sebelum PutItem Anda kembali.

Pembaca punya pilihan. Pembacaan strongly consistent ditujukan kepada pemimpin dan dilihat penulisan komitmen terbaru. Pembacaan eventually consistent dapat dilayani oleh salah satu dari tiga node, salah satunya mungkin tertinggal beberapa milidetik — itu saja kelambatan yang Anda tukarkan dengan bacaan yang lebih murah dan lebih banyak tersedia.

Pada penagihan sesuai permintaan, item yang dibaca 2 KB sangat berharga 1 RCU; sama baca biaya yang pada akhirnya konsisten 0,5 RCU. Beri peringkat jalur panas Anda di kalkulator harga.

Ide propagasi asinkron yang sama adalah alasan mengapa pembacaan GSI bisa membosankan - lihat GSI pada akhirnya konsisten.

Bacalah peraturan di luar struktur

Hampir setiap "aturan" DynamoDB hanyalah fisika penyimpanan:

• Selalu berikan kunci partisi. Tanpa kunci, tanpa target hash — Anda sedang memindai seluruh peta. Ini adalah inti dari Query vs Scan.
• Tempatkan bersama apa yang Anda baca bersama di bawah satu kunci partisi, jadi satu hash + tree-walk mengembalikan seluruh koleksi item. Itulah dasar dari desain meja tunggal.
• Jaga agar partisi tetap dibatasi. Satu partisi adalah satu pohon B pada himpunan berhingga node; hot key yang tidak dapat digunakan atau batas 10 GB LSI keduanya merupakan batasan fisik tersebut partisi.

Setelah Anda melihat bentuk pohon hash lalu B, disiplin pola akses berhenti merasa sewenang-wenang — Anda hanya menjaga agar setiap bacaan tetap pada jalur yang cepat.

Langkah selanjutnya

Modelkan kunci Anda agar sesuai dengan struktur dengan strategi kunci pengurutan dan desain meja tunggal, lalu rakit yang sebenarnya ekspresi di DynamoDB Expression Builder. Coba DynoTable untuk melihat pembacaan ini dijalankan pada tabel Anda sendiri dan melihat dengan tepat item mana yang ditarik kembali oleh kondisi utama.