Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Tabel global DynamoDB: Cara kerjanya
Bagian berikut menjelaskan konsep dan perilaku tabel global di Amazon DynamoDB.
Konsep tabel global
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 . Untuk informasi selengkapnya tentang cara mulai menggunakan tabel global, lihat Tutorial: Membuat tabel global.
Saat Anda membuat tabel global DynamoDB, tabel tersebut 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. Saat aplikasi menulis data ke tabel replika di satu Wilayah, DynamoDB menyebarkan penulisan ke tabel replika lainnya di Wilayah lain secara otomatis. AWS
Anda dapat menambahkan tabel replika ke tabel global sehingga dapat tersedia di Wilayah tambahan.
Dengan Versi 2019.11.21 (Terbaru), saat Anda membuat Indeks Sekunder Global di satu Wilayah, indeks tersebut otomatis direplikasi ke Wilayah lain serta di-backfill secara otomatis.
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 memiliki salinan tabel sebagai entitas independen. Anda dapat menyalin tabel global ke tabel lokal di Wilayah tersebut, lalu menghapus replika global untuk Wilayah tersebut.
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:
Hanya mengizinkan penulisan ke tabel dalam satu Wilayah.
Merutekan lalu lintas pengguna ke Wilayah yang berbeda sesuai dengan kebijakan tulis Anda, untuk memastikan tidak ada konflik.
Menghindari penggunaan pembaruan non-idempoten seperti Bookmark = Bookmark + 1, dan mendukung pembaruan statis seperti Bookmark=25.
Ingatlah bahwa saat Anda merutekan penulisan atau pembacaan ke satu Wilayah, terserah aplikasi Anda untuk memastikan bahwa aliran diberlakukan.
Memantau tabel global
Anda dapat menggunakan CloudWatch untuk mengamati metrikReplicationLatency. CloudWatch melacak waktu yang berlalu antara ketika item ditulis ke tabel replika, dan ketika item tersebut muncul di replika lain di tabel global. Waktu tersebut dinyatakan dalam milidetik dan dipancarkan untuk setiap pasangan Wilayah-sumber dan Wilayah-tujuan. Metrik ini disimpan di Wilayah sumber. Ini adalah satu-satunya CloudWatch metrik yang disediakan oleh Global Tables v2.
Latensi replikasi yang akan Anda alami tergantung pada jarak antara yang Anda pilih Wilayah AWS, serta variabel lainnya. Jika tabel asli Anda berada di Wilayah AS Barat (California Utara) (us-west-1), replika di Wilayah yang lebih dekat, seperti Wilayah AS Barat (Oregon) (us-west-2), akan memiliki latensi replikasi yang lebih rendah dibandingkan dengan replika di Wilayah yang jauh lebih jauh, seperti Afrika (Cape Town) (af-south-1 1) Wilayah.
catatan
Latensi replikasi tidak mempengaruhi API latensi. Jika Anda memiliki klien dan tabel di Wilayah A dan Anda menambahkan replika tabel global di Wilayah B, klien dan tabel di Wilayah A akan memiliki latensi yang sama seperti sebelum menambahkan Wilayah B. Jika Anda memanggil PutItemAPIoperasi di Wilayah B, akhirnya akan tersedia untuk dibaca di Wilayah A setelah penundaan kira-kira ReplicationLatency statistik yang tersedia di Amazon. CloudWatch Sebelum direplikasi, Anda akan menerima respons kosong dan setelah direplikasi, Anda akan menerima item; kedua panggilan akan memiliki latensi yang kira-kira samaAPI.
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 hitungan detik sejak awal jangka waktu Unix. Setelah itu, DynamoDB dapat menghapus item tanpa menimbulkan biaya tulis.
Dengan tabel global yang Anda konfigurasikan TTL di satu Wilayah, dan pengaturan itu direplikasi secara otomatis ke Wilayah lainnya. Ketika item dihapus melalui TTL aturan, pekerjaan itu dilakukan tanpa menggunakan Unit Tulis pada tabel sumber - tetapi tabel target akan dikenakan biaya Unit Tulis Replikasi.
Ketahuilah bahwa jika tabel sumber dan target memiliki kapasitas penulisan Provisioned yang sangat rendah, ini dapat menyebabkan pelambatan, karena penghapusan memerlukan kapasitas tulis. TTL
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 memproses penulisan lokal tetapi tidak direplikasi tulis, Anda dapat menambahkan atribut Region 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) hanya 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 dilakukan di Wilayah sumber.
catatan
Tabel global “write-around” DynamoDB Accelerator dengan memperbarui DynamoDB secara langsung. Akibatnya tidak DAX akan menyadari itu menyimpan data basi. DAXCache hanya akan di-refresh ketika cache TTL kedaluwarsa.
Tag pada tabel global tidak secara otomatis menyebar.
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. Artinya, perubahan kapasitas tulis pada satu tabel akan mereplikasi tabel 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. 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. DynamoDB tidak mendukung pembacaan yang sangat konsisten di seluruh Wilayah. Oleh karena itu, jika Anda menulis ke satu Wilayah dan membaca dari Wilayah lain, respons baca mungkin menyertakan data usang yang tidak mencerminkan hasil penulisan yang baru saja diselesaikan di Wilayah lain.
Jika aplikasi memperbarui item yang sama di Wilayah yang berbeda pada waktu yang sama, konflik dapat terjadi. 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. Ini dilakukan di tingkat item. 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 Region menjadi terisolasi atau terdegradasi, DynamoDB melacak penulisan apa pun 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. Ini juga melanjutkan menyebarkan tulisan dari tabel replika lain ke Wilayah yang sekarang kembali online.
