Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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 DynamoDB 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 kumpulan dari satu atau lebih tabel replika, semuanya dimiliki oleh satu AWS akun.
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.
-
Buat tabel DynamoDB biasa, dengan DynamoDB Streams diaktifkan, di Region. AWS
-
Ulangi langkah 1 untuk setiap Wilayah lain tempat Anda ingin mereplikasi data.
-
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
Ketahuilah 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 replika sebagai terputus sebelum membuat penulisan lebih lanjut sebagai tabel regionalnya yang terisolasi.
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 IAM kebijakan untuk hanya mengizinkan penulisan ke tabel di satu Wilayah.
Menggunakan IAM kebijakan untuk merutekan pengguna hanya ke satu Wilayah dan menjaga yang lain sebagai siaga siaga, atau secara bergantian merutekan pengguna ganjil ke satu Wilayah dan bahkan pengguna 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 Hidup (TTL)
Anda dapat menggunakan Time To Live (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 lama tabel global, TTL penghapusan tidak direplikasi secara otomatis di seluruh replika lainnya. Ketika item dihapus melalui TTL aturan, pekerjaan itu dilakukan tanpa menggunakan Unit Tulis.
Ketahuilah bahwa jika tabel sumber dan target memiliki kapasitas tulis Provisioned yang sangat rendah, ini dapat menyebabkan pembatasan karena TTL penghapusan 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, and Durability) ONLY di Wilayah tempat penulisan awalnya dibuat. 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 tidak DAX akan sadar itu memegang data basi. DAXCache hanya akan di-refresh ketika cache TTL 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 (Saat ini, jika tabel diatur untuk mendukung penskalaan otomatis atau dalam mode sesuai permintaan maka kapasitas tulis secara otomatis tetap sinkron. 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 pembacaan yang konsisten pada akhirnya dan hanya masalah yang dibaca terhadap satu AWS Wilayah, itu akan berfungsi tanpa modifikasi 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 AWS Wilayah menjadi terisolasi atau terdegradasi, aplikasi Anda dapat mengarahkan ulang ke Wilayah lain dan melakukan pembacaan dan penulisan 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.
