DynamoDB vs Redshift

DynamoDB dan Amazon Redshift jarang menjadi alternatif satu sama lain. DynamoDB adalah database operasional — pembacaan dan penulisan milidetik satu digit terhadap key yang diketahui, melayani trafik aplikasi live. Redshift adalah "a fully managed, petabyte-scale data warehouse service in the cloud," dibangun untuk melakukan Scan dan agregasi atas dataset besar untuk pelaporan dan analitik. Tim yang menjalankan keduanya adalah kasus normal, dan AWS menyediakan integrasi terkelola untuk memindahkan data satu arah di antara keduanya.

Haruskah Anda menggunakan DynamoDB atau Redshift?

Gunakan DynamoDB untuk data live aplikasi: pesanan yang dibuat, session yang dibaca, record yang diambil berdasarkan key. Gunakan Redshift ketika seseorang perlu mengajukan pertanyaan di seluruh dataset — pendapatan per region dan bulan, retensi kohort, dashboard yang meng-join beberapa sumber. Pertanyaan "yang mana" biasanya terpecah menjadi "DynamoDB untuk jalur tulis, Redshift untuk analis," dengan integrasi zero-ETL di antaranya.

DynamoDB vs Redshift sekilas

Karakteristik	DynamoDB	Redshift
Workload	Operasional (gaya OLTP) — pembacaan dan penulisan bervolume tinggi berdasarkan key	Analitik — Scan dan agregasi atas dataset besar
Model data	Item NoSQL tanpa skema hingga 400 KB; atribut bervariasi per Item	Tabel relasional dengan kolom terdeklarasi, distribution key, dan sort key
Bahasa kueri	API native (`GetItem`, `Query`, `Scan`, …) plus PartiQL	SQL penuh, dengan tooling BI dan SQL yang menyertainya
Join dan agregasi	Tidak ada join sisi server; agregasi bukan operasi sisi server	Join, window function, `GROUP BY`, dan sisa SQL analitik
Pola akses	Dirancang mengelilingi key yang diketahui; Scan adalah pengecualian mahal	Dirancang untuk Scan — membaca banyak baris adalah kasus normal
Latensi	Milidetik satu digit per permintaan	Detik hingga menit per kueri analitik, atas jauh lebih banyak data
Penskalaan	Serverless; partisi dikelola AWS	Workgroup serverless atau kluster provisioned; kapasitas disesuaikan dengan workload kueri
Kesegaran data	Read-your-write sesuai permintaan	Segaring apa pun yang memuatnya — integrasi zero-ETL mendaratkan pembaruan setiap 15–30 menit
Model harga	Per-permintaan atau kapasitas provisioned, plus penyimpanan	Kapasitas komputasi plus penyimpanan; warehouse serverless yang idle tidak ditagih komputasi

Kapan DynamoDB adalah pilihan yang lebih baik

Trafik aplikasi live. Pembacaan dan penulisan milidetik satu digit yang dapat diprediksi terhadap key yang diketahui, pada tingkat permintaan apa pun.
Skema yang bervariasi per Item. Item heterogen dalam satu tabel adalah hal biasa di DynamoDB; warehouse menginginkan kolom terdeklarasi.
Operasi serverless. Tidak ada kluster untuk diukur, di-patch, atau dijeda.
Jalur intensif penulisan. DynamoDB menyerap penulisan bervolume tinggi sebagai pekerjaan utamanya; warehouse dioptimalkan untuk bulk load dan baca.

Kapan Redshift adalah pilihan yang lebih baik

Pertanyaan yang melintasi seluruh tabel. Mengagregasi satu tahun pesanan pada dasarnya adalah Scan — persis pola akses yang DynamoDB minta Anda hindari dan Redshift dirancang untuknya.
Join di banyak sumber. Warehouse melakukan join. DynamoDB tidak punya join sisi server.
Tooling BI. Redshift berbicara SQL melalui JDBC/ODBC, sehingga masuk ke dashboard yang ada dan "the same SQL-based tools and business intelligence applications that you use today."
Analitik yang tidak boleh mengganggu produksi. Menjalankan analitik terhadap salinan replika menjauhkan beban dari tabel yang melayani pengguna Anda.

Menggunakan keduanya bersama

Pola standarnya satu arah: DynamoDB melayani aplikasi, salinan mendarat di Redshift, analis bekerja pada salinan. AWS mendukung dua rute — perintah COPY yang lebih lama, yang memuat langsung "from Amazon S3 or Amazon DynamoDB into Amazon Redshift," dan integrasi zero-ETL terkelola, yang menjaga salinan tetap mutakhir sendiri.

Apa yang sebenarnya dilakukan integrasi zero-ETL

"Zero-ETL" menyiratkan tampilan live. Bukan demikian, dan detailnya penting sebelum Anda merancang dashboard di atasnya.

Ini adalah pipeline replikasi ber-timer. AWS tepat: "On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." Lalu "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." Jadi data di Redshift basi hingga setengah jam. Itu baik untuk pelaporan harian dan salah untuk apa pun yang dimaksudkan pengguna lihat mencerminkan aksi terakhir mereka.

