Концепция ACID

3.1 Поява на КИСЕЛИНА

Съкращението ACID се появява за първи път през 1983 г. в статия на Theo Haerder и Andreas Reuter. За да опростя текста и да го направя по-убедителен, ще дам превод на фрагмент от тази статия (с леки съкращения). Този фрагмент използва пример за банкова транзакция, при която пари се прехвърлят от една сметка в друга.

Концепцията за транзакция, която в примера включва всички взаимодействия с базата данни между $BEGIN_TRANSACTIONи $COMMIT_TRANSACTION, изисква всички действия да се извършват неделимо: or всички действия са правилно отразени в състоянието на базата данни, or нищо не се случва. Ако в който и да е момент преди достигане $COMMIT_TRANSACTIONпотребителят въведе изявление, ERRORсъдържащо $RESTORE_TRANSACTION, тогава в базата данни не се отразяват промени.

За да се постигне тази неделимост, транзакцията трябва да има следните четири свойства:

Атомност (Атомност). Транзакцията трябва да бъде от типа "всичко or нищо", описан по-горе, и без meaning Howво се случва, потребителят трябва да знае в Howво състояние е транзакцията.

Съгласуваност (Постоянство). Транзакция, която достига своя нормален край на транзакцията (EOT) и по този начин ангажира своите резултати, поддържа последователност на базата данни. С други думи, всяка успешна транзакция, по дефиниция, ангажира само валидни резултати. Това condition е необходимо за поддържане на четвъртото свойство - издръжливост.

Изолация (изолация). Събитията, които се случват в рамките на транзакция, трябва да бъдат скрити от други едновременно изпълняващи се транзакции. Ако това condition не беше изпълнено, тогава поради посочените по-горе причини транзакцията би била невъзможна за връщане в началото. За постигане на изолация се използват методи, наречени синхронизация ...

Устойчивост (Издръжливост). След като дадена транзакция приключи и изпрати своите резултати в базата данни, системата трябва да гарантира, че тези резултати оцеляват при всяHowви последващи грешки. Тъй като няма обхват на контрол, който да обхваща набори от транзакции, системата за управление на база данни (СУБД) няма контрол извън границите на транзакциите.

Следователно потребителят трябва да бъде гарантиран, че ако системата го информира, че нещо се е случило, значи това „нещо“ наистина се е случило. Тъй като по дефиниция всяка (успешно завършена - S.K.) транзакция е правилна, резултатите от неизбежно появяващи се неправилни транзакции (т.е. транзакции, съдържащи грешни данни) могат да бъдат елиминирани само чрез съответната "насрещна" транзакция (насрещна транзакция).

3.2 Възникване на сделки

Тези четири свойства – атомарност, съгласуваност, изолация и устойчивост (ACID) – описват основните характеристики на транзакционната парадигма, които засягат много аспекти на дизайна на системата от бази данни. Ето защо ние вярваме, че способността на всяка система да поддържа транзакции е тестът (ACID тест) за качеството на тази система.

Проста PL/1-SQL програма, която прехвърля средства от една сметка в друга.

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

Предоставих пример за този code, за да ви напомня, че всъщност свойствата на ACID, от една страна, могат да се разглеждат като изисквания за всяка СУБД, която твърди, че поддържа транзакции, а от друга страна, като дефиниция на транзакция в система от бази данни . Това определение е напълно в съответствие със световната практика. Трудно е да си представим, например, че клиент, извършващ банкова транзакция (независимо дали с помощта на жив касиер or чрез интернет банкиране), не очаква банката да удовлетвори всички характеристики на ACID. Банка, която не поддържа свойствата на ACID за своите транзакции, в най-добрия случай ще загуби клиенти, а в най-лошия - ще фалира.

3.3 ACID свързаност

Много е важно, че ACID свойствата са неразделни, отхвърлянето на което и да е от тях обезсмисля останалата комбинация. По-специално, ако отхвърлим свойството съгласуваност (в смисъла, в който е използвано в горния цитат), тогава ще загубим критерия за коректност на транзакцията. Системата от бази данни няма да може да реши по Howъвто и да било смислен начин дали транзакциите са разрешени or не да бъдат ангажирани и всички проверки за коректността на извършените операции в текущото състояние на базата данни ще трябва да се извършват в codeа на приложението.

Трябва да разберете, че в този случай говорим за логическа последователност. Клиентът на банката има нужда банката да работи по правилата, установени от него и известни на клиентите, така че да е невъзможно извършването на транзакция, която нарушава тези правила, така че следващата транзакция на същия клиент да бъде изпълнена в среда, договорена в съответствие с тези правила.

Клиентът на онлайн магазина има нужда заявената и заплатена от него стока да му бъде доставена своевременно (съгласно установените и известни на клиента правила). В противен случай той няма да се довери на този магазин. В същото време нито клиентът на банката, нито клиентът на интернет магазина не се интересуват от вътрешната кухня на предприятието, Howви вътрешни действия се предприемат за извършване на неговата сделка. Клиентът не се интересува How се поддържа физическата консистенция на това предприятие, How се извършват операциите на физическо ниво.

Ако СУБД се грижи за поддържането на логическата последователност на транзакциите (и базата данни), тогава applicationsта стават по-прости, по-разбираеми и по-надеждни. Цялата логика на областта на приложението (банка, магазин, склад и т.н.) по отношение на транзакциите и валидното състояние на данните отива в системата от бази данни. А изискванията за тази система са много прости: поддръжка на ACID транзакции, като се вземат предвид правилата за последователност, предоставени в базата данни от приложението. От моя гледна точка отхвърлянето на ACID транзакциите създава неумерени трудности за разработчиците на applications, които, независимо дали ви харесва or не, ще трябва сами да внедрят нещо подобно, за да задоволят естествените нужди на своите клиенти.

И още веднъж отбелязвам, че ACID свойствата всъщност дефинират концепцията за транзакция. Според мен, за да имаме поне няHowва възможност да говорим за система за управление на транзакционни данни, в която не се поддържа свойството на последователност на транзакцията, е абсолютно необходимо да се дефинира Howво се разбира под термина транзакция в този случай.

За съжаление днес в много случаи (по-специално това е характерно за посоката на NoSQL) хората говорят за поддръжка на OLTP applications, без изобщо да уточняват Howъв вид транзакции имат предвид. Ето защо в тази статия ще използвам комбинацията ACID транзакция, за да се позова на реални транзакции, а неквалифицираният термин транзакция ще се използва в неофициален смисъл, различен в различни контексти.

Нека сега се заемем с "теоремата" за CAP и се опитаме да разберем Howво означава последователност в смисъла на Брюър.