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, Anda dapat memperlakukannya sebagai aktif-pasif dengan mengontrol cara Anda merutekan permintaan tulis. Misalnya, Anda dapat memutuskan untuk merutekan permintaan tulis ke satu Wilayah untuk menghindari potensi konflik penulisan.

Ada tiga kategorisasi utama pola penulisan terkelola:

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. Praktik terbaik secara keseluruhan dapat berbeda tergantung pada mode tulis aplikasi Anda.

Mode tulis ke Wilayah mana pun (tidak ada primer)

Mode tulis ke Wilayah mana pun sepenuhnya aktif-aktif dan tidak memberlakukan batasan tempat penulisan dapat terjadi. Wilayah mana pun dapat menerima penulisan kapan saja. Ini adalah mode yang paling sederhana. Mode ini hanya dapat digunakan dengan beberapa jenis aplikasi. Ini cocok jika semua penulis idempoten, dan oleh karena itu dapat diulang dengan aman sehingga operasi tulis secara bersamaan atau berulang di seluruh Wilayah tidak menimbulkan konflik. 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 jika risiko penulisan yang bertentangan 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 setiap penulisan terbaru dapat diputar ulang beberapa kali ke Wilayah sekunder mana pun. Jika memungkinkan, Anda harus merancang mode tulis ini.

Misalnya, layanan streaming video sering kali menggunakan tabel global untuk melacak bookmark, ulasan, bendera status tontonan, dan sebagainya. Deployment ini dapat menggunakan mode tulis ke Wilayah mana pun selama setiap tulis bersifat idempoten dan nilai benar berikutnya untuk suatu item tidak bergantung pada nilainya saat ini. Hal ini berlaku untuk pembaruan pengguna yang menetapkan status baru pengguna secara langsung, seperti mengatur kode waktu terbaru, menetapkan ulasan baru, atau menyetel status tontonan baru. Jika permintaan tulis pengguna dirutekan ke Wilayah lain, operasi tulis terakhir akan tetap ada dan status global akan diselesaikan sesuai dengan penetapan terakhir. Operasi baca dalam mode ini pada akhirnya akan menjadi konsisten, setelah tertunda oleh nilai ReplicationLatency 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. Transaksi baru mengalir dari seluruh dunia dan masuk ke berbagai Wilayah. Untuk desain mereka saat ini yang tidak memanfaatkan tabel global, mereka menggunakan satu item Running Balance per pelanggan. Tindakan pelanggan memperbarui saldo dengan ADD ekspresi, yang tidak idempoten karena nilai baru yang benar tergantung pada nilai saat ini. Ini berarti saldo menjadi tidak sinkron jika ada dua operasi tulis ke saldo yang sama pada waktu yang hampir bersamaan di Wilayah berbeda.

Perusahaan yang sama ini dapat menerapkan mode tulis ke Wilayah mana pun melalui desain ulang yang cermat dengan tabel global DynamoDB. Desain baru ini dapat mengikuti model "streaming peristiwa" - yang pada dasarnya merupakan buku besar dengan alur kerja tambah-saja. Setiap tindakan pelanggan menambahkan item baru ke koleksi item yang dikelola untuk pelanggan tersebut. Koleksi item adalah kumpulan item yang memiliki kunci primer yang sama, tetapi kunci urutannya berbeda. Setiap tindakan tulis yang menambahkan tindakan pelanggan adalah sisipan idempoten, menggunakan ID pelanggan sebagai kunci partisi dan ID transaksi sebagai kunci pengurutan. Desain ini membuat penghitungan saldo menjadi lebih rumit, karena memerlukan Query untuk menarik item yang diikuti oleh beberapa perhitungan sisi klien. Namun, keuntungannya adalah membuat semua penulisan menjadi idempoten, sehingga memberikan penyederhanaan perutean dan failover yang signifikan. Untuk informasi selengkapnya, lihat Minta perutean dengan tabel global DynamoDB.

Contoh ketiga, katakanlah ada pelanggan yang menempatkan iklan online. Mereka telah memutuskan risiko rendah kehilangan data akan dapat diterima untuk menghasilkan penyederhanaan desain mode tulis Wilayah mana pun. Saat menayangkan iklan, mereka hanya memiliki waktu beberapa milidetik untuk mengambil metadata yang cukup guna menentukan iklan yang akan ditampilkan, lalu mencatat tayangan iklan sehingga iklan yang sama tidak terulang kembali kepada pengguna tersebut. Dengan tabel global, mereka bisa mendapatkan pembacaan latensi rendah untuk pengguna akhir di seluruh dunia dan penulisan latensi rendah. Mereka dapat mencatat semua tayangan iklan untuk pengguna dalam satu item, dan menampilkannya sebagai Daftar yang terus bertambah. Mereka dapat menggunakan satu item alih-alih menambahkan ke koleksi item, karena dengan cara ini mereka dapat menghapus tayangan iklan lama yang merupakan bagian dari setiap penulisan tanpa membayar biaya penghapusan. Operasi penulisan ini NOT idempoten, jadi jika pengguna akhir yang sama melihat iklan yang ditayangkan dari beberapa Wilayah pada waktu yang hampir bersamaan, ada kemungkinan satu penulisan tayangan iklan dapat menimpa yang lain. Untuk penempatan iklan online, risiko bahwa pengguna terkadang melihat iklan berulang-ulang sepadan dengan desain yang lebih sederhana dan efisien ini.

Primer tunggal (“Tulis ke satu Wilayah”)

Mode tulis ke satu Wilayah bersifat aktif-pasif dan merutekan semua penulisan 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 menghindari konflik penulisan dengan memastikan penulisan hanya mengalir ke satu Wilayah pada satu waktu. Mode tulis ini berguna ketika Anda ingin menggunakan ekspresi atau transaksi bersyarat, karena keduanya tidak akan berfungsi kecuali Anda mengetahui bahwa Anda bertindak berdasarkan data terbaru. Jadi, menggunakan ekspresi dan transaksi bersyarat memerlukan pengiriman semua permintaan tulis ke satu Wilayah dengan data terbaru.

Bacaan akhir konsisten dapat dilakukan di Wilayah replika mana pun untuk mendapatkan latensi yang lebih rendah. Bacaan sangat konsisten harus ditujukan ke satu wilayah utama.

Terkadang perlu untuk mengubah Wilayah aktif sebagai respons terhadap kegagalan Regional, untuk membantu data. Mengevakuasi Wilayah dengan tabel global DynamoDBadalah salah satu contoh kasus penggunaan ini. Beberapa pelanggan akan mengubah Wilayah yang aktif saat ini dengan jadwal reguler, seperti deployment "follow-the-sun". Hal ini menempatkan Wilayah aktif di dekat geografi dengan aktivitas terbanyak, sehingga memberikan latensi baca dan tulis terendah. Hal ini juga memiliki keuntungan tambahan dengan memanggil jalur kode yang mengubah Wilayah setiap hari, memastikan jalur tersebut telah diuji dengan baik sebelum pemulihan bencana apa pun.

Wilayah pasif dapat mempertahankan serangkaian infrastruktur yang diperkecil di sekitar DynamoDB yang akan dibangun hanya jika wilayah tersebut menjadi wilayah aktif. Untuk diskusi yang lebih mendalam tentang desain pilot light dan warm standby, lihat Disaster Recovery (DR) Architecture on AWS, PartIII: Pilot Light and Warm Standby.

Menggunakan mode tulis ke satu Wilayah berfungsi dengan baik saat memanfaatkan tabel global untuk pembacaan terdistribusi global dengan latensi rendah. Misalnya, sebuah perusahaan media sosial besar memiliki jutaan pengguna dan miliaran postingan. Setiap pengguna ditetapkan ke suatu Wilayah pada saat pembuatan akun, yang ditempatkan dekat dengan lokasi mereka secara geografis. Semua data mereka berada di tabel non-global itu. Perusahaan menggunakan tabel global terpisah untuk menyimpan pemetaan pengguna ke wilayah asal mereka, menggunakan mode tulis ke satu Wilayah. Ini menyimpan salinan hanya-baca di seluruh dunia untuk membantu menemukan lokasi setiap data pengguna secara langsung dengan latensi tambahan minimum. Pembaruan jarang terjadi (hanya ketika memindahkan Wilayah asal pengguna dari satu Wilayah ke Wilayah lain) dan selalu melalui satu Wilayah untuk penulisan, guna menghindari kemungkinan konflik penulisan.

