Kapan Menggunakan DynamoDB (dan Kapan Tidak)

DynamoDB adalah database fantastis untuk beban kerja yang dibuatnya dan membuat frustrasi satu untuk sisanya. Pertanyaan penentunya adalah "apakah saya tahu pola akses saya di awal, dan apakah berbasis kunci?" Lakukan dengan benar dan DynamoDB memberi Anda pembacaan satu digit milidetik pada skala apa pun; lakukan kesalahan dan kamu akan bertarung kurangnya gabungan dan pertanyaan ad-hoc selamanya.

Kapan saya harus menggunakan DynamoDB?

Gunakan DynamoDB ketika pola akses Anda diketahui, berbasis kunci, dan bervolume tinggi, dan Anda menginginkan latensi satu digit milidetik yang dapat diprediksi pada skala apa pun tanpa server mengelola. Hindari ini untuk kueri ad-hoc, gabungan kaya, atau analisis seluruh kumpulan data, dan kapan datanya kecil dengan bentuk kueri yang terus berubah.

• Gunakan DynamoDB ketika pola akses Anda diketahui, berbasis kunci, dan bervolume tinggi — dan Anda menginginkan latensi yang dapat diprediksi pada skala apa pun tanpa perlu mengelola server.
• Hindari saat Anda memerlukan kueri ad-hoc, gabungan kaya, atau analisis secara keseluruhan kumpulan data, atau ketika datanya kecil dan bentuk kueri terus berubah.
• Perdagangan inti: DynamoDB membuat Anda merancang pertanyaan Anda terlebih dahulu; sebagai imbalannya tidak pernah melambat seiring pertumbuhan Anda.
• Ini bukan database relasional dengan sintaksis berbeda — memodelkannya seperti itu sumber rasa sakit nomor 1.

Sinyal yang mendukung DynamoDB

DynamoDB bersinar ketika sebagian besar dari ini bertahan:

• Anda mengetahui pola akses Anda sebelumnya. Anda dapat membuat daftar kueri yang tepat pada aplikasi membuat ("dapatkan pengguna berdasarkan id", "daftarkan pesanan pengguna terbaru-pertama") dan itu tidak berubah secara tiba-tiba. DynamoDB dimodelkan di sekitar kueri tersebut.
• Akses berbasis kunci. Anda mencari item berdasarkan kunci partisi yang dikenal, bukan dengan memindai untuk kombinasi atribut sewenang-wenang.
• Skala dan latensi yang dapat diprediksi penting. DynamoDB memberikan hasil milidetik satu digit yang konsisten kinerja apakah tabel tersebut memuat seribu item atau satu miliar.
• Anda tidak memerlukan overhead operasional. Tanpa instance, tanpa failover, tanpa penghisapan debu — ini sepenuhnya terkelola dan berskala hingga nol sesuai permintaan.
• Throughput penulisan tinggi dan runcing. Log peristiwa, telemetri IoT, sesi/keranjang negara bagian, papan peringkat — tambahkan beban kerja yang berat dengan kunci yang jelas.

Sinyal yang menentangnya

Gunakan database relasional (atau mesin pencari/analitik) ketika:

• Kueri Anda bersifat ad-hoc. Analis membagi data berdasarkan kolom arbitrer, atau persyaratan berubah setiap minggu. Fleksibilitas SQL menang; DynamoDB memerlukan indeks baru per pola.
• Anda memerlukan gabungan dan agregasi nyata di seluruh kumpulan data. Pelaporan, intelijen bisnis, "jumlah pendapatan menurut wilayah per bulan" — itulah OLAP/relasional pekerjaan. (Pertanyaan satu kali terhadap tabel langsung adalah kasus yang berbeda — Meja Kerja SQL DynoTable menjalankan JOIN, GROUP BY, dan mengumpulkan melalui sisi klien DynamoDB; yang dimaksud adalah beban kerja BI yang ada milik tempat lain.)
• Kumpulan datanya kecil dan lalu lintasnya rendah. Beberapa ribu baris di aplikasi admin yang tenang tidak mendapat manfaat dari skala DynamoDB dan kehilangan kenyamanan SQL.
• Anda belum dapat memprediksi pola akses. Produk tahap awal masih menemukannya membentuk? Skema relasional yang dapat Anda kueri ulang secara bebas akan lebih mudah dimaafkan hingga saat ini pola settle.

Bagaimana DynamoDB dibandingkan dengan database lain

"Haruskah saya menggunakan DynamoDB atau X?" biasanya pertanyaan yang sama dengan pakaian berbeda: apakah X izinkan saya menunda keputusan pola akses, dan apa yang harus saya bayar untuk itu? DynamoDB adalah pilihan yang menolak membiarkan Anda menundanya. Setiap perbandingan di bawah ini mengacu pada hal tersebut perdagangan, bukan pada daftar periksa fitur.

