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

Menulis 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 tulis 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 penulisan aplikasi Anda.

Mode tulis ke Wilayah mana pun (tidak ada primer)

Mode tulis ke Wilayah apa 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, setiap penulisan terbaru dapat diputar ulang berkali-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, bendera status tonton, dan sebagainya. Penerapan ini menggunakan tabel MREC karena memerlukan replika yang tersebar di seluruh dunia, dengan setiap replika menyediakan operasi baca dan tulis latensi rendah. Penerapan ini dapat menggunakan mode tulis ke Wilayah apa pun selama mereka memastikan bahwa setiap operasi penulisan tidak berpotensi. Ini akan terjadi jika setiap pembaruan — misalnya, menyetel kode waktu terbaru baru, menetapkan ulasan baru, atau menyetel status tontonan baru — menetapkan status baru pengguna secara langsung, dan nilai benar berikutnya 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 penugasan 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 item per pelanggan. Mode tulis ini secara alami tidak berpotensi karena saat transaksi mengalir masuk, mereka memodifikasi saldo dengan menggunakan ADD ekspresi di mana nilai yang benar baru 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 terbaru dari item tersebut.

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 apa 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 lama sebagai bagian dari setiap operasi penulisan tanpa membayar untuk operasi penghapusan. Operasi penulisan ini tidak berpotensi; jika pengguna akhir yang sama melihat iklan yang ditayangkan dari beberapa Wilayah pada waktu yang kira-kira bersamaan, ada kemungkinan bahwa satu operasi penulisan untuk tayangan iklan dapat menggantikan yang lain. Risikonya adalah bahwa 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, bersifat aktif-pasif dan merutekan semua tulisan tabel 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 bekerja dengan baik untuk tabel MREC yang perlu menghindari konflik penulisan dengan memastikan bahwa operasi tulis mengalir hanya 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 mungkin dilakukan kecuali Anda tahu bahwa Anda bertindak terhadap data terbaru, sehingga mereka memerlukan pengiriman semua permintaan penulisan ke satu Wilayah yang memiliki data terbaru.

Saat 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 menulis ke Wilayah mana pun karena dengan MRSC Anda dapat menulis dengan aman ke Wilayah mana pun kapan saja tanpa khawatir 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. Bacaan yang sangat konsisten harus masuk ke Wilayah utama tunggal.

Kadang-kadang perlu untuk mengubah Wilayah aktif sebagai tanggapan atas kegagalan Regional. Beberapa pengguna mengubah Wilayah yang saat ini aktif pada jadwal reguler, seperti menerapkan penerapan follow-the-sun. 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 memanggil Region-changing kode setiap hari dan memastikan bahwa kode 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 selengkapnya, lihat Ar sitektur Pemulihan Bencana (DR) pada AWS, Bagian III: Pilot Light dan 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 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, pertimbangkan perusahaan jasa keuangan yang dibahas sebelumnya yang menerapkan perhitungan cash-back harian. Mereka menggunakan mode tulis ke Wilayah apa pun untuk menghitung saldo tetapi menulis ke satu mode Wilayah untuk melacak pembayaran. Pekerjaan ini membutuhkan transaksi, yang tidak didukung dalam tabel MRSC, sehingga bekerja lebih baik dengan tabel MREC terpisah dan menulis ke satu mode Wilayah.

Menulis ke Wilayah Anda (primer campuran)

Mode tulis ke 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 utama untuk dataset yang tidak tumpang tindih sendiri, dan operasi penulisan harus dijaga untuk memastikan lokalitas yang tepat.

Mode ini mirip dengan menulis ke satu Wilayah kecuali memungkinkan operasi penulisan latensi rendah, karena data yang terkait dengan setiap pengguna dapat ditempatkan di dekat jaringan dengan pengguna tersebut. Ini juga menyebarkan infrastruktur di sekitarnya secara lebih merata antar Wilayah 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 dengan beberapa cara:

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

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