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

Cara kerja tabel global DynamoDB

Bagian berikut menjelaskan konsep dan perilaku tabel global di Amazon DynamoDB.

Konsep

Tabel global adalah fitur DynamoDB yang mereplikasi data tabel di seluruh Wilayah. AWS

Tabel replika (atau replika) adalah tabel DynamoDB yang berfungsi sebagai bagian dari tabel global. Tabel global terdiri dari dua atau lebih tabel replika di berbagai Wil AWS ayah. Setiap tabel global hanya dapat memiliki satu replika per Wil AWS ayah. Semua replika dalam tabel global berbagi nama tabel, skema kunci utama, dan data item yang sama.

Ketika aplikasi menulis data ke replika di satu Wilayah, DynamoDB secara otomatis mereplikasi penulisan ke semua replika lain dalam tabel global. Untuk informasi selengkapnya tentang cara mulai menggunakan tabel global, lihat Tutorial: Membuat tabel global.

Versi

Ada dua versi tabel global DynamoDB yang tersedia: Versi 2019.11.21 (Current) dan Version 2017.11.29 (Legacy). Anda harus menggunakan Versi 2019.11.21 (Current) bila memungkinkan. Informasi di bagian dokumentasi ini adalah untuk Versi 2019.11.21 (Current). Untuk informasi selengkapnya, lihat Menentukan versi tabel global.

Ketersediaan

Tabel global membantu meningkatkan kelangsungan bisnis Anda dengan mempermudah penerapan arsitektur ketersediaan tinggi Multi-wilayah. Jika beban kerja di satu Wil AWS ayah menjadi terganggu, Anda dapat memindahkan lalu lintas aplikasi ke Wilayah yang berbeda dan melakukan pembacaan dan penulisan ke tabel replika yang berbeda dalam tabel global yang sama.

Setiap tabel replika dalam tabel global memberikan daya tahan dan ketersediaan yang sama dengan tabel DynamoDB wilayah tunggal. Tabel global menawarkan ketersediaan Perjanjian Tingkat Layanan (SLA) 99,999%, dibandingkan dengan 99,99% untuk tabel wilayah tunggal.

Mode konsistensi

Saat Anda membuat tabel global, Anda dapat mengonfigurasi mode konsistensinya. Tabel global mendukung dua mode konsistensi: Konsistensi akhir multi-wilayah (MREC), dan konsistensi kuat multi-wilayah (MRSC).

Jika Anda tidak menentukan mode konsistensi saat membuat tabel global, tabel global default ke Konsistensi akhir Multi-wilayah (MREC). Tabel global tidak dapat berisi replika yang dikonfigurasi dengan mode konsistensi yang berbeda. Anda tidak dapat mengubah mode konsistensi tabel global setelah pembuatan.

Multi-Region konsistensi akhirnya (MREC)

Multi-Region konsistensi akhir (MREC) adalah mode konsistensi default untuk tabel global. Perubahan item dalam replika tabel global MREC direplikasi secara asinkron ke semua replika lainnya, biasanya dalam satu detik atau kurang. Dalam hal yang tidak mungkin replika dalam tabel global MREC menjadi terisolasi atau terganggu, data apa pun yang belum direplikasi ke Wilayah lain akan direplikasi ketika replika menjadi sehat.

Jika item yang sama dimodifikasi di beberapa Wilayah secara bersamaan, DynamoDB akan menyelesaikan konflik dengan menggunakan modifikasi dengan stempel waktu internal terbaru berdasarkan per-item, yang disebut sebagai metode resolusi konflik “penulis terakhir menang”. Sebuah item pada akhirnya akan menyatu di semua replika ke versi yang dibuat oleh penulisan terakhir.

Operasi baca yang sangat konsisten mengembalikan versi terbaru item jika item itu terakhir diperbarui di Wilayah tempat pembacaan terjadi, tetapi dapat mengembalikan data basi jika item terakhir diperbarui di Wilayah yang berbeda. Penulisan bersyarat mengevaluasi ekspresi kondisi terhadap versi item di Wilayah.

Anda membuat tabel global MREC dengan menambahkan replika ke tabel DynamoDB yang ada. Menambahkan replika tidak memiliki dampak kinerja pada tabel DynamoDB wilayah tunggal atau replika tabel global yang ada. Anda dapat menambahkan replika ke tabel global MREC untuk memperluas jumlah Wilayah tempat data direplikasi, atau menghapus replika dari tabel global MREC jika tidak lagi diperlukan. Tabel global MREC dapat memiliki replika di Wilayah mana pun di mana DynamoDB tersedia, dan dapat memiliki replika sebanyak yang ada Wilayah di partisi. AWS

Multi-Region konsistensi yang kuat (MRSC)

Anda dapat mengonfigurasi mode konsistensi kuat multi-wilayah (MRSC) saat membuat tabel global. 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. Penulisan bersyarat selalu mengevaluasi ekspresi kondisi terhadap versi terbaru dari item.

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 tabel global MRSC yang berisi data yang ditulis ke replika tabel global dan menyediakan alternatif opsional untuk replika penuh sambil mendukung arsitektur ketersediaan MRSC. Anda tidak dapat melakukan operasi membaca atau menulis pada saksi. Seorang saksi terletak di Wilayah yang berbeda dari dua replika. Saat membuat tabel global MRSC, Anda memilih Wilayah untuk replika Anda dan penyebaran saksi pada waktu pembuatan tabel MRSC. Anda dapat menentukan apakah dan di Wilayah mana tabel global MRSC memiliki saksi yang dikonfigurasi dari output DescribeTable API. Saksi dimiliki dan dikelola oleh DynamoDB, dan saksi tidak akan muncul di AWS akun Anda di Wilayah tempat saksi dikonfigurasi.

Tabel global MRSC tersedia dalam rangkaian Wilayah berikut: Set Wilayah AS (AS Virginia Timur, Ohio Timur AS, Oregon Barat AS), Set Wilayah UE (Eropa Irlandia, Eropa London, Eropa Paris, Eropa Frankfurt), dan Set Wilayah AP (Asia Pasifik Tokyo, Asia Pasifik Seoul, dan Asia Pasifik Osaka). Tabel global MRSC tidak dapat menjangkau kumpulan Wilayah (misalnya tabel global MRSC tidak dapat berisi replika dari kumpulan Wilayah AS dan UE).

Anda membuat tabel global MRSC dengan menambahkan satu replika dan saksi atau dua replika ke tabel DynamoDB yang ada yang tidak berisi data. Saat mengonversi tabel wilayah tunggal yang ada ke tabel global MRSC, Anda harus memastikan bahwa tabel tersebut kosong. Mengonversi tabel wilayah tunggal ke tabel global MRSC dengan item yang ada tidak didukung. Pastikan tidak ada data yang ditulis ke dalam tabel selama proses konversi. 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, mengubah replika yang tersisa menjadi tabel DynamoDB wilayah tunggal.

Operasi penulisan gagal ReplicatedWriteConflictException saat mencoba memodifikasi item yang sudah dimodifikasi di Wilayah lain. Menulis bahwa gagal dengan ReplicatedWriteConflictException dapat dicoba ulang dan akan berhasil jika item tidak lagi dimodifikasi di Wilayah lain.

Pertimbangan berikut berlaku untuk tabel global MRSC:

Memilih mode konsistensi

Kriteria utama untuk memilih mode konsistensi multi-wilayah adalah apakah aplikasi Anda memprioritaskan penulisan latensi yang lebih rendah dan pembacaan yang sangat konsisten, atau memprioritaskan konsistensi kuat global.

Tabel global MREC akan memiliki penulisan yang lebih rendah dan latensi baca yang sangat konsisten dibandingkan dengan tabel global MRSC. Tabel global MREC memiliki Recovery Point Objective (RPO) sama dengan penundaan replikasi antar replika, biasanya beberapa detik tergantung pada Wilayah replika.

Anda harus menggunakan mode MREC ketika:

Tabel global MRSC akan memiliki penulisan yang lebih tinggi dan latensi baca yang sangat konsisten dibandingkan dengan tabel global MREC. Tabel global MRSC mendukung Recovery Point Objective (RPO) nol.

Anda harus menggunakan mode MRSC ketika:

Memantau tabel global

Tabel global yang dikonfigurasi untuk konsistensi akhir Multi-wilayah (MREC) menerbitkan ReplicationLatency metrik ke. CloudWatch Metrik ini melacak waktu yang telah berlalu antara saat item ditulis ke tabel replika, dan ketika item itu muncul di replika lain di tabel global. ReplicationLatencydinyatakan dalam milidetik dan dipancarkan untuk setiap pasangan Wilayah sumber dan tujuan dalam tabel global.

Nilai ReplicationLatency tipikal tergantung pada jarak antara Wil AWS ayah yang Anda pilih, serta variabel lain seperti jenis beban kerja dan throughput. Misalnya, replika sumber di Wilayah AS Barat (California Utara) (us-west-1) memiliki Wilayah AS Barat (Oregon) (us-west-2) yang lebih rendah ReplicationLatency dibandingkan dengan Wilayah Afrika (Cape Town) (af-selatan-1).

Nilai yang meningkat untuk ReplicationLatency dapat menunjukkan bahwa pembaruan dari satu replika tidak menyebar ke tabel replika lain secara tepat waktu. Dalam hal ini, Anda dapat mengalihkan sementara aktivitas baca dan tulis aplikasi Anda ke Wilayah yang berbeda AWS .

Tabel global yang dikonfigurasi untuk konsistensi kuat multi-wilayah (MRSC) tidak menerbitkan metrik. ReplicationLatency

Pengujian injeksi kesalahan

Tabel global MREC dan MRSC terintegrasi dengan F AWS ault Injection Service (AWS FIS), layanan yang dikelola sepenuhnya untuk menjalankan eksperimen injeksi kesalahan terkontrol untuk meningkatkan ketahanan aplikasi. Menggunakan AWS FIS, Anda dapat:

Misalnya, dalam tabel global dengan replika di AS Timur (Virginia Utara), AS Timur (Ohio), dan AS Barat (Oregon), Anda dapat menjalankan eksperimen di AS Timur (Ohio) untuk menguji isolasi wilayah di sana sementara AS Timur (Virginia Utara) dan AS Barat (Oregon) melanjutkan operasi normal. Pengujian terkontrol ini membantu Anda mengidentifikasi dan menyelesaikan masalah potensial sebelum memengaruhi beban kerja produksi.

Lihat Target tindakan di panduan pengguna AWS FIS untuk daftar lengkap tindakan yang didukung AWS FIS dan Konek Cross-Region tivitas untuk menjeda replikasi DynamoDB antar wilayah.

Untuk informasi tentang tindakan tabel global Amazon DynamoDB yang tersedia di AWS FIS, lihat referensi tindakan tabel global DynamoDB di Panduan Pengguna FIS. AWS

Untuk memulai menjalankan eksperimen injeksi kesalahan, lihat Mer encanakan eksperimen AWS FIS Anda di panduan pengguna AWS FIS.

Waktu Untuk Tayang (TTL)

Tabel global yang dikonfigurasi untuk mendukung MREC mengonfigurasi penghapusan Time To Live (TTL). Pengaturan TTL secara otomatis disinkronkan untuk semua replika dalam tabel global. Ketika TTL menghapus item dari replika di Wilayah, penghapusan direplikasi ke semua replika lain dalam tabel global. TTL tidak menggunakan kapasitas penulisan, jadi Anda tidak dikenakan biaya untuk penghapusan TTL di Wilayah tempat penghapusan terjadi. Namun, Anda dikenakan biaya untuk penghapusan yang direplikasi di setiap wilayah lain dengan replika di tabel global.

Replikasi penghapusan TTL menghabiskan kapasitas tulis pada replika tempat penghapusan sedang direplikasi. Replika yang dikonfigurasi untuk kapasitas yang disediakan dapat membatasi permintaan jika kombinasi throughput tulis dan throughput penghapusan TTL lebih tinggi daripada kapasitas tulis yang disediakan.

Tabel global yang dikonfigurasi untuk konsistensi kuat multi-wilayah (MRSC) tidak mendukung konfigurasi penghapusan Time To Live (TTL).

Pengaliran

Tabel global yang dikonfigurasi untuk konsistensi akhir multi-wilayah (MREC) mereplikasi perubahan dengan membaca perubahan tersebut dari Stream DynamoDB pada tabel replika dan menerapkan perubahan itu ke semua tabel replika lainnya. Oleh karena itu, aliran diaktifkan secara default pada semua replika dalam tabel global MREC, dan tidak dapat dinonaktifkan pada replika tersebut. Proses replikasi MREC dapat menggabungkan beberapa perubahan dalam waktu singkat menjadi satu penulisan yang direplikasi, menghasilkan setiap Stream replika berisi catatan yang sedikit berbeda. Catatan aliran pada replika MREC selalu diurutkan berdasarkan per item, tetapi urutan antar item mungkin berbeda antar replika.

Tabel global yang dikonfigurasi untuk konsistensi kuat multi-wilayah (MRSC) tidak menggunakan Streams DynamoDB untuk replikasi, sehingga Streams tidak diaktifkan secara default pada replika MRSC. Anda dapat mengaktifkan Streams pada replika MRSC. Catatan aliran pada replika MRSC identik untuk setiap replika, termasuk urutan rekaman Stream.

Jika Anda ingin menulis aplikasi yang memproses catatan Streams untuk perubahan yang terjadi di Wilayah tertentu tetapi tidak Wilayah lain dalam tabel global, Anda dapat menambahkan atribut ke setiap item yang menentukan di Wilayah mana perubahan untuk item tersebut terjadi. Anda dapat menggunakan atribut ini untuk memfilter catatan Streams untuk perubahan yang terjadi di Wilayah lain, termasuk penggunaan filter peristiwa Lambda untuk hanya memanggil fungsi Lambda untuk perubahan di Wilayah tertentu.

Transaksi

Pada tabel global yang dikonfigurasi untuk MREC, operasi transaksi DynamoDB (TransactWriteItemsdan TransactGetItems) hanya bersifat atom dalam Wilayah tempat operasi dipanggil. Penulisan transaksional tidak direplikasi sebagai unit di seluruh Wilayah, yang berarti hanya beberapa penulisan dalam transaksi yang dapat dikembalikan oleh operasi baca di replika lain pada titik waktu tertentu.

Misalnya, jika Anda memiliki tabel global dengan replika di Wilayah AS Timur (Ohio) dan AS Barat (Oregon) dan melakukan TransactWriteItems operasi di Wilayah AS Timur (Ohio), Anda dapat mengamati transaksi yang diselesaikan sebagian di Wilayah AS Barat (Oregon) saat perubahan direplikasi. Perubahan hanya akan direplikasi ke Wilayah lain setelah dilakukan di Wilayah sumber.

Tabel global yang dikonfigurasi untuk konsistensi kuat multi-wilayah (MRSC) tidak mendukung operasi transaksi, dan akan mengembalikan kesalahan jika operasi tersebut dipanggil pada replika MRSC.

Throughput baca dan tulis

Mode yang disediakan

Replikasi menghabiskan kapasitas tulis. Replika yang dikonfigurasi untuk kapasitas yang disediakan dapat membatasi permintaan jika kombinasi throughput penulisan aplikasi dan throughput penulisan replikasi melebihi kapasitas tulis yang disediakan. Untuk tabel global menggunakan mode yang disediakan, pengaturan penskalaan otomatis untuk kapasitas baca dan tulis disinkronkan antar replika.

Anda dapat secara independen mengonfigurasi pengaturan kapasitas baca untuk setiap replika dalam tabel global dengan menggunakan ProvisionedThroughputOverride parameter di tingkat replika. Secara default, perubahan kapasitas baca yang disediakan diterapkan ke semua replika dalam tabel global. Saat menambahkan replika baru ke tabel global, kapasitas baca tabel sumber atau replika digunakan sebagai nilai awal kecuali penggantian tingkat replika ditentukan secara eksplisit.

On-demand Modus

Untuk tabel global yang dikonfigurasi untuk mode on-demand, kapasitas tulis secara otomatis disinkronkan di semua replika. DynamoDB secara otomatis menyesuaikan kapasitas berdasarkan lalu lintas, dan tidak ada pengaturan kapasitas baca atau tulis khusus replika untuk dikelola.

Setelan sinkronisasi

Pengaturan dalam tabel global DynamoDB adalah parameter konfigurasi yang mengontrol berbagai aspek perilaku dan replikasi tabel. Pengaturan ini dikelola melalui API bidang kontrol DynamoDB dan dapat dikonfigurasi saat membuat atau memodifikasi tabel global. Tabel global secara otomatis menyinkronkan pengaturan tertentu di semua replika untuk menjaga konsistensi, sambil memungkinkan fleksibilitas untuk pengoptimalan khusus wilayah. Memahami pengaturan mana yang disinkronkan dan bagaimana perilakunya membantu Anda mengonfigurasi tabel global secara efektif. Pengaturan terbagi dalam tiga kategori utama berdasarkan bagaimana mereka disinkronkan di seluruh replika.

Pengaturan berikut selalu disinkronkan antar replika dalam tabel global:

Pengaturan berikut disinkronkan antar replika, tetapi dapat diganti berdasarkan per-replika:

Pengaturan berikut tidak pernah disinkronkan antar replika:

Semua pengaturan lain tidak disinkronkan antar replika.

DynamoDB Accelerator (DAX)

Menulis ke replika tabel global melewati DynamoDB Accelerator (DAX), memperbarui DynamoDB secara langsung. Akibatnya, cache DAX dapat menjadi basi karena penulisan tidak memperbarui cache DAX. Cache DAX yang dikonfigurasi untuk replika tabel global hanya akan diperbarui saat cache TTL kedaluwarsa.

Pertimbangan untuk mengelola tabel global

Anda tidak dapat menghapus tabel yang digunakan untuk menambahkan replika tabel global baru sampai 24 jam telah berlalu sejak replika baru dibuat.

Jika Anda menonaktifkan Wil AWS ayah yang berisi replika tabel global, replika tersebut secara permanen dikonversi ke tabel Wilayah tunggal 20 jam setelah Wilayah dinonaktifkan.