Point-in-time recovery wajib — dan sekarang alasannya jelas. Prasyaratnya dinyatakan dengan jelas: "A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." AWS mendokumentasikan persyaratan di satu tempat dan mekanismenya di tempat lain, dan tidak menghubungkannya, tetapi resource-based policy yang harus Anda lampirkan memberi petunjuk — ia memberikan aksi dynamodb:ExportTableToPointInTime kepada redshift.amazonaws.com. Integrasi dibangun di atas mesin export-ke-S3 DynamoDB, dan mesin itu membaca dari backup berkelanjutan. Tanpa PITR, tidak ada export, tidak ada integrasi.

Itu punya konsekuensi anggaran yang orang temui terlambat: mengaktifkan PITR pada tabel besar adalah biaya berkelanjutan atas ukuran tabel, ditanggung untuk pipeline analitik alih-alih untuk pemulihan. Hargai integrasi sebagai "Redshift plus PITR," bukan Redshift saja — kalkulator harga DynamoDB gratis akan mengukur sisi penyimpanannya sebelum Anda berkomitmen.

Dua kendala yang memblokir tabel yang sudah ada. Keduanya adalah keterbatasan terdokumentasi, dan keduanya sulit diperbaiki setelah fakta:

"The DynamoDB table and Amazon Redshift cluster need to be in the same Region." Warehouse yang mengonsolidasikan beberapa Region tidak bisa menarik semuanya melalui jalur ini.
"The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." Tabel yang dibuat di bawah enkripsi terkelola AWS perlu mengubah pengaturan enkripsinya sebelum integrasi dapat dibuat.

Di mana bentuk data Anda menggigit. Item DynamoDB heterogen secara desain; tabel warehouse punya kolom. Desain single-table yang menampung beberapa tipe entitas di bawah satu konvensi partition key tidak menjadi star schema yang bersih hanya karena direplikasi. Rencanakan pekerjaan pemodelan di Redshift setelah data mendarat — integrasi menghilangkan pipeline, bukan desain schema.

Ketika Anda belum membutuhkan warehouse

Tidak setiap agregasi adalah masalah analitik. Sebagian besar "kita harus memasukkan ini ke Redshift" dimulai sebagai satu pertanyaan — berapa banyak Item dalam status ini, berapa total untuk pelanggan ini, partition key mana yang dominan — ditanyakan sesekali, oleh seorang engineer, terhadap satu tabel.

SQL Workbench DynoTable menjawab kelas pertanyaan itu langsung terhadap DynamoDB, sesuai permintaan: SQL nyata dengan COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING, dan DISTINCT, plus INNER/LEFT JOIN. Posisinya sengaja sempit — SQL dalam aturan pola akses DynamoDB. Ini satu SELECT; tidak ada CTE, tidak ada UNION, tidak ada window function, dan tidak ada subquery skalar; target join harus partition key atau partition key GSI. Hasil distream dengan badge parsial dan menjadi eksak setelah kueri berjalan sampai akhir, dan membaca data tetap berbiaya pembacaan yang dibutuhkan.

Itu bukan pengganti warehouse, dan batas di atas adalah batas yang jujur. Tetapi ini jawaban lebih cepat daripada pipeline replikasi, biaya PITR, dan desain schema — dan memberi tahu Anda apakah pertanyaan itu layak warehouse sebelum Anda membangunnya. Menjalankan kueri Workbench adalah fitur berbayar; editor dan autocomplete gratis. DynoTable adalah aplikasi komersial closed-source; halaman ini menjelaskan apa yang dilakukannya, bukan bagaimana ia dibangun.

FAQ

Bisakah Redshift menggantikan DynamoDB?

Tidak, untuk trafik aplikasi. Redshift adalah data warehouse yang dibangun untuk Scan dan agregasi; ia tidak dirancang melayani lookup key bervolume tinggi pada latensi milidetik satu digit. Keduanya berjalan berdampingan, dengan DynamoDB melayani aplikasi dan salinan replika di Redshift melayani analitik.

Seberapa segar data DynamoDB di Redshift?

Dengan integrasi zero-ETL, basi hingga sekitar 30 menit. AWS mendokumentasikan bahwa setelah export penuh awal ia "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." Anggap sebagai pelaporan mendekati real-time, bukan tampilan live.

Mengapa integrasi zero-ETL memerlukan PITR?

Karena ia dibangun di atas export point-in-time DynamoDB. Resource-based policy yang dibutuhkan integrasi memberikan aksi dynamodb:ExportTableToPointInTime kepada Amazon Redshift, dan export itu membaca dari backup berkelanjutan yang dipelihara PITR. Mengaktifkan PITR karenanya adalah biaya nyata dan berkelanjutan dari integrasi.

Terkait

Pelajari kapan menggunakan DynamoDB dan mengapa Scan mahal.
Bandingkan DynamoDB dan PostgreSQL untuk pertanyaan relasional operasional.
Modelkan pola akses di awal dengan single-table design.
Ukur sisi penyimpanan dan kapasitas dengan kalkulator harga DynamoDB gratis.
Unduh DynoTable untuk melakukan kueri dan agregasi tabel DynamoDB Anda secara langsung.

Referensi

Terakhir diverifikasi 2026-08-02 terhadap AWS Redshift Management Guide resmi dan DynamoDB Developer Guide.