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

Tulis mode dengan tabel global DynamoDB

Tabel global selalu aktif-aktif di tingkat tabel. Namun, terutama untuk tabel MREC, Anda mungkin ingin memperlakukannya sebagai aktif-pasif dengan mengontrol cara Anda merutekan permintaan penulisan. Misalnya, Anda mungkin memutuskan untuk merutekan permintaan penulisan ke satu Wilayah untuk menghindari potensi konflik penulisan yang dapat terjadi dengan tabel MREC.

Ada tiga pola penulisan terkelola utama, seperti yang dijelaskan dalam tiga bagian berikutnya. Anda harus mempertimbangkan pola penulisan yang sesuai dengan kasus penggunaan Anda. Pilihan ini memengaruhi cara Anda merutekan permintaan, mengevakuasi suatu Wilayah, dan menangani pemulihan bencana. Panduan di bagian selanjutnya tergantung pada mode tulis aplikasi Anda.

Mode tulis ke Wilayah mana pun (tidak ada primer)

Tulis ke mode Wilayah mana pun, diilustrasikan dalam diagram berikut, sepenuhnya aktif-aktif dan tidak memberlakukan batasan di mana penulisan dapat terjadi. Wilayah mana pun dapat menerima penulisan kapan saja. Ini adalah mode paling sederhana, tetapi hanya dapat digunakan dengan beberapa jenis aplikasi. Mode ini cocok untuk semua tabel MRSC. Ini juga cocok untuk tabel MREC ketika semua penulis idempoten, dan karena itu dapat diulang dengan aman sehingga operasi penulisan bersamaan atau berulang di seluruh Wilayah tidak bertentangan. Misalnya, saat pengguna memperbarui data kontak mereka. Mode ini juga berfungsi dengan baik untuk kasus khusus idempoten, set data khusus tambahan yang semua penulisannya merupakan sisipan unik dengan kunci primer deterministik. Terakhir, mode ini cocok untuk MREC di mana risiko penulisan yang bertentangan akan dapat diterima.

Mode tulis ke Wilayah mana pun adalah arsitektur yang paling mudah untuk diimplementasikan. Perutean lebih mudah karena Wilayah mana pun dapat menjadi target penulisan kapan saja. Failover lebih mudah, karena dengan tabel MRSC, item selalu disinkronkan, dan dengan tabel MRSC, penulisan terbaru apa pun dapat diputar ulang beberapa kali ke Wilayah sekunder mana pun. Jika memungkinkan, Anda harus merancang mode tulis ini.

Misalnya, beberapa layanan streaming video menggunakan tabel global untuk melacak bookmark, ulasan, menonton bendera status, dan sebagainya. Penerapan ini menggunakan tabel MREC karena membutuhkan replika yang tersebar di seluruh dunia, dengan setiap replika menyediakan operasi baca dan tulis latensi rendah. Penerapan ini dapat menggunakan mode tulis ke Wilayah mana pun selama mereka memastikan bahwa setiap operasi penulisan adalah idempoten. Ini akan terjadi jika setiap pembaruan―misalnya, menyetel kode waktu terbaru baru, menetapkan tinjauan baru, atau menyetel status jam tangan baru―menetapkan status baru pengguna secara langsung, dan nilai berikutnya yang benar untuk item tidak bergantung pada nilainya saat ini. Jika, secara kebetulan, permintaan tulis pengguna dialihkan ke Wilayah yang berbeda, operasi penulisan terakhir akan bertahan dan status global akan diselesaikan sesuai dengan tugas terakhir. Operasi baca dalam mode ini pada akhirnya akan menjadi konsisten, tertunda oleh ReplicationLatency nilai terbaru.

Contoh lain, sebuah perusahaan jasa keuangan menggunakan tabel global sebagai bagian dari sistem untuk menyimpan penghitungan pembelian kartu debit untuk setiap pelanggan, untuk menghitung hadiah cash-back pelanggan tersebut. Mereka ingin menyimpan RunningBalance barang per pelanggan. Mode tulis ini tidak secara alami idempoten karena saat transaksi mengalir, mereka memodifikasi saldo dengan menggunakan ADD ekspresi di mana nilai baru yang benar bergantung pada nilai saat ini. Dengan menggunakan tabel MRSC mereka masih dapat menulis ke Wilayah mana pun, karena setiap ADD panggilan selalu beroperasi terhadap nilai item terbaru.

