Saya akan memposting ini sebagai jawaban murni untuk mendukung percakapan - Tim Mahy , nawroth , dan CraigTP telah menyarankan database yang layak. CouchDB akan menjadi pilihan saya karena penggunaan Erlang , tetapi ada orang lain di luar sana.
Saya akan mengatakan ACID tidak bertentangan atau meniadakan konsep NoSQL ... Meskipun tampaknya ada tren mengikuti pendapat yang diungkapkan oleh merpati , saya berpendapat konsepnya berbeda.
NoSQL pada dasarnya tentang nilai kunci sederhana (misalnya Redis) atau skema gaya dokumen (pasangan nilai kunci yang dikumpulkan dalam model "dokumen", misalnya MongoDB) sebagai alternatif langsung ke skema eksplisit dalam RDBMSs klasik. Hal ini memungkinkan pengembang untuk memperlakukan hal - hal secara asimetris, sedangkan mesin tradisional telah menegakkan kesamaan di seluruh model data. Alasan ini sangat menarik adalah karena menyediakan cara berbeda untuk menghadapi perubahan , dan untuk set data yang lebih besar, ini memberikan peluang menarik untuk menangani volume dan kinerja.
ACID memberikan prinsip-prinsip yang mengatur bagaimana perubahan diterapkan ke database. Dengan cara yang sangat sederhana, ini menyatakan (versi saya sendiri):
(A) ketika Anda melakukan sesuatu untuk mengubah database perubahan harus berfungsi atau gagal secara keseluruhan
(C) database harus tetap konsisten (ini adalah topik yang cukup luas)
(I) jika hal-hal lain terjadi pada saat yang sama mereka seharusnya tidak dapat melihat hal-hal di tengah pembaruan
(D) jika sistem meledak (perangkat keras atau perangkat lunak) database harus dapat mengambil sendiri cadangannya; dan jika dikatakan selesai menerapkan pembaruan, perlu dipastikan
Percakapan menjadi sedikit lebih bersemangat ketika datang ke gagasan propagasi dan kendala . Beberapa mesin RDBMS menyediakan kemampuan untuk menegakkan batasan (misalnya kunci asing) yang mungkin memiliki elemen propagasi (a cascade ). Dalam istilah yang lebih sederhana, satu "benda" mungkin memiliki hubungan dengan "benda" lain di dalam basis data, dan jika Anda mengubah atribut yang satu itu mungkin memerlukan yang lainnya diubah (diperbarui, dihapus, ... banyak opsi). Basis data NoSQL , yang sebagian besar (saat ini) berfokus pada volume data tinggi dan lalu lintas tinggi, tampaknya menangani gagasan pembaruan terdistribusi yang terjadi di dalam (dari perspektif konsumen) kerangka waktu sewenang-wenang. Ini pada dasarnya adalah bentuk replikasi khusus yang dikelola viatransaksi - jadi saya akan mengatakan bahwa jika basis data tradisional yang terdistribusi dapat mendukung ACID, demikian juga dengan basis data NoSQL.
Jawaban yang bagus. Anda dapat memiliki NoSQL + ACID dan non-ACID-RDBMS (pikirkan MySQL + MyISAM). Saya biasanya menganggap NoSQL sebagai "akhirnya konsisten". Saya akan memasukkan teorema CAP juga ... :-)
gbn
+1 @gbn untuk menyebutkan teorema CAP. Menjadi lebih akrab dengan "nosql" db sekarang daripada saya hanya memperkuat pemisahan konsep. Juga, kunci-nilai vs database doc, karena ada perbedaan arsitektur.
UPDATE (27 Juli 2012): Tautan ke artikel Wikipedia telah diperbarui untuk mencerminkan versi artikel yang saat ini ketika jawaban ini diposting. Harap dicatat bahwa artikel Wikipedia saat ini telah banyak direvisi!
NoSQL adalah gerakan yang mempromosikan kelas penyimpanan data non-relasional yang didefinisikan secara longgar, yang terpecah dengan sejarah panjang basis data relasional dan jaminan ACID.
dan juga:
Nama itu merupakan upaya untuk menggambarkan munculnya semakin banyak toko data non-relasional terdistribusi yang sering tidak berupaya memberikan jaminan ACID.
dan
Sistem NoSQL sering memberikan jaminan konsistensi yang lemah seperti konsistensi akhirnya dan transaksi terbatas pada item data tunggal, meskipun orang dapat memaksakan jaminan ACID penuh dengan menambahkan lapisan middleware tambahan.
Jadi, singkatnya, saya akan mengatakan bahwa salah satu manfaat utama dari "NoSQL" menyimpan data berbeda yang kurangnya dari ACID properti. Selain itu, IMHO, semakin banyak orang mencoba menerapkan dan menegakkan properti ACID , semakin jauh dari "semangat" penyimpanan data "NoSQL" yang Anda dapatkan, dan semakin dekat ke RDBMS "benar" yang Anda dapatkan (relatif berbicara, tentu saja ).
Namun, semua yang mengatakan, "NoSQL" adalah istilah yang sangat samar dan terbuka untuk interpretasi individu, dan sangat bergantung pada seberapa banyak dari sudut pandang murni yang Anda miliki. Misalnya, yang paling modern-hari RDBMS sistem tidak benar-benar mematuhi semua dari Edgar F. Codd 's 12 aturan nya Model hubungan !
Mengambil pendekatan pragmatis, akan terlihat bahwa Apache CouchDB menjadi yang paling dekat dengan mewujudkan kedua kepatuhan ACID sambil tetap mempertahankan mentalitas "NoSQL" yang tidak berpasangan dan tidak berhubungan.
+1 Saya tidak yakin saya setuju dengan kurangnya ACID yang menjadi karakteristik utama "NoSQL", tapi saya sangat menghargai artikel Anda. Pada akhirnya, itu harus tentang solusi yang cocok.
AJ.
2
Saya mengedit (menunggu tinjauan) untuk mencoba membuatnya lebih jelas. Tidak ada tentang datamodels NoSQL yang menyiratkan transaksi ACID tidak mungkin. Beberapa sistem terdistribusi NoSQL tidak memilikinya. Beberapa benar-benar melakukannya tanpa "lapisan middleware".
Eric Bloch
2
Ini tidak pernah benar dan bahkan kehilangan sumbernya. Itu harus benar-benar dihapus.
Lennart Regebro
2
Yah, yang paling mencolok, ini: "Singkatnya, saya akan mengatakan bahwa salah satu manfaat utama dari penyimpanan data" NoSQL "adalah tidak adanya properti ACID yang jelas." Anda juga menyiratkan bahwa NoSQL dan ACID entah bagaimana saling eksklusif yang pasti salah. Ini adalah contoh yang baik ketika sejumlah besar orang yang tidak tahu diri memilih jawaban yang salah karena itu terdengar masuk akal. Bahwa sebagian besar basis data NoSQL tidak sesuai dengan ACID sebagian besar karena orang yang mengimplementasikannya tidak tahu apa itu / mengapa itu penting / tidak peduli.
Lennart Regebro
@LennartRegebro - Saya tidak menyiratkan hal seperti itu. Kepatuhan ACID memang telah dihindari oleh sebagian besar, database NoSQL saat ini yang ada dalam mendukung kecepatan / kinerja dan akhirnya konsistensi. Saya tidak pernah mengatakan bahwa Anda tidak dapat memiliki NoSQL dengan kepatuhan ACID.
Pertama-tama, kita dapat membedakan dua jenis database NoSQL:
Database berorientasi agregat;
Database berorientasi grafik (misalnya Neo4J).
Secara desain, kebanyakan basis data yang berorientasi Grafik adalah ASAM !
Lalu, bagaimana dengan tipe lainnya?
Dalam database berorientasi agregat, kita dapat menempatkan tiga sub-tipe:
Database NoSQL berbasis dokumen (mis. MongoDB, CouchDB);
Kunci / Nilai database NoSQL (mis. Redis);
Database NoSQL keluarga kolom (mis. Hibase, Cassandra).
Apa yang kita sebut Agregat di sini, adalah apa yang didefinisikan oleh Eric Evans dalam Desain Berbasis Domain sebagai kemandirian Entitas dan Nilai-Objek dalam Konteks Terbatas yang diberikan.
Sebagai konsekuensinya, agregat adalah kumpulan data yang kami berinteraksi sebagai satu unit. Agregat membentuk batasan untuk operasi ACID dengan database. (Martin Fowler)
Jadi, pada tingkat Agregat, kita dapat mengatakan bahwa sebagian besar basis data NoSQL dapat seaman ACID RDBMS , dengan pengaturan yang tepat. Tentu saja, jika Anda menyetel server Anda untuk kecepatan terbaik, Anda mungkin akan melakukan sesuatu yang bukan ACID. Tetapi replikasi akan membantu.
Poin utama saya adalah bahwa Anda harus menggunakan database NoSQL sebagaimana adanya, bukan sebagai alternatif (murah) dari RDBMS. Saya telah melihat terlalu banyak proyek menyalahgunakan hubungan antar dokumen. Ini tidak bisa ASAM. Jika Anda tetap pada level dokumen, yaitu pada batas Agregat, Anda tidak memerlukan transaksi apa pun. Dan data Anda akan seaman dengan database ACID, bahkan jika itu tidak benar-benar ACID, karena Anda tidak memerlukan transaksi tersebut! Jika Anda memerlukan transaksi dan memperbarui beberapa "dokumen" sekaligus, Anda tidak lagi berada di dunia NoSQL - jadi gunakan mesin RDBMS!
beberapa pembaruan 2019: Mulai dalam versi 4.0, untuk situasi yang memerlukan atomicity untuk pembaruan ke beberapa dokumen atau konsistensi antara membaca ke beberapa dokumen, MongoDB menyediakan transaksi multi-dokumen untuk set replika .
Ada kasus ketika ada proses / saga besar yang menangani banyak kelompok unsur kehidupan. Ada beberapa kasus ketika perintah yang dikirim ke agregat dapat memicu beberapa peristiwa yang mengubah agregat lainnya. Dalam kasus ini, Anda memerlukan penyimpanan data yang sesuai dengan ACID.
Tudor
1
@TudorTudor tetapi dalam kasus ini Anda melanggar salah satu prinsip nosql, karena Anda menggunakannya sebagai rdbms. Anda hanya perlu agregat yang lebih besar atau versi dokumen (seperti di couchdb). Db berorientasi dokumen nosql adalah asam pada batas dokumen / agregat.
Arnaud Bouchez
Tidak satu pun dari daftar yang Anda patuhi asam. Mongo hanya memiliki tidak mematuhi ACID. CouchDB berpura-pura sesuai dengan asam selama Anda tidak memperbarui dua dokumen. Redis hanya memiliki "dukungan parsial untuk transaksi". HBase lurus dan tidak sesuai asam (dari devs) , begitu pula Cassandra. Jawaban ini sebenarnya salah besar. Tidak satu pun dari database ini yang mendukung ACID, dan kebanyakan dari mereka secara terbuka memilikinya dengan pencarian google sederhana.
Evan Carroll
@ EvanCarroll Saya tidak pernah menulis bahwa MongoDB adalah ACID compliant, dalam arti yang sama dengan transaksi ACB RDBMS. Tidak ada transaksi yang tersedia. Apa yang saya tulis adalah bahwa kebanyakan database NoSQL dapat seaman ACID RDBMS, dengan pengaturan yang tepat . Misalnya, periksa operator MongoDB $ terisolasi untuk DB tanpa cluster bersama. Saya tidak akan pernah menggunakan MongoDB untuk proses keuangan, tetapi saya bisa mempercayai proses penulisannya sampai batas tertentu, untuk operasi mirip ACID, jika A untuk Atomicity sudah cukup. Maaf jika jawaban saya membingungkan.
Ini memiliki transaksi yang tepat, sehingga Anda dapat memperbarui beberapa item data yang berbeda secara ACID. Ini digunakan sebagai dasar untuk mempertahankan indeks pada lapisan yang lebih tinggi.
sayangnya itu bukan open source. Tapi itu terlihat seperti database yang sangat bagus.
Kevin Cox
Untuk menambahkan hingga @ Ken-Tindell jawaban, djondb juga NoSQL dan mengimplementasikan transaksi dan itu sesuai ACID. djondb.com Saya setuju bahwa NoSQL hanyalah istilah untuk koin semua basis data yang tidak mengikuti aturan tradisional RDBMS, itu tidak berarti "singkirkan sistem TX", atau lupakan hubungannya.
Cross
3
Jawaban saya telah diperdebatkan oleh akuisisi Apple atas Foundation DB.
Ken Tindell
1
foundationdb sekarang open source oleh Apple
RBanerjee
17
Dalam pertanyaan ini seseorang harus menyebutkan OrientDB : OrientDB adalah basis data NoSQL, satu dari sedikit, yang mendukung transaksi sepenuhnya ACID. ACID tidak hanya untuk RDBMS karena itu bukan bagian dari aljabar Relasional. Jadi mungkin untuk memiliki database NoSQL yang mendukung ACID.
Fitur ini adalah yang paling saya lewatkan di MongoDB
ACID dan NoSQL sepenuhnya ortogonal. Satu tidak menyiratkan yang lain.
Saya memiliki buku catatan di meja saya, saya menggunakannya untuk mencatat hal-hal yang masih harus saya lakukan. Notebook ini adalah basis data NoSQL. Saya meminta menggunakan pencarian linear dengan "cache halaman" jadi saya tidak selalu harus mencari setiap halaman. Ini juga sesuai ACID karena saya memastikan bahwa saya hanya menulis satu hal pada satu waktu dan tidak pernah saat saya membacanya.
NoSQL berarti bukan SQL. Banyak orang bingung dan berpikir itu berarti penyimpanan sangat liar-barat-super-cepat. Tidak. Itu tidak berarti penyimpanan nilai kunci, atau konsistensi akhirnya. Semua itu berarti "bukan SQL", ada banyak basis data di planet ini dan kebanyakan dari mereka bukan SQL [rujukan?] .
Anda dapat menemukan banyak contoh di jawaban lain jadi saya tidak perlu mencantumkannya di sini, tetapi ada database non-SQL dengan kepatuhan ACID untuk berbagai operasi, beberapa hanya ACID untuk objek tunggal menulis sementara beberapa jaminan jauh lebih banyak. Setiap basis data berbeda.
Hanya untuk menjadi bertele-tele tetapi biasanya berarti 'Tidak hanya SQL' :-)
shmish111
4
@ shmish111 tidak juga. Itu berarti "No SQL" ketika istilah ini pertama kali diciptakan. "O" itu kecil, bukan modal. Ada upaya kemudian untuk merujuk kembali istilah sebagai "Tidak Hanya SQL" ketika beberapa dari ini (produk NoSQL) mulai menambahkan antarmuka bahasa query seperti SQL.
ypercubeᵀᴹ
11
"NoSQL" bukan istilah yang didefinisikan dengan baik. Itu konsep yang sangat kabur. Dengan demikian, bahkan tidak mungkin untuk mengatakan apa yang ada dan apa yang bukan produk "NoSQL". Tidak hampir semua produk yang secara khas bermerek dengan label merupakan kunci-nilai toko.
Jawaban Terbaik. Ketika perang api ini muncul, saya ingin bertanya kepada pihak lain fitur apa yang mereka tentukan secara eksplisit dari database NoSQL dan sering kali tumpang tindih dengan fitur yang dapat mereka temukan dalam RDBMS - bukan karena satu atau RDBMS yang sesuai dengan tema NoSQL tetapi hanya karena mereka fitur 'persyaratan' begitu kabur sehingga tidak meniadakan sepenuhnya, fitur yang ditemukan di (tidak semua harus) RDMBSs. +1 untuk teman komentar Anda!
StartupGuy
8
Ya, MarkLogic Server adalah solusi NoSQL (database dokumen yang saya suka menyebutnya) yang bekerja dengan transaksi ACID
Bagi mereka yang mencari transisi dari perpustakaan "rak" python, saya menemukan ZODB hampir tidak terlihat. Saya tidak perlu menulis ulang semua fungsi saya - cukup akses ZODB sebagai kamus seperti rak, tetapi ini adalah urutan besarnya lebih cepat.
Michael Galaxy
8
Sebagai salah satu penggagas NoSQL (saya adalah kontributor awal untuk Apache CouchDB, dan pembicara pada acara NoSQL pertama yang diadakan di CBS Interactive / CNET pada tahun 2009) Saya senang melihat algoritma baru membuat kemungkinan yang tidak ada sebelumnya . Protokol Calvin menawarkan cara baru untuk memikirkan kendala fisik seperti CAP dan PACELC .
Alih-alih replikasi async aktif / pasif, atau replikasi sinkron aktif / aktif, Calvin mempertahankan kebenaran dan ketersediaan selama pemadaman replika dengan menggunakan protokol seperti RAFT untuk memelihara log transaksi. Selain itu, transaksi diproses secara deterministik di setiap replika, menghilangkan potensi kebuntuan, sehingga kesepakatan dicapai hanya dengan satu putaran konsensus. Ini membuatnya cepat bahkan pada penyebaran multi-cloud di seluruh dunia.
FaunaDB adalah satu-satunya implementasi basis data yang menggunakan protokol Calvin, membuatnya secara unik cocok untuk beban kerja yang memerlukan integritas data seperti mainframe dengan skala dan fleksibilitas NoSQL.
Jika Anda mencari toko kunci / nilai yang sesuai dengan ACID, ada Berkeley DB . Di antara basis data grafik setidaknya Neo4j dan HyperGraphDB menawarkan transaksi ACID (HyperGraphDB sebenarnya menggunakan Berkeley DB untuk penyimpanan tingkat rendah saat ini).
[…] Kelas sistem manajemen basis data relasional modern yang berupaya memberikan kinerja sistem NoSQL scalable yang sama untuk beban transaksi baca-tulis pemrosesan transaksi online (OLTP) sambil tetap mempertahankan jaminan ACID dari sistem basis data tradisional.[1][2][3]
Ya, transaksi multi-dokumen ACID sekarang didukung di MongoDB. Lihat mongodb.com/transactions untuk info lebih lanjut dan selami video mendalam tentang cara penerapannya.
Tidak seperti roll-kegigihan Anda sendiri atau serialisasi, db4o adalah transaksi ACID aman dan memungkinkan untuk perubahan kueri, replikasi dan skema selama runtime
Tarantool adalah basis data ACID NoSQL sepenuhnya. Anda dapat mengeluarkan operasi CRUD atau prosedur tersimpan, semuanya akan berjalan sesuai ketat dengan properti ACID. Anda juga dapat membaca tentang itu di sini: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
Apakah Aerospike mendukung transaksi ACID multi-kunci? AKAIK terbatas pada transaksi satu tombol.
eonil
1
BergDB adalah basis data NoSQL yang ringan, sumber terbuka, dan dirancang sejak awal untuk menjalankan transaksi ACID. Sebenarnya, BergDB "lebih" ACID daripada kebanyakan database SQL dalam arti bahwa satu - satunya cara untuk mengubah keadaan database adalah dengan menjalankan transaksi ACID dengan tingkat isolasi tertinggi (istilah SQL: "serializable"). Tidak akan pernah ada masalah dengan pembacaan yang kotor, pembacaan yang tidak dapat diulang, atau pembacaan hantu.
Menurut pendapat saya, database masih sangat berkinerja; tapi jangan percaya padaku, saya membuat perangkat lunak. Cobalah sendiri.
Banyak solusi NoSQL modern tidak mendukung transaksi ACID (pembaruan multi-kunci yang terisolasi secara atom), tetapi kebanyakan dari mereka mendukung primitif yang memungkinkan Anda untuk mengimplementasikan transaksi pada level aplikasi.
Jika penyimpanan data mendukung per liniabilitas utama dan bandingkan-dan-set (atomisitas tingkat dokumen) maka cukup untuk mengimplementasikan transaksi sisi klien, lebih dari itu Anda memiliki beberapa opsi untuk dipilih:
Jika Anda membutuhkan tingkat isolasi Serializable maka Anda dapat mengikuti algoritma yang sama yang digunakan Google untuk sistem Percolator atau Lab Kecoa untuk CockroachDB . Saya telah membuat blog tentang hal itu dan membuat visualisasi langkah demi langkah , saya harap ini akan membantu Anda untuk memahami ide utama di balik algoritma.
Jika Anda mengharapkan pertengkaran tinggi tetapi tidak masalah bagi Anda untuk memiliki tingkat isolasi Baca Komit maka silakan lihat pada transaksi RAMP oleh Peter Bailis.
Pendekatan ketiga adalah menggunakan transaksi kompensasi yang juga dikenal sebagai pola saga. Itu dijelaskan pada akhir 80-an di koran Sagas tetapi menjadi lebih aktual dengan peningkatan sistem terdistribusi. Silakan lihat ceramah Menerapkan Pola Saga untuk inspirasi.
Daftar toko data yang cocok untuk transaksi sisi klien termasuk Cassandra dengan transaksi ringan, Riak dengan bucket konsisten, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB, dan lainnya.
Pembuat VoltDB menyebutkan bahwa mereka tidak melabeli diri mereka sebagai NoSql tetapi lebih seperti NewSql (masih menggunakan Sql tetapi dengan implementasi yang lebih baik daripada RDBM yang dibangun pada tahun delapan puluhan)
Matt W
0
Sementara itu hanya mesin tertanam dan bukan server, leveldb memiliki WriteBatch dan kemampuan untuk mengaktifkan Synchronous menulis untuk menyediakan perilaku ACID.
Tidak hanya NoSQL tidak sesuai dengan desain ACID. Gerakan NoSQL merangkul BASE (Dasarnya Tersedia, Soft state, Akhirnya konsistensi) diklaim sebagai lawan dari ACID. Basis data NoSQL sering disebut basis data Eventually-Consisted. Untuk memahami perbedaannya, Anda harus menelusuri ke dalam teorema CAP (teorema Brewer's)
Saya pikir pointer ke teorema CAP sangat relevan untuk pertanyaan ini!
mxro
2
Beberapa database NoSQL memiliki transaksi ACID.
Eric Bloch
1
Beberapa noSQL mengklaim sebagai ACID tetapi ketika Anda menelusuri dalam Anda menemukan bahwa hanya dalam beberapa kasus mereka ACID jadi IMHO karena tidak ada 'akhirnya ACID' mereka pasti tidak ACID
Ste
1
Anda pada dasarnya salah menerapkan CAP. CAP dan ACID terkait longgar paling baik, tetapi CAP tidak mencegah sistem terdistribusi dari yang mematuhi ACID. CAP menguraikan pertukaran timbal balik yang diperlukan dari sistem terdistribusi - sistem NoSQL yang sangat konsisten mungkin tidak tersedia selama partisi, tetapi itu tidak menghalangi hal tersebut dari kepatuhan ACID.
Jawaban:
Saya akan memposting ini sebagai jawaban murni untuk mendukung percakapan - Tim Mahy , nawroth , dan CraigTP telah menyarankan database yang layak. CouchDB akan menjadi pilihan saya karena penggunaan Erlang , tetapi ada orang lain di luar sana.
Saya akan mengatakan ACID tidak bertentangan atau meniadakan konsep NoSQL ... Meskipun tampaknya ada tren mengikuti pendapat yang diungkapkan oleh merpati , saya berpendapat konsepnya berbeda.
NoSQL pada dasarnya tentang nilai kunci sederhana (misalnya Redis) atau skema gaya dokumen (pasangan nilai kunci yang dikumpulkan dalam model "dokumen", misalnya MongoDB) sebagai alternatif langsung ke skema eksplisit dalam RDBMSs klasik. Hal ini memungkinkan pengembang untuk memperlakukan hal - hal secara asimetris, sedangkan mesin tradisional telah menegakkan kesamaan di seluruh model data. Alasan ini sangat menarik adalah karena menyediakan cara berbeda untuk menghadapi perubahan , dan untuk set data yang lebih besar, ini memberikan peluang menarik untuk menangani volume dan kinerja.
ACID memberikan prinsip-prinsip yang mengatur bagaimana perubahan diterapkan ke database. Dengan cara yang sangat sederhana, ini menyatakan (versi saya sendiri):
Percakapan menjadi sedikit lebih bersemangat ketika datang ke gagasan propagasi dan kendala . Beberapa mesin RDBMS menyediakan kemampuan untuk menegakkan batasan (misalnya kunci asing) yang mungkin memiliki elemen propagasi (a cascade ). Dalam istilah yang lebih sederhana, satu "benda" mungkin memiliki hubungan dengan "benda" lain di dalam basis data, dan jika Anda mengubah atribut yang satu itu mungkin memerlukan yang lainnya diubah (diperbarui, dihapus, ... banyak opsi). Basis data NoSQL , yang sebagian besar (saat ini) berfokus pada volume data tinggi dan lalu lintas tinggi, tampaknya menangani gagasan pembaruan terdistribusi yang terjadi di dalam (dari perspektif konsumen) kerangka waktu sewenang-wenang. Ini pada dasarnya adalah bentuk replikasi khusus yang dikelola viatransaksi - jadi saya akan mengatakan bahwa jika basis data tradisional yang terdistribusi dapat mendukung ACID, demikian juga dengan basis data NoSQL.
Beberapa sumber untuk bacaan lebih lanjut:
sumber
UPDATE (27 Juli 2012): Tautan ke artikel Wikipedia telah diperbarui untuk mencerminkan versi artikel yang saat ini ketika jawaban ini diposting. Harap dicatat bahwa artikel Wikipedia saat ini telah banyak direvisi!
Menurut versi artikel Wikipedia yang lebih lama di NoSQL :
dan juga:
dan
Jadi, singkatnya, saya akan mengatakan bahwa salah satu manfaat utama dari "NoSQL" menyimpan data berbeda yang kurangnya dari ACID properti. Selain itu, IMHO, semakin banyak orang mencoba menerapkan dan menegakkan properti ACID , semakin jauh dari "semangat" penyimpanan data "NoSQL" yang Anda dapatkan, dan semakin dekat ke RDBMS "benar" yang Anda dapatkan (relatif berbicara, tentu saja ).
Namun, semua yang mengatakan, "NoSQL" adalah istilah yang sangat samar dan terbuka untuk interpretasi individu, dan sangat bergantung pada seberapa banyak dari sudut pandang murni yang Anda miliki. Misalnya, yang paling modern-hari RDBMS sistem tidak benar-benar mematuhi semua dari Edgar F. Codd 's 12 aturan nya Model hubungan !
Mengambil pendekatan pragmatis, akan terlihat bahwa Apache CouchDB menjadi yang paling dekat dengan mewujudkan kedua kepatuhan ACID sambil tetap mempertahankan mentalitas "NoSQL" yang tidak berpasangan dan tidak berhubungan.
sumber
Harap pastikan Anda membaca pengantar Martin Fowler tentang database NoSQL . Dan video yang sesuai.
Pertama-tama, kita dapat membedakan dua jenis database NoSQL:
Secara desain, kebanyakan basis data yang berorientasi Grafik adalah ASAM !
Lalu, bagaimana dengan tipe lainnya?
Dalam database berorientasi agregat, kita dapat menempatkan tiga sub-tipe:
Apa yang kita sebut Agregat di sini, adalah apa yang didefinisikan oleh Eric Evans dalam Desain Berbasis Domain sebagai kemandirian Entitas dan Nilai-Objek dalam Konteks Terbatas yang diberikan.
Jadi, pada tingkat Agregat, kita dapat mengatakan bahwa sebagian besar basis data NoSQL dapat seaman ACID RDBMS , dengan pengaturan yang tepat. Tentu saja, jika Anda menyetel server Anda untuk kecepatan terbaik, Anda mungkin akan melakukan sesuatu yang bukan ACID. Tetapi replikasi akan membantu.
Poin utama saya adalah bahwa Anda harus menggunakan database NoSQL sebagaimana adanya, bukan sebagai alternatif (murah) dari RDBMS. Saya telah melihat terlalu banyak proyek menyalahgunakan hubungan antar dokumen. Ini tidak bisa ASAM. Jika Anda tetap pada level dokumen, yaitu pada batas Agregat, Anda tidak memerlukan transaksi apa pun. Dan data Anda akan seaman dengan database ACID, bahkan jika itu tidak benar-benar ACID, karena Anda tidak memerlukan transaksi tersebut! Jika Anda memerlukan transaksi dan memperbarui beberapa "dokumen" sekaligus, Anda tidak lagi berada di dunia NoSQL - jadi gunakan mesin RDBMS!
beberapa pembaruan 2019: Mulai dalam versi 4.0, untuk situasi yang memerlukan atomicity untuk pembaruan ke beberapa dokumen atau konsistensi antara membaca ke beberapa dokumen, MongoDB menyediakan transaksi multi-dokumen untuk set replika .
sumber
FoundationDB kompatibel dengan ACID:
http://www.foundationdb.com/
Ini memiliki transaksi yang tepat, sehingga Anda dapat memperbarui beberapa item data yang berbeda secara ACID. Ini digunakan sebagai dasar untuk mempertahankan indeks pada lapisan yang lebih tinggi.
sumber
Dalam pertanyaan ini seseorang harus menyebutkan OrientDB : OrientDB adalah basis data NoSQL, satu dari sedikit, yang mendukung transaksi sepenuhnya ACID. ACID tidak hanya untuk RDBMS karena itu bukan bagian dari aljabar Relasional. Jadi mungkin untuk memiliki database NoSQL yang mendukung ACID.
Fitur ini adalah yang paling saya lewatkan di MongoDB
sumber
ACID dan NoSQL sepenuhnya ortogonal. Satu tidak menyiratkan yang lain.
Saya memiliki buku catatan di meja saya, saya menggunakannya untuk mencatat hal-hal yang masih harus saya lakukan. Notebook ini adalah basis data NoSQL. Saya meminta menggunakan pencarian linear dengan "cache halaman" jadi saya tidak selalu harus mencari setiap halaman. Ini juga sesuai ACID karena saya memastikan bahwa saya hanya menulis satu hal pada satu waktu dan tidak pernah saat saya membacanya.
NoSQL berarti bukan SQL. Banyak orang bingung dan berpikir itu berarti penyimpanan sangat liar-barat-super-cepat. Tidak. Itu tidak berarti penyimpanan nilai kunci, atau konsistensi akhirnya. Semua itu berarti "bukan SQL", ada banyak basis data di planet ini dan kebanyakan dari mereka bukan SQL [rujukan?] .
Anda dapat menemukan banyak contoh di jawaban lain jadi saya tidak perlu mencantumkannya di sini, tetapi ada database non-SQL dengan kepatuhan ACID untuk berbagai operasi, beberapa hanya ACID untuk objek tunggal menulis sementara beberapa jaminan jauh lebih banyak. Setiap basis data berbeda.
sumber
"NoSQL" bukan istilah yang didefinisikan dengan baik. Itu konsep yang sangat kabur. Dengan demikian, bahkan tidak mungkin untuk mengatakan apa yang ada dan apa yang bukan produk "NoSQL". Tidak hampir semua produk yang secara khas bermerek dengan label merupakan kunci-nilai toko.
sumber
Ya, MarkLogic Server adalah solusi NoSQL (database dokumen yang saya suka menyebutnya) yang bekerja dengan transaksi ACID
sumber
Kakek NoSQL: ZODB kompatibel dengan ACID. http://www.zodb.org/
Namun, itu hanya Python.
sumber
Sebagai salah satu penggagas NoSQL (saya adalah kontributor awal untuk Apache CouchDB, dan pembicara pada acara NoSQL pertama yang diadakan di CBS Interactive / CNET pada tahun 2009) Saya senang melihat algoritma baru membuat kemungkinan yang tidak ada sebelumnya . Protokol Calvin menawarkan cara baru untuk memikirkan kendala fisik seperti CAP dan PACELC .
Alih-alih replikasi async aktif / pasif, atau replikasi sinkron aktif / aktif, Calvin mempertahankan kebenaran dan ketersediaan selama pemadaman replika dengan menggunakan protokol seperti RAFT untuk memelihara log transaksi. Selain itu, transaksi diproses secara deterministik di setiap replika, menghilangkan potensi kebuntuan, sehingga kesepakatan dicapai hanya dengan satu putaran konsensus. Ini membuatnya cepat bahkan pada penyebaran multi-cloud di seluruh dunia.
FaunaDB adalah satu-satunya implementasi basis data yang menggunakan protokol Calvin, membuatnya secara unik cocok untuk beban kerja yang memerlukan integritas data seperti mainframe dengan skala dan fleksibilitas NoSQL.
sumber
Jika Anda mencari toko kunci / nilai yang sesuai dengan ACID, ada Berkeley DB . Di antara basis data grafik setidaknya Neo4j dan HyperGraphDB menawarkan transaksi ACID (HyperGraphDB sebenarnya menggunakan Berkeley DB untuk penyimpanan tingkat rendah saat ini).
sumber
NewSQL
Konsep ini didefinisikan oleh kontributor Wikipedia sebagai:
Referensi
[1]Nancy Lynch dan Seth Gilbert, "dugaan Brewer dan kelayakan layanan web yang konsisten, tersedia, dan toleran-partisi" , ACM SIGACT News, Volume 33 Edisi 2 (2002), hal. 51-59.[2]"Brewer's CAP Theorem" , julianbrowne.com, Diperoleh 02-Mar-2010[3]"Brewers CAP teorema pada sistem terdistribusi" , royans.netsumber
MongoDB mengumumkan bahwa versi 4.0-nya akan sesuai dengan ACID untuk transaksi multi-dokumen.
Versi 4.2. seharusnya mendukungnya di bawah pengaturan sharded.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
sumber
FoundationDB disebutkan dan pada saat itu bukan open source. Sudah open source oleh Apple dua hari lalu: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Saya percaya ini sesuai ACID.
sumber
lihat teorema CAP
EDIT: RavenDB tampaknya kompatibel dengan ACID
sumber
Untuk menambah daftar alternatif, sepenuhnya ASAM basis data NoSQL lain compliant adalah GT.M .
sumber
Hyperdex Warp http://hyperdex.org/warp/ Warp (fitur ACID) adalah hak milik, tetapi Hyperdex gratis.
sumber
db4o
http://www.db4o.com/about/productinformation/db4o/
sumber
Tarantool adalah basis data ACID NoSQL sepenuhnya. Anda dapat mengeluarkan operasi CRUD atau prosedur tersimpan, semuanya akan berjalan sesuai ketat dengan properti ACID. Anda juga dapat membaca tentang itu di sini: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
sumber
MarkLogic juga kompatibel dengan ACID. Saya pikir adalah salah satu pemain terbesar sekarang.
sumber
Tunggu sudah berakhir.
ACID NoSQL DB yang sesuai keluar ----------- lihat citrusleaf
sumber
BergDB adalah basis data NoSQL yang ringan, sumber terbuka, dan dirancang sejak awal untuk menjalankan transaksi ACID. Sebenarnya, BergDB "lebih" ACID daripada kebanyakan database SQL dalam arti bahwa satu - satunya cara untuk mengubah keadaan database adalah dengan menjalankan transaksi ACID dengan tingkat isolasi tertinggi (istilah SQL: "serializable"). Tidak akan pernah ada masalah dengan pembacaan yang kotor, pembacaan yang tidak dapat diulang, atau pembacaan hantu.
Menurut pendapat saya, database masih sangat berkinerja; tapi jangan percaya padaku, saya membuat perangkat lunak. Cobalah sendiri.
sumber
Banyak solusi NoSQL modern tidak mendukung transaksi ACID (pembaruan multi-kunci yang terisolasi secara atom), tetapi kebanyakan dari mereka mendukung primitif yang memungkinkan Anda untuk mengimplementasikan transaksi pada level aplikasi.
Jika penyimpanan data mendukung per liniabilitas utama dan bandingkan-dan-set (atomisitas tingkat dokumen) maka cukup untuk mengimplementasikan transaksi sisi klien, lebih dari itu Anda memiliki beberapa opsi untuk dipilih:
Jika Anda membutuhkan tingkat isolasi Serializable maka Anda dapat mengikuti algoritma yang sama yang digunakan Google untuk sistem Percolator atau Lab Kecoa untuk CockroachDB . Saya telah membuat blog tentang hal itu dan membuat visualisasi langkah demi langkah , saya harap ini akan membantu Anda untuk memahami ide utama di balik algoritma.
Jika Anda mengharapkan pertengkaran tinggi tetapi tidak masalah bagi Anda untuk memiliki tingkat isolasi Baca Komit maka silakan lihat pada transaksi RAMP oleh Peter Bailis.
Pendekatan ketiga adalah menggunakan transaksi kompensasi yang juga dikenal sebagai pola saga. Itu dijelaskan pada akhir 80-an di koran Sagas tetapi menjadi lebih aktual dengan peningkatan sistem terdistribusi. Silakan lihat ceramah Menerapkan Pola Saga untuk inspirasi.
Daftar toko data yang cocok untuk transaksi sisi klien termasuk Cassandra dengan transaksi ringan, Riak dengan bucket konsisten, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB, dan lainnya.
sumber
YugaByte DB mendukung txns terdistribusi ACID Compliant serta kompatibilitas Redis dan CQL API pada lapisan kueri.
sumber
VoltDB adalah peserta yang mengklaim kepatuhan ACID, dan meskipun masih menggunakan SQL, tujuannya sama dalam hal skalabilitas
sumber
Sementara itu hanya mesin tertanam dan bukan server, leveldb memiliki WriteBatch dan kemampuan untuk mengaktifkan Synchronous menulis untuk menyediakan perilaku ACID.
sumber
Node levelUP bersifat transaksional dan dibangun di atas leveldb https://github.com/rvagg/node-levelup#batch
sumber
Google Cloud Datastore adalah basis data NoSQL yang mendukung transaksi ACID
sumber
DynamoDB adalah database NoSQL dan memiliki transaksi ACID .
sumber
Tidak hanya NoSQL tidak sesuai dengan desain ACID. Gerakan NoSQL merangkul BASE (Dasarnya Tersedia, Soft state, Akhirnya konsistensi) diklaim sebagai lawan dari ACID. Basis data NoSQL sering disebut basis data Eventually-Consisted. Untuk memahami perbedaannya, Anda harus menelusuri ke dalam teorema CAP (teorema Brewer's)
Kunjungi http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
sumber