Menulis dan membaca/menulis operasi - Amazon Redshift

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

Menulis dan membaca/menulis operasi

Anda dapat mengelola perilaku spesifik operasi penulisan bersamaan dengan memutuskan kapan dan bagaimana menjalankan berbagai jenis perintah. Perintah berikut relevan dengan diskusi ini:

  • COPYperintah, yang melakukan beban (awal atau inkremental)

  • INSERTperintah yang menambahkan satu atau lebih baris sekaligus

  • UPDATEperintah, yang memodifikasi baris yang ada

  • DELETEperintah, yang menghapus baris

COPYdan INSERT operasi adalah operasi tulis murni, tetapi DELETE dan UPDATE operasi adalah operasi baca/tulis. (Agar baris dihapus atau diperbarui, baris harus dibaca terlebih dahulu.) Hasil operasi penulisan bersamaan bergantung pada perintah spesifik yang sedang dijalankan secara bersamaan. COPYdan INSERT operasi terhadap tabel yang sama ditahan dalam keadaan menunggu sampai kunci dilepaskan, kemudian dilanjutkan seperti biasa.

UPDATEdan DELETE operasi berperilaku berbeda karena mereka bergantung pada pembacaan tabel awal sebelum mereka melakukan penulisan apa pun. Mengingat bahwa transaksi bersamaan tidak terlihat satu sama lain, keduanya UPDATEs dan DELETEs harus membaca snapshot data dari komit terakhir. Ketika yang pertama UPDATE atau DELETE melepaskan kuncinya, yang kedua UPDATE atau DELETE perlu menentukan apakah data yang akan dikerjakannya berpotensi basi. Itu tidak akan basi, karena transaksi kedua tidak mendapatkan snapshot datanya sampai setelah transaksi pertama merilis kuncinya.

Potensi situasi kebuntuan untuk transaksi tulis bersamaan

Setiap kali transaksi melibatkan pembaruan lebih dari satu tabel, selalu ada kemungkinan transaksi yang berjalan secara bersamaan menjadi menemui jalan buntu ketika mereka berdua mencoba menulis ke set tabel yang sama. Sebuah transaksi melepaskan semua kunci tabelnya sekaligus ketika melakukan atau memutar kembali; itu tidak melepaskan kunci satu per satu.

Misalnya, transaksi T1 dan T2 dimulai pada waktu yang hampir bersamaan. Jika T1 mulai menulis ke tabel A dan T2 mulai menulis ke tabel B, kedua transaksi dapat dilanjutkan tanpa konflik; Namun, jika T1 selesai menulis ke tabel A dan perlu mulai menulis ke tabel B, itu tidak akan dapat dilanjutkan karena T2 masih memegang kunci pada B. Sebaliknya, jika T2 selesai menulis ke tabel B dan perlu mulai menulis ke tabel A, itu tidak akan dapat melanjutkan karena T1 masih memegang kunci pada A. Karena tidak ada transaksi yang dapat melepaskan kuncinya sampai semua operasi penulisannya dilakukan, tidak ada transaksi yang dapat dilanjutkan.

Untuk menghindari kebuntuan semacam ini, Anda perlu menjadwalkan operasi penulisan bersamaan dengan hati-hati. Misalnya, Anda harus selalu memperbarui tabel dalam urutan yang sama dalam transaksi dan, jika menentukan kunci, mengunci tabel dalam urutan yang sama sebelum Anda melakukan DML operasi apa pun.