Contoh ketiga melibatkan perusahaan yang menyediakan layanan penempatan iklan online. Perusahaan ini memutuskan bahwa risiko kehilangan data yang rendah akan dapat diterima untuk mencapai penyederhanaan desain penulisan ke mode Wilayah mana pun. Ketika mereka menayangkan iklan, mereka hanya memiliki beberapa milidetik untuk mengambil metadata yang cukup untuk menentukan iklan mana yang akan ditampilkan, dan kemudian merekam tayangan iklan sehingga mereka tidak segera mengulangi iklan yang sama. Mereka menggunakan tabel global untuk mendapatkan operasi baca latensi rendah untuk pengguna akhir di seluruh dunia dan operasi penulisan latensi rendah. Mereka merekam semua tayangan iklan untuk pengguna dalam satu item, yang direpresentasikan sebagai daftar yang terus bertambah. Mereka menggunakan satu item alih-alih menambahkan ke koleksi item, sehingga mereka dapat menghapus tayangan iklan yang lebih lama sebagai bagian dari setiap operasi penulisan tanpa membayar operasi penghapusan. Operasi penulisan ini tidak idempoten; jika pengguna akhir yang sama melihat iklan yang ditayangkan dari beberapa Wilayah pada waktu yang hampir bersamaan, ada kemungkinan satu operasi penulisan untuk tayangan iklan dapat menimpa yang lain. Risikonya adalah pengguna mungkin melihat iklan diulang sesekali. Mereka memutuskan bahwa ini dapat diterima.

Menulis ke satu Wilayah (primer tunggal)

Mode tulis ke satu Wilayah, diilustrasikan dalam diagram berikut, adalah aktif-pasif dan merutekan semua tabel menulis ke satu wilayah aktif. Perhatikan bahwa DynamoDB tidak memiliki gagasan tentang satu wilayah aktif; perutean aplikasi di luar DynamoDB mengatur ini. Mode tulis ke satu Wilayah berfungsi dengan baik untuk tabel MREC yang perlu menghindari konflik tulis dengan memastikan bahwa operasi tulis hanya mengalir ke satu Wilayah pada satu waktu. Mode tulis ini membantu ketika Anda ingin menggunakan ekspresi bersyarat dan tidak dapat menggunakan MRSC karena alasan tertentu, atau ketika Anda perlu melakukan transaksi. Ekspresi ini tidak dimungkinkan kecuali Anda tahu bahwa Anda bertindak terhadap data terbaru, sehingga mereka memerlukan pengiriman semua permintaan tulis ke satu Wilayah yang memiliki data terbaru.

Bila Anda menggunakan tabel MRSC, Anda mungkin memilih untuk menulis secara umum ke satu Wilayah untuk kenyamanan. Misalnya, ini dapat membantu meminimalkan pembangunan infrastruktur Anda di luar DynamoDB. Mode tulis masih akan ditulis ke Wilayah mana pun karena dengan MRSC Anda dapat dengan aman menulis ke Wilayah mana pun kapan saja tanpa memperhatikan resolusi konflik yang akan menyebabkan tabel MREC memilih untuk menulis ke satu Wilayah.

Bacaan akhir konsisten dapat dilakukan di Wilayah replika mana pun untuk mendapatkan latensi yang lebih rendah. Pembacaan yang sangat konsisten harus masuk ke Wilayah primer tunggal.

Terkadang perlu untuk mengubah Wilayah aktif sebagai respons terhadap kegagalan Regional. Beberapa pengguna mengubah Wilayah yang saat ini aktif pada jadwal reguler, seperti menerapkan follow-the-sun penerapan. Ini menempatkan Wilayah aktif di dekat geografi yang memiliki aktivitas paling banyak (biasanya di siang hari, demikian namanya), yang menghasilkan operasi baca dan tulis latensi terendah. Ini juga memiliki manfaat sampingan untuk memanggil kode perubahan Wilayah setiap hari dan memastikan bahwa itu diuji dengan baik sebelum pemulihan bencana.

Wilayah pasif dapat menyimpan serangkaian infrastruktur yang diturunkan di sekitar DynamoDB yang dibangun hanya jika menjadi Wilayah aktif. Panduan ini tidak mencakup lampu pilot dan desain siaga hangat. Untuk informasi lebih lanjut, lihat Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light and Warm Standby.

Menggunakan mode tulis ke satu Wilayah berfungsi dengan baik saat Anda menggunakan tabel global untuk operasi baca terdistribusi global latensi rendah. Contohnya adalah perusahaan media sosial besar yang perlu memiliki data referensi yang sama yang tersedia di setiap Wilayah di seluruh dunia. Mereka tidak sering memperbarui data, tetapi ketika mereka melakukannya, mereka menulis hanya ke satu Wilayah untuk menghindari potensi konflik penulisan. Operasi baca selalu diizinkan dari Wilayah mana pun.

Sebagai contoh lain, perhatikan perusahaan jasa keuangan yang dibahas sebelumnya yang menerapkan perhitungan cash-back harian. Mereka menggunakan menulis ke mode Wilayah mana pun untuk menghitung saldo tetapi menulis ke satu mode Wilayah untuk melacak pembayaran. Pekerjaan ini memerlukan transaksi, yang tidak didukung dalam tabel MRSC, sehingga berfungsi lebih baik dengan tabel MREC terpisah dan menulis ke satu mode Wilayah.

Menulis ke Wilayah Anda (primer campuran)

Tulis ke mode tulis Wilayah Anda, diilustrasikan dalam diagram berikut, bekerja dengan tabel MREC. Ini menetapkan subset data yang berbeda ke Wilayah rumah yang berbeda dan memungkinkan operasi penulisan ke item hanya melalui Wilayah asalnya. Mode ini aktif-pasif tetapi menetapkan Wilayah aktif berdasarkan item. Setiap Wilayah adalah yang utama untuk dataset yang tidak tumpang tindih, dan operasi penulisan harus dijaga untuk memastikan lokalitas yang tepat.

Mode ini mirip dengan menulis ke satu Wilayah kecuali memungkinkan operasi tulis latensi rendah, karena data yang terkait dengan setiap pengguna dapat ditempatkan di kedekatan jaringan yang lebih dekat dengan pengguna tersebut. Ini juga menyebarkan infrastruktur di sekitarnya secara lebih merata antar Daerah dan membutuhkan lebih sedikit pekerjaan untuk membangun infrastruktur selama skenario failover, karena semua Wilayah memiliki sebagian infrastruktur mereka yang sudah aktif.

Anda dapat menentukan wilayah rumah untuk item dalam beberapa cara:

Misalnya, bayangkan Anda bekerja untuk perusahaan game. Anda memerlukan operasi baca dan tulis latensi rendah untuk semua gamer di seluruh dunia. Anda menugaskan setiap pemain ke Wilayah yang paling dekat dengan mereka. Wilayah itu mengambil semua operasi baca dan tulis mereka, memastikan read-after-write konsistensi yang kuat. Namun, ketika seorang gamer bepergian atau jika wilayah asal mereka mengalami pemadaman, salinan lengkap data mereka tersedia di Wilayah lain, dan pemain dapat ditugaskan ke Wilayah asal yang berbeda.

Sebagai contoh lain, bayangkan Anda bekerja di perusahaan konferensi video. Setiap metadata panggilan konferensi ditetapkan ke Wilayah tertentu. Penelepon dapat menggunakan Wilayah yang paling dekat dengan mereka untuk latensi terendah. Jika ada pemadaman Wilayah, menggunakan tabel global memungkinkan pemulihan cepat karena sistem dapat memindahkan pemrosesan panggilan ke Wilayah lain di mana salinan data yang direplikasi sudah ada.