ACID berbanding BASE Data Stores - dummies

Salah satu ciri sistem pangkalan data relasional adalah sesuatu yang dikenali sebagai pematuhan ACID . Seperti yang anda dapati, ACID adalah akronim - huruf individu, yang dimaksudkan untuk menggambarkan ciri-ciri transaksi pangkalan data individu, boleh diperluas seperti yang dijelaskan dalam senarai ini: Atomicity:

Transaksi pangkalan data mesti sepenuhnya berjaya atau gagal sepenuhnya. Kejayaan separa tidak dibenarkan.

Konsistensi:
Semasa urus niaga pangkalan data, RDBMS berlangsung dari satu keadaan yang sah ke yang lain. Negeri tidak pernah berlaku. Pengasingan:
Transaksi pangkalan data klien mesti berlaku secara berasingan daripada pelanggan lain yang cuba berurusan dengan RDBMS. Ketahanan:
Pengoperasian data yang merupakan sebahagian dari urus niaga mesti dicerminkan dalam penyimpanan tanpa voltan (memori komputer yang boleh mendapatkan maklumat tersimpan walaupun tidak dikuasakan - seperti cakera keras) dan berterusan urus niaga berjaya dilengkapkan. Kegagalan urus niaga tidak boleh meninggalkan data dalam keadaan komitmen yang separa.

Kes penggunaan tertentu untuk RDBMS, seperti pemprosesan transaksi dalam talian, bergantung kepada transaksi yang mematuhi ACID antara klien dan RDBMS untuk sistem berfungsi dengan baik. Contoh yang baik dari transaksi yang mematuhi ACID ialah pemindahan dana dari satu akaun bank kepada yang lain.

Ini terbahagi kepada dua urus niaga pangkalan data, di mana akaun pemula menunjukkan pengeluaran, dan akaun destinasi menunjukkan deposit. Jelas sekali, kedua-dua urus niaga ini perlu diikat bersama supaya berlaku jika salah satu daripadanya gagal, keseluruhan operasi mesti gagal untuk memastikan kedua-dua baki masih sah.

Hadoop sendiri tidak mempunyai konsep transaksi (atau bahkan rekod, untuk perkara itu), jadi ia jelas bukan sistem yang mematuhi ACID. Berfikir secara lebih khusus mengenai projek penyimpanan dan pemprosesan data di seluruh ekosistem Hadoop, tidak satupun dari mereka yang mematuhi sepenuhnya ACID, sama ada. Walau bagaimanapun, mereka lakukan mencerminkan sifat yang sering anda lihat di kedai data NoSQL, jadi terdapat beberapa contoh untuk pendekatan Hadoop. Satu konsep utama di sebalik kedai data NoSQL adalah bahawa tidak setiap aplikasi benar-benar memerlukan transaksi yang mematuhi ACID. Santai pada sifat-sifat tertentu ACID (dan bergerak jauh dari model hubungan) telah membuka banyak kemungkinan, yang telah membolehkan beberapa kedai data NoSQL untuk mencapai skala besar dan prestasi untuk aplikasi khusus mereka.

Manakala ACID mentakrifkan ciri-ciri utama yang diperlukan untuk pemprosesan urus niaga yang boleh dipercayai, dunia NoSQL memerlukan ciri-ciri yang berbeza untuk membolehkan kelenturan dan skalabiliti.Ciri-ciri lawan ini cerdik ditangkap dalam akronim BASE:

asical A vailable: Sistem ini dijamin tersedia untuk pertanyaan oleh semua pengguna. (Tidak ada pengasingan di sini.) S
oft State: Nilai-nilai yang disimpan dalam sistem mungkin berubah kerana model konsisten akhirnya, seperti yang dijelaskan dalam peluru seterusnya. E
secara serentak Konsisten: Seperti data yang ditambahkan ke sistem, keadaan sistem secara beransur-ansur direplikasi di semua nod. Sebagai contoh, dalam Hadoop, apabila fail ditulis ke HDFS, replika blok data dicipta dalam nod data yang berbeza selepas blok data asal ditulis. Untuk tempoh yang singkat sebelum blok direplikasi, keadaan sistem fail tidak konsisten. BASE akronim sedikit dibuat, kerana kebanyakan kedai data NoSQL tidak sepenuhnya meninggalkan

semua ciri-ciri ACID - ia tidak benar-benar konsep bertentangan kutub yang namanya menerangkan, dengan kata lain. Juga, keadaan Soft State dan Akhirnya Konsisten adalah sama dengan perkara yang sama, tetapi maksudnya adalah dengan melegakan konsistensi, sistem boleh skala secara melintang (banyak nod) dan memastikan ketersediaan. Tiada perbincangan mengenai NoSQL akan lengkap tanpa menyebut teorem CAP, yang mewakili tiga jenis jaminan yang arkitek bertujuan menyediakan dalam sistem mereka:

Konsistensi:

Sama dengan C di ACID, semua nod dalam sistem akan mempunyai pandangan yang sama pada data pada bila-bila masa. Ketersediaan:
Sistem ini sentiasa memberi respons kepada permintaan. Toleransi partition:
Sistem ini tetap dalam talian jika masalah rangkaian berlaku antara nod sistem. Teorema CAP menyatakan bahawa dalam sistem rangkaian teragih, arkitek perlu memilih dua daripada tiga jaminan ini - anda tidak boleh menjanjikan pengguna anda semua tiga. Ini memberi anda tiga kemungkinan yang ditunjukkan:

Sistem yang menggunakan teknologi relational tradisional

biasanya bukan partition tolerant, sehingga mereka dapat menjamin ketekalan dan ketersediaan. Ringkasnya, jika satu bahagian sistem teknologi relasional tradisional ini di luar talian, seluruh sistem di luar talian. Sistem di mana toleransi dan ketersediaan partisyen sangat penting
tidak dapat menjamin ketekalan, kerana kemas kini (pemusnah konsistensi) boleh dibuat di kedua-dua belah pihak. Kedai nilai utama Dynamo dan CouchDB dan stor keluarga kolum Cassandra adalah contoh popular sistem toleransi / ketersediaan partisi (PA). Sistem di mana toleransi partition dan konsistensi penting
tidak dapat menjamin ketersediaan kerana sistem mengembalikan kesilapan sehingga keadaan partition diselesaikan. Kedai data berasaskan Hadoop dianggap sebagai sistem CP (c toleran artileri dan p yang bertentangan). Dengan data yang tersimpan redundantly merentasi banyak nod hamba, gangguan kepada bahagian besar (sekatan) dari cluster Hadoop boleh diterima. Hadoop dianggap konsisten kerana ia mempunyai pusat metadata pusat (NameNode) yang mengekalkan pandangan tunggal, konsisten data yang disimpan dalam kelompok.