Relasional: PostgreSQL, RDS, dan Aurora

Ini adalah percabangan yang sebenarnya, dan kesalahan yang dilakukan sebagian besar tim. Basis data relasional memungkinkan Anda tulis kueri setelah Anda memiliki datanya. DynamoDB tidak — tabel dibentuk oleh pertanyaan sebelum satu item ditulis.

Pilih relasional ketika bentuk kueri masih bergerak, ketika Anda perlu bergabung atau agregat di seluruh kumpulan data, atau ketika data cukup kecil maka skalanya tidak masalah yang Anda miliki. Pilih DynamoDB ketika polanya settl dan berbasis kunci dan Anda ingin harganya sama pada satu miliar item dengan seribu item.

RDS dan Aurora tidak mengubah kalkulus itu — jadi mereka adalah mesin relasional yang dikelola mereka mewarisi fleksibilitas SQL dan model penskalaannya. Yang mereka ubah adalah operasionalnya perbandingan: dengan Aurora Tanpa Server argumen "tidak ada server untuk dikelola" untuk DynamoDB didapat jauh lebih lemah, dan keputusan sepenuhnya bergantung pada pola akses. skala aurora menghitung; DynamoDB menghilangkan konsep tersebut.

Dokumen: MongoDB dan DocumentDB

Keduanya menyimpan dokumen JSON, sehingga terlihat dapat dipertukarkan dengan DynamoDB dari kejauhan. Sebenarnya tidak. MongoDB mengindeks bidang apa pun dan menjalankan kueri ad-hoc terhadap bidang tersebut; DynamoDB memberi Anda kunci partisi, kunci pengurutan, dan indeks yang Anda nyatakan sebelumnya.

Hal ini membuat MongoDB lebih cocok untuk mengembangkan bentuk kueri, dan DynamoDB lebih cocok untuk yang dikenal dengan volume tinggi. DocumentDB berada di sisi AWS dari baris yang sama — itu berbicara tentang MongoDB API, jadi perlakukan itu sebagai "fleksibilitas MongoDB, model operasional AWS", dan bandingkan dengan DynamoDB tepat pada sumbu fleksibilitas versus prediktabilitas di atas.

Kolom lebar: Cassandra

Cassandra adalah kerabat arsitektur terdekat DynamoDB: kunci partisi, pengelompokan kunci, dan kenyataan pahit yang sama bahwa kunci partisi yang buruk adalah bug desain yang tidak dapat Anda indeks jalan keluarmu. Jika Anda memilih di antara keduanya, faktor penentunya jarang sekali model data — merekalah yang menjalankannya dan cara Anda membayar. Cassandra yang Anda operasikan (atau beli dikelola); DynamoDB yang Anda konsumsi. Amazon Keyspaces adalah jalan tengah yang dikelola Cassandra.

Karena modelnya sangat mirip, panduan pemodelan di situs ini sebagian besar bersifat transfer: the desain meja tunggal alasan tentang kunci partisi dan pola akses yang diterapkan pada Cassandra hampir baris demi baris.

Dalam memori: Redis

Redis dan DynamoDB memecahkan masalah yang berbeda. Redis mengutamakan memori dan dioptimalkan untuk akses sub-milidetik data yang Anda mampu kehilangan atau membangunnya kembali; DynamoDB tahan lama secara default. Yang umum jawaban produksinya adalah keduanya — DynamoDB sebagai sistem pencatatan, Redis (atau DAX, yaitu cache baca DynamoDB sendiri) di depan tombol pintas.

Jangkau Redis saja hanya jika datanya benar-benar bersifat sementara: penghitung batas tarif, sesi berumur pendek, papan peringkat yang dapat Anda hitung ulang.

Pencarian: Elasticsearch dan OpenSearch

Pencarian dan DynamoDB juga memecahkan masalah yang berbeda — untuk alasan yang lebih tajam daripada Redis: DynamoDB tidak memiliki teks lengkap mencari sama sekali. Query cocok berdasarkan kesetaraan kunci dan serangkaian kondisi kunci pengurutan yang sempit. Scan dengan FilterExpression membaca setiap item dan kemudian membuang sebagian besar item — ini adalah a table walk dengan filter terpasang, bukan pencarian, dan Anda membayar untuk item yang dibaca barang dikembalikan. Tidak ada peringkat relevansi, tidak ada penganalisis, tidak ada pencocokan fuzzy, tidak segi.

