АҚБТ (Atomicity, Consistency, Isolation, Durability) – дерекқорының транзакцияларының қауіпсіздігін қамтамасыз ететін қасиеттері. Деректердің дұрыстығын сақтау үшін маңызды!
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Деректер базасы транзакцияларының қасиеттері жиынтығы
Set of properties of database transactions
Компьютерлік ғылымда ACID (атомдық, сәйкестік, оқшаулану, беріктік) – қателерге, қуат үзілуіне және басқа да жағдайларға қарамастан деректердің дұрыстығына кепілдік беруге бағытталған деректер базасы транзакцияларының қасиеттері жиынтығы. Деректер базасы контекстінде, ACID қасиеттерін қанағаттандыратын (деректердегі бір логикалық операция ретінде қарастырылатын) деректер базасы операцияларының тізбегі транзакция деп аталады. Мысалы, бір банк шотынан екіншісіне қаражат аудару, тіпті бір шотынан соманы алу және екіншісіне қосу сияқты бірнеше өзгерістерді қамтитын болса да, ол бір транзакция болып саналады. 1983 жылы Андреас Ройтер және Тео Хердер бұрынғы Джим Грейдің транзакция тұжырымын сипаттағанда атомдық, сәйкестік және беріктік аталымдарын қолданған, бірақ оқшаулануды атамаған, соның негізінде ACID аббревиатурасын жасады. Бұл төрт қасиет – деректер базасы жүйелерінің дамуының көптеген саласына әсер еткен транзакция парадигмасының маңызды кепілдіктері болып табылады. Грей мен Ройтердің сөзіне сүйенсек, IBM ақпараттық жүйесі 1973 жылдан бастап ACID транзакцияларын қолдаған (дегенмен, аббревиатура кейін пайда болған).
In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps. In the context of databases, a sequence of database operations that satisfies the ACID properties (which can be perceived as a single logical operation on the data) is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction. In 1983, Andreas Reuter and Theo Härder coined the acronym ACID, building on earlier work by Jim Gray who named atomicity, consistency, and durability, but not isolation, when characterizing the transaction concept. These four properties are the major guarantees of the transaction paradigm, which has influenced many aspects of development in database systems. According to Gray and Reuter, the IBM Information Management System supported ACID transactions as early as 1973 (although the acronym was created later).
Атомдық
Транзакциялар көбінесе бірнеше операциядан тұрады. Атомдық қасиет әрбір транзакцияның бір "бүтін" ретінде қарастырылатынын қамтамасыз етеді, яғни ол толығымен орындалады немесе толығымен орындалмайды: егер транзакция құрамына кіретін операциялардың біреуі аяқталмаса, бүкіл транзакция сәтсіз аяқталады және деректер базасы өзгеріссіз қалады. Атомдық жүйе электр қуатының үзілуі, қателер және жүйелік қателер сияқты кез келген жағдайда атомдық қасиетті сақтауға тиіс. Атомдық қасиеттің болуы деректер базасына жаңартулардың толық емес орындалуына жол бермейді, бұл бүкіл транзакцияны бірден қабылдамаудан да қауіпті проблемаларға әкелуі мүмкін. Соның салдарынан, басқа деректер базасы қолданушысы транзакцияның орындалып жатқанын байқамайды. Бір сәтте ол әлі басталмаған, ал келесі сәтте ол толығымен орындалған (немесе транзакция тоқтатылса, ештеңе орындалмаған).
Transactions are often composed of multiple statements. Atomicity guarantees that each transaction is treated as a single "unit", which either succeeds completely or fails completely: if any of the statements constituting a transaction fails to complete, the entire transaction fails and the database is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors, and crashes. A guarantee of atomicity prevents updates to the database from occurring only partially, which can cause greater problems than rejecting the whole series outright. As a consequence, the transaction cannot be observed to be in progress by another database client. At one moment in time, it has not yet happened, and at the next, it has already occurred in whole (or nothing happened if the transaction was canceled in progress).
Бірқалыптылық
Тұрақтылық транзакцияның дерекқорды бір тұрақты күйден екінші тұрақты күйге ғана көшіретінін және дерекқор инварианттарын сақтайтынын қамтамасыз етеді: дерекқорға жазылған кез келген дерек, шектеулер, каскадтар, триггерлер және олардың кез келген комбинациясын қоса алғанда, барлық анықталған ережелерге сәйкес жарамды болуы керек. Бұл заңсыз транзакция нәтижесінде дерекқордың бұзылуына жол бермейді. Сілтемелік тұтастық негізгі кілт пен сыртқы кілт арасындағы қатынасты қамтамасыз етеді.
Consistency ensures that a transaction can only bring the database from one consistent state to another, preserving database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction. Referential integrity guarantees the primary key–foreign key relationship.
Оқшаулау
Транзакциялар көбінесе бір мезгілде орындалады (мысалы, бірнеше транзакция бір уақытта кестеден деректерді оқып немесе жазып жатуы мүмкін). Оқшаулау, транзакциялардың бір мезгілде орындалуы деректер базасын транзакциялар тізбектей орындалғандағыдай бірдей күйде қалдыруын қамтамасыз етеді. Оқшаулау – бір мезгілде орындауды басқарудың басты мақсаты; қолданылған оқшаулау деңгейіне байланысты, аяқталмаған транзакцияның әсері басқа транзакцияларға көрінбей қалуы мүмкін.
Transactions are often executed concurrently (e. g., multiple transactions reading and writing to a table at the same time). Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially. Isolation is the main goal of concurrency control; depending on the isolation level used, the effects of an incomplete transaction might not be visible to other transactions.
Ұзаққа созылмалылық
Тұрақтылық – транзакция орындалғаннан кейін, жүйе іркілген жағдайда да (мысалы, қуат өшірілуі немесе құлау) оның орындалғандығы сақталады деген кепілдік береді. Әдетте, орындалған транзакциялардың (немесе олардың нәтижелерінің) мәліметтері ұдайы сақталынатын жадқа жазылады.
Durability guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure (e. g., power outage or crash). This usually means that completed transactions (or their effects) are recorded in non volatile memory.
Мысалдар
Келесі мысалдар АСИД қасиеттерін одан әрі түсіндіреді. Бұл мысалдарда деректер базасының кестесінде екі баған бар: А және В. Тұтастық шектеуі А және В бағандарындағы мәндердің қосындысы 100-ге тең болуын талап етеді. Төмендегі SQL коды жоғарыда сипатталған кестені құрайды: CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));
The following examples further illustrate the ACID properties. In these examples, the database table has two columns, A and B. An integrity constraint requires that the value in A and the value in B must sum to 100. The following SQL code creates a table as described above:CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));
Атомдық
Атомдық – атомдық транзакциядағы деректер базасы операцияларының тізбегінің толығымен орындалуына (сәтті операция) немесе мүлдем орындалмауына (сәтсіз операция) кепілдік береді. Операциялар тізбегін бөліп-жару мүмкін емес, олардың бір бөлігі ғана орындалады, бұл тізбекті "бөлінбес" етеді. Атомдық кепілдік деректер базасын жаңартудың толық емес орындалуына жол бермейді, бұл бүкіл тізбекті бірден қабылдамаудан да қауіптірек болуы мүмкін. Басқаша айтқанда, атомдық – бұл бөлінбеушілік және толықтығын жоғалту мүмкін еместігі. Сондай-ақ, логикалық транзакция бірнеше физикалық транзакциядан тұруы мүмкін. Барлық құрамдас физикалық транзакциялар орындалғанша, логикалық транзакция орындалмайды. Атомдық транзакцияға мысал – А банктік шотынан В банктік шотына ақша аудару. Ол екі операциядан тұрады: А шотынан ақшаны алу және В шотына салу. Ақша А шотынан алынғанын, оның В шотына аударылғанына көз жеткізбейінше біз көруге ішін тырыспаймыз. Осы операцияларды атомдық транзакция ретінде орындау деректер базасының дұрыс күйде қалуын қамтамасыз етеді, яғни егер осы екі операцияның бірі сәтсіз аяқтаса, ақша дебеттелмейді немесе кредиттелмейді.
Atomicity is the guarantee that series of database operations in an atomic transaction will either all occur (a successful operation), or none will occur (an unsuccessful operation). The series of operations cannot be separated with only some of them being executed, which makes the series of operations "indivisible". A guarantee of atomicity prevents updates to the database from occurring only partially, which can cause greater problems than rejecting the whole series outright. In other words, atomicity means indivisibility and irreducibility. Alternatively, we may say that a logical transaction may be composed of several physical transactions. Unless and until all component physical transactions are executed, the logical transaction will not have occurred. An example of an atomic transaction is a monetary transfer from bank account A to account B. It consists of two operations, withdrawing the money from account A and depositing it to account B. We would not want to see the amount removed from account A before we are sure it has also been transferred into account B. Performing these operations in an atomic transaction ensures that the database remains in a consistent state, that is, money is neither debited nor credited if either of those two operations fails.
Біркелкілік жетіспеушілігі
Тұтастылық – өте жалпы термин, ол деректердің барлық тексеру ережелеріне сәйкес келуін қажет етеді. Алдыңғы мысалда, тексеру – барлық тексеру ережелерін тұтастықты қамтамасыз ету үшін тексеру талабы. Егер транзакция өзгеріссіз 10-ды алып тастауға тырысса, онда ол бастапқы күйінде қалады. Егер транзакция 10-ды сәтті алып тастаса, атомдыққа қол жеткізіледі. Дегенмен, тексеру нәтижесі көрсетер, бұл дерекқорының ережелеріне қайшы келеді. Соның салдарынан, транзакция толығымен жойылмалы және әсер еткен қатарлар транзакциядан бұрынғы күйіне қайтарылмалы. Егер басқа шектеулер, триггерлер немесе каскадтар болғанда, әрбір өзгерту операциясы транзакция бекітілмес бұрын жоғарыда аталғандай тексерілер еді. Басқа шектеулермен де ұқсас мәселелер туындауы мүмкін. Мысалы, екі мәннің де дерек типі бүтін сан болуы керек. Егер біз мәні ретінде 13,5 енгізсек, транзакция жойылған болар еді немесе жүйе триггер арқылы ескерту берер еді (егер триггер осы мақсатта жазылған болса). Тағы бір мысал – тұтастық шектеулері, олар бізге басқа кестелерде кем дегенде бір сыртқы кілтпен сілтеме берілген қатарды өшіруге рұқсат етпейді.
Consistency is a very general term, which demands that the data must meet all validation rules. In the previous example, the validation is a requirement that All validation rules must be checked to ensure consistency. Assume that a transaction attempts to subtract 10 from without altering Because consistency is checked after each transaction, it is known that before the transaction begins. If the transaction removes 10 from successfully, atomicity will be achieved. However, a validation check will show that , which is inconsistent with the rules of the database. The entire transaction must be canceled and the affected rows rolled back to their pre transaction state. If there had been other constraints, triggers, or cascades, every single change operation would have been checked in the same way as above before the transaction was committed. Similar issues may arise with other constraints. We may have required the data types of both and to be integers. If we were then to enter, say, the value 13.5 for , the transaction will be canceled, or the system may give rise to an alert in the form of a trigger (if/when the trigger has been written to this effect). Another example would be integrity constraints, which would not allow us to delete a row in one table whose primary key is referred to by at least one foreign key in other tables.
Ұзаққа созылу қабілеті бұзылуы
А-дан В-ға 10 бірлікті аударатын мәмілені қарастырайық. Біріншіден, ол А-дан 10 бірлікті алып тастайды, содан кейін В-ға 10 бірлікті қосады. Осы сәтте пайдаланушыға транзакция сәтті аяқталды деп хабар беріледі. Алайда, өзгерістер әлі де диск буферінде кезекте тұрып, дискке жазылуын күтуде. Электр қуаты үзіліп, өзгерістер жоғалып кетеді, бірақ пайдаланушы өзгерістердің сақталғанын (әрине) ойлайды.
Consider a transaction that transfers 10 from A to B. First, it removes 10 from A, then it adds 10 to B. At this point, the user is told the transaction was a success. However, the changes are still queued in the disk buffer waiting to be committed to disk. Power fails and the changes are lost, but the user assumes (understandably) that the changes persist.
Іске асыру
Транзакцияны өңдеу көбінесе түрлі себептерге байланысты қателікке ұшырауы мүмкін операциялар тізбегін қажет етеді. Мысалы, жүйеде дискіде орын қалмауы немесе берілген CPU уақыты таусылған болуы мүмкін. Осы мәселені шешу үшін екі танымал әдіс бар: алдын ала жазу (write ahead logging) және көлеңкелік беттеу (shadow paging). Екі жағдайда да жаңартылатын барлық ақпаратқа құлып қою қажет, ал оқшаулану деңгейіне байланысты, оқылмалы барлық деректерге де құлып қою қажет болуы мүмкін. Алдын ала жазу әдісінде, деректер қорын өзгертпес бұрын болашақ өзгеріс тұрақты журналға жазылып, деректердің сақталуы қамтамасыз етіледі. Бұл деректер қорының құлау жағдайында тұрақты күйіне оралуына мүмкіндік береді. Көлеңкелік беттеуде жаңартулар деректер қорының толық емес көшірмесіне қолданылады, ал транзакция аяқталғанда жаңа көшірме белсендіріледі.
Processing a transaction often requires a sequence of operations that is subject to failure for a number of reasons. For instance, the system may have no room left on its disk drives, or it may have used up its allocated CPU time. There are two popular families of techniques: write ahead logging and shadow paging. In both cases, locks must be acquired on all information to be updated, and depending on the level of isolation, possibly on all data that may be read as well. In write ahead logging, durability is guaranteed by writing the prospective change to a persistent log before changing the database. That allows the database to return to a consistent state in the event of a crash. In shadowing, updates are applied to a partial copy of the database, and the new copy is activated when the transaction commits.
Қалпына келтіру мен бірнеше нұсқаны жасау
Көптеген деректер қоры ACID мүмкіндіктерін қамтамасыз ету үшін құлыптауға сүйенеді. Құлыптау дегеніміз, транзакция қол жеткізетін деректерді белгілейді, соның арқасында ДБЖС (Деректерді басқару жүйесі) бірінші транзакция сәтті аяқталғанға дейін немесе сәтсіздікке ұшырағанға дейін басқа транзакцияларға оларды өзгертуге рұқсат бермейтінін біледі. Құлыпты деректерді өңдеу алдында міндетті түрде алу керек, оның ішінде тек оқылатын, бірақ өзгертілмейтін деректерді де. Тривиальды емес транзакциялар көбінесе көптеген құлыптарды қажет етеді, бұл айтарлықтай қосымша шығындарға және басқа транзакцияларды тоқтатуға әкеледі. Мысалы, егер A пайдаланушысы B пайдаланушы өзгертуге тырысатын деректердің қатарын оқуға тиіс транзакцияны іске қосса, B пайдаланушысы A пайдаланушысының транзакциясы аяқталғанша күтуі керек. Толық оқшаулануды қамтамасыз ету үшін екі кезеңді құлыптау жиі қолданылады. Құлыптауға балама – көп нұсқалы бір мезгілде басқару, онда деректер қоры әрбір оқу транзакциясына басқа белсенді транзакциямен өзгертілген деректердің бұрынғы, өзгертілмеген нұсқасын ұсынады. Бұл оқырмандарға құлыптарды пайдаланбастан жұмыс істеуге мүмкіндік береді, яғни жазу транзакциялары оқу транзакцияларын тоқтатпайды, ал оқырмандар жазушыларды тоқтатпайды. Мысалға қайта оралайық, егер A пайдаланушысының транзакциясы B пайдаланушы өзгертетін деректерді сұраса, деректер қоры A пайдаланушысына B пайдаланушы транзакцияны бастаған кезде болған деректердің нұсқасын ұсынады. A пайдаланушысы деректер қорының тұрақты көрінісін алады, тіпті басқа пайдаланушылар деректерді өзгертіп жатқанда да. Бір іске асыру, атап айтқанда, деректерді көшіру (snapshot isolation), оқшаулану қасиетін жеңілдетеді.
Many databases rely upon locking to provide ACID capabilities. Locking means that the transaction marks the data that it accesses so that the DBMS knows not to allow other transactions to modify it until the first transaction succeeds or fails. The lock must always be acquired before processing data, including data that is read but not modified. Non trivial transactions typically require a large number of locks, resulting in substantial overhead as well as blocking other transactions. For example, if user A is running a transaction that has to read a row of data that user B wants to modify, user B must wait until user A's transaction completes. Two phase locking is often applied to guarantee full isolation. An alternative to locking is multiversion concurrency control, in which the database provides each reading transaction the prior, unmodified version of data that is being modified by another active transaction. This allows readers to operate without acquiring locks, i. e., writing transactions do not block reading transactions, and readers do not block writers. Going back to the example, when user A's transaction requests data that user B is modifying, the database provides A with the version of that data that existed when user B started his transaction. User A gets a consistent view of the database even if other users are changing data. One implementation, namely snapshot isolation, relaxes the isolation property.
Бөлінген операциялар
Асылы таратылған деректер базасындағы таратылған транзакцияда ACID қасиеттерін қамтамасыз ету, егер транзакцияға әсер ететін барлық деректерге бір ғана түйін жауапты болмаса, қосымша қиындықтар тудырады. Желілік байланыстар үзілуі мүмкін, немесе бір түйін транзакцияның өзінің бөлігін сәтті орындап бітіргеннен кейін, басқа түйіндегі қателік салдарынан өзгерістерін кері қайтаруға мәжбүр болуы мүмкін. Екі кезеңді келісім протоколы (екі кезеңді құлыптаумен шатастырмаңыз) таратылған транзакциялар үшін атомдық тұрақтылықты қамтамасыз етеді, транзакцияға қатысушылардың әрқайсысы транзакцияны қабылдау немесе қабылдамау туралы келісуін қамтамасыз ету үшін. Қысқасы, бірінші кезеңде бір түйін (координатор) басқа түйіндерден (қатысушылардан) сауал алады, және барлығы дайын екенін растағаннан кейін ғана координатор екінші кезеңде транзакцияны ресмилендіреді.
Guaranteeing ACID properties in a distributed transaction across a distributed database, where no single node is responsible for all data affecting a transaction, presents additional complications. Network connections might fail, or one node might successfully complete its part of the transaction and then be required to roll back its changes because of a failure on another node. The two phase commit protocol (not to be confused with two phase locking) provides atomicity for distributed transactions to ensure that each participant in the transaction agrees on whether the transaction should be committed or not. Briefly, in the first phase, one node (the coordinator) interrogates the other nodes (the participants), and only when all reply that they are prepared does the coordinator, in the second phase, formalize the transaction.