Meskipun ini adalah pertanyaan lama ...
Singkatnya, Anda dapat memahami ACID sebagai jaminan integritas / keamanan data dalam kondisi apa pun yang diharapkan . Seperti dalam pemrograman generik, semua sakit kepala berasal dari multi-threading.
Masalah terbesar pada NoSQL sebagian besar adalah ACI. D (urability) biasanya merupakan masalah yang terpisah.
Jika DB Anda single-threaded - jadi hanya satu pengguna yang dapat mengakses sekaligus -, itu sesuai dengan ACI. Tapi saya yakin hampir tidak ada server yang dapat memiliki kemewahan ini.
Jika DB Anda perlu multi-utas - melayani beberapa pengguna / klien secara bersamaan - Anda harus membutuhkan transaksi yang sesuai dengan ACI. Atau Anda akan mendapatkan korupsi data diam-diam daripada kehilangan data sederhana. Yang jauh lebih mengerikan. Sederhananya, ini persis sama dengan pemrograman multi-threaded generik. Jika Anda tidak memiliki mekanisme yang tepat seperti kunci, Anda akan mendapatkan data yang tidak ditentukan. Dan mekanisme dalam DB disebut kepatuhan ACID sepenuhnya .
Banyak database YesSQL / NoSQL mengiklankan diri mereka sendiri yang kompatibel dengan ACID, tetapi sebenarnya, sangat sedikit dari mereka yang benar-benar melakukannya.
Tidak ada kepatuhan ACID = Anda akan selalu mendapatkan hasil yang tidak ditentukan dalam lingkungan multi-pengguna (klien). Saya bahkan tidak berpikir DB seperti apa yang melakukan ini.
Baris tunggal / kunci ACID compliant = Anda akan mendapatkan hasil yang dijamin jika Anda hanya mengubah satu nilai sekaligus. Tetapi hasil yang tidak terdefinisi (= korupsi data diam-diam) untuk pembaruan multi baris / kunci secara bersamaan. Sebagian besar DB NoSQL yang saat ini populer termasuk Cassandra, MongoDB, CouchDB, ... DB semacam ini hanya aman untuk transaksi baris tunggal. Jadi, Anda perlu menjamin bahwa logika DB Anda tidak akan menyentuh banyak baris dalam transaksi.
Kepatuhan multi baris / kunci ACID = Anda akan selalu mendapatkan hasil yang dijamin untuk operasi apa pun. Ini adalah persyaratan minimal sebagai RDBMS. Di bidang NoSQL, sangat sedikit dari mereka yang melakukan ini. Spanner, MarkLogic, VoltDB, FoundationDB. Saya bahkan tidak yakin ada lebih banyak solusi. DB semacam ini benar-benar segar dan baru, jadi sebagian besar tidak diketahui tentang kemampuan atau keterbatasan mereka.
Bagaimanapun, ini adalah perbandingan kecuali D (urability). Jadi jangan lupa untuk memeriksa atribut ketahanan juga. Sangat sulit untuk membandingkan daya tahan karena rentang menjadi terlalu lebar. Saya tidak tahu topik ini dengan baik ...
Tidak ada daya tahan. Anda akan kehilangan data kapan saja.
Disimpan dengan aman di disk. Ketika Anda dapatkan COMMIT OK, maka data dijamin pada disk. Anda kehilangan data jika disk rusak.
Juga, ada perbedaan bahkan pada DB yang sesuai dengan ACID.
Terkadang ACID compliant / Anda memerlukan konfigurasi / tidak ada sesuatu yang otomatis .. / beberapa komponen tidak ACID-complient / sangat cepat tetapi Anda perlu mematikan sesuatu untuk ini ... / ACID-compliant jika Anda menggunakan modul tertentu ... = kami tidak akan mengikat keamanan data secara default. Itu add-on, opsi atau penjualan terpisah. Jangan lupa mengunduh, memasang, mengatur, dan mengeluarkan perintah yang tepat. Bagaimanapun, keamanan data dapat diabaikan secara diam-diam. Lakukan sendiri. Periksa sendiri. Semoga beruntung tidak membuat kesalahan. Semua orang di tim Anda harus menjadi DBA sempurna untuk menggunakan DB jenis ini dengan aman. MySQL
Selalu mematuhi ACID = Kami tidak menukar keamanan data dengan kinerja atau apa pun. Keamanan data adalah paket paksa dengan paket DB ini. RDBMS paling komersial, PostgreSQL.
Di atas adalah implementasi khas DB. Namun tetap saja, kegagalan perangkat keras lainnya dapat merusak database. Seperti kesalahan memori, kesalahan saluran data, atau kesalahan lainnya yang mungkin terjadi. Jadi Anda perlu redundansi tambahan, dan DB berkualitas nyata harus menawarkan fitur toleransi kesalahan.
Tidak ada redundansi. Anda kehilangan semua data jika data Anda rusak.
Cadangkan. Anda membuat salinan / pengembalian foto. Anda kehilangan data setelah cadangan terakhir.
Cadangan online. Anda dapat melakukan backup snapshot saat database sedang berjalan.
Replikasi asinkron. Cadangkan untuk setiap detik (atau periode tertentu). Jika mesin mati, DB ini dijamin untuk mendapatkan kembali data hanya dengan me-reboot. Anda kehilangan data setelah detik terakhir.
Replikasi sinkron. Segera buat cadangan untuk setiap pembaruan data. Anda selalu memiliki salinan data asli yang tepat. Gunakan salinan jika asal rusak.
Sampai sekarang, saya melihat banyak implementasi DB kurang banyak. Dan saya pikir jika mereka tidak memiliki dukungan ACID dan redundansi yang tepat, pengguna pada akhirnya akan kehilangan data.