Transaksi dan kontrol konkurensi optimis

  • Artikel

BERLAKU UNTUK: NoSQL

Transaksi database menyediakan model pemrograman yang aman dan dapat diprediksi untuk menghadapi perubahan bersamaan pada data. Database hubungan tradisional, seperti SQL Server, memungkinkan Anda menulis logika bisnis menggunakan prosedur dan/atau pemicu yang disimpan, mengirimkannya ke server untuk dieksekusi langsung di dalam mesin database. Dengan database hubungan tradisional, Anda diharuskan untuk berurusan dengan dua bahasa pemrograman yang berbeda bahasa pemrograman aplikasi (non-transaksional) seperti JavaScript, Python, C #, Java, dll. dan transaksi bahasa komputer (seperti T-SQL) yang dieksekusi secara natif oleh database.

Mesin database di Azure Cosmos DB mendukung transaksi yang sesuai dengan ACID (Atomicity, Consistency, Isolation, Durability) dengan isolasi rekam jepret. Semua operasi database dalam lingkup partisi logis kontainer dieksekusi secara transaksional dalam mesin database yang dihosting oleh replika partisi. Operasi ini mencakup penulisan (memperbarui satu atau beberapa item dalam partisi logika) dan operasi baca. Tabel berikut ini mengilustrasikan berbagai operasi dan jenis transaksi:

Operasi Jenis operasi Transaksi Tunggal atau Multi Item
Masukkan (tanpa pemicu pra/posting) Tulis Transaksi item tunggal
Masukkan (tanpa pemicu pra/posting) Tulis dan Baca Transaksi multi-item
Ganti (tanpa pemicu pra/pos) Tulis Transaksi item tunggal
Mengganti (dengan pemicu pra/pos) Tulis dan Baca Transaksi multi-item
Upsert (tanpa pemicu pra/posting) Tulis Transaksi item tunggal
Upsert (tanpa pemicu pra/posting) Tulis dan Baca Transaksi multi-item
Hapus (tanpa pemicu pra/posting) Tulis Transaksi item tunggal
Hapus (dengan pemicu pra/posting) Tulis dan Baca Transaksi multi-item
Jalankan prosedur tersimpan Tulis dan Baca Transaksi multi-item
Sistem memulai eksekusi prosedur penggabungan Tulis Transaksi multi-item
Sistem memulai eksekusi penghapusan item berdasarkan kedaluwarsa (TTL) item Tulis Transaksi multi-item
Baca Baca Transaksi item tunggal
Ubah umpan Baca Transaksi multi-item
Bacaan Halaman Baca Transaksi multi-item
Kueri Yang Di-Halaman Baca Transaksi multi-item
Jalankan UDF sebagai bagian dari kueri paginasi Baca Transaksi multi-item

Transaksi multi-item

Azure Cosmos DB memungkinkan Anda menulis prosedur yang disimpan, pemicu pra/posting, fungsi yang ditentukan pengguna (U GIF) dan menggabungkan prosedur di JavaScript. Azure Cosmos DB secara asli mendukung eksekusi JavaScript di dalam mesin databasenya. Anda dapat mendaftarkan prosedur tersimpan, pemicu pra/pasca, fungsi yang ditentukan pengguna (UDF) dan menggabungkan prosedur pada kontainer dan kemudian menjalankannya secara transaksional dalam mesin database Azure Cosmos DB. Menulis logika aplikasi di JavaScript memungkinkan ekspresi alami aliran kontrol, scoping variabel, penugasan, dan integrasi primitif penanganan pengecualian dalam transaksi database langsung dalam bahasa JavaScript.

Prosedur, pemicu, UDF, dan prosedur penggabungan berbasis JavaScript dibungkus dalam transaksi ASAM sekitar dengan isolasi snapshot di semua item dalam partisi logis. Selama pelaksanaannya, jika program JavaScript melemparkan pengecualian, seluruh transaksi dibatalkan dan digulirkan kembali. Model pemrograman yang dihasilkan sederhana namun kuat. Pengembang JavaScript mendapatkan model pemrograman yang tahan lama saat masih menggunakan konstruksi bahasa dan primitif perpustakaan mereka yang akrab.

Kemampuan untuk menjalankan JavaScript langsung dalam mesin database memberikan kinerja dan eksekusi transaksional operasi database terhadap item kontainer. Selain itu, karena mesin database Azure Cosmos DB secara asli mendukung JSON dan JavaScript, tidak ada ketidakcocokan impedansi antara sistem jenis aplikasi dan database.

kontrol konkurensi optimis

Operasi kontrol konkurensi optimis mengizinkan Anda untuk mencegah pembaruan dan penghapusan yang hilang. Bersamaan dengan itu, operasi yang bertentangan dikenakan penguncian pesimistic reguler dari mesin dataabase yang dihosting oleh partisi logis yang memiliki item. Saat dua operasi bersamaan mencoba untuk memperbarui versi terbaru suatu item di partisi logis, salah satu dari operasi tersebut akan berhasil dan lainnya akan gagal. Namun, jika satu atau dua operasi mencoba memperbarui item yang sama sebelumnya telah membaca nilai item yang lebih lama, maka database tidak akan mengetahui apakah nilai yang dibaca sebelumnya oleh salah satu atau dua operasi yang bertentangan merupakan nilai terbaru dari item tersebut. Untungnya, situasi ini dapat terdeteksi dengan Kontrol Kurensi Optimis (OOC) sebelum dua operasi masuk ke batas transaksi dalam mesin database. Kontrol konkurensi optimis melindungi data Anda dari secara tidak sengaja menimpa perubahan yang dibuat oleh orang lain. Hal ini juga mencegah orang lain secara tidak sengaja menimpa perubahan Anda sendiri.

Menerapkan kontrol konkurensi yang optimis dengan menggunakan ETag dan header HTTP

Setiap item yang disimpan dalam kontainer Azure Cosmos DB memiliki properti yang ditentukan _etag sistem. Nilai dari _etag secara otomatis dihasilkan dan diperbarui oleh server setiap item tersebut diperbarui. _etag dapat digunakan dengan header permintaan klien if-match untuk memungkinkan server dalam menentukan apakah item dapat di perbarui secara kondisional. Nilai dari header if-match cocok dengan nilai _etag pada server, item tersebut kemudian diperbarui. Jika nilai if-matchheader permintaan tidak ada, maka server akan menolak operasi dengan respon pesan "Kegagalan Prakondisi HTTP 412 " Klien kemudian dapat mengambil kembali item untuk memperoleh versi terbaru item pada server atau mengesampingkan versi item pada server dengan nilai _etag sendiri untuk item tersebut. Selain itu, _etag dapat digunakan dengan header if-none-match untuk menentukan apakah pengambilan kembali diperlukan.

Nilai item _etag berubah setiap waktu item tersebut diperbarui Untuk merubah operasi item if-match harus secara eksplisit dinyatakan sebagai bagian dari opsi permintaan. Misalnya, lihat kode sampel pada GitHub. Nilai _etag diperiksa secara implisit untuk semua item tertulis yang disentuh oleh prosedur yang disimpan. Jika ada konflik terdeteksi, prosedur tersimpan akan mengembalikan transaksi dan memberikan pengecualian. Dengan metode ini, baik semua atau tidak ada tulisan di prosedur yang tersimpan diterapkan secara otomatis. Terdapat tanda untuk menerapkan ulang pembaruan aplikasi dan mencoba kembali permintaan asli klient.

Kontrol konkurensi yang optimis dan distribusi global

Pembaruan konkurensi dari suati item diarahkan ke Kontrol konkurensi optimis oleh lapisan protokol komunikasi Azure Cosmos DB. Untuk akun Azure Cosmos DB yang dikonfigurasi untuk penulisan wilayah tunggal, Azure Cosmos DB memastikan bahwa versi sisi klien item yang Anda perbarui (atau hapus) sama dengan versi item dalam kontainer Azure Cosmos DB. Hal ini memastikan bahwa peulisan Anda terlindungi dari tertimpa perubahan secara tidak sengaja oleh penulis lain atau sebaliknya. Pada lingkungan yang multi pengguna, Kontrol konkurensi optimis melindungi Anda dari secara tidak sengaja menghapus atau memperbarui versi yang salah pada suatu item. Dengan demikian, item terlindungi terhadap masalah yang terkenal jahat "Kehilangan pembaruan" atau "kehilangan penghapusan".

Dalam akun Azure Cosmos DB yang dikonfigurasi dengan penulisan multi-wilayah, data dapat diterapkan secara independen ke wilayah sekunder jika _etag cocok dengan data di wilayah lokal. Setelah data baru dilakukan secara lokal ke wilayah sekunder, maka data tersebut akan digabungkan ke hub atau wilayah primer. Jika kebijakan penyelesaian konflik menggabungkan data baru ke wilayah hub, maka data tersebut akan kemudian di replikasi secara global dengan data baru _etag. Jika kebijakan penyelesaian konflik menolak data baru, maka wilayah sekunder akan dikembalikan ke data asli dan _etag.

Langkah berikutnya

Pelajari selengkapnya tentang transaksi database dan kontrol konkurensi optimis pada arikel berikut: