3.1 Munculnya ASAM
Singkatan ACID pertama kali muncul pada tahun 1983 dalam sebuah artikel oleh Theo Haerder dan Andreas Reuter. Untuk menyederhanakan teks dan membuatnya lebih meyakinkan, saya akan memberikan terjemahan dari penggalan artikel ini (dengan sedikit pengurangan). Cuplikan ini menggunakan contoh transaksi bank di mana uang ditransfer dari satu rekening ke rekening lainnya.
Konsep transaksi, yang dalam contoh mencakup semua interaksi dengan database antara $BEGIN_TRANSACTIONdan $COMMIT_TRANSACTION, mensyaratkan bahwa semua tindakan dilakukan secara terpisah: apakah semua tindakan tercermin dengan benar dalam keadaan database, atau tidak ada yang terjadi. Jika suatu saat sebelum mencapai $COMMIT_TRANSACTIONpengguna memasukkan pernyataan ERRORyang berisi $RESTORE_TRANSACTION, maka tidak ada perubahan yang tercermin dalam database.
Untuk mencapai ketidakterpisahan ini, sebuah transaksi harus memiliki empat sifat berikut:
Atomisitas (Atomisitas). Transaksi harus dari jenis semua atau tidak sama sekali yang dijelaskan di atas, dan apa pun yang terjadi, pengguna harus mengetahui status transaksi tersebut.
Konsistensi (Konsistensi). Sebuah transaksi yang mencapai akhir normal transaksi (EOT) dan dengan demikian melakukan hasilnya menjaga konsistensi database. Dengan kata lain, setiap transaksi yang sukses, menurut definisi, hanya memberikan hasil yang valid. Kondisi ini diperlukan untuk mendukung sifat keempat - daya tahan.
Isolasi (Isolasi). Peristiwa yang terjadi dalam suatu transaksi harus disembunyikan dari transaksi lain yang dilakukan secara bersamaan. Jika kondisi ini tidak terpenuhi, maka karena alasan yang disebutkan di atas, transaksi tidak mungkin kembali ke awal. Untuk mencapai isolasi, metode yang disebut sinkronisasi digunakan ...
Daya Tahan (Durability). Setelah transaksi selesai dan memasukkan hasilnya ke database, sistem harus memastikan bahwa hasil tersebut selamat dari kegagalan berikutnya. Karena tidak ada ruang lingkup kendali yang mencakup serangkaian transaksi, sistem manajemen basis data (DBMS) tidak memiliki kendali di luar batas transaksi.
Oleh karena itu, pengguna harus dijamin bahwa jika sistem memberi tahu dia bahwa sesuatu telah terjadi, maka "sesuatu" ini benar-benar terjadi. Karena, menurut definisi, setiap transaksi (berhasil diselesaikan - S.K.) adalah benar, hasil dari transaksi yang salah yang pasti muncul (yaitu transaksi yang berisi data yang salah) hanya dapat dihilangkan dengan transaksi "kontra" yang sesuai (transaksi balasan).
3.2 Munculnya transaksi
Keempat properti ini—Atomicity, Consistency, Isolation, dan Durability (ACID)—menjelaskan fitur inti dari paradigma transaksional yang memengaruhi banyak aspek desain sistem basis data. Oleh karena itu, kami percaya bahwa kemampuan suatu sistem untuk mendukung transaksi adalah batu ujian (ACID test) dari kualitas sistem ini.
Program PL/1-SQL sederhana yang mentransfer dana dari satu akun ke akun lainnya.
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */Saya memberikan contoh kode ini untuk mengingatkan Anda bahwa, pada kenyataannya, properti ACID, di satu sisi, dapat dianggap sebagai persyaratan untuk setiap DBMS yang mengklaim mendukung transaksi, dan di sisi lain, sebagai definisi transaksi di sebuah sistem basis data . Definisi ini sepenuhnya konsisten dengan praktik duniawi. Sulit membayangkan, misalnya, bahwa nasabah yang melakukan transaksi perbankan (baik dengan bantuan teller langsung atau menggunakan internet banking) tidak mengharapkan bank untuk memenuhi semua sifat ACID. Bank yang tidak mendukung properti ACID untuk transaksinya paling-paling akan kehilangan pelanggan, dan paling buruk bangkrut.
3.3 Konektivitas ASAM
Sangat penting bahwa properti ACID tidak dapat dipisahkan, membuang salah satunya membuat kombinasi yang tersisa menjadi tidak berarti. Secara khusus, jika kita membuang properti konsistensi (dalam arti yang digunakan dalam kutipan di atas), maka kita akan kehilangan kriteria kebenaran suatu transaksi. Sistem basis data tidak akan dapat memutuskan dengan cara apa pun apakah transaksi diizinkan atau tidak untuk dilakukan, dan semua pemeriksaan untuk kebenaran operasi yang dilakukan dalam keadaan basis data saat ini harus dilakukan dalam kode aplikasi.
Anda perlu memahami bahwa dalam hal ini kita berbicara tentang konsistensi logis. Klien bank membutuhkan bank untuk bekerja sesuai dengan aturan yang ditetapkan olehnya dan diketahui oleh klien, sehingga tidak mungkin melakukan transaksi apa pun yang melanggar aturan tersebut, sehingga transaksi berikutnya dari klien yang sama dijalankan dalam suatu lingkungan yang disepakati sesuai dengan aturan tersebut.
Klien toko online membutuhkan barang yang dipesan dan dibayar olehnya untuk dikirimkan kepadanya tepat waktu (sesuai dengan aturan yang ditetapkan dan diketahui klien). Kalau tidak, dia tidak akan mempercayai toko ini. Pada saat yang sama, baik klien bank maupun klien toko Internet tidak peduli dengan dapur internal perusahaan, tindakan internal apa yang diambil untuk menyelesaikan transaksinya. Klien tidak peduli bagaimana konsistensi fisik perusahaan ini dipertahankan, bagaimana operasi dilakukan pada lapisan fisik.
Jika DBMS menjaga konsistensi logis dari transaksi (dan database), maka aplikasi menjadi lebih sederhana, lebih mudah dipahami, dan lebih dapat diandalkan. Semua logika area aplikasi (bank, toko, gudang, dll.) Mengenai transaksi dan status data yang valid masuk ke sistem database. Dan persyaratan untuk sistem ini sangat sederhana: dukungan untuk transaksi ACID, dengan mempertimbangkan aturan konsistensi yang disediakan oleh aplikasi di database. Dari sudut pandang saya, penolakan transaksi ACID menciptakan kesulitan yang tidak wajar bagi pengembang aplikasi, yang suka atau tidak suka, harus mengimplementasikan sesuatu yang serupa untuk memenuhi kebutuhan alami pelanggan mereka.
Dan sekali lagi saya perhatikan bahwa properti ACID sebenarnya menentukan konsep transaksi. Menurut pendapat saya, untuk memiliki setidaknya beberapa kemungkinan berbicara tentang sistem manajemen data transaksional di mana sifat konsistensi transaksi tidak didukung, mutlak diperlukan untuk mendefinisikan apa yang dimaksud dengan istilah transaksi dalam kasus ini.
Sayangnya, hari ini dalam banyak kasus (khususnya, ini adalah karakteristik dari arah NoSQL), orang berbicara tentang mendukung aplikasi OLTP tanpa menentukan jenis transaksi apa yang mereka maksud. Oleh karena itu, dalam artikel ini, saya akan menggunakan transaksi ACID kombinasi untuk merujuk pada transaksi nyata, dan istilah transaksi yang tidak memenuhi syarat akan digunakan dalam pengertian informal, berbeda dalam konteks yang berbeda.
Sekarang mari kita berurusan dengan "teorema" CAP dan mencoba mencari tahu apa arti konsistensi dalam pengertian Brewer.