Menggunakan tabel global DynamoDB - Amazon DynamoDB
Fakta kunciFakta Utama tentang MRECFakta Utama tentang MRSCKasus penggunaanKesimpulan dan sumber daya

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menggunakan tabel global DynamoDB

Tabel global dibangun di atas jejak global Amazon DynamoDB untuk memberi Anda database multi-wilayah, Multi-wilayah, dan multi-aktif yang dapat memberikan kinerja cepat dan lokal, baca dan tulis untuk aplikasi global yang diskalakan secara besar-besaran. Tabel global mereplikasi tabel DynamoDB Anda secara otomatis di seluruh pilihan Anda. Wilayah AWS Tidak ada perubahan aplikasi yang diperlukan karena tabel global menggunakan DynamoDB APIs yang ada. Tidak ada biaya atau komitmen di muka untuk menggunakan tabel global, dan Anda hanya membayar untuk sumber daya yang Anda gunakan.

Panduan ini menjelaskan cara menggunakan tabel global DynamoDB secara efektif. Ini memberikan fakta kunci tentang tabel global, menjelaskan kasus penggunaan utama fitur, menjelaskan dua mode konsistensi, memperkenalkan taksonomi dari tiga model penulisan berbeda yang harus Anda pertimbangkan, berjalan melalui empat pilihan perutean permintaan utama yang mungkin Anda terapkan, membahas cara untuk mengevakuasi Wilayah yang hidup atau Wilayah yang offline, menjelaskan cara berpikir tentang perencanaan kapasitas throughput, dan memberikan daftar periksa hal-hal yang perlu dipertimbangkan ketika Anda menerapkan tabel global.

Panduan ini cocok dengan konteks penyebaran AWS Multi-wilayah yang lebih besar, seperti yang tercakup dalam whitepaper AWS Multi-Region Fundamentals dan pola desain ketahanan data dengan video. AWS

Topik

Fakta kunci tentang desain tabel global DynamoDB

  • Ada dua versi tabel global: versi saat ini Tabel Global versi 2019.11.21 (Saat ini) (kadang-kadang disebut “V2"), dan Versi tabel global 2017.11.29 (Legacy) (kadang-kadang disebut “V1"). Panduan ini berfokus secara eksklusif pada versi saat ini.

  • DynamoDB (tanpa tabel global) adalah layanan Regional, yang berarti sangat tersedia dan secara intrinsik tahan terhadap kegagalan infrastruktur, termasuk kegagalan seluruh Availability Zone. Tabel DynamoDB wilayah tunggal dirancang untuk ketersediaan 99,99%. Untuk informasi selengkapnya, lihat DynamoDB service-level agreement (SLA).

  • Tabel global DynamoDB mereplikasi datanya antara dua atau lebih Wilayah. Tabel DynamoDB Multi-region dirancang untuk ketersediaan 99,999%. Dengan perencanaan yang tepat, tabel global dapat membantu menciptakan arsitektur yang tahan terhadap kegagalan Regional.

  • DynamoDB tidak memiliki titik akhir global. Semua permintaan dibuat ke titik akhir Regional yang mengakses instance tabel global yang lokal ke Wilayah tersebut.

  • Panggilan ke DynamoDB tidak boleh melintasi Wilayah. Praktik terbaik adalah untuk aplikasi yang homed ke satu Region untuk langsung mengakses hanya endpoint DynamoDB lokal untuk Wilayahnya. Jika masalah terdeteksi dalam Region (di layer DynamoDB atau di tumpukan sekitarnya), lalu lintas pengguna akhir harus diarahkan ke titik akhir aplikasi lain yang di-host di Wilayah berbeda. Tabel global memastikan bahwa aplikasi yang ditempatkan di setiap Wilayah memiliki akses ke data yang sama.

Mode konsistensi

Saat Anda membuat tabel global, Anda mengonfigurasi mode konsistensinya. Tabel global mendukung dua mode konsistensi: Multi-region ending consistency (MREC) dan Multi-region strong consistency (MRSC) yang diperkenalkan pada Juni 2025.

Jika Anda tidak menentukan mode konsistensi saat membuat tabel global, tabel global default ke MREC. Tabel global tidak dapat berisi replika yang dikonfigurasi dengan mode konsistensi yang berbeda. Anda tidak dapat mengubah mode konsistensi tabel global setelah pembuatannya.

