3.1 Pag-usbong ng ACID
Ang abbreviation na ACID ay unang lumabas noong 1983 sa isang artikulo nina Theo Haerder at Andreas Reuter. Upang gawing simple ang teksto at gawin itong mas kapani-paniwala, magbibigay ako ng pagsasalin ng isang fragment ng artikulong ito (na may kaunting mga pagbawas). Gumagamit ang snippet na ito ng halimbawa ng transaksyon sa bangko kung saan inililipat ang pera mula sa isang account patungo sa isa pa.
Ang konsepto ng isang transaksyon, na sa halimbawa ay kinabibilangan ng lahat ng mga pakikipag-ugnayan sa database sa pagitan $BEGIN_TRANSACTIONng at $COMMIT_TRANSACTION, ay nangangailangan na ang lahat ng mga aksyon ay isasagawa nang hindi mahahati: alinman sa lahat ng mga aksyon ay maayos na makikita sa estado ng database, o walang mangyayari. Kung sa anumang punto ng oras bago maabot $COMMIT_TRANSACTIONang user ay nagpasok ng isang pahayag ERRORna naglalaman ng $RESTORE_TRANSACTION, walang mga pagbabago na makikita sa database.
Upang makamit ang indivisibility na ito, ang isang transaksyon ay dapat magkaroon ng sumusunod na apat na katangian:
Atomicity (Atomicity). Ang transaksyon ay dapat na nasa all-or-nothing na uri na inilarawan sa itaas, at anuman ang mangyari, dapat malaman ng user kung anong estado ang transaksyon.
Consistency (Consistency). Ang isang transaksyon na umabot sa normal nitong pagtatapos ng transaksyon (EOT) at sa gayon ay nagsasagawa ng mga resulta nito ay nagpapanatili ng pagkakapare-pareho ng database. Sa madaling salita, ang bawat matagumpay na transaksyon, ayon sa kahulugan, ay gumagawa lamang ng mga wastong resulta. Ang kundisyong ito ay kinakailangan upang suportahan ang ikaapat na ari-arian - tibay.
Paghihiwalay (Isolation). Ang mga kaganapang nagaganap sa loob ng isang transaksyon ay dapat na nakatago mula sa iba pang kasabay na pagpapatupad ng mga transaksyon. Kung ang kundisyong ito ay hindi natugunan, kung gayon para sa mga kadahilanang nabanggit sa itaas, ang transaksyon ay magiging imposibleng bumalik sa simula nito. Upang makamit ang paghihiwalay, ang mga pamamaraan na tinatawag na synchronization ay ginagamit ...
Katatagan (Durability). Kapag nakumpleto na ang isang transaksyon at naibigay ang mga resulta nito sa database, dapat tiyakin ng system na ang mga resultang iyon ay makakaligtas sa anumang mga kasunod na pagkabigo. Dahil walang saklaw ng kontrol na sumasaklaw sa mga hanay ng mga transaksyon, ang database management system (DBMS) ay walang kontrol na lampas sa mga hangganan ng mga transaksyon.
Samakatuwid, ang gumagamit ay dapat na garantisadong kung ipaalam sa kanya ng system na may nangyari, kung gayon ang "isang bagay" ay talagang nangyari. Dahil, ayon sa kahulugan, ang anumang (matagumpay na nakumpleto - S.K.) na transaksyon ay tama, ang mga resulta ng hindi maiiwasang paglitaw ng mga maling transaksyon (i.e. mga transaksyong naglalaman ng maling data) ay maaari lamang maalis ng kaukulang "counter" na transaksyon (countertransaction).
3.2 Ang paglitaw ng mga transaksyon
Ang apat na katangiang ito—Atomicity, Consistency, Isolation, and Durability (ACID)—ay naglalarawan sa mga pangunahing tampok ng transactional paradigm na nakakaapekto sa maraming aspeto ng disenyo ng database system. Samakatuwid, naniniwala kami na ang kakayahan ng anumang system na suportahan ang mga transaksyon ay ang touchstone (ACID test) ng kalidad ng system na ito.
Isang simpleng PL/1-SQL program na naglilipat ng mga pondo mula sa isang account patungo sa isa pa.
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 */Nagbigay ako ng halimbawa ng code na ito upang ipaalala sa iyo na, sa katunayan, ang mga katangian ng ACID, sa isang banda, ay maaaring ituring bilang mga kinakailangan para sa anumang DBMS na nagsasabing sumusuporta sa mga transaksyon, at sa kabilang banda, bilang kahulugan ng isang transaksyon sa isang database system . Ang kahulugang ito ay ganap na naaayon sa makamundong gawain. Mahirap isipin, halimbawa, na ang isang customer na nagsasagawa ng isang transaksyon sa pagbabangko (sa tulong man ng isang live na human teller o gumagamit ng Internet banking) ay hindi umaasa na masisiyahan ng bangko ang lahat ng mga katangian ng ACID. Ang isang bangko na hindi sumusuporta sa mga pag-aari ng ACID para sa mga transaksyon nito, sa pinakamabuting kalagayan, ay mawawalan ng mga customer, at sa pinakamasama, mabangkarote.
3.3 Pagkakakonekta sa ACID
Napakahalaga na ang mga katangian ng ACID ay hindi mapaghihiwalay, ang pagtatapon ng alinman sa mga ito ay ginagawang walang kabuluhan ang natitirang kumbinasyon. Sa partikular, kung itatapon namin ang consistency property (sa kahulugan kung saan ito ginamit sa quote sa itaas), mawawala sa amin ang criterion para sa kawastuhan ng isang transaksyon. Ang sistema ng database ay hindi makakapagpasya sa anumang makabuluhang paraan kung ang mga transaksyon ay pinahihintulutan o hindi na gawin, at ang lahat ng mga pagsusuri para sa kawastuhan ng mga operasyon na isinagawa sa kasalukuyang estado ng database ay kailangang isagawa sa application code.
Kailangan mong maunawaan na sa kasong ito pinag-uusapan natin ang lohikal na pagkakapare-pareho. Kailangan ng kliyente ng bangko na magtrabaho ang bangko ayon sa mga patakarang itinatag niya at alam ng mga kliyente, upang imposibleng magsagawa ng anumang transaksyon na lumalabag sa mga patakarang ito, upang ang susunod na transaksyon ng parehong kliyente ay maisakatuparan sa isang kapaligiran na napagkasunduan alinsunod sa mga tuntuning ito.
Ang kliyente ng online na tindahan ay nangangailangan ng mga kalakal na iniutos at binayaran niya upang maihatid sa kanya sa isang napapanahong paraan (alinsunod sa mga patakarang itinatag at alam ng kliyente). Kung hindi, hindi siya magtitiwala sa tindahang ito. Kasabay nito, ang kliyente ng bangko o ang kliyente ng tindahan ng Internet ay hindi nagmamalasakit sa panloob na kusina ng negosyo, kung anong mga panloob na aksyon ang gagawin upang makumpleto ang transaksyon nito. Walang pakialam ang kliyente kung paano pinapanatili ang pisikal na pagkakapare-pareho ng negosyong ito, kung paano isinasagawa ang mga operasyon sa pisikal na antas.
Kung pinangangalagaan ng DBMS ang pagpapanatili ng lohikal na pagkakapare-pareho ng mga transaksyon (at ang database), ang mga application ay magiging mas simple, mas mauunawaan, at mas maaasahan. Ang lahat ng lohika ng lugar ng aplikasyon (bangko, tindahan, bodega, atbp.) tungkol sa mga transaksyon at ang wastong estado ng data ay napupunta sa sistema ng database. At ang mga kinakailangan para sa sistemang ito ay napaka-simple: suporta para sa mga transaksyon sa ACID, na isinasaalang-alang ang mga panuntunan sa pagkakapare-pareho na ibinigay sa database ng application. Mula sa aking pananaw, ang pagtanggi sa mga transaksyon sa ACID ay lumilikha ng hindi katamtamang mga paghihirap para sa mga developer ng application, na, gusto mo man o hindi, ay kailangang magpatupad ng isang katulad na bagay upang matugunan ang mga natural na pangangailangan ng kanilang mga customer.
At muli kong tandaan na ang mga katangian ng ACID, sa katunayan, ay tumutukoy sa konsepto ng isang transaksyon. Sa palagay ko, upang magkaroon ng hindi bababa sa ilang posibilidad na pag-usapan ang tungkol sa isang transactional data management system kung saan ang pag-aari ng pagkakapare-pareho ng transaksyon ay hindi suportado, ito ay ganap na kinakailangan upang tukuyin kung ano ang ibig sabihin ng terminong transaksyon sa kasong ito.
Sa kasamaang palad, ngayon sa maraming mga kaso (sa partikular, ito ay katangian ng direksyon ng NoSQL), ang mga tao ay nagsasalita tungkol sa pagsuporta sa mga aplikasyon ng OLTP nang hindi tinukoy kung anong uri ng mga transaksyon ang ibig nilang sabihin. Samakatuwid, sa artikulong ito, gagamitin ko ang kumbinasyong transaksyon ng ACID upang sumangguni sa mga tunay na transaksyon, at ang hindi kwalipikadong terminong transaksyon ay gagamitin sa isang impormal na kahulugan, naiiba sa iba't ibang konteksto.
Hayaan natin ngayon na harapin ang "teorama" ng CAP at subukang malaman kung ano ang ibig sabihin ng pagkakapare-pareho sa kahulugan ng Brewer.