Contoh lainnya, perhatikan pelanggan jasa keuangan yang menerapkan penghitungan cash-back harian. Mereka menggunakan mode tulis ke Wilayah mana pun untuk menghitung saldo tetapi menggunakan mode tulis ke satu Wilayah untuk melacak pembayaran cash-back yang sebenarnya. Jika mereka ingin memberikan hadiah kepada pelanggan sebesar 1 sen untuk setiap $10 yang dibelanjakan dalam sehari, mereka perlu melakukan Query untuk semua transaksi dari hari sebelumnya, menghitung total pembelanjaan, menulis keputusan cash-back ke tabel baru, menghapus kumpulan item yang dikueri untuk menandainya sebagai digunakan, dan menggantinya dengan item tunggal yang menyimpan jumlah sisa yang harus dimasukkan ke dalam penghitungan hari berikutnya. Pekerjaan ini memerlukan transaksi, sehingga akan lebih baik dengan mode tulis ke satu Wilayah. Suatu aplikasi dapat menggabungkan mode penulisan, bahkan pada tabel yang sama, selama beban kerja tidak memiliki peluang untuk tumpang tindih.

Primer campuran (“Tulis ke Wilayah Anda”)

Mode tulis ke Wilayah Anda menetapkan subset data yang berbeda ke Wilayah yang berbeda dan hanya mengizinkan operasi tulis pada item melalui wilayah asalnya. Mode ini aktif-pasif tetapi menetapkan Wilayah aktif berdasarkan item. Setiap Wilayah adalah yang utama untuk kumpulan datanya yang tidak tumpang tindih, dan penulisan harus dijaga untuk memastikan lokalitas yang tepat.

Mode ini mirip dengan mode tulis ke satu Wilayah, hanya saja mode ini memungkinkan penulisan dengan latensi lebih rendah, karena data yang terkait dengan setiap pengguna akhir dapat ditempatkan di jaringan yang lebih dekat dengan pengguna tersebut. Mode ini juga menyebarkan infrastruktur sekitar secara lebih merata di antara Wilayah dan memerlukan lebih sedikit pekerjaan untuk membangun infrastruktur selama skenario failover, karena sebagian infrastruktur di semua wilayah sudah aktif.

Menentukan wilayah asal untuk item dapat dilakukan dengan berbagai cara:

Misalnya, anggaplah Anda bekerja di perusahaan game. Anda memerlukan pembacaan dan penulisan dengan latensi rendah untuk semua gamer di seluruh dunia. Anda dapat menempatkan setiap gamer di Wilayah terdekat mereka. Wilayah itu mengambil semua bacaan dan tulisan mereka, memastikan selalu ada read-after-write konsistensi yang kuat. Namun, jika gamer tersebut melakukan perjalanan atau Wilayah asal mereka mengalami gangguan, salinan lengkap data mereka akan tersedia di Wilayah alternatif. Jadi, gamer dapat ditetapkan ke Wilayah asal yang berbeda sesuai kebutuhan.

Contoh lainnya, katakanlah Anda bekerja di perusahaan konferensi video. Setiap metadata panggilan konferensi ditetapkan ke Wilayah tertentu. Pemanggil dapat menggunakan Wilayah yang paling dekat dengan mereka untuk mendapatkan latensi terendah. Jika terjadi gangguan Wilayah, penggunaan tabel global memungkinkan pemulihan cepat karena sistem dapat memindahkan pemrosesan panggilan ke Wilayah lain yang sudah terdapat salinan data yang direplikasi.