Seberapa cepat DynamoDB?

Cepat. DynamoDB memberikan latensi baca dan tulis milidetik satu digit yang konsisten pada skala apa pun. Menambahkan DynamoDB Accelerator (DAX), sebuah cache in-memory, memangkas pembacaan eventually consistent menjadi mikrodetik. Performanya tetap datar seiring tabel membesar karena pembacaan langsung menyasar sebuah partition key alih-alih melakukan scan, jadi latensinya tidak memburuk mengikuti volume data.

Mengapa ia tetap cepat pada skala besar

Sebuah GetItem atau Query mem-hash partition key-nya dan langsung menuju partisi fisik yang tepat. Ia tak pernah mem-scan seluruh tabel, jadi waktu responsnya kira-kira konstan entah tabelnya berisi ribuan atau miliaran item.

Pembacaan mikrodetik dengan DAX

DAX adalah cache in-memory terkelola penuh yang kompatibel dengan DynamoDB dan berdiri di depan tabel Anda. Ia mengembalikan pembacaan eventually consistent dalam mikrodetik — peningkatan hingga 10x dibanding milidetik — tanpa invalidasi cache yang perlu dikelola. Ia tidak cocok untuk workload yang membutuhkan pembacaan strongly consistent.

Angka yang benar-benar dilihat pengguna Anda

Milidetik satu digit itu diukur di endpoint DynamoDB. Yang dialami aplikasi Anda adalah angka itu plus jaringannya, dan jaringan biasanya separuh yang jauh lebih besar.

Diukur dari satu mesin di Spanyol pada 2026-07-28, sembilan sampel per Region, median handshake TCP ke tiap endpoint DynamoDB regional. Itu satu perjalanan bolak-balik, sebelum satu byte pun request dikirim:

Satu mesin, satu ISP, satu sore, jadi bacalah ini sebagai orde besaran, bukan sebagai benchmark. Dua hal di dalamnya berlaku umum. Perjalanan bolak-balik lintas Atlantik lebih dari sepuluh kali lipat pembacaan yang ia bawa, jadi pada jarak itu latensi DynamoDB hanyalah pembulatan di dalam latensi Anda. Dan Region yang paling dekat secara geografis dari mesinnya bukan yang tercepat: eu-south-2 berada di Spanyol dan terukur tidak lebih baik daripada Frankfurt, karena yang menentukan adalah routing, bukan jarak.

Versi praktisnya: menempatkan compute berdampingan dengan tabelnya mengalahkan tuning DynamoDB apa pun yang bisa Anda lakukan. Sebuah fungsi Lambda di Region tabel itu membayar sebagian kecil dari angka di atas; laptop atau job CI di benua lain membayar semuanya pada setiap koneksi, dan itu juga sebabnya pemakaian ulang koneksi SDK lebih penting daripada kelihatannya.

Apa yang bisa memperlambat Anda

• Scan dan filter — membaca seluruh tabel itu lambat dan mahal; rancang akses berbasis key sebagai gantinya.
• Hot partition — ketika satu partition key menarik trafik jauh melebihi jatahnya, request terhadapnya di-throttle padahal kapasitas tabel secara keseluruhan baik-baik saja.

Desain key yang baik, bukan perangkat keras yang lebih banyak, itulah yang menjaga DynamoDB tetap cepat.

Pelajari lebih lanjut

Baca query vs scan dan hindari hot partition. Unduh DynoTable untuk melihat pembacaan mana yang berjalan sebagai Query dan mana sebagai Scan.

Referensi

• Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
• In-memory acceleration with DynamoDB Accelerator (DAX) — Amazon DynamoDB Developer Guide
• What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
• Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide

Terakhir diverifikasi 2026-07-13 terhadap dokumentasi resmi AWS yang ditautkan di atas.

Angka latensi diukur 2026-07-28 dari satu mesin di Spanyol dengan curl, sembilan request per Region, melaporkan median dari time_connect dikurangi time_namelookup terhadap https://dynamodb.<region>.amazonaws.com. Dua kali jalan independen sepakat dalam selisih 3 ms.