ACID

Prinsip ACID (akronim dari istilah bahasa Inggris atomicity, consistency, isolation dan durability) adalah serangkaian sifat dari transaksi yang terjadi dalam basis data yang menjamin validitas data meskipun terjadi galat, kegagalan daya, dan kerusakan lainnya pada mesin saat basis data beroperasi melakukan transaksi data pada mesin. Dalam konteks basis data, suatu transaksi dimaknai sebagai suatu rangkaian operasi logis pada basis data yang memenuhi sifat ACID. Sebagai contoh, operasi transfer dana dari satu rekening bank ke rekening bank lain, bahkan apabila melibatkan perubahan pada beberapa data seperti mendebit satu rekening dan mengkredit rekening lain, dihitung sebagai satu transaksi.

Pada tahun 1983, Andreas Reuter dan Theo Härder menciptakan akronim ACID,^[1] yang merupakan modifikasi dari hasil penelitian sebelumnya oleh Jim Gray^[2] yang pertama menelurkan sifat atomicity (atomisitas), consistency (konsistensi), dan durability (ketahanan) dalam mendeskripsikan suatu transaksi basis data. Heuter dan Härder kemudian menambahkan satu sifat lagi, yaitu isolation (isolasi). Keempat sifat ini menjadi patokan jaminan keberhasilan transaksi dalam basis data, memengaruhi banyak aspek pengembangan dalam kajian sistem basis data.

Menurut Gray dan Reuter, Sistem Manajemen Informasi IBM telah mengimplementasikan sifat ACID dalam transaksi basis data pada sistemnya sejak tahun 1973 (meskipun akronimnya secara teoretis baru dibuat 1 dekade kemudian).^[3]

Selain prinsip ACID, dalam basis data juga dikenal prinsip BASE yang merupakan akronim dari basically available (selalu tersedia), soft state (berkeadaan tidak tetap), and eventually consistent (akan konsisten di akhir). Secara teoretik, prinsip BASE merupakan kebalikan dari prinsip ACID, sebagaimana kata benda yang membentuk akronim merupakan kebalikan dalam ilmu kimia (basa dan asam).^[4] Basis data yang berprinsip ACID mengutamakan konsistensi pada data ketimbang ketersediaan — membuat suatu transaksi akan gagal jika terjadi kesalahan pada langkah mana pun dalam transaksi, sehingga data akan tetap konsisten; sebaliknya, basis data berprinsip BASE mengutamakan ketersediaan data daripada konsistensi: ketika terjadi kegagalan dalam transaksi, pengguna tetap dapat mengakses data yang tidak konsisten untuk sementara untuk kemudian dibenahi dan dikembalikan. Dalam prinsip BASE, konsistensi data dapat tercapai, tetapi tidak langsung, sedang dalam prinsip ACID, konsistensi terjadi secara langsung.^[5]

Karakteristik

Reuter dan Härder mendefinisikan masing-masing karakteristik pada prinsip ACID sebagai berikut:

Atomisitas (Atomicity)

Transaksi dalam basis data, yang terjadi menggunakan perintah SQL, sering kali terdiri dari beberapa pernyataan SQL. Prinsip atomisitas menjamin bahwa setiap transaksi diperlakukan sebagai satu "unit" (atom), yang dapat bernilai berhasil atau tidak: jika salah satu pernyataan dalam transaksi gagal diselesaikan, seluruh transaksi gagal dan basis data tidak berubah. Sistem yang berprinsip atomik harus menjamin setiap situasi, termasuk kegagalan daya, kesalahan, dan kerusakan terjadi secara atomik untuk menjaga integritas data.^[6] Prinsip atomisitas mencegah pembaruan tidak sempurna (sebagian) pada basis data, yang dapat menyebabkan masalah yang lebih besar ketimbang menolak seluruh transaksi secara langsung. Sebagai konsekuensi, pengguna atau program lain yang sedang mengakses basis data pada saat yang sama tidak akan pernah melihat transaksi yang baru setengah jalan. Pada satu saat, transaksi tersebut belum terjadi, dan pada saat berikutnya, itu transaksi tersebut telah terjadi secara sempurna (atau tidak ada yang terjadi jika transaksi dibatalkan saat sedang berlangsung).

Konsistensi (Consistency)

Prinsip konsistensi memastikan bahwa suatu transaksi hanya dapat membawa basis data dari satu keadaan konsisten ke keadaan konsisten lainnya, sehingga mempertahankan invarian (aturan dan batasan) pada basis data. Maksudnya, setiap data yang ditulis ke basis data harus valid sesuai dengan semua aturan dan batasan yang ditetapkan, termasuk kendala (constraints), penjalaran (cascade), pemicu (triggers), dan kombinasi apa pun dari ketiganya. Hal ini mencegah kerusakan basis data akibat transaksi ilegal. Contoh invarian basis data adalah integritas referensial, yang menjamin validitas hubungan antara kunci primer – kunci asing.

Isolasi (Isolation)

Beberapa transaksi seringkali dieksekusi secara serentak (concurrent; misalnya, beberapa transaksi membaca dan menulis ke tabel secara bersamaan). Prinsip isolasi memastikan bahwa eksekusi transaksi secara bersamaan dan menjadikan basis data dalam keadaan yang sama seperti jika transaksi dieksekusi secara berurutan. Isolasi adalah tujuan utama dari kontrol keserentakan (concurrency control); tergantung pada tingkat isolasi yang digunakan, efek dari transaksi yang tidak lengkap mungkin tidak terlihat oleh transaksi lain.^[7]

Ketahanan (Durability)

Ketahanan menjamin bahwa setelah transaksi selesai dilakukan, transaksi tersebut akan bersifat tetap (committed) bahkan jika terjadi kegagalan sistem (misalnya, pemadaman listrik atau mogok). Ini biasanya berarti bahwa transaksi yang telah selesai (atau dampaknya) dicatat dalam memori non-volatil.^[8]

Contoh

Contoh-contoh berikut memberikan ilustrasi sifat ACID dalam transaksi di suatu basis data perbankan. Dalam contoh ini, tabel basis data memiliki dua kolom, ${\displaystyle A}$ dan ${\displaystyle B}$. Kendala integritas mengharuskan nilai di ${\displaystyle A}$ dan nilai di ${\displaystyle B}$ berjumlah 100. Kode SQL berikut membuat tabel seperti yang dijelaskan di atas:

CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));

Atomisitas

Menggunakan ilustrasi basis data perbankan yang telah disiapkan, terdapat suatu transaksi transfer uang dari rekening A ke rekening B. Transaksi ini terdiri dari dua operasi, yaitu penarikan sejumlah uang dari rekening A dan penyetorannya ke rekening B. Suatu transaksi berhasil yang bersifat atomik terjadi apabila kedua operasi tersebut berhasil secara sempurna. Transaksi tidak bisa dikatakan berhasil sebelum jumlah uang yang ditarik dari rekening A telah ditransfer ke rekening B dalam jumlah yang sama. Transaksi yang atomik memastikan bahwa basis data tetap konsisten, yaitu, uang tidak akan didebet maupun dikredit jika salah satu dari kedua operasi tersebut gagal. ^[9]

Kegagalan konsistensi

Konsistensi adalah istilah yang sangat umum, yang menuntut bahwa data harus memenuhi semua aturan validasi. Dalam contoh basis data perbankan sebelumnya, validasi dilakukan dengan memeriksa bahwa A + B = 100. Seluruh aturan validasi harus diperiksa untuk memastikan prinsip konsistensi terpenuhi. Misalkan suatu transaksi mencoba untuk mengurangi sebanyak 10 unit dari ${\displaystyle A}$ tanpa melakukan perubahan pada ${\displaystyle B}$. Karena konsistensi diperiksa setelah setiap transaksi, diketahui bahwa A + B = 100 sebelum transaksi dimulai. Jika transaksi menghapus 10 unit dari ${\displaystyle A}$ dengan sukses, transaksi tersebut dapat disifati sebagai atomik. Namun, ketika pengecekan validasi dilakukan, ditemukan bahwa A + B = 90, yang tidak konsisten dengan aturan validasi. Dengan demikian, sistem akan membatalkan transaksi dan baris akan dikembalikan ke keadaan sebelum transaksi (rollback). Bila sistem menetapkan suatu kendala, pemicu, atau penjalaran lain, tiap operasi perubahan tunggal akan diperiksa dengan cara yang sama sebelum transaksi disahkan/dikomit (committed). Masalah serupa dapat muncul dengan kendala lain. Pengguna dapat mensyaratkan tipe data bilangan bulat untuk ${\displaystyle A}$ dan ${\displaystyle B}$. Jika kita kemudian terdapat transaksi yang memasukkan nilai desimal, semisal 13,5 untuk ${\displaystyle A}$, transaksi akan dibatalkan, atau sistem mungkin akan memunculkan peringatan berupa pemicu (jika pengguna membuatnya). Contoh lain dari suatu kendala integritas, adalah suatu kendala yang tidak mengizinkan kita menghapus baris yang kunci utamanya dirujuk oleh setidaknya satu kunci asing di tabel lain.

Kegagalan isolasi

Misalkan terdapat dua transaksi dijalankan pada saat yang sama, masing-masing mencoba mengubah data yang sama. Salah satu transaksi harus menunggu hingga transaksi lainnya selesai agar isolasi tetap terjaga.

Berikut dua transaksi:

• ${\displaystyle T_{1}}$ melakukan operasi transfer 10 unit dari ${\displaystyle A}$ ke ${\displaystyle B}$.
• ${\displaystyle T_{2}}$ melakukan operasi transfer 20 unit dari ${\displaystyle B}$ ke ${\displaystyle A}$.

Jika digabungkan, terdapat empat operasi:

1. ${\displaystyle T_{1}}$ mengurangi 10 unit dari ${\displaystyle A}$.
2. ${\displaystyle T_{1}}$ menambahkan 10 unit ke ${\displaystyle B}$.
3. ${\displaystyle T_{2}}$ mengurangi 20 unit dari ${\displaystyle B}$.
4. ${\displaystyle T_{2}}$ menambahkan 20 unit ke ${\displaystyle A}$.

Jika operasi-operasi ini dilakukan secara berurutan, isolasi tetap terjaga, meskipun ${\displaystyle T_{2}}$ harus menunggu. Apabila terjadi kegagalan pada ${\displaystyle T_{1}}$ di tengah operasi, basis data cukup menghilangkan hasil ${\displaystyle T_{1}}$, dan ${\displaystyle T_{2}}$ hanya menggunakan data awal yang valid.

Bila dilakukan penjalinan pada transaksi (tanpa isolasi), urutan tindakan mungkin menjadi:

1. ${\displaystyle T_{1}}$ mengurangi 10 unit dari ${\displaystyle A}$.
2. ${\displaystyle T_{2}}$ mengurangi 20 unit dari ${\displaystyle B}$.
3. ${\displaystyle T_{2}}$ menambahkan 20 unit ke ${\displaystyle A}$.
4. ${\displaystyle T_{1}}$ menambahkan 10 unit ke ${\displaystyle B}$.

Pada skema ini, misalkan terjadi kegagalan pada langkah ke-4, yaitu saat ${\displaystyle T_{1}}$ mencoba memodifikasi ${\displaystyle B}$. Ketika ${\displaystyle T_{1}}$ gagal, ${\displaystyle T_{2}}$ sudah lebih dulu mengubah nilai ${\displaystyle A}$. Akibatnya, nilai ${\displaystyle A}$ tidak dapat dikembalikan ke keadaan sebelum ${\displaystyle T_{1}}$ dimulai tanpa sekaligus membatalkan perubahan sah yang telah dilakukan oleh ${\displaystyle T_{2}}$, yang akan menyebabkan basis data menjadi tidak konsisten. Hal ini dikenal sebagai write-to-write contention (konflik penulisan ganda),^[10] karena dua transaksi mencoba menulis ke isian data yang sama. Umumnya, masalah ini dapat diselesaikan dengan melakukan pengembalian ke status baik termutakhir yang diketahui, membatalkan transaksi ${\displaystyle T_{1}}$ yang gagal, dan memulai kembali transaksi ${\displaystyle T_{2}}$ berdasarkan status baik termutakhir.

Kegagalan daya tahan

Asumsikan suatu transaksi yang mentransfer 10 unit dari ${\displaystyle A}$ ke ${\displaystyle B}$. Pertama, transaksi tersebut menghapus 10 unit dari ${\displaystyle A}$, lalu menambahkan 10 unit ke ${\displaystyle B}$. Pada titik ini, pengguna diberi tahu bahwa transaksi tersebut berhasil. Namun, pada keadaan fisik cakram perangkat, perubahan tersebut masih mengantre di disk buffer (penyimpan sementara), menunggu untuk dikomit ke disk. Bila terjadi pemadaman listrik, perubahan hilang, tetapi pengguna berasumsi bahwa perubahan tersebut sudah masuk ke dalam penyimpanan. Ini adalah salah satu bentuk kegagalan dalam prinsip ketahanan.

Implementasi

Pemrosesan transaksi sering kali memerlukan serangkaian operasi yang rentan terhadap kegagalan karena sejumlah alasan. Misalnya, sistem mungkin tidak memiliki ruang tersisa pada disk drive-nya, atau mungkin telah menggunakan semua alokasi waktu CPU yang tersedia. Terdapat dua jenis teknik yang populer menghadapi potensi kegagalan: write-ahead logging dan shadow paging. Dalam kedua kasus tersebut, kunci (lock) harus diperoleh pada semua informasi yang akan diubah dan mungkin pada semua data yang dapat dibaca juga (tergantung tingkatan proses isolasi pada data tersebut). Dalam write ahead logging, penjaminan ketahanan dilakukan dengan menulis calon perubahan data (prospective changes) ke log persisten sebelum dilakukan perubahan dalam basis data. Hal tersebut memungkinkan basis data untuk kembali ke keadaan konsisten jika terjadi kegagalan sistem. Dalam page shadowing, pembaruan diterapkan pada salinan parsial basis data, dan salinan baru diaktifkan ketika transaksi dikomit.

Penguncian vs. multiversi

Banyak basis data mengandalkan sistem penguncian (locks) untuk memenuhi prinsip ACID. Penguncian bermakna suatu transaksi menandai data yang sedang diakses untuk memberitahu DBMS agar tidak mengizinkan transaksi lain mengaksesnya hingga transaksi pertama berstatus berhasil atau gagal. Status penguncian harus selalu diperoleh dari DBMS sebelum transaksi memproses data, termasuk data yang dibaca tetapi tidak diubah. Transaksi non-trivial biasanya membutuhkan sejumlah besar penguncian, yang mengakibatkan overhead yang substansial serta memblokir transaksi lain. Misalnya, jika pengguna X menjalankan transaksi yang harus membaca baris data yang ingin diubah oleh pengguna Y, pengguna X harus menunggu hingga transaksi pengguna Y selesai. Penguncian dua fase (two-phase locking) sering diterapkan untuk menjamin isolasi penuh.

Alternatif untuk penguncian adalah kontrol keserentakan multiversi (multiversion concurrency control), yakni basis data menyediakan versi data sebelumnya yang belum dimodifikasi untuk tiap transaksi, yang mungkin sedang dimodifikasi oleh transaksi aktif lainnya. Hal ini memungkinkan pengguna untuk melakukan operasi baca (read) tanpa memerlukan kunci, yaitu, transaksi penulisan tidak perlu memblokir transaksi pembacaan, dan pengguna yang melakukan operasi baca tidak memblokir pengguna yang melakukan operasi tulis. Misalnya, ketika transaksi pengguna X meminta data yang dimodifikasi oleh pengguna Y, basis data menyediakan X dengan versi data yang ada sebelum pengguna Y memulai transaksinya. Pengguna X mendapatkan tampilan basis data yang konsisten meskipun pengguna lain mengubah data. Salah satu implementasi, disebut isolasi snapshot, memberlakukan prinsip isolasi dengan lebih longgar.

Transaksi terdistribusi

Menjamin sifat ACID dalam transaksi terdistribusi di seluruh basis data terdistribusi merupakan aksi yang kompleks, karena tidak ada satu simpul pun yang bertanggung jawab atas semua data yang memengaruhi transaksi. Dapat terjadi kegagalan dalam koneksi jaringan, atau satu simpul mungkin berhasil menyelesaikan bagiannya dari transaksi dan kemudian diminta untuk mengembalikan perubahannya karena kegagalan pada simpul lain. Protokol komit dua fase (two-phase commit protocol; berbeda dengan penguncian dua fase) menyediakan proses atomik untuk transaksi terdistribusi dengan memastikan bahwa setiap peserta dalam transaksi memberikan tanda setuju apakah transaksi harus dikomit atau tidak.^[11] Secara singkat, pada fase pertama, satu simpul (koordinator) menginterogasi simpul lain (peserta), dan hanya ketika semua menjawab bahwa mereka siap, koordinator, pada fase kedua, melakukan komit terhadap transaksi.

Lihat juga

• Interkoneksi Sistem Terbuka
• CRUD