Ikhtisar tabel global

Fakta kunci

• Ada dua versi tabel global: versi 2017.11.29 (warisan) (kadang-kadang disebut v1) dan versi 2019.11.21 (saat ini) (kadang-kadang disebut v2). 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 Anda 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 MREC 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 cenderung menambah latensi yang meningkat berdasarkan latensi pulang-pergi antara Wilayah yang sedang 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 Amazon 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 yang 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 membaca atau menulis pada saksi. Seorang saksi tidak dikenakan biaya penyimpanan atau menulis. Seorang saksi berada di dalam 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 DescribeTableAPI. Saksi dimiliki dan dikelola oleh DynamoDB dan tidak muncul di Wilayah Akun AWS Anda di mana ia 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 dilaporkan hanya untuk Wilayah tempat operasi terjadi.

• Wilayah lokal menerima semua operasi baca dan tulis selama Wilayah kedua yang menampung replika atau saksi tersedia 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 akan mengembalikan kesalahan. Namun, pada akhirnya operasi baca yang konsisten 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 membawa tabel kembali sinkron

Kasus penggunaan

Tabel global MREC memberikan manfaat ini:

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

• Operasi penulisan latensi lebih rendah. Pengguna akhir dapat menulis ke Wilayah terdekat untuk mengurangi latensi jaringan dan waktu untuk menyelesaikan operasi penulisan. Lalu lintas tulis harus diarahkan dengan hati-hati untuk memastikan tidak ada konflik. Teknik untuk routing dibahas di bagian selanjutnya.

• Migrasi Wilayah yang mulus. Anda dapat menambahkan Region baru dan kemudian menghapus Region lama untuk memigrasikan penyebaran dari satu Region ke Region lainnya, tanpa downtime pada layer data.

Baik tabel global MREC dan MRSC memberikan manfaat ini:

• Peningkatan ketahanan dan pemulihan bencana. Jika suatu Wilayah mengalami penurunan kinerja atau pemadaman penuh, Anda dapat mengevakuasinya (yaitu, memindahkan beberapa atau semua permintaan yang masuk ke Wilayah tersebut). 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. Untuk informasi selengkapnya, lihat Mode konsistensi dalam dokumentasi DynamoDB.