Amazon Redshift tidak akan lagi mendukung penggunaan Python UDF setelah 30 Juni 2026. Kami akan mulai menegakkannya secara bertahap. Untuk informasi lebih lanjut tentang detail opsi akhir masa pakai dan migrasi Python, lihat posting blog yang diterbitkan pada 30 Juni 2025.

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

Menulis dan men read/write goperasikan

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

Operasi COPY dan INSERT adalah operasi tulis murni. Operasi DELETE dan UP read/write DATE adalah operasi (untuk baris yang akan dihapus atau diperbarui, mereka harus dibaca terlebih dahulu). Hasil operasi penulisan bersamaan bergantung pada perintah spesifik yang dijalankan secara bersamaan.

Operasi UPDATE dan DELETE berperilaku berbeda karena mereka bergantung pada tabel awal yang dibaca sebelum mereka melakukan penulisan apa pun. Mengingat bahwa transaksi bersamaan tidak terlihat satu sama lain, baik UPdates dan Delete harus membaca snapshot data dari komit terakhir. Ketika UPDATE atau DELETE pertama melepaskan kuncinya, UPDATE atau DELETE kedua perlu menentukan apakah data yang akan digunakan berpotensi basi. Itu tidak akan basi, karena transaksi kedua tidak mendapatkan snapshot datanya sampai setelah transaksi pertama melepaskan kuncinya.

Situasi kebuntuan potensial untuk transaksi penulisan bersamaan yang melibatkan beberapa tabel

Ketika transaksi melibatkan pembaruan lebih dari satu tabel, selalu ada kemungkinan transaksi yang berjalan secara bersamaan menjadi menemui jalan buntu ketika keduanya mencoba menulis ke kumpulan tabel yang sama. Transaksi melepaskan semua kunci tabelnya sekaligus ketika melakukan atau memutar kembali; itu tidak melepaskan kunci satu per satu.

Misalnya, anggaplah transaksi T1 dan T2 dimulai kira-kira pada waktu yang sama. 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 melanjutkan karena T2 masih memegang kunci pada B. Demikian pula, jika T2 selesai menulis ke tabel B dan perlu mulai menulis ke tabel A, itu tidak akan dapat melanjutkan juga 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, kunci tabel dalam urutan yang sama sebelum Anda melakukan operasi DML apa pun.

Situasi kebuntuan potensial untuk transaksi penulisan bersamaan yang melibatkan satu tabel

Dalam lingkungan isolasi snapshot, kebuntuan dapat terjadi saat menjalankan transaksi penulisan bersamaan pada tabel yang sama. Kebuntuan isolasi snapshot terjadi ketika pernyataan INSERT atau COPY bersamaan berbagi kunci dan membuat kemajuan, dan pernyataan lain perlu melakukan operasi (operasi UPDATE, DELETE, MERGE, atau DDL) yang memerlukan kunci eksklusif pada tabel yang sama.

Pertimbangkan skenario berikut:

Transaksi 1 (T1):

INSERT/COPY INTO table_A;

Transaksi 2 (T2):

INSERT/COPY INTO table_A; 
            <UPDATE/DELETE/MERGE/DDL statement> table_A

Kebuntuan dapat terjadi ketika beberapa transaksi dengan operasi INSERT atau COPY berjalan secara bersamaan pada tabel yang sama dengan kunci bersama, dan salah satu transaksi tersebut mengikuti operasi penulisan murni dengan operasi yang memerlukan kunci eksklusif, seperti pernyataan UPDATE, MERGE, DELETE, atau DDL.

Untuk menghindari kebuntuan dalam situasi ini, Anda dapat memisahkan pernyataan yang memerlukan kunci eksklusif (UPDATE/MERGE/DELETE/DDL pernyataan) ke transaksi yang berbeda sehingga INSERT/COPY pernyataan apa pun dapat berkembang secara bersamaan, dan pernyataan yang memerlukan kunci eksklusif dapat dieksekusi setelahnya. Atau, untuk transaksi dengan INSERT/COPY pernyataan dan MERGE/UPDATE/MERGE pernyataan pada tabel yang sama, Anda dapat menyertakan logika coba ulang dalam aplikasi Anda untuk mengatasi potensi kebuntuan.