Mengenal Transaksi Database & ACID
Pernahkah anda berpikir apa yang akan terjadi jika ada dua orang memesan kamar hotel yang sama pada durasi dan waktu yang sama juga (Bahkan tidak ada perbedaan detiknya sedikitpun saat mereka memesan dengan mengkliknya) ?
Mengapa dalam domain Perbankan database NoSQL tidak direkomendasikan ?
Tulisan ini menjelaskan sedikit tentang :
1.Apa itu transaksi ? Apa itu ACID di database dan mengapa kita membutuhkanya ?
2. Mengapa kita membutuhkan transaksi dengan skenario real-time ?
3. Apa saja jenis Isolasi di Database Transaksional dan apa saja keuntungan dan kerugianya ?
Apa itu transaksi ?
Pada istilah awam, transaksi merupakan cara aplikasi mengelompokkan beberapa baca dan tulis (CRUD) bersama-sama dalam satu unit logis.
Secara teknis yaitu segala sesuatu antara BEGIN TRANSACTION dan pernyataan COMMIT dianggap sebagai bagian dari transaksi yang sama.
Dalam transaksi kita pasti membutuhkan jaminan keamanan bukan ? Jaminan ini biasa kita kenal dengan singkatan ACID yang merupakan singkatan dari Atomicity, Consistency, Isolation, Durability.
1. Atomicity
Atomicity mengacu dari kata dasar “ATOM” yang artinya mengacu pada sesuatu yang kecil dan tidak dapat dipecah menjadi bagian yang lebih kecil lagi.
Bagaimana caranya jika anda adalah nasabah dari bank A, namun anda ingin memindahkan saldo di bank tersebut ke bank B secepatnya ? Mungkin konsepnya cukup sederhana yaitu langkah pertama dengan mengurangi jumlah rekening A dan langkah kedua menambahkan jumlah yang sama ke rekening B.
Namun permasalahan sesungguhnya adalah bagaimana jika ketika langkah pertama selesai dan server perbankan rusak ?
Benar! Jawabanya adalah uang anda akan hilang terbang bersama angan-angan anda yang belum tercapai :”p
Lalu apa fungsi dari Atomicity ? Tentu saja sebagai penyelamat uang anda. Atomicity menyederhanakan masalah saat transaksi dibatalkan, aplikasi tidak akan mengubah apapun, sehingga dapat dicoba lagi nanti dengan aman jika diperlukan.
2. Consistency
Menurut Kamus Besar Bahasa Indonesia, konsistensi adalah ketetapan dan kemantapan dalam bertindak.
Konsep konsistensi dalam database berarti sebuah keadaan yang harus dalam “kondisi yang baik”. Ide dari ACID konsistensi sendiri adalah ketika terjadi transaksi, aplikasi bertanggung jawab atas transaksinya dengan benar dan secara konsisten.
3. Isolation
Isolasi berarti bahwa dalam transaksi yang dieksekusi secara bersamaan diisolasi dari satu sama lain dan mereka tidak dapat melihat operasi satu sama lain.
4. Durability
Durability menjamin ketika anda melakukan transaksi data apapun yang telah anda lakukan tidak akan hilang, bahkan jika ada kesalahan atau kegagalan dari perangkat keras dan databasenya.
Secara sederhana, ada backup data secara terus menerus sebagai tindakan preventif untuk pemulihan ketika terjadi bencana.
Semua yang ada di dunia ini tidak ada yang sempurna, termasuk dengan cara kerja Durabilty itu sendiri. Jika semua hard disk dan semua data yang anda backup hancur pada waktu yang sama, tidak akan ada yang bisa menyelamatkan semua data yang anda punya.
Sistem yang tidak memenuhi kriteria ACID kita sebut dengan BASE, yaitu Basically Available, Soft state, & Eventual consistent. Sebagian besar NoSQL saat ini sebenarnya BASE. Untuk bersaing mereka mengatakan bahwa mereka 100% sesuai dengan ACID.
Sebenarnya NoSQL database sangat berguna dalam hal data dalam jumlah besar. NoSQL datang tidak untuk menggantikan database relasional. Ini hanya menjadi alternatif, di tengah dunia yang masih butuh banyak data untuk dianalisis.
Database SQL terhubung secara relasional, memberi skema yang lebih kaku yang menawarkan konsistensi data yang lebih baik tetapi lebih sedikit fleksibilitas. SQL menskalakan secara vertikal yang merupakan kerugian dibandingkan dengan database NoSQL.
Namun, mereka menawarkan bahasa kueri yang kuat dan universal yang disebut SQL dan mereka mematuhi properti ACID. Di sisi lain, data model NoSQL tanpa relasi tabel dari database relasional yang memungkinkan skema yang lebih fleksibel tetapi menawarkan konsistensi data yang lebih sedikit. Mereka menskalakan secara horizontal memberi mereka keuntungan besar dibandingkan database SQL tetapi tidak memiliki bahasa kueri universal. Akhirnya, mereka tidak mematuhi properti ACID.
ISOLATION LEVELS
Sekarang mari kita pelajari lebih lanjut tentang isolation levels. Isolation levels terdiri dari 4, yaitu :
- Read Uncommitted (Weakest Isolation Level)
- Read Committed
- Repeatable Read or Snapshot Isolation (Default level for many DB)
- Serializable (Strongest Isolation Level)
Read Committed
Tingkat paling dasar dari isolasi transaksi adalah read committed. Ini memberikan dua jaminan :
1. Ketika membaca dari database, anda akan melihat data yang telah dilakukan ( tidak ada dirty reads)
2. Ketika menulis ke database, anda hanya akan menimpa data yang telah dilakukan (tidak ada dirty writes)
Singkatnya, jika dua transaksi T1 dan T2 dijalankan , maka transaksi T1 dapat melihat atau membaca perubahan (tulis atau update) yang dibuat oleh transaksi T2 jika T2 dilakukan sebelum T1.
Apa itu Dirty Read ?
Dirty Read atau pembacaan kotor terjadi ketika transaksi diizinkan untuk membaca data dari baris yang telah dimodifikasi oleh transaksi lain yang sedang berjalan dan belum dilakukan.
Apa itu Dirty Write?
Dirty Write atau penulisan kotor terjadi saat transaksi diizinkan untuk menimpa data dari baris yang telah dimodifikasi oleh transaksi lain yang sedang berjalan dan belum dilakukan.
Implementasi Read Committed
Database mencegah dirty writes dan dirty reads dengan menggunakan row-level locks. Ketika transaksi ingin mengubah baris atau dokumen tertentu, itu harus terlebih dahulu memperoleh kunci pada objek tersebut (baris atau dokumen). Kemudian harus menahan transaksi dilakukan atau dibatalkan.
Hanya satu transaksi yang dapat menahan kunci untuk baris atau dokumen tertentu. Namun, pendekatan yang membutuhkan kunci baca tidak bekerja dengan baik dalam praktiknya, karena satu transaksi tulis yang berjalan lama dapat memaksa banyak transaksi hanya read-only untuk menunggu hingga transaksi yang berjalan lama selesai.
Hal ini merusak waktu respon transaksi read-only karena perlambatan di suatu bagian aplikasi yang sama,karena menunggu locks.
Masalah pada Read Committed
Sekarang kita pahami masalahnya dengan skenario real-time.
- Misalkan ada seorang pelanggan bernama Alice memiliki jumlah uang 100 juta dalam dua rekeningnya di sebuah bank dan jumlahnya dibagi di kedua rekening tersebut dengan masing masing 50 juta.
- Kemudian Alice memulai transaksi transfer 10 juta dari satu akun ke akun lainya. Transaksi ini terdiri dari dua laporan, pertama adalah menambahkan 10 juta ke akun 1 dan kedua mengurangi 10 juta dari akun 2.
- Tetapi sebelum memulai transaksi transfer. Alice juga memulai membaca transaksi yang pertama-tama membaca saldo dari akun 1 dan kemudian membaca saldo dari akun 2.
- Seperti yang biasa kita lakukan, baca transaksi dimulai sebelum transfer, dan baca transaksi dilakukan setelah transfer.
- Sekarang menurut aturan Read Committed Isolation sebagai Transfer-Transaction dilakukan sebelum Read-Transcation. Karenanya Read-Transaction dapat melihat perubahan yang dilakukan oleh Transfer-Transaction.
- Jadi Alice dapat melihat akun 1 sebelum pembayaran masuk (dengan saldo 50 juta), dan melihat akun lain setelah transfer keluar (saldo baru adalah 40 juta)
- Jadi bagi Alice, sekarang ia hanya memeliki total 90 juta di akunnya ( 50 juta di akun 1 dan 40 juta di akun 2). Lalu kemana 10 juta yang telah ia transfer sebelumnya ?
- Anomali ini disebut Non-Repeatable Read or Read Skew. Tetapi, jika Alice membaca saldo akun 1 lagi di akhir transaksi, dia akan melihat nilai yang berbeda (60 juta) dari yang dia lihat di query sebelumnya.
Daftar Pustaka :
A Critique of ANSI SQL Isolation Levels | the morning paper (acolyer.org)
