View a markdown version of this page

Menggunakan tabel global DynamoDB - Amazon DynamoDB
Fakta kunciFakta penting tentang MRECFakta penting 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, dan multi-aktif yang dikelola sepenuhnya yang dapat memberikan kinerja baca dan tulis yang cepat dan lokal untuk aplikasi global yang berskala 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 API DynamoDB 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-fakta penting tentang tabel global, menjelaskan kasus penggunaan utama fitur, menjelaskan dua mode konsistensi, memperkenalkan taksonomi dari tiga model penulisan berbeda yang harus Anda pertimbangkan, menelusuri 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 menyediakan daftar hal-hal yang perlu dipertimbangkan saat Anda menerapkan tabel global.

Panduan ini cocok dengan konteks penerapan AWS Multi-wilayah yang lebih luas, seperti yang tercakup dalam whitepaper AWS Multi-Region Dasar-dasar 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 (Current) (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 bahwa layanan ini sangat tersedia dan secara intrinsik tahan terhadap kegagalan infrastruktur, termasuk kegagalan seluruh Zona Ketersediaan. Tabel DynamoDB wilayah tunggal dirancang untuk ketersediaan 99,99%. Untuk informasi selengkapnya, lihat perjanjian tingkat layanan (SLA) DynamoDB.

  • Tabel global DynamoDB mereplikasi datanya antara dua atau lebih Wilayah. Tabel DynamoDB multi-wilayah 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 untuk Wilayah tersebut.

  • Panggilan ke DynamoDB tidak boleh melintasi Wilayah. Praktik terbaik adalah untuk aplikasi yang diarahkan ke satu Wilayah untuk langsung mengakses hanya titik akhir DynamoDB lokal untuk Wilayah-nya. Jika masalah terdeteksi dalam Wilayah (di lapisan DynamoDB atau di tumpukan sekitarnya), lalu lintas pengguna akhir harus dialihkan ke titik akhir aplikasi yang berbeda yang dihosting di Wilayah yang berbeda. Tabel global memastikan bahwa aplikasi yang dirujuk 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: Konsistensi akhir multi-wilayah (MREC) dan konsistensi kuat multi-wilayah (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 penting tentang MREC

  • Tabel global yang menggunakan MREC 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 lainnya 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 penulisan dalam Wilayah terpencil mungkin tidak cocok dengan urutan operasi penulisan yang terjadi 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 penulisan awal mereka, dan menghitung rata-rata. Timing disimpan CloudWatch di dalam Wilayah sumber. Melihat waktu rata-rata dan maksimum dapat berguna untuk menentukan lag replikasi rata-rata dan kasus 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 tulis kedua terjadi sebelum operasi tulis 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” ke operasi kedua. Konflik ini tidak dicatat dalam CloudWatch atau AWS CloudTrail.

  • Setiap item memiliki timestamp tulis terakhir yang disimpan sebagai properti sistem privat. Pendekatan penulis terakhir menang diimplementasikan dengan menggunakan operasi penulisan bersyarat yang mengharuskan stempel waktu item 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 yang berpartisipasi yang berbeda.

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

  • Jika suatu Wilayah tidak mungkin sepenuhnya offline, ketika kembali online nanti, semua ulangan 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 Wilayah (bahkan Wilayah asli), dan ini akan menghapus tabel lokal di Wilayah itu.

Fakta penting 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 item. Pembaruan selalu beroperasi terhadap versi terbaru dari suatu item.

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

  • Operasi tulis gagal dengan peng ReplicatedWriteConflictException ecualian ketika mencoba untuk memodifikasi item yang sudah dimodifikasi di Wilayah lain. Operasi tulis yang gagal dengan peng ReplicatedWriteConflictException ecualian 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 menambahkan 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 Multi-Region yang kuat dengan tabel global DynamoDB. Akhirnya operasi baca yang konsisten tidak mengalami latensi tambahan.

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

  • Tabel global MRSC harus dikerahkan 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 penuh sambil mendukung arsitektur ketersediaan MRSC. Anda tidak dapat melakukan operasi membaca atau menulis pada saksi. Seorang saksi tidak dikenakan biaya penyimpanan atau penulisan. 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 Anda Akun AWS di mana ia dikonfigurasi.

  • Tabel global MRSC tersedia dalam set Wilayah berikut:

    • Wilayah AS ditetapkan: AS Timur (Virginia Utara), AS Timur (Ohio), AS Barat (Oregon)

    • Wilayah UE ditetapkan: 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 kumpulan Wilayah AS dan UE.

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

  • Indeks sekunder lokal (LSI) 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 menjadi tuan rumah replika atau saksi untuk menetapkan kuorum. Jika Wilayah kedua tidak tersedia, Wilayah lokal hanya dapat melayani pembacaan yang konsisten pada akhirnya.

  • Dalam kasus yang tidak mungkin bahwa suatu Wilayah sepenuhnya offline, ketika kembali online nanti, itu akan secara otomatis mengejar ketinggalan. Sampai tertangkap, operasi tulis dan operasi baca yang sangat konsisten hanya ke Wilayah yang mengejar akan mengembalikan kesalahan sementara permintaan ke Wilayah lain akan terus berjalan normal. Akhirnya operasi baca yang konsisten ke Wilayah mengejar 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:

  • Lower-latency membaca operasi. Tempatkan salinan data lebih dekat ke pengguna akhir untuk mengurangi latensi jaringan selama operasi baca. Data disimpan segar seperti nil ReplicationLatency ainya.

  • Lower-latency menulis operasi. 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 routing di DynamoDB.

  • Migrasi Wilayah yang mulus. Anda dapat menambahkan Wilayah baru dan menghapus Wilayah lama untuk memigrasikan penerapan dari satu Wilayah ke Wilayah lainnya tanpa downtime di 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. Mengevakuasi berarti memindahkan sebagian atau semua permintaan ke Wilayah itu. Menggunakan tabel global meningkatkan SLA DynamoDB untuk persentase waktu aktif bulanan dari 99,99% menjadi 99,999%. Menggunakan MREC mendukung tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) yang diukur dalam 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 Availability Zone 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 yang lebih tinggi, tetapi mendukung RPO nol. Tabel global MREC mendukung RPO yang sama dengan penundaan replikasi antar 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 dataset 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: