Concurrency control adalah elemen krusial dalam manajemen basis data, terutama saat banyak transaksi berlangsung secara bersamaan. Tanpa pengelolaan yang tepat, integritas data dapat terancam. MySQL, sebagai salah satu sistem manajemen basis data yang paling banyak digunakan, mengimplementasikan berbagai mekanisme untuk mengontrol concurrency. Dalam artikel ini, kita akan menjelajahi bagaimana konsep ACID, read phenomena, isolation level, dan locking saling berhubungan dalam menjaga integritas dan konsistensi data.

ACID

ACID adalah singkatan dari Atomicity, Consistency, Isolation, dan Durability. Keempat properti ini merupakan fondasi dari transaksi basis data. Sebuah sistem basis data yang mematuhi prinsip-prinsip ACID dapat diandalkan dalam menjaga integritas data bahkan dalam situasi yang sangat kompleks dan penuh tekanan.

Konsep ACID diperkenalkan oleh Jim Gray, seorang ilmuwan komputer yang memainkan peran kunci dalam pengembangan sistem basis data dan transaksi. Pada tahun 1970-an, Jim Gray dan timnya di Microsoft dan IBM memperkenalkan prinsip-prinsip ini sebagai bagian dari penelitian untuk meningkatkan keandalan sistem manajemen basis data transaksi.

A. Atomicity

Atomicity memastikan bahwa setiap transaksi dieksekusi secara utuh. Artinya, semua operasi dalam sebuah transaksi harus berhasil sepenuhnya atau semuanya dibatalkan. Dalam konteks MySQL, ini berarti bahwa jika ada satu langkah dalam transaksi yang gagal, seluruh transaksi akan di-rollback, mengembalikan database ke keadaan sebelum transaksi dimulai.

Contohnya, bayangkan sebuah transaksi yang mencakup dua operasi: memasukkan data ke tabel orders dan memperbarui stok barang di tabel inventory. Jika pembaruan stok gagal karena suatu alasan (misalnya, stok tidak mencukupi), maka operasi pertama (memasukkan data ke orders) juga harus dibatalkan. Dengan demikian, basis data tidak akan berada dalam keadaan di mana pesanan telah ditambahkan, tetapi stok tidak berkurang.

B. Consistency

Consistency memastikan bahwa sebuah transaksi membawa basis data dari satu keadaan yang valid ke keadaan valid lainnya, sesuai dengan aturan yang telah ditentukan. Konsistensi mengacu pada penerapan semua aturan integritas referensial, constraint, trigger, dan aturan bisnis lainnya. Setiap transaksi yang berhasil harus meninggalkan basis data dalam keadaan konsisten, di mana semua aturan dipenuhi.

Sebagai contoh, jika dalam sebuah basis data ada aturan bahwa setiap order harus memiliki customer_id yang valid yang mengacu pada tabel customers, maka basis data tidak boleh mengizinkan transaksi yang mencoba memasukkan order dengan customer_id yang tidak ada di tabel customers. MySQL memastikan konsistensi ini melalui mekanisme constraint seperti foreign key, serta melalui penggunaan trigger dan aturan-aturan lain yang dapat ditetapkan oleh pengguna.

C. Isolation

Isolation memastikan bahwa transaksi yang dieksekusi secara bersamaan tidak saling mempengaruhi. Dalam konteks concurrency, isolation menjadi sangat penting karena transaksi yang dieksekusi bersamaan mungkin mengakses data yang sama. Isolation mencegah perubahan yang belum selesai oleh satu transaksi dilihat oleh transaksi lain.

Ada berbagai tingkat isolasi yang dapat diterapkan di MySQL, dan kita akan membahas ini lebih detail nanti di bagian isolation level. Namun, secara umum, semakin tinggi tingkat isolasi, semakin sedikit kemungkinan transaksi untuk saling mempengaruhi. Misalnya, dalam isolation level tertinggi (Serializable), transaksi dieksekusi seolah-olah tidak ada transaksi lain yang berjalan bersamaan, memberikan isolasi penuh tetapi dengan biaya kinerja yang lebih tinggi.

D. Durability

Durability memastikan bahwa setelah transaksi berhasil diselesaikan, semua perubahan data yang dilakukan oleh transaksi tersebut tetap ada, meskipun terjadi kegagalan sistem atau pemadaman listrik. MySQL menggunakan mekanisme seperti redo log untuk memastikan bahwa transaksi yang telah di-commit tetap ada bahkan setelah kegagalan sistem.

Misalnya, jika sebuah transaksi telah berhasil menambahkan data ke tabel sales dan memperbarui stok di tabel inventory, MySQL memastikan bahwa perubahan tersebut tidak hilang bahkan jika sistem tiba-tiba mati setelah transaksi selesai. Saat sistem di-restart, MySQL akan menggunakan redo log untuk memastikan bahwa semua perubahan yang dilakukan oleh transaksi yang telah di-commit tetap diterapkan.

Jenis-Jenis Read Phenomena

Setelah memahami prinsip dasar ACID, kita dapat melihat bagaimana salah satu komponen dari ACID, yaitu Isolation, berkaitan erat dengan fenomena yang terjadi dalam situasi concurrency, yang dikenal sebagai read phenomena. Read phenomena adalah istilah yang digunakan untuk menggambarkan berbagai perilaku aneh yang bisa muncul ketika dua atau lebih transaksi bersamaan mengakses data yang sama.

Dalam konteks concurrency, read phenomena adalah situasi di mana hasil pembacaan data dalam satu transaksi dapat terpengaruh oleh transaksi lain yang berjalan bersamaan. Tiga jenis utama read phenomena yang biasa terjadi adalah Dirty Read, Non-Repeatable Read, dan Phantom Read.

1. Dirty Read

Dirty read terjadi ketika sebuah transaksi membaca data yang telah dimodifikasi oleh transaksi lain tetapi belum di-commit. Ini berbahaya karena jika transaksi yang mengubah data tersebut di-rollback, maka data yang dibaca oleh transaksi pertama menjadi tidak valid

Contoh:

• Transaksi A mengubah nilai saldo dari 100 menjadi 200 tetapi belum mengkomit.
• Transaksi B membaca nilai saldo sebagai 200.
• Transaksi A melakukan rollback, mengembalikan nilai saldo menjadi 100.
• Transaksi B kini memiliki data yang tidak konsisten.

2. Non-Repeatable Read

Non-repeatable read terjadi ketika suatu transaksi membaca data yang sama lebih dari sekali dan mendapatkan hasil yang berbeda karena transaksi lain mengubah data tersebut di antara dua pembacaan.

Contoh:

• Transaksi A membaca harga produk sebagai 100.
• Transaksi B mengubah harga produk menjadi 150 dan melakukan komit.
• Transaksi A membaca harga produk lagi dan melihat nilai 150, berbeda dari pembacaan pertama.

3. Phantom Read

Phantom read terjadi ketika suatu transaksi menjalankan kueri yang sama beberapa kali dan mendapatkan hasil yang berbeda karena transaksi lain menambah atau menghapus baris yang memenuhi kriteria kueri.

Contoh:

• Transaksi A menghitung jumlah produk dengan harga lebih dari 100 dan mendapatkan 10.
• Transaksi B menambahkan produk baru dengan harga 120 dan mengkomit.
• Transaksi A menjalankan kueri yang sama lagi dan mendapatkan 11 karena produk baru ditambahkan oleh transaksi B.

Tipe-Tipe Isolation Level di MySQL

Setelah memahami berbagai jenis read phenomena yang dapat terjadi dalam skenario concurrency, langkah selanjutnya adalah mempelajari cara mengatasi fenomena tersebut.

MySQL menyediakan empat tingkat isolation level yang berbeda untuk mengelola seberapa besar transaksi diisolasi satu sama lain. Setiap tingkat menawarkan keseimbangan yang berbeda antara kinerja dan isolasi, memungkinkan pengembang dan administrator database untuk memilih tingkat isolasi yang paling sesuai dengan kebutuhan aplikasi mereka.

1.     Read Uncommitted

Tingkat isolasi ini adalah yang paling rendah, di mana transaksi dapat membaca data yang telah diubah oleh transaksi lain meskipun perubahan tersebut belum di-commit. Ini dapat menyebabkan masalah seperti pembacaan data yang tidak konsisten.

Karakteristik

• Dirty Reads: Transaksi dapat membaca data yang belum di-commit, sehingga data yang dibaca mungkin berubah jika transaksi lain yang mengubah data tersebut dibatalkan.
• Kinerja: Memberikan performa yang sangat baik karena tidak ada penundaan untuk menunggu konfirmasi commit.
• Konsistensi: Konsistensi data sangat rendah karena memungkinkan data yang belum final untuk dibaca.

2. Read Committed

Pada tingkat ini, transaksi hanya dapat membaca data yang telah di-commit oleh transaksi lain. Ini mengurangi masalah terkait dengan dirty reads tetapi masih memungkinkan masalah seperti non-repeatable reads.

Karakteristik

• No Dirty Reads: Transaksi tidak akan membaca data yang belum di-commit oleh transaksi lain.
• Non-Repeatable Reads: Data yang dibaca bisa berubah jika transaksi lain melakukan commit setelah pembacaan.
• Kinerja: Menyediakan keseimbangan yang baik antara kinerja dan konsistensi.
• Konsistensi: Konsistensi data lebih baik daripada Read Uncommitted.

3. Repeatable Read

Tingkat isolasi ini memastikan bahwa jika sebuah transaksi membaca data, data tersebut tidak akan berubah selama transaksi berlangsung. Ini mengurangi masalah non-repeatable reads tetapi masih memungkinkan phantom reads.

Karakterisitik

• No Dirty Reads and No Non-Repeatable Reads: Menjamin bahwa data yang dibaca dalam transaksi tetap konsisten selama transaksi berlangsung.
• Phantom Reads: Data yang baru ditambahkan atau dihapus oleh transaksi lain mungkin tidak terlihat selama transaksi saat ini.
• Kinerja: Mengorbankan beberapa performa untuk meningkatkan konsistensi data.
• Konsistensi: Memberikan konsistensi data yang tinggi, cocok untuk aplikasi yang memerlukan keakuratan data.

4. Serializable

Tingkat isolasi tertinggi ini memastikan bahwa transaksi dieksekusi secara sekuensial dan tidak saling bertentangan. Ini menghindari semua masalah yang terkait dengan tingkat isolasi yang lebih rendah tetapi dapat mempengaruhi performa karena transaksi harus menunggu satu sama lain.

Karakteristik

• No Dirty Reads, No Non-Repeatable Reads, No Phantom Reads: Menjamin isolasi penuh antar transaksi.
• Kinerja: Performa dapat menurun secara signifikan karena transaksi harus menunggu satu sama lain untuk menyelesaikan.
• Konsistensi: Menyediakan tingkat konsistensi data yang tertinggi, cocok untuk aplikasi yang sangat memerlukan integritas data yang sempurna.

Perbedaan Antar Isolation Level

Berikut adalah tabel yang membandingkan berbagai jenis read phenomena dengan tingkat isolasi dalam MySQL:

Locking

Setelah memahami bagaimana isolation level bekerja untuk mengatasi berbagai read phenomena, kita bisa mengeksplorasi lebih lanjut tentang bagaimana MySQL menerapkan isolation level ini secara teknis. Salah satu mekanisme utama yang digunakan oleh MySQL untuk memastikan tingkat isolasi yang diinginkan adalah melalui locking. Locking memungkinkan MySQL untuk mengontrol akses terhadap data selama transaksi berlangsung, mencegah terjadinya konflik antar transaksi dan menjaga konsistensi data.

1.      Mengapa Locking Diperlukan?

Locking diperlukan untuk mencegah situasi di mana dua atau lebih transaksi mencoba mengakses atau memodifikasi data yang sama pada waktu yang bersamaan. Tanpa mekanisme locking, transaksi yang berjalan bersamaan bisa menyebabkan berbagai masalah seperti inkonsistensi data, kerusakan data, atau bahkan kegagalan total dalam pemrosesan transaksi.

Contoh Kasus: Stok Produk

Mari kita ambil contoh sederhana dalam konteks e-commerce, yaitu pengelolaan stok produk.

Misalkan kita mengelola toko online yang menjual produk elektronik. Ada satu produk populer dengan stok yang terbatas, katakanlah 10 unit. Dua pelanggan, Pelanggan A dan Pelanggan B, mencoba membeli produk tersebut secara bersamaan.

1. Tanpa Locking:
   • Pelanggan A: Membuka halaman produk dan melihat ada 10 unit yang tersedia.
   • Pelanggan B: Membuka halaman produk beberapa detik setelah Pelanggan A dan juga melihat ada 10 unit yang tersedia.
   • Pelanggan A: Menambah 1 unit produk ke dalam keranjang belanja dan melanjutkan ke proses pembayaran.
   • Pelanggan B: Juga menambah 1 unit produk ke dalam keranjang belanja dan melanjutkan ke proses pembayaran.
   • Keduanya menyelesaikan pembelian hampir bersamaan.

Tanpa mekanisme locking, sistem mungkin tidak mendeteksi bahwa kedua pelanggan telah membeli produk yang sama pada waktu yang hampir bersamaan. Akibatnya, sistem bisa saja mengurangi stok dua kali dari jumlah yang sama, dan stok akhir yang tersisa mungkin dihitung sebagai 9 unit, padahal sebenarnya hanya 8 unit yang seharusnya tersisa. Ini menciptakan ketidakakuratan dalam data stok yang bisa mengarah pada overselling, di mana lebih banyak produk dijual daripada yang tersedia.

• Dengan Locking:
  • Pelanggan A: Membuka halaman produk dan melihat ada 10 unit yang tersedia.
  • Pelanggan B: Membuka halaman produk beberapa detik setelah Pelanggan A dan juga melihat ada 10 unit yang tersedia.
  • Pelanggan A: Menambah 1 unit produk ke dalam keranjang belanja dan memulai proses pembayaran. Pada tahap ini, sistem menerapkan exclusive lock pada data stok produk tersebut.
  • Pelanggan B: Juga mencoba menambah 1 unit produk ke dalam keranjang, tetapi harus menunggu karena stok sedang di-locked oleh transaksi Pelanggan A.
  • Pelanggan A: Menyelesaikan pembelian, stok dikurangi menjadi 9 unit, dan lock dilepaskan.
  • Pelanggan B: Sekarang dapat melanjutkan proses pembelian, tetapi melihat bahwa stok yang tersedia sekarang hanya 9 unit.

Dengan locking, sistem memastikan bahwa hanya satu transaksi yang dapat mengubah data stok pada satu waktu. Hal ini mencegah situasi di mana dua pelanggan membeli produk yang sama melebihi jumlah stok yang tersedia. Locking menjamin bahwa setiap transaksi diproses secara eksklusif, sehingga data tetap konsisten dan akurat.

2. Jenis-Jenis Berdasarkan Level atau Skop

1. Table-Level Locks

Table locks adalah mekanisme penguncian yang memberikan kontrol eksklusif atas seluruh tabel selama transaksi berlangsung. Ketika sebuah tabel dikunci, transaksi lain tidak dapat membaca atau mengubah data di tabel tersebut hingga kunci dilepaskan. Kunci tabel sering digunakan untuk operasi yang memerlukan akses penuh ke seluruh tabel, seperti pemeliharaan tabel atau operasi batch besar.

2. Row-Level Locks

Row locks adalah mekanisme penguncian yang memungkinkan transaksi untuk mengunci baris tertentu dalam tabel tanpa mempengaruhi baris lain. Kunci baris digunakan untuk mengelola akses data secara granular, memastikan bahwa hanya baris yang spesifik yang dikunci, sementara baris lainnya tetap dapat diakses oleh transaksi lain.

3. Jenis-Jenis Locking Berdasarkan Sifat

1. Shared Locks (S Locks)

Shared locks adalah jenis penguncian yang memungkinkan beberapa transaksi untuk membaca data yang sama secara bersamaan tanpa mengubah data tersebut. Dengan menggunakan kunci bersama, transaksi dapat memastikan bahwa data yang dibaca tetap konsisten selama periode akses, tanpa memungkinkan perubahan oleh transaksi lain selama proses pembacaan. Ini berguna untuk menjaga integritas data dan menghindari konflik saat banyak transaksi mencoba mengakses data yang sama.

Contoh Kasus:

Misalkan Anda memiliki sebuah tabel products yang menyimpan informasi tentang produk di sebuah toko online. Ada dua pengguna yang ingin membaca detail produk yang sama secara bersamaan

Dalam contoh ini, kedua transaksi berhasil memperoleh Shared Lock pada baris data yang sama (product_id = 101). Keduanya bisa membaca data yang sama tanpa masalah, namun tidak ada yang bisa memodifikasi data tersebut selama S-Lock masih aktif.

2. Exclusive Locks (X Locks)

Exclusive locks adalah jenis penguncian yang memberikan kontrol penuh atas data yang dikunci kepada satu transaksi. Ketika sebuah transaksi memegang kunci eksklusif pada data, transaksi lain tidak dapat membaca atau mengubah data tersebut hingga kunci dilepaskan. Ini menjamin bahwa data yang dikunci tidak akan terpengaruh oleh transaksi lain selama periode penguncian, sehingga menjaga integritas data.

Contoh Kasus:

Misalkan kita memiliki akun bank dengan saldo yang ingin ditarik. Untuk memastikan proses penarikan dilakukan dengan benar dan tidak ada transaksi lain yang mengubah saldo akun pada saat yang sama, kita menggunakan Exclusive Lock. Ini mencegah transaksi lain dari mengakses atau mengubah saldo selama proses penarikan berlangsung.

Penjelasan

• BEGIN: Memulai transaksi baru.
  • SELECT … FOR UPDATE: Mengunci saldo akun, mencegah transaksi lain dari mengubah saldo akun ini selama proses penarikan.
  • UPDATE: Mengurangi saldo akun setelah penarikan. Karena kita telah mengunci akun, operasi ini dilakukan dengan aman tanpa gangguan dari transaksi lain.

COMMIT: Menyimpan perubahan saldo dan melepaskan kunci.

Kesimpulan

Concurrency control adalah elemen penting dalam manajemen basis data, terutama di lingkungan dengan banyak transaksi yang berjalan secara bersamaan. Dalam artikel ini, kita telah membahas berbagai konsep yang berkaitan dengan concurrency control di MySQL, mulai dari ACID, read phenomena, isolation level, hingga locking.

• ACID adalah prinsip dasar yang menjamin transaksi dalam database akan berjalan dengan aman dan konsisten. Ini adalah fondasi untuk memahami bagaimana sebuah sistem database menjaga integritas datanya.
• Read phenomena mengidentifikasi potensi masalah yang bisa terjadi ketika beberapa transaksi mengakses data yang sama secara bersamaan, seperti dirty read, non-repeatable read, dan phantom read. Memahami fenomena ini membantu kita untuk menyadari pentingnya isolation level yang tepat.
• Isolation level menyediakan cara untuk mengontrol seberapa besar pengaruh satu transaksi terhadap transaksi lainnya. Dengan memilih isolation level yang tepat, kita dapat menyeimbangkan antara kinerja sistem dan tingkat isolasi yang diperlukan untuk mencegah masalah seperti read phenomena.
• Locking adalah alat utama yang digunakan oleh MySQL untuk mengimplementasikan isolation level dan menjaga konsistensi data selama transaksi berjalan. Berbagai jenis locking, seperti shared lock, exclusive lock, dan intention lock, bekerja di belakang layar untuk memastikan bahwa data tetap konsisten dan terhindar dari konflik antar transaksi.

Dengan memahami keterkaitan antara konsep-konsep ini, Anda dapat lebih baik dalam merancang sistem database yang mampu menangani banyak transaksi secara efisien, tanpa mengorbankan konsistensi dan integritas data. Concurrency control bukan hanya soal memastikan bahwa data tidak rusak, tetapi juga soal mengoptimalkan kinerja database dalam skenario dengan beban kerja tinggi. Badr Interactive telah menerapkan concurrency control dalam aktivitas pengembangan yang dilakukan. Jika Anda tertarik untuk diskusi lebih lanjut silakan bisa menghubungi kami.