Kapan Menggunakan DynamoDB (dan Kapan Tidak)

DynamoDB adalah database yang luar biasa untuk workload yang menjadi tujuannya dan yang menjengkelkan untuk sisanya. Pertanyaan penentunya bukan "apakah ia web-scale?" — melainkan "apakah saya tahu pola akses saya di muka, dan apakah mereka berbasis-key?" Jawab itu dengan benar dan DynamoDB memberi Anda pembacaan satu-digit-milidetik pada skala apa pun; salah menjawabnya dan Anda akan melawan ketiadaan join dan query ad-hoc selamanya.

Kapan sebaiknya saya menggunakan DynamoDB?

Gunakan DynamoDB saat pola akses Anda diketahui, berbasis-key, dan bervolume tinggi, dan Anda menginginkan latensi satu-digit-milidetik yang dapat diprediksi pada skala apa pun tanpa server untuk dikelola. Hindari untuk query ad-hoc, join yang kaya, atau analitik seluruh-dataset, dan saat datanya kecil dengan bentuk query yang terus berubah.

• Gunakan DynamoDB saat pola akses Anda diketahui, berbasis-key, dan bervolume tinggi — dan Anda menginginkan latensi yang dapat diprediksi pada skala apa pun tanpa server untuk dikelola.
• Hindari ia saat Anda butuh query ad-hoc, join yang kaya, atau analitik atas seluruh dataset, atau saat datanya kecil dan bentuk query terus berubah.
• Pertukaran intinya: DynamoDB mengharuskan Anda merancang untuk query Anda di muka; sebagai imbalannya ia tidak pernah melambat seiring Anda tumbuh.
• Ia bukan database relasional dengan sintaks berbeda — memodelkannya seperti itu adalah sumber penderitaan nomor 1.

Sinyal yang mengunggulkan DynamoDB

DynamoDB bersinar saat sebagian besar dari ini berlaku:

• Anda tahu pola akses Anda sebelumnya. Anda dapat mendaftar query persis yang dibuat aplikasi ("ambil seorang user berdasarkan id", "daftar order seorang user terbaru-dulu") dan mereka tidak berubah seenaknya. DynamoDB dimodelkan di sekitar query tersebut.
• Akses berbasis-key. Anda mencari Item lewat partition key yang diketahui, bukan dengan men-scan untuk kombinasi atribut sembarang.
• Skala dan latensi yang dapat diprediksi penting. DynamoDB menghadirkan performa satu-digit-milidetik yang konsisten entah tabel menampung seribu Item atau semiliar.
• Anda menginginkan overhead operasional nol. Tanpa instance, tanpa failover, tanpa vacuuming — ia fully managed dan menskala ke nol secara on-demand.
• Throughput penulisan tinggi dan melonjak. Event log, telemetri IoT, state sesi/keranjang, papan peringkat — workload yang berat-append dengan key yang jelas.

Sinyal yang menentangnya

Raih database relasional (atau mesin pencarian/analitik) sebagai gantinya saat:

• Query Anda ad-hoc. Analis mengiris data berdasarkan kolom sembarang, atau kebutuhan berubah mingguan. Fleksibilitas SQL menang; DynamoDB akan butuh index baru per pola.
• Anda butuh join dan agregasi sungguhan lintas seluruh dataset. Pelaporan, business intelligence, "jumlahkan pendapatan per region per bulan" — itu pekerjaan OLAP/relasional.
• Dataset-nya kecil dan bertrafik rendah. Beberapa ribu baris pada aplikasi admin yang sepi tidak mendapat manfaat dari skala DynamoDB dan kehilangan kenyamanan SQL.
• Anda belum bisa memprediksi pola akses. Produk tahap-awal yang masih mencari bentuknya? Sebuah schema relasional yang dapat Anda Query-ulang dengan bebas lebih pemaaf sampai polanya mengendap.

Menghitung biaya sebelum Anda berkomitmen

Harga DynamoDB mengikuti pembacaan, penulisan, dan storage — bukan jam-instance — jadi ia murah untuk workload yang melonjak dan serverless serta bisa mahal untuk scan berat yang berkelanjutan. Modelkan campuran baca/tulis nyata Anda dengan kalkulator harga DynamoDB sebelum berkomitmen; sebuah workload yang tampak cocok secara teknis sebaiknya juga masuk akal secara biaya.

Setelah Anda memutuskan ia cocok

Pekerjaannya bergeser ke pemodelan. DynamoDB memberi imbalan untuk merancang tabel di sekitar query Anda — lihat cara memodelkan data di DynamoDB dan single-table design — serta secara eksplisit kapan tidak meraih single-table.

Jebakan dan langkah berikutnya

• Jangan memodelkan DynamoDB seperti database relasional — tabel ternormalisasi yang Anda join saat baca adalah anti-pola yang paling keras dihukumnya.
• Jangan memilihnya untuk analitik — pasangkan dengan penyimpanan analitik (atau ekspor ke salah satunya) untuk pelaporan alih-alih men-scan.
• Tak yakin tentang pola akses? Tunggu. Mengadopsi DynamoDB sebelum Anda tahu query Anda adalah memilih satu-satunya database yang menuntut Anda mengetahuinya.
• Terkait: query vs scan menunjukkan apa yang sebenarnya dibeli oleh "akses berbasis-key" untuk Anda.

Ingin menjelajahi sebuah tabel DynamoDB sebelum mempertaruhkan aplikasi Anda padanya? Unduh DynoTable dan hubungkan ke data Anda secara langsung.