Jadi pertanyaannya bukanlah "DynamoDB atau mesin pencari". Ini adalah "apakah kebutuhan beban kerja ini pencarian, dan jika ya, apa yang memberi makan indeks?" Bentuk standarnya adalah keduanya: DynamoDB sebagai sistemnya catatan, cluster pencarian alongside itu, dan Aliran DynamoDB membawa setiap perubahan ke dalam indeks. Itu membeli pencarian nyata dan membebani Anda dengan sistem kedua yang harus dijalankan dan indeksnya akhirnya konsisten dengan tabel.

OpenSearch dan Elasticsearch adalah keputusan yang sama. OpenSearch adalah cabang dari AWS Elasticsearch, terpecah pada 7.10 pada tahun 2021 karena perubahan lisensi Elastic, dan keduanya telah menyimpang terpisah sejak itu. Tak satu pun dari penyimpangan tersebut yang menyentuh pertanyaan ini - karena "seharusnya pencarian dilakukan di luar DynamoDB", mereka berperilaku sama. Pilih di antara mereka dalam hal lisensi, hosting, dan yang mana layanan terkelola yang ingin Anda operasikan, tidak ada hubungannya dengan DynamoDB.

Jangkau mesin telusur sebagai toko utama hanya jika penelusuran benar-benar adalah produknya — log analitik, katalog yang pola akses utamanya adalah teks bebas. Meski begitu, sebagian besar tim tetap bertahan penyimpanan yang tahan lama di baliknya, karena indeks pencarian adalah tampilan turunan yang Anda perlukan untuk dapat melakukannya membangun kembali.

Sumbu biaya, yang disembunyikan oleh perbandingan model

Setiap perbandingan di atas adalah tentang model data, tetapi biasanya kejutan pada tagihannya struktural: tagihan mesin relasional untuk kapasitas yang Anda sediakan, tagihan untuk DynamoDB operasi yang Anda lakukan. Hal ini menjadikan DynamoDB murah untuk beban kerja yang rumit dan menganggur mahal untuk pemindaian berkelanjutan — beban kerja yang sama dapat menghasilkan keuntungan pada satu mesin dan menghasilkan kerugian yang sangat besar di sisi lain tanpa perubahan kode di antara keduanya.

Pengganda yang dilewatkan orang adalah indeks. Pada mesin relasional, indeks tambahan membutuhkan penyimpanan dan beberapa menulis latensi; di DynamoDB setiap indeks sekunder adalah penulisan ekstra penuh darinya atribut yang diproyeksikan. Kami mengerjakan aritmatika dalam tiga volume tulis panduan indeks — satu GSI menggandakan tagihan tulis, dua tiga kali lipat itu. Modelkan campuran baca/tulis Anda yang sebenarnya di kalkulator harga sebelum Anda berkomitmen pada kedua sisi.

Menghitung biaya sebelum Anda berkomitmen

Penetapan harga DynamoDB mengikuti pembacaan, penulisan, dan penyimpanan — bukan jam instan — memang demikian murah untuk beban kerja yang rumit dan tanpa server, serta bisa jadi mahal untuk pemindaian berat yang berkelanjutan. Modelkan campuran baca/tulis Anda yang sebenarnya dengan Kalkulator harga DynamoDB sebelum melakukan; beban kerja yang terlihat sesuai secara teknis juga harus memperhitungkan biaya.

Setelah Anda memutuskan itu cocok

Pekerjaan beralih ke pemodelan. Hadiah DynamoDB mendesain tabel di sekitar pertanyaan Anda — lihat cara memodelkan data di DynamoDB dan desain meja tunggal — dan secara eksplisit bila tidak ingin meraih meja tunggal.

<gambar kelas="doc-media-placeholder" jenis data="tangkapan layar" data-src="docs/panduan-kapan-menggunakan-dynamodb-browse.png"

Jebakan + langkah selanjutnya

• Jangan memodelkan DynamoDB seperti database relasional — tabel yang dinormalisasi tempat Anda bergabung waktu membaca adalah anti-pola yang paling keras dihukum.
• Jangan memilihnya untuk analisis — pasangkan dengan toko analisis (atau ekspor ke salah satunya) untuk pelaporan, bukan pemindaian.
• Tidak yakin dengan pola akses? Tunggu. Mengadopsi DynamoDB sebelum Anda mengetahui milik Anda query adalah memilih satu database yang menuntut Anda mengetahuinya.
• Terkait: kueri vs pemindaian menunjukkan apa yang dimaksud dengan "akses berbasis kunci" sebenarnya membelikanmu.

Ingin menjelajahi tabel DynamoDB sebelum mempertaruhkan aplikasi Anda padanya? Unduh DynoTable dan sambungkan ke data Anda secara langsung — ini SQL Workbench menjalankan JOIN dan agregat ad-hoc DynamoDB sendiri tidak akan melakukannya.