Cara kerja internal penyimpanan DynamoDB

DynamoDB adalah sebuah hash table yang nilainya adalah pohon terurut, tersebar di mesin-mesin dalam tiga Availability Zone. Dua struktur data melakukan hampir semua pekerjaan: sebuah hash pada partition key memilih sebuah mesin, sebuah B-tree pada sort key mengurutkan Item di dalamnya.

Bagaimana DynamoDB menyimpan data?

DynamoDB menyimpan data Anda sebagai hash table terdistribusi raksasa yang nilainya adalah B-tree terurut. Sebuah hash pada partition key memilih satu storage node; sebuah B-tree mengurutkan Item berdasarkan sort key di dalamnya. Setiap penulisan direplikasi secara sinkron ke tiga node di tiga Availability Zone sebelum di-acknowledge.

• Partition key di-hash, bukan dicari. DynamoDB menjalankan fungsi hash atas PK Anda untuk menemukan satu storage node yang menampung partition itu — sebuah lompatan O(1), tanpa memandang ukuran tabel.
• Sort key tinggal di sebuah B-tree. Di dalam sebuah partition, Item disimpan dalam B-tree yang diurutkan secara leksikografis oleh SK, itulah mengapa pembacaan rentang (begins_with, between) murah dan Scan tidak.
• Setiap tulisan mengenai tiga node sebelum di-ack. Sebuah tulisan masuk ke sebuah leader, yang mereplikasi secara sinkron ke dua peer di AZ lain — durabilitas dibeli sebelum PutItem Anda kembali.
• Inilah mengapa aturan pola-akses ada. Hash-lalu-pohon cepat hanya saat Anda membaca berdasarkan key. Tanpa key, tanpa jalur cepat — Anda jatuh kembali ke memindai pohon.

Mulai dengan struktur data, bukan API

Datang dari SQL, Anda membayangkan sebuah tabel sebagai baris di disk dengan query planner yang memilih index. DynamoDB tidak punya planner. Tata letak penyimpanan adalah kontraknya — apa yang cepat dan apa yang footgun keduanya langsung jatuh dari dua struktur.

Bayangkan sebuah map terdistribusi raksasa. Key-nya adalah hash dari partition key Anda. Nilainya bukan satu Item tunggal — ia adalah seluruh B-tree dari Item yang berbagi partition key itu, diurutkan berdasarkan sort key.

Segala hal lainnya — semantik query, peringatan 10 GB, mengapa key yang hilang memaksa sebuah Scan — adalah konsekuensi dari satu kalimat itu.

Hash partition key untuk menemukan node

Saat sebuah request tiba, DynamoDB menerapkan fungsi hash internal pada nilai partition-key. Hash secara deterministik memetakan ke satu storage node — partition fisik yang memiliki Item tersebut. AWS mendokumentasikan ini sebagai mekanisme di balik pencarian key bertenaga-konstan tanpa memandang ukuran tabel.

Itulah langkah O(1). Sebuah tabel 10 TB dan tabel 10 KB berbiaya sama untuk dilokasikan: hash, lompat, selesai. Tak ada index scan untuk menemukan node, tak ada statistik, tak ada plan.

Tangkapannya adalah sisi sebaliknya. Jika Anda tidak menyuplai partition key, DynamoDB tak punya node untuk dilompati — ia harus menjelajahi setiap partition. Itu sebuah Scan, dan itulah perbedaan antara O(1) dan membaca seluruh tabel.

Request di-hash ke tepat satu partition, lalu menuruni B-tree sort-key partition itu ke Item — dua langkah murah alih-alih menjelajahi tabel.

Urutkan Item dalam B-tree per-partition

Di dalam satu partition, Item bukanlah heap. Mereka ditampung dalam B-tree yang di-key oleh sort key, diurutkan secara leksikografis. Pencarian B-tree adalah O(log n), dan yang krusial n itu adalah Item dalam satu partition, bukan seluruh tabel.

Inilah seluruh alasan pembacaan rentang sort-key murah. Ambil sebuah tabel telemetri-armada di mana pembacaan setiap perangkat tinggal di bawah satu partition key:

Karena B-tree terurut, "semua pembacaan antara 08:00 dan 09:00" adalah sebuah penurunan pohon ke nilai awal ditambah penjelajahan sekuensial — bukan sebuah filter atas setiap pembacaan yang pernah dikirim perangkat. Anda hanya membaca rentang yang cocok.

Pengurutan itu juga mengapa sebuah query begins_with(SK, "READING#2026-06-23") cepat sementara memfilter pada atribut non-key tidak. Pohon bisa mencari berdasarkan SK; ia tak bisa mencari berdasarkan yang lain. Untuk menyusun key condition itu dengan aman, bangun di DynamoDB Expression Builder alih-alih menggabungkan string dengan tangan:

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

Replikasikan setiap tulisan ke tiga AZ

Sebuah partition bukan satu mesin. Masing-masing direplikasi di seluruh tiga node dalam tiga Availability Zone — sebuah garis keturunan desain yang berakar pada model replikasi paper Amazon Dynamo 2007.

Satu node adalah leader untuk partition. Sebuah tulisan masuk ke leader, yang menulis secara lokal dan mereplikasi ke dua peer-nya. Leader meng-ack tulisan begitu quorum node yang durabel memilikinya — sehingga durabilitas di seluruh AZ dibayar sebelum PutItem Anda kembali.

Pembacaan punya pilihan. Sebuah pembacaan strongly consistent masuk ke leader dan melihat tulisan terbaru yang ter-commit. Sebuah pembacaan eventually consistent bisa dilayani oleh salah satu dari tiga node, salah satunya mungkin tertinggal beberapa milidetik — itulah jeda yang Anda tukar untuk pembacaan yang lebih murah dan lebih tersedia.

Gagasan async-propagation yang sama adalah mengapa sebuah pembacaan GSI bisa basi — lihat GSI eventually consistent.

Baca aturannya dari struktur

Hampir setiap "aturan" DynamoDB hanyalah fisika penyimpanan:

• Selalu suplai partition key. Tanpa key, tanpa target hash — Anda memindai seluruh map. Ini inti dari Query vs Scan.
• Ko-lokasikan apa yang Anda baca bersama di bawah satu partition key, sehingga satu hash + tree-walk mengembalikan seluruh item collection. Itu fondasi dari single-table design.
• Jaga partition tetap terbatas. Satu partition adalah satu B-tree pada himpunan node yang terhingga; sebuah hot key yang lepas kendali atau plafon 10 GB sebuah LSI keduanya adalah batas partition fisik itu.

Begitu Anda melihat bentuk hash-lalu-B-tree, disiplin pola-akses berhenti terasa sewenang-wenang — Anda hanya menjaga setiap pembacaan di jalur cepat.

Langkah berikutnya

Modelkan key Anda agar cocok dengan strukturnya dengan strategi sort key dan single-table design, lalu susun expression yang sebenarnya di DynamoDB Expression Builder. Coba DynoTable untuk menyaksikan pembacaan ini berjalan terhadap tabel Anda sendiri dan melihat persis Item mana yang ditarik kembali oleh sebuah key condition.