Fakta Utama tentang MREC

  • Tabel global yang menggunakan MRSC juga menggunakan model replikasi aktif-aktif. Dari perspektif DynamoDB, tabel di setiap Wilayah memiliki kedudukan yang sama untuk menerima permintaan baca dan tulis. Setelah menerima permintaan tulis, tabel replika lokal mereplikasi operasi penulisan ke Wilayah terpencil lain yang berpartisipasi di latar belakang.

  • Item direplikasi satu per satu. Item yang diperbarui dalam satu transaksi mungkin tidak direplikasi bersama.

  • Setiap partisi tabel di Wilayah sumber mereplikasi operasi penulisannya secara paralel dengan setiap partisi lainnya. Urutan operasi tulis dalam Wilayah terpencil mungkin tidak cocok dengan urutan operasi tulis yang terjadi di dalam Wilayah sumber. Untuk informasi selengkapnya tentang partisi tabel, lihat postingan blog Penskalaan DynamoDB: Dampak partisi, hot key, dan pemisahan panas terhadap performa.

  • Item yang baru ditulis biasanya disebarkan ke semua tabel replika dalam hitungan detik. Wilayah terdekat cenderung menyebarkan lebih cepat.

  • Amazon CloudWatch menyediakan ReplicationLatency metrik untuk setiap pasangan Wilayah. Ini dihitung dengan melihat item yang tiba, membandingkan waktu kedatangan mereka dengan waktu tulis awal mereka, dan menghitung rata-rata. Pengaturan waktu disimpan CloudWatch di dalam Wilayah sumber. Melihat pengaturan waktu rata-rata dan maksimum dapat berguna untuk menentukan kelambatan replikasi rata-rata dan terburuk. Tidak ada SLA pada latensi ini.

  • Jika item individual diperbarui pada waktu yang hampir bersamaan (dalam ReplicationLatency jendela ini) di dua Wilayah yang berbeda, dan operasi penulisan kedua terjadi sebelum operasi penulisan pertama direplikasi, ada potensi konflik penulisan. Tabel global yang menggunakan MREC menyelesaikan konflik tersebut dengan menggunakan mekanisme kemenangan penulis terakhir, berdasarkan stempel waktu operasi penulisan. Operasi pertama “kalah” dengan operasi kedua. Konflik ini tidak dicatat dalam CloudWatch atau AWS CloudTrail.

  • Setiap item memiliki timestamp tulis terakhir yang disimpan sebagai properti sistem privat. Pendekatan pemenang penulis terakhir diimplementasikan dengan menggunakan operasi penulisan bersyarat yang mengharuskan stempel waktu item yang masuk lebih besar dari stempel waktu item yang ada.

  • Tabel global mereplikasi semua item ke semua Wilayah yang berpartisipasi. Jika Anda ingin memiliki cakupan replikasi yang berbeda, Anda dapat membuat beberapa tabel global dan menetapkan setiap tabel Wilayah berpartisipasi yang berbeda.

  • Wilayah lokal menerima operasi penulisan meskipun Region replika sedang offline atau ReplicationLatency tumbuh. Tabel lokal terus mencoba mereplikasi item ke tabel jarak jauh hingga setiap item berhasil.

  • Jika Wilayah tidak mungkin sepenuhnya offline, ketika kembali online nanti, semua replikasi keluar dan masuk yang tertunda akan dicoba lagi. Tidak ada tindakan khusus yang diperlukan untuk mengembalikan sinkronisasi tabel. Mekanisme kemenangan penulis terakhir memastikan bahwa data akhirnya menjadi konsisten.

  • Anda dapat menambahkan Region baru ke tabel DynamoDB MREC kapan saja. DynamoDB menangani sinkronisasi awal dan replikasi yang sedang berlangsung. Anda juga dapat menghapus Region (bahkan Region asli), dan ini akan menghapus tabel lokal di Region tersebut.

Fakta Utama tentang MRSC

  • Tabel global yang menggunakan MRSC juga menggunakan model replikasi aktif-aktif. Dari perspektif DynamoDB, tabel di setiap Wilayah memiliki kedudukan yang sama untuk menerima permintaan baca dan tulis. Perubahan item dalam replika tabel global MRSC direplikasi secara sinkron ke setidaknya satu Wilayah lain sebelum operasi penulisan mengembalikan respons yang berhasil.

  • Operasi baca yang sangat konsisten pada replika MRSC apa pun selalu mengembalikan versi terbaru dari suatu item. Operasi penulisan bersyarat selalu mengevaluasi ekspresi kondisi terhadap versi terbaru dari suatu item. Pembaruan selalu beroperasi terhadap versi terbaru dari suatu item.

  • Akhirnya operasi pembacaan yang konsisten pada replika MRSC mungkin tidak menyertakan perubahan yang baru-baru ini terjadi di Wilayah lain, dan bahkan mungkin tidak menyertakan perubahan yang baru-baru ini terjadi di Wilayah yang sama.

  • Operasi tulis gagal dengan ReplicatedWriteConflictException pengecualian ketika mencoba memodifikasi item yang sudah dimodifikasi di Wilayah lain. Operasi tulis yang gagal dengan ReplicatedWriteConflictException pengecualian dapat dicoba ulang dan akan berhasil jika item tidak lagi dimodifikasi di Wilayah lain.

  • Dengan MRSC, latensi lebih tinggi untuk operasi tulis dan untuk operasi baca yang sangat konsisten. Operasi ini membutuhkan komunikasi lintas wilayah. Komunikasi ini dapat menambah latensi yang meningkat berdasarkan latensi pulang-pergi antara Wilayah yang diakses dan Wilayah terdekat yang berpartisipasi dalam tabel global. Untuk informasi lebih lanjut, lihat presentasi AWS re:Invent 2024, konsistensi kuat Multi-Region dengan tabel global DynamoDB. Akhirnya operasi baca yang konsisten tidak mengalami latensi tambahan. Ada alat penguji open source yang memungkinkan Anda menghitung latensi ini secara eksperimental dengan Wilayah Anda.

  • Item direplikasi satu per satu. Tabel global menggunakan MRSC tidak mendukung transaksi APIs.

  • Tabel global MRSC harus ditempatkan tepat di tiga Wilayah. Anda dapat mengonfigurasi tabel global MRSC dengan tiga replika, atau dengan dua replika dan satu saksi. Saksi adalah komponen dari tabel global MRSC yang berisi data terbaru yang ditulis ke replika tabel global. Seorang saksi memberikan alternatif opsional untuk replika lengkap sambil mendukung arsitektur ketersediaan MRSC. Anda tidak dapat melakukan operasi baca atau tulis pada saksi. Seorang saksi tidak dikenakan biaya penyimpanan atau menulis. Seorang saksi berada di wilayah yang berbeda dari dua replika.

  • Untuk membuat tabel global MRSC, Anda menambahkan satu replika dan saksi, atau menambahkan dua replika ke tabel DynamoDB yang ada yang tidak berisi data. Anda tidak dapat menambahkan replika tambahan ke tabel global MRSC yang ada. Anda tidak dapat menghapus satu replika atau saksi dari tabel global MRSC. Anda dapat menghapus dua replika, atau menghapus satu replika dan saksi, dari tabel global MRSC. Skenario kedua mengonversi replika yang tersisa ke tabel DynamoDB wilayah tunggal.

  • Anda dapat menentukan apakah tabel global MRSC memiliki saksi yang dikonfigurasi, dan Wilayah mana yang dikonfigurasikan, dari output DescribeTable API. Saksi dimiliki dan dikelola oleh DynamoDB dan tidak muncul di Wilayah Akun AWS Anda di mana itu dikonfigurasi.

  • Tabel global MRSC tersedia dalam set Wilayah berikut:

    • Set Wilayah AS: AS Timur (Virginia N.), AS Timur (Ohio), AS Barat (Oregon)

    • Set Wilayah UE: Eropa (Irlandia), Eropa (London), Eropa (Paris), Eropa (Frankfurt)

    • Set Wilayah AP: Asia Pasifik (Tokyo), Asia Pasifik (Seoul), dan Asia Pasifik (Osaka)

  • Tabel global MRSC tidak dapat menjangkau set Wilayah. Misalnya, tabel global MRSC tidak dapat berisi replika dari set Wilayah AS dan UE.

  • Time to Live (TTL) tidak didukung untuk tabel global MRSC.

  • Indeks sekunder lokal (LSIs) tidak didukung untuk tabel global MRSC.

  • CloudWatch Informasi Wawasan Kontributor hanya dilaporkan untuk Wilayah tempat operasi terjadi.

  • Wilayah lokal menerima semua operasi baca dan tulis selama ada Wilayah kedua yang menampung replika atau saksi untuk menetapkan kuorum. Jika Wilayah kedua tidak tersedia, Wilayah lokal hanya dapat melayani pembacaan yang konsisten pada akhirnya.

  • Dalam hal yang tidak mungkin bahwa suatu Wilayah sepenuhnya offline, ketika kembali online nanti, ia akan secara otomatis mengejar ketinggalan. Sampai tertangkap, operasi tulis dan operasi baca yang sangat konsisten hanya untuk Wilayah yang mengejar akan mengembalikan kesalahan sementara permintaan ke Wilayah lain akan terus berkinerja normal. Akhirnya operasi pembacaan yang konsisten ke Wilayah pengejaran akan mengembalikan data yang sejauh ini telah disebarkan ke Wilayah, dengan perilaku konsistensi lokal yang biasa antara node pemimpin dan replika lokal. Tidak ada tindakan khusus yang diperlukan untuk mengembalikan sinkronisasi tabel.

Kasus penggunaan tabel global MREC DynamoDB

Tabel global MREC memberikan manfaat ini:

  • Operasi baca latensi lebih rendah. Tempatkan salinan data lebih dekat ke pengguna akhir untuk mengurangi latensi jaringan selama operasi baca. Data disimpan sesegar ReplicationLatency nilainya.

  • Operasi penulisan latensi rendah. Anda dapat menulis ke wilayah terdekat untuk mengurangi latensi jaringan dan waktu yang dibutuhkan untuk menghasilkan penulisan. Lalu lintas tulis harus dirutekan dengan hati-hati untuk memastikan tidak ada konflik. Teknik perutean dibahas lebih detail di Strategi perutean di DynamoDB.

  • Migrasi Wilayah yang mulus. Anda dapat menambahkan Region baru dan menghapus Region lama untuk memigrasikan penyebaran dari satu Region ke wilayah lain tanpa downtime pada lapisan data.

Tabel global MREC dan MRSC keduanya memberikan manfaat ini:

  • Peningkatan ketahanan dan pemulihan bencana. Jika suatu Wilayah mengalami penurunan kinerja atau pemadaman penuh, Anda dapat mengevakuasinya. Untuk mengevakuasi berarti memindahkan beberapa atau semua permintaan ke Wilayah itu. Menggunakan tabel global meningkatkan DynamoDB SLA untuk persentase uptime bulanan dari 99,99% menjadi 99,999%. Menggunakan MREC mendukung tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) yang diukur dalam hitungan detik. Menggunakan MRSC mendukung RPO nol.

    Misalnya, Fidelity Investments disajikan di re:Invent 2022 tentang bagaimana mereka menggunakan tabel global DynamoDB untuk sistem manajemen pesanan mereka. Tujuan mereka adalah untuk mencapai pemrosesan latensi rendah yang andal pada skala yang tidak dapat mereka capai dengan pemrosesan lokal sambil juga mempertahankan ketahanan terhadap Zona Ketersediaan dan kegagalan Regional.

Jika tujuan Anda adalah ketahanan dan pemulihan bencana, tabel MRSC memiliki latensi tulis yang lebih tinggi dan latensi baca yang sangat konsisten, tetapi mendukung RPO nol. Tabel global MREC mendukung RPO yang sama dengan penundaan replikasi antara replika, biasanya beberapa detik tergantung pada Wilayah replika.

Kesimpulan dan sumber daya

Tabel global DynamoDB memiliki kontrol yang sangat sedikit tetapi masih memerlukan pertimbangan yang cermat. Anda harus menentukan mode tulis, model perutean, dan proses evakuasi. Anda harus melengkapi aplikasi Anda di setiap Wilayah dan siap menyesuaikan rute atau melakukan evakuasi untuk menjaga kesehatan global. Hadiahnya adalah memiliki kumpulan data yang didistribusikan secara global dengan operasi baca dan tulis latensi rendah yang dirancang untuk ketersediaan 99,999%.

Untuk informasi selengkapnya tentang tabel global DynamoDB, lihat sumber daya berikut: