Konsep ACID

3.1 Munculé ASAM

Singkatan ACID pisanan muncul ing taun 1983 ing artikel dening Theo Haerder lan Andreas Reuter. Kanggo nyederhanakake teks lan nggawe luwih ngyakinake, aku bakal menehi terjemahan saka pecahan artikel iki (kanthi nyuda sithik). Cuplikan iki nggunakake conto transaksi bank sing dhuwit ditransfer saka akun siji menyang akun liyane.

Konsep transaksi, kang ing conto kalebu kabeh interaksi karo database antarane $BEGIN_TRANSACTIONlan $COMMIT_TRANSACTION, mbutuhake kabeh tumindak dileksanakake indivisibly: salah siji kabeh tumindak sing bener dibayangke ing negara database, utawa boten kedaden. Yen ing sembarang wektu sadurunge tekan $COMMIT_TRANSACTIONpangguna ngetik statement ERRORngemot $RESTORE_TRANSACTION, banjur ora owah-owahan sing dibayangke ing database.

Kanggo entuk indivisibility iki, transaksi kudu nduweni papat sifat ing ngisor iki:

Atomicity (Atomicity). Transaksi kasebut kudu saka jinis kabeh-utawa-ora ana sing diterangake ing ndhuwur, lan ora ketompo apa wae, pangguna kudu ngerti apa negara transaksi kasebut.

Konsistensi (konsistensi). Transaksi sing tekan pungkasan transaksi normal (EOT) lan kanthi mangkono nindakake asile njaga konsistensi database. Ing tembung liya, saben transaksi sing sukses, miturut definisi, mung ngasilake asil sing bener. Kondisi iki perlu kanggo ndhukung properti kaping papat - daya tahan.

Isolasi (Isolasi). Acara sing kedadeyan ing transaksi kudu didhelikake saka transaksi eksekusi liyane sing bebarengan. Yen kondisi iki ora ketemu, banjur kanggo alasan sing kasebut ing ndhuwur, transaksi ora bisa bali menyang wiwitan. Kanggo entuk isolasi, metode sing diarani sinkronisasi digunakake ...

Daya Tahan (Durability). Sawise transaksi wis rampung lan menehi asil menyang database, sistem kudu mesthekake yen asil bisa slamet saka kegagalan sakteruse. Amarga ora ana ruang lingkup kontrol sing ngluwihi set transaksi, sistem manajemen basis data (DBMS) ora duwe kontrol ngluwihi wates transaksi.

Mulane, pangguna kudu dijamin yen sistem ngandhani yen ana kedadeyan, mula "sesuatu" iki wis kedadeyan. Wiwit, miturut definisi, transaksi apa wae (kasil rampung - S.K.) bener, asil transaksi sing ora bener (yaiku transaksi sing ngemot data sing salah) mung bisa diilangi dening transaksi "counter" sing cocog (countertransaction).

3.2 Munculé transaksi

Papat sifat iki-Atomicity, Consistency, Isolation, and Durability (ACID) - nggambarake fitur inti paradigma transaksional sing mengaruhi akeh aspek desain sistem database. Mulane, kita yakin manawa kemampuan sistem apa wae kanggo ndhukung transaksi minangka touchstone (test ACID) kualitas sistem iki.

Program PL/1-SQL prasaja sing nransfer dana saka akun siji menyang akun liyane.

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 */

Aku nyedhiyakake conto kode iki kanggo ngelingake yen, nyatane, sifat ACID, ing tangan siji, bisa dianggep minangka syarat kanggo DBMS sing ngaku ndhukung transaksi, lan ing sisih liya, minangka definisi transaksi ing sistem database . Dhéfinisi iki cocog karo praktik kadonyan. Iku angel mbayangno, contone, yen pelanggan sing nindakake transaksi perbankan (apa karo bantuan saka teller manungsa urip utawa nggunakake Internet banking) ora nyana bank kanggo gawe marem kabeh sifat ACID. Bank sing ora ndhukung properti ACID kanggo transaksi, paling apik, bakal kelangan pelanggan, lan paling awon, bangkrut.

3.3 Konektivitas ASAM

Penting banget yen sifat-sifat ACID ora bisa dipisahake, ngilangake samubarang kabeh ndadekake kombinasi sing isih ana ora ana gunane. Utamane, yen kita mbuwang properti konsistensi (ing pangertèn sing digunakake ing kutipan ndhuwur), kita bakal kelangan kritéria kanggo bener saka transaksi. Sistem basis data ora bakal bisa mutusake kanthi cara apa wae apa transaksi diijini utawa ora ditindakake, lan kabeh mriksa kanggo bener operasi sing ditindakake ing basis data saiki kudu ditindakake ing kode aplikasi.

Sampeyan kudu ngerti yen ing kasus iki kita ngomong babagan konsistensi logis. Klien bank mbutuhake bank supaya bisa kerja miturut aturan sing diadegake lan dingerteni para klien, saengga ora bisa nindakake transaksi sing nglanggar aturan kasebut, supaya transaksi sabanjure klien sing padha ditindakake ing sawijining lingkungan sarujuk miturut aturan kasebut.

Klien toko online mbutuhake barang sing dipesen lan dibayar dening dheweke supaya dikirim menyang dheweke kanthi pas wektune (sesuai karo aturan sing ditetepake lan dikenal kanggo klien). Yen ora, dheweke ora bakal ngandel ing toko iki. Ing wektu sing padha, ora ana klien bank utawa klien toko Internet ora peduli karo pawon internal perusahaan, apa tindakan internal sing ditindakake kanggo ngrampungake transaksi kasebut. Klien ora peduli kepiye konsistensi fisik perusahaan iki dijaga, kepiye operasi ditindakake ing tingkat fisik.

Yen DBMS njaga konsistensi logis transaksi (lan database), banjur aplikasi dadi luwih prasaja, bisa dingerteni, lan luwih dipercaya. Kabeh logika wilayah aplikasi (bank, toko, gudang, lan liya-liyane) babagan transaksi lan status data sing sah menyang sistem database. Lan syarat kanggo sistem iki gampang banget: dhukungan kanggo transaksi ACID, njupuk aturan konsistensi sing diwenehake ing database dening aplikasi kasebut. Saka sudut pandangku, penolakan transaksi ACID nggawe kesulitan sing ora wajar kanggo pangembang aplikasi, sing, seneng utawa ora, kudu ngetrapake sing padha supaya bisa nyukupi kabutuhan alami para pelanggan.

Lan sepisan maneh aku nyathet yen sifat ACID, nyatane, nemtokake konsep transaksi. Ing mratelakake panemume, supaya duwe paling sawetara kamungkinan kanggo ngomong bab sistem manajemen data transactional kang properti saka konsistensi transaksi ora didhukung, iku pancene perlu kanggo nemtokake apa temenan dening istilah transaksi ing kasus iki.

Sayange, saiki ing akeh kasus (utamane, iki minangka karakteristik saka arah NoSQL), wong ngomong babagan ndhukung aplikasi OLTP tanpa nemtokake apa jenis transaksi sing dimaksud. Mulane, ing artikel iki, aku bakal nggunakake kombinasi transaksi ACID kanggo deleng transaksi nyata, lan transaksi istilah unqualified bakal digunakake ing pangertèn informal, beda ing konteks beda.

Ayo kita saiki menehi hasil karo "teorema" CAP lan nyoba kanggo mangerteni apa tegese konsistensi ing pangertèn Brewer.