Tabel global: Cara kerjanya

penting

Dokumentasi ini ditujukan untuk versi 2017.11.29 (Lama) tabel global, yang tidak boleh digunakan untuk tabel global baru. Pelanggan harus menggunakan Tabel Global versi 2019.11.21 (Saat Ini) jika memungkinkan, karena memberikan fleksibilitas yang lebih besar, efisiensi yang lebih tinggi, dan mengkonsumsi kapasitas tulis yang lebih sedikit daripada 2017.11.29 (Legacy).

Untuk menentukan versi mana yang sedang Anda gunakan, lihat Menentukan versi tabel global yang Anda gunakan. Untuk memperbarui tabel global yang ada dari versi 2017.11.29 (Lama) ke versi 2019.11.21 (Terbaru), lihat Meningkatkan tabel global.

Bagian berikut membantu Anda memahami konsep dan perilaku tabel global di Amazon DynamoDB.

Konsep tabel global untuk Versi 2017.11.29 (Lama)

Tabel global adalah koleksi dari satu atau beberapa tabel replika, semuanya dimiliki oleh satu akun AWS.

Tabel replika (atau replika, untuk singkatnya) adalah tabel DynamoDB tunggal yang berfungsi sebagai bagian dari tabel global. Setiap replika menyimpan set item data yang sama. Setiap tabel global tertentu hanya dapat memiliki satu tabel replika per Wilayah AWS.

Berikut ini adalah gambaran umum konseptual tentang cara pembuatan tabel global.

1. Buat tabel DynamoDB biasa, dengan DynamoDB Streams diaktifkan, di Wilayah AWS.

2. Ulangi langkah 1 untuk setiap Wilayah lain tempat Anda ingin mereplikasi data.

3. Definisikan tabel global DynamoDB berdasarkan tabel yang telah Anda buat.

AWS Management Console mengotomatiskan tugas-tugas ini, sehingga Anda dapat membuat tabel global lebih cepat dan mudah. Untuk informasi selengkapnya, lihat Membuat tabel global.

Tabel global DynamoDB yang dihasilkan terdiri dari beberapa tabel replika, satu per Wilayah, yang diperlakukan DynamoDB sebagai satu unit. Setiap replika memiliki nama tabel yang sama dan skema kunci primer yang sama. Ketika aplikasi menulis data ke tabel replika di satu wilayah, DynamoDB otomatis menyebarkan aktivitas tulis tersebut ke tabel replika lain di AWS Wilayah lain.

penting

Agar data tabel Anda tetap sinkron, tabel global otomatis membuat atribut berikut untuk setiap item:

• aws:rep:deleting

• aws:rep:updatetime

• aws:rep:updateregion

Jangan mengubah atribut ini atau membuat atribut dengan nama yang sama.

Anda dapat menambahkan tabel replika ke tabel global sehingga dapat tersedia di Wilayah tambahan. (Untuk melakukannya, tabel global harus kosong. Dengan kata lain, tidak boleh ada tabel replika yang berisi data apa pun.)

Anda juga dapat menghapus tabel replika dari tabel global. Jika Anda melakukannya, tabel benar-benar terpisah dari tabel global. Tabel yang baru independen ini tidak lagi berinteraksi dengan tabel global, dan data tidak lagi disebarkan ke atau dari tabel global.

Awas

Perlu diketahui bahwa menghapus replika bukanlah proses atom. Untuk memastikan perilaku yang konsisten dan status yang diketahui, Anda sebaiknya mempertimbangkan untuk mengalihkan lalu lintas tulis aplikasi dari replika untuk dihapus sebelumnya. Setelah menghapusnya, tunggu hingga semua titik akhir wilayah replika menunjukkan bahwa replika tersebut tidak terkait sebelum melakukan penulisan lebih lanjut ke replika tersebut sebagai tabel regional terisolasinya sendiri.

Tugas umum

Tugas umum untuk tabel global berfungsi sebagai berikut.

Anda dapat menghapus tabel replika tabel global sama seperti tabel biasa. Ini akan menghentikan replikasi ke Wilayah itu dan menghapus salinan tabel yang disimpan di Wilayah itu. Anda tidak dapat memutuskan replikasi dan membuat salinan tabel ada sebagai entitas independen.

catatan

Anda tidak akan dapat menghapus tabel sumber hingga setidaknya 24 jam setelah tabel tersebut digunakan untuk memulai Wilayah baru. Jika mencoba menghapusnya terlalu cepat, Anda akan menerima pesan kesalahan.

Konflik dapat terjadi jika aplikasi memperbarui item yang sama di Wilayah yang berbeda pada waktu yang sama. Untuk membantu memastikan konsistensi akhirnya, tabel global DynamoDB menggunakan metode “penulis terakhir menang” untuk merekonsiliasi antara pembaruan yang dilakukan secara bersamaan. Semua replika akan menyetujui pembaruan terkini dan berkumpul menuju status ketika semua replika memiliki data yang identik.

catatan

Ada beberapa cara untuk menghindari konflik, antara lain:

• Menggunakan kebijakan IAM untuk hanya mengizinkan penulisan ke tabel di satu wilayah.

• Menggunakan kebijakan IAM untuk mengarahkan pengguna hanya ke satu wilayah dan menjadikan wilayah lainnya sebagai siaga, atau secara bergantian merutekan pengguna ganjil ke satu wilayah dan pengguna genap ke wilayah lain.

• Menghindari penggunaan pembaruan non-idempoten seperti Bookmark = Bookmark + 1, dan mendukung pembaruan statis seperti Bookmark=25.

Memantau tabel global

Anda dapat menggunakan CloudWatch untuk mengamati metrikReplicationLatency. Metrik ini melacak waktu yang telah berlalu antara saat item yang diperbarui muncul di aliran DynamoDB untuk satu tabel replika, dan kapan item itu muncul di replika lain di tabel global. ReplicationLatencydinyatakan dalam milidetik dan dipancarkan untuk setiap pasangan Source-region dan Destination-region. Ini adalah satu-satunya CloudWatch metrik yang disediakan oleh Global Tables v2.

Latensi yang akan Anda lihat bergantung pada jarak antara Wilayah yang Anda pilih, serta variabel lainnya. Latensi dalam kisaran 0,5 hingga 2,5 detik untuk Wilayah mungkin umum terjadi dalam wilayah geografis yang sama.

Waktu Untuk Tayang (TTL)

Anda dapat menggunakan Waktu Untuk Tayang (TTL) untuk menentukan nama atribut yang nilainya menunjukkan waktu kedaluwarsa item tersebut. Nilai ini ditentukan sebagai angka dalam detik sejak dimulainya zaman Unix.

Dengan versi warisan tabel global, penghapusan TTL tidak secara otomatis direplikasi di seluruh replika lainnya. Ketika item dihapus melalui aturan TTL, pekerjaan itu dilakukan tanpa menggunakan Unit Tulis.

Perlu diketahui jika tabel sumber dan target memiliki kapasitas tulis yang disediakan yang sangat rendah, hal ini dapat menyebabkan throttling karena penghapusan TTL memerlukan kapasitas tulis.

Aliran dan transaksi dengan tabel global

Setiap tabel global menghasilkan aliran independen berdasarkan semua tulisannya, terlepas dari titik asal untuk penulisan tersebut. Anda dapat memilih untuk menggunakan aliran DynamoDB ini di satu Wilayah atau di semua Wilayah secara independen.

Jika Anda ingin penulisan lokal yang diproses tetapi bukan penulisan yang direplikasi, Anda dapat menambahkan atribut wilayah Anda sendiri ke setiap item. Kemudian, Anda dapat menggunakan filter peristiwa Lambda untuk hanya menginvokasi Lambda untuk penulisan di Wilayah lokal.

Operasi transaksional memberikan jaminan ACID (Atomicity, Consistency, Isolation, dan Durability) HANYA di Wilayah tempat awal tulis dilakukan. Transaksi tidak didukung di seluruh Wilayah dalam tabel global.

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 perubahan telah dilakukan di Wilayah sumber.

catatan

• Tabel global “write-around” DynamoDB Accelerator dengan memperbarui DynamoDB secara langsung. Akibatnya, DAX tidak akan mengetahui jika sedang menyimpan data usang. Cache DAX hanya akan disegarkan ketika TTL cache kedaluwarsa.

• Tanda pada tabel global tidak disebarkan secara otomatis.

Throughput baca dan tulis

Tabel global mengelola throughput baca dan tulis dengan cara berikut.

• Kapasitas tulis harus sama di semua instans tabel di seluruh Wilayah.

• Dengan Versi 2019.11.21 (Terbaru), jika tabel diatur untuk mendukung penskalaan otomatis atau berada dalam mode sesuai permintaan, maka kapasitas tulis tetap sinkron secara otomatis. Jumlah kapasitas tulis saat ini yang disediakan di setiap Wilayah akan naik dan turun secara independen dalam pengaturan penskalaan otomatis yang disinkronkan tersebut. Jika tabel ditempatkan dalam mode sesuai permintaan, mode tersebut akan disinkronkan ke replika lainnya.

• Kapasitas baca dapat berbeda antarWilayah karena baca mungkin tidak sama. Saat menambahkan replika global ke tabel, kapasitas Wilayah sumber disebarkan. Setelah pembuatan, Anda dapat menyesuaikan kapasitas baca untuk satu replika, dan pengaturan baru ini tidak ditransfer ke sisi lain.

Konsistensi dan resolusi konflik

Setiap perubahan yang dibuat pada item apa pun di tabel replika mana pun akan direplikasi ke semua replika lain dalam tabel global yang sama. Dalam tabel global, item yang baru ditulis biasanya disebarkan ke semua tabel replika dalam hitungan detik.

Dengan tabel global, setiap tabel replika menyimpan set item data yang sama. DynamoDB tidak mendukung replikasi parsial hanya beberapa item.

Aplikasi dapat membaca dan menulis data ke tabel replika mana pun. DynamoDB mendukung bacaan akhir konsisten di seluruh Wilayah, tetapi tidak mendukung bacaan sangat konsisten di seluruh Wilayah. Jika aplikasi Anda hanya menggunakan bacaan akhir konsisten dan hanya mengeluarkan aktivitas baca terhadap satu Wilayah AWS, aplikasi akan berjalan tanpa perubahan apa pun. Namun, jika aplikasi Anda membutuhkan bacaan sangat konsisten, aplikasi harus melakukan semua penulisan dan bacaan sangat konsisten di Wilayah yang sama. Jika tidak, jika Anda menulis ke satu Wilayah dan membaca dari Wilayah lain, maka respons baca mungkin menyertakan data usang yang tidak mencerminkan hasil penulisan yang baru saja diselesaikan di Wilayah lain.

Konflik dapat terjadi jika aplikasi memperbarui item yang sama di Wilayah yang berbeda pada waktu yang sama. Untuk membantu memastikan konsistensi akhir, tabel global DynamoDB menggunakan rekonsiliasi penulis terakhir menang antara pembaruan serentak, dengan DynamoDB melakukan upaya terbaik untuk menentukan penulis terakhir. Dengan mekanisme resolusi konflik ini, semua replika akan menyetujui pembaruan terkini dan berkumpul menuju status ketika semua replika memiliki data yang identik.

Ketersediaan dan daya tahan

Jika satu Wilayah AWS menjadi terisolasi atau terdegradasi, aplikasi Anda dapat mengalihkan ke Wilayah yang berbeda dan melakukan aktivitas baca dan tulis terhadap tabel replika yang berbeda. Anda dapat menerapkan logika bisnis khusus untuk menentukan kapan harus mengalihkan permintaan ke Wilayah lain.

Jika suatu Wilayah menjadi terisolasi atau terdegradasi, DynamoDB melacak setiap penulisan yang telah dilakukan tetapi belum disebarkan ke semua tabel replika. Setelah Wilayah kembali online, DynamoDB melanjutkan penyebaran penulisan yang tertunda dari Wilayah tersebut ke tabel replika di Wilayah lain. DynamoDB juga melanjutkan penyebaran penulisan dari tabel replika lain ke Wilayah yang saat ini kembali online. Semua aktivitas tulis yang berhasil sebelumnya akan disebarkan pada akhirnya, terlepas dari berapa lama Wilayah tersebut terisolasi.