konsep ASID

3.1 Kemunculan ASID

Singkatan ACID pertama kali muncul pada tahun 1983 dalam artikel oleh Theo Haerder dan Andreas Reuter. Untuk memudahkan teks dan menjadikannya lebih meyakinkan, saya akan memberikan terjemahan serpihan artikel ini (dengan sedikit pengurangan). Coretan ini menggunakan contoh transaksi bank di mana wang dipindahkan dari satu akaun ke akaun yang lain.

Konsep transaksi, yang dalam contoh termasuk semua interaksi dengan pangkalan data antara $BEGIN_TRANSACTIONdan $COMMIT_TRANSACTION, memerlukan semua tindakan dilakukan secara tidak boleh dibahagikan: sama ada semua tindakan ditunjukkan dengan betul dalam keadaan pangkalan data, atau tiada apa-apa yang berlaku. Jika pada bila-bila masa sebelum mencapai $COMMIT_TRANSACTIONpengguna memasukkan pernyataan ERRORyang mengandungi $RESTORE_TRANSACTION, maka tiada perubahan ditunjukkan dalam pangkalan data.

Untuk mencapai ketakbolehbahagiaan ini, transaksi mesti mempunyai empat sifat berikut:

Atomicity (Atomicity). Urus niaga mestilah daripada jenis semua-atau-tiada yang diterangkan di atas, dan tidak kira apa yang berlaku, pengguna mesti mengetahui keadaan transaksi tersebut.

Konsistensi (Consistency). Transaksi yang mencapai penghujung urus niaga biasa (EOT) dan dengan itu melakukan keputusannya mengekalkan konsistensi pangkalan data. Dalam erti kata lain, setiap transaksi yang berjaya, mengikut definisi, hanya melakukan keputusan yang sah. Keadaan ini adalah perlu untuk menyokong harta keempat - ketahanan.

Pengasingan (Isolation). Peristiwa yang berlaku dalam transaksi mesti disembunyikan daripada transaksi lain yang melaksanakan secara serentak. Sekiranya syarat ini tidak dipenuhi, maka atas sebab-sebab yang disebutkan di atas, transaksi itu mustahil untuk kembali ke permulaannya. Untuk mencapai pengasingan, kaedah yang dipanggil penyegerakan digunakan ...

Ketahanan (Durability). Sebaik sahaja urus niaga telah selesai dan menyerahkan keputusannya kepada pangkalan data, sistem mesti memastikan bahawa keputusan tersebut bertahan daripada sebarang kegagalan berikutnya. Memandangkan tiada skop kawalan yang merangkumi set transaksi, sistem pengurusan pangkalan data (DBMS) tidak mempunyai kawalan di luar sempadan transaksi.

Oleh itu, pengguna mesti dijamin bahawa jika sistem memaklumkan kepadanya bahawa sesuatu telah berlaku, maka "sesuatu" ini benar-benar berlaku. Memandangkan, mengikut takrifan, mana-mana transaksi (berjaya diselesaikan - S.K.) adalah betul, keputusan transaksi yang tidak dapat dielakkan muncul (iaitu transaksi yang mengandungi data yang salah) hanya boleh dihapuskan oleh transaksi "kaunter" yang sepadan (urus niaga balas).

3.2 Kemunculan urus niaga

Empat sifat ini—Atomicity, Consistency, Isolation, and Durability (ACID)—menghuraikan ciri teras paradigma transaksi yang mempengaruhi banyak aspek reka bentuk sistem pangkalan data. Oleh itu, kami percaya bahawa keupayaan mana-mana sistem untuk menyokong transaksi adalah batu ujian (ujian ACID) kualiti sistem ini.

Program PL/1-SQL mudah yang memindahkan dana dari satu akaun ke akaun yang lain.

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 kod ini untuk mengingatkan anda bahawa, sebenarnya, sifat ACID, dalam satu pihak, boleh dianggap sebagai keperluan untuk mana-mana DBMS yang mendakwa menyokong transaksi, dan sebaliknya, sebagai definisi transaksi dalam sebuah sistem pangkalan data . Takrifan ini selaras sepenuhnya dengan amalan duniawi. Sukar untuk membayangkan, sebagai contoh, bahawa pelanggan yang melakukan transaksi perbankan (sama ada dengan bantuan juruwang langsung atau menggunakan perbankan Internet) tidak mengharapkan bank untuk memenuhi semua sifat ACID. Bank yang tidak menyokong hartanah ACID untuk urus niaganya akan, paling baik, kehilangan pelanggan, dan paling teruk, muflis.

3.3 Ketersambungan ASID

Adalah sangat penting bahawa sifat ACID tidak dapat dipisahkan, membuang mana-mana daripadanya menjadikan gabungan yang tinggal tidak bermakna. Khususnya, jika kita membuang sifat konsisten (dalam erti kata ia digunakan dalam petikan di atas), maka kita akan kehilangan kriteria untuk ketepatan transaksi. Sistem pangkalan data tidak akan dapat memutuskan dalam apa-apa cara yang bermakna sama ada transaksi dibenarkan atau tidak dilakukan, dan semua pemeriksaan untuk ketepatan operasi yang dilakukan dalam keadaan semasa pangkalan data perlu dilakukan dalam kod aplikasi.

Anda perlu memahami bahawa dalam kes ini kita bercakap tentang konsistensi logik. Pelanggan bank memerlukan bank untuk bekerja mengikut peraturan yang ditetapkan olehnya dan diketahui oleh pelanggan, sehingga mustahil untuk melakukan sebarang transaksi yang melanggar peraturan ini, supaya transaksi seterusnya pelanggan yang sama dilaksanakan dalam persekitaran yang dipersetujui mengikut peraturan ini.

Pelanggan kedai dalam talian memerlukan barang yang dipesan dan dibayar olehnya untuk dihantar kepadanya tepat pada masanya (mengikut peraturan yang ditetapkan dan diketahui oleh pelanggan). Jika tidak, dia tidak akan mempercayai kedai ini. Pada masa yang sama, baik pelanggan bank mahupun pelanggan kedai Internet tidak mengambil berat tentang dapur dalaman perusahaan, apakah tindakan dalaman yang diambil untuk menyelesaikan transaksinya. Pelanggan tidak peduli bagaimana konsistensi fizikal perusahaan ini dikekalkan, bagaimana operasi dilakukan pada lapisan fizikal.

Jika DBMS menjaga konsistensi logik transaksi (dan pangkalan data), maka aplikasi menjadi lebih mudah, lebih mudah difahami dan lebih dipercayai. Semua logik kawasan aplikasi (bank, kedai, gudang, dll.) mengenai transaksi dan keadaan data yang sah masuk ke dalam sistem pangkalan data. Dan keperluan untuk sistem ini sangat mudah: sokongan untuk transaksi ACID, dengan mengambil kira peraturan konsistensi yang disediakan dalam pangkalan data oleh aplikasi. Dari sudut pandangan saya, penolakan urus niaga ACID mewujudkan kesukaran yang tidak sederhana untuk pembangun aplikasi, yang, sama ada anda suka atau tidak, perlu melaksanakan sesuatu yang serupa dengan mereka sendiri untuk memenuhi keperluan semula jadi pelanggan mereka.

Dan sekali lagi saya perhatikan bahawa sifat ACID, sebenarnya, mentakrifkan konsep transaksi. Pada pendapat saya, untuk mempunyai sekurang-kurangnya beberapa kemungkinan bercakap tentang sistem pengurusan data transaksi di mana sifat konsistensi transaksi tidak disokong, adalah perlu untuk menentukan apa yang dimaksudkan dengan istilah transaksi dalam kes ini.

Malangnya, hari ini dalam banyak kes (khususnya, ini adalah ciri arah NoSQL), orang ramai bercakap tentang menyokong aplikasi OLTP tanpa menyatakan sama sekali jenis transaksi yang mereka maksudkan. Oleh itu, dalam artikel ini, saya akan menggunakan gabungan urus niaga ACID untuk merujuk kepada urus niaga sebenar, dan urus niaga istilah tidak layak akan digunakan dalam erti kata tidak formal, berbeza dalam konteks yang berbeza.

Sekarang mari kita berurusan dengan "teorem" CAP dan cuba memikirkan maksud konsistensi dalam pengertian Brewer.