Opublikuję to jako odpowiedź wyłącznie w celu wsparcia rozmowy - Tim Mahy , nawroth i CraigTP zasugerowali opłacalne bazy danych. CouchDB byłby moim ulubionym ze względu na użycie Erlanga , ale są tam inne.
Powiedziałbym, że ACID nie zaprzecza ani nie neguje koncepcji NoSQL ... Chociaż wydaje się, że istnieje trend podążający za opinią wyrażoną przez gołębia , uważam, że koncepcje są różne.
NoSQL zasadniczo dotyczy prostego schematu klucz-wartość (np. Redis) lub schematu w stylu dokumentu (zebrane pary klucz-wartość w modelu „dokumentu”, np. MongoDB) jako bezpośredniej alternatywy dla jawnego schematu w klasycznych RDBMS. Pozwala programistom traktować rzeczy asymetrycznie, podczas gdy tradycyjne silniki wymuszały sztywną identyczność w modelu danych. Jest to tak interesujące, ponieważ zapewnia inny sposób radzenia sobie ze zmianami , aw przypadku większych zestawów danych zapewnia interesujące możliwości radzenia sobie z wolumenami i wydajnością.
ACID zawiera zasady regulujące sposób wprowadzania zmian w bazie danych. W bardzo uproszczony sposób stwierdza (moja własna wersja):
(A) Kiedy robisz coś, aby zmienić bazę danych, zmiana powinna działać lub nie powieść się jako całość
(C) baza danych powinna pozostać spójna (jest to dość szeroki temat)
(I) jeśli inne rzeczy dzieją się w tym samym czasie, nie powinni być w stanie zobaczyć rzeczy w trakcie aktualizacji
(D) jeśli system ulegnie awarii (sprzęt lub oprogramowanie), baza danych musi mieć możliwość samodzielnego przywrócenia; a jeśli mówi, że zakończyło stosowanie aktualizacji, musi być pewne
Rozmowa staje się trochę bardziej pobudzająca, jeśli chodzi o ideę propagacji i ograniczeń . Niektóre silniki RDBMS zapewniają możliwość wymuszania ograniczeń (np. Kluczy obcych), które mogą mieć elementy propagacji (a la cascade ). Mówiąc prościej, jedna „rzecz” może mieć związek z inną „rzeczą” w bazie danych, a jeśli zmienisz atrybut jednej z nich, może to wymagać zmiany drugiej (zaktualizowanie, usunięcie,… wiele opcji). Bazy danych NoSQL , skupione głównie (w tej chwili) na dużych ilościach danych i dużym ruchu, wydają się rozwiązywać problem rozproszonych aktualizacji, które mają miejsce (z punktu widzenia konsumenta) w dowolnych ramach czasowych. Jest to w zasadzie wyspecjalizowana forma replikacji zarządzana przeztransakcja - więc powiedziałbym, że jeśli tradycyjna rozproszona baza danych może obsługiwać ACID, to również baza danych NoSQL.
Dobra odpowiedź. Możesz mieć zarówno NoSQL + ACID, jak i nie-ACID-RDBMS (pomyśl o MySQL + MyISAM). Chciałbym zwykle rozważyć NoSQL jako „ostatecznie spójne”.
Dorzucę
+1 @ gbn za wzmiankę o twierdzeniu CAP. Bycie bardziej zaznajomionym z "nosql" dbami teraz niż wtedy tylko wzmocniło separację pojęć. Ponadto bazy danych klucz-wartość i doc, ponieważ istnieją różnice architektoniczne.
AKTUALIZACJA (27 lipca 2012 r.): Link do artykułu w Wikipedii został zaktualizowany w celu odzwierciedlenia wersji artykułu, która była aktualna w momencie opublikowania tej odpowiedzi. Zwróć uwagę, że aktualny artykuł w Wikipedii został gruntownie poprawiony!
NoSQL to ruch promujący luźno zdefiniowaną klasę nierelacyjnych magazynów danych, które zrywają z długą historią relacyjnych baz danych i gwarancji ACID.
i również:
Nazwa była próbą opisania pojawienia się rosnącej liczby nierelacyjnych, rozproszonych magazynów danych, które często nie starały się zapewnić gwarancji ACID.
i
Systemy NoSQL często zapewniają słabe gwarancje spójności, takie jak ostateczna spójność i transakcje ograniczone do pojedynczych elementów danych, nawet jeśli można nałożyć pełne gwarancje ACID, dodając dodatkową warstwę oprogramowania pośredniego.
Tak, w skrócie, powiedziałbym, że jedną z głównych korzyści z „NoSQL” magazynu danych jest jego wyraźny brak z ACID właściwości. Co więcej, IMHO, im bardziej ktoś próbuje zaimplementować i wymusić właściwości ACID , tym dalej znajdujesz się od "ducha" magazynu danych "NoSQL" i im bliżej "prawdziwego" RDBMS (mówiąc względnie, oczywiście ).
Jednak wszystko, co zostało powiedziane, „NoSQL” jest terminem bardzo niejasnym i otwartym na indywidualne interpretacje i zależy w dużej mierze od tego, jak bardzo masz purystyczny punkt widzenia. Na przykład, najbardziej współczesny systemy RDBMS rzeczywistości nie stosować się do wszystkich z Edgar F. Codd „s 12 zasad jego modelu relacji !
Przyjmując pragmatyczne podejście, wydaje się, że CouchDB Apache jest najbliżej urzeczywistnienia zgodności z ACID, zachowując jednocześnie luźno powiązaną, nierelacyjną mentalność „NoSQL”.
+1 Nie jestem pewien, czy zgadzam się z brakiem ACID jako kluczową cechą „NoSQL”, ale naprawdę doceniam twoją opinię. Ostatecznie powinno to dotyczyć rozwiązania, które pasuje.
AJ.
2
Edytowałem (oczekuję na recenzję), aby było jeszcze bardziej zrozumiałe. W modelach danych NoSQL nie ma nic, co sugerowałoby, że transakcje ACID nie są możliwe. Niektóre systemy rozproszone NoSQL ich nie mają. Niektóre faktycznie nie mają żadnej „warstwy pośredniej”.
Eric Bloch
2
To nigdy nie było poprawne, a nawet straciło swoje źródło. Naprawdę powinien zostać usunięty.
Lennart Regebro
2
Cóż, najbardziej rażąco, to: „w skrócie, powiedziałbym, że jedną z głównych zalet magazynu danych„ NoSQL ”jest wyraźny brak właściwości ACID”. Sugerujesz również, że NoSQL i ACID w jakiś sposób wykluczają się wzajemnie, co jest zdecydowanie niepoprawne. To dobry przykład, kiedy duża liczba ignorantów głosuje za niewłaściwą odpowiedzią, ponieważ brzmi to rozsądnie. Większość baz danych NoSQL nie jest zgodnych z ACID głównie dlatego, że ludzie zaimplementowani nie wiedzieli, co to jest / dlaczego było to ważne / nie obchodziło ich.
Lennart Regebro
@LennartRegebro - nie sugerowałem niczego takiego. Większość obecnych, istniejących baz danych NoSQL rzeczywiście unikała zgodności z ACID na rzecz szybkości / wydajności i ostatecznej spójności. Jednak nigdy nie powiedziałem, że nie można mieć NoSQL ze zgodnością z ACID.
Przede wszystkim możemy wyróżnić dwa typy baz danych NoSQL:
Bazy danych zorientowane na agregaty;
Graficzne bazy danych (np. Neo4J).
Z założenia większość baz danych zorientowanych na wykresy to ACID !
A co z innymi typami?
W bazach danych zorientowanych na agregaty możemy umieścić trzy podtypy:
Bazy danych NoSQL oparte na dokumentach (np. MongoDB, CouchDB);
Bazy danych klucza / wartości NoSQL (np. Redis);
Bazy danych z rodziny kolumn NoSQL (np. Hibase, Cassandra).
To, co nazywamy tutaj Agregatem , jest tym, co Eric Evans zdefiniował w swoim projekcie opartym na domenie jako samowystarczalność jednostek i obiektów wartości w danym ograniczonym kontekście.
W konsekwencji agregat to zbiór danych, z którymi wchodzimy w interakcje jako jednostka. Agregaty tworzą granice operacji ACID z bazą danych. (Martin Fowler)
Tak więc na poziomie agregacji możemy powiedzieć, że większość baz danych NoSQL może być tak samo bezpieczna jak ACID RDBMS , z odpowiednimi ustawieniami. Ze źródła, jeśli dostroisz serwer pod kątem najlepszej szybkości, możesz wpaść na coś innego niż ACID. Ale replikacja pomoże.
Moim głównym celem jest to, że musisz używać baz danych NoSQL takimi, jakimi są, a nie (tanią) alternatywą dla RDBMS. Za dużo widziałem projektów nadużywających relacji między dokumentami. To nie może być ACID. Jeśli pozostajesz na poziomie dokumentu, tj. W granicach agregatu, nie potrzebujesz żadnej transakcji. Twoje dane będą tak samo bezpieczne, jak w przypadku bazy danych ACID, nawet jeśli nie jest to naprawdę ACID, ponieważ nie potrzebujesz tych transakcji! Jeśli potrzebujesz transakcji i aktualizujesz kilka "dokumentów" na raz, nie jesteś już w świecie NoSQL - więc użyj zamiast tego silnika RDBMS!
jakaś aktualizacja 2019: Począwszy od wersji 4.0, w sytuacjach, które wymagają atomowości w celu aktualizacji wielu dokumentów lub spójności między odczytami wielu dokumentów, MongoDB zapewnia transakcje wielodokumentowe dla zestawów replik .
Zdarzają się przypadki, gdy istnieje duży proces / saga, która obsługuje wiele agregatów. Istnieją przypadki, gdy polecenie wysłane do agregatu może wywołać pewne zdarzenia, które zmieniają inne agregacje. W takich przypadkach potrzebne są magazyny danych zgodne z ACID.
Tudor
1
@TudorTudor, ale w tym przypadku łamiesz jedną z zasad nosql, ponieważ używasz jej jako rdbms. Potrzebujesz tylko większych agregatów lub wersjonowania dokumentów (jak w couchdb). Nosql zorientowane na dokument bazy danych są kwasowe na granicach dokumentu / agregatu.
Arnaud Bouchez
Żadne z wymienionych przez Ciebie nie są zgodne z kwasami. Mongo po prostu nie jest zgodne z ACID. CouchDB udaje, że jest zgodny z kwasem, o ile nie aktualizujesz dwóch dokumentów. Redis ma tylko „częściową obsługę transakcji”. HBase po prostu nie jest zgodna z kwasami (od twórców), podobnie jak Cassandra. Ta odpowiedź jest w rzeczywistości po prostu błędna. Żadna z tych baz danych nie obsługuje ACID, a większość z nich otwarcie posiada go za pomocą prostego wyszukiwania w Google.
Evan Carroll
@EvanCarroll Nigdy nie pisałem, że MongoDB jest zgodny z ACID, w tym samym znaczeniu co w przypadku transakcji ACID RDBMS. Brak dostępnej transakcji. Napisałem, że większość baz danych NoSQL może być tak bezpieczna jak ACID RDBMS, z odpowiednimi ustawieniami . Na przykład sprawdź $ izolowany operator MongoDB dla bazy danych bez żadnego współużytkowanego klastra. Nigdy nie użyłbym MongoDB do procesu finansowego, ale mógłbym w pewnym stopniu zaufać jego procesowi zapisu, w przypadku operacji typu ACID, jeśli wystarczy A jak Atomicity. Przepraszam, jeśli moja odpowiedź jest zagmatwana.
Ma prawidłowe transakcje, dzięki czemu można aktualizować wiele różnych elementów danych w sposób ACID. Jest to podstawa do utrzymania indeksów w wyższej warstwie.
niestety nie jest to oprogramowanie typu open source. Ale wygląda na bardzo ładną bazę danych.
Kevin Cox
Aby dodać do odpowiedzi @ Ken-Tindell, djondb jest również NoSQL i implementuje transakcje oraz jest zgodny z ACID. djondb.com Zgadzam się, że NoSQL to po prostu określenie wszystkich baz danych, które nie są zgodne z tradycyjnymi zasadami RDBMS, nie oznacza to „pozbycia się systemów TX”, ani zapomnienia o związkach.
Cross
3
Moja odpowiedź stała się dyskusyjna po przejęciu Foundation DB przez Apple.
Ken Tindell
1
Foundationdb jest teraz open
source
17
W tym pytaniu ktoś musi wspomnieć o OrientDB : OrientDB to baza danych NoSQL, jedna z nielicznych, które w pełni obsługują transakcje ACID. ACID jest nie tylko dla RDBMS, ponieważ nie jest częścią algebry relacyjnej. Więc możliwe jest posiadanie bazy danych NoSQL obsługującej ACID.
ACID i NoSQL są całkowicie ortogonalne. Jedno nie implikuje drugiego.
Na biurku mam zeszyt, używam go do notowania rzeczy, które mam jeszcze do zrobienia. Ten notatnik jest bazą danych NoSQL. Odpowiadam za pomocą wyszukiwania liniowego z „pamięcią podręczną stron”, więc nie zawsze muszę przeszukiwać każdą stronę. Jest również zgodny z ACID, ponieważ zapewniam, że piszę tylko jedną rzecz na raz i nigdy podczas czytania.
NoSQL oznacza po prostu, że to nie jest SQL. Wiele osób jest zdezorientowanych i myśli, że oznacza to bardzo skalowalne, super szybkie przechowywanie z dzikim zachodem. Tak nie jest. Nie oznacza to przechowywania klucza i wartości ani ostatecznej spójności. Oznacza to tylko „nie SQL”, na tej planecie jest wiele baz danych, a większość z nich nie jest SQL [potrzebne źródło] .
Możesz znaleźć wiele przykładów w innych odpowiedziach, więc nie muszę ich tutaj wymieniać, ale istnieją bazy danych inne niż SQL zgodne z ACID dla różnych operacji, niektóre są tylko ACID dla zapisu pojedynczego obiektu, a niektóre gwarantują znacznie więcej. Każda baza danych jest inna.
@ shmish111 nie bardzo. Oznaczało to „brak języka SQL”, kiedy ten termin został wymyślony. „O” jest małe, w końcu nie duże. Później pojawiły się próby ponownego określenia terminu „nie tylko SQL”, gdy niektóre z nich (produkty NoSQL) zaczęły dodawać interfejsy języka zapytań podobne do SQL.
ypercubeᵀᴹ
11
„NoSQL” nie jest dobrze zdefiniowanym terminem. To bardzo niejasna koncepcja. W związku z tym nie można nawet powiedzieć, co jest, a co nie jest produktem „NoSQL”. Nie wszystkie produkty typowo oznaczone tą etykietą to sklepy z kluczową wartością.
Najlepsza odpowiedź. Kiedy kiedykolwiek pojawia się ta płomienna wojna, chciałbym zapytać drugą stronę, jakich definiujących funkcji wyraźnie wymagają z bazy danych NoSQL i często pokrywa się to z funkcjami, które mogą znaleźć w RDBMS - nie dlatego, że jeden lub RDBMS pasują do motywu NoSQL, ale po prostu dlatego, że ich „wymagania” funkcji są tak niejasne, że nie negują całkowicie funkcji występujących w (niekoniecznie wszystkich) RDMBS. +1 za Twój komentarz, kolego!
StartupGuy
8
Tak, MarkLogic Server to rozwiązanie NoSQL (baza dokumentów, którą lubię nazywać), które działa z transakcjami ACID
MarkLogic obsługuje transakcje ACID, transakcje wielodokumentowe, transakcje z wieloma wyciągami i obsługę XA - wszystkie w całym klastrze / rozproszone.
Dla tych, którzy chcą przejść z biblioteki Pythona „shelve”, ZODB wydaje mi się prawie bezsensowne. Nie musiałem ponownie pisać wszystkich moich funkcji - po prostu uzyskaj dostęp do ZODB jako słownika, tak jak na półce, ale jest to o rząd wielkości szybsze.
Michael Galaxy
8
Jako jeden z pomysłodawców NoSQL (byłem jednym z pierwszych współpracowników Apache CouchDB i prelegentem na pierwszym wydarzeniu NoSQL, które odbyło się w CBS Interactive / CNET w 2009 r.) Nie mogę się doczekać, gdy nowe algorytmy stworzą możliwości, których wcześniej nie było . Protokół Calvina oferuje nowy sposób myślenia o fizycznych ograniczeniach, takich jak CAP i PACELC .
Zamiast aktywnej / pasywnej replikacji asynchronicznej lub aktywnej / aktywnej replikacji synchronicznej, Calvin zachowuje poprawność i dostępność podczas przestojów repliki, używając protokołu podobnego do RAFT do prowadzenia dziennika transakcji. Ponadto transakcje są przetwarzane deterministycznie w każdej replice, co eliminuje potencjalne zakleszczenia, więc porozumienie jest osiągane tylko w jednej rundzie konsensusu. Dzięki temu jest szybki nawet w przypadku wdrożeń obejmujących wiele chmur na całym świecie.
FaunaDB to jedyna implementacja bazy danych wykorzystująca protokół Calvin, dzięki czemu jest wyjątkowo dostosowana do obciążeń, które wymagają integralności danych podobnej do mainframe ze skalą i elastycznością NoSQL.
Jeśli szukasz magazynu kluczy / wartości zgodnego z ACID, jest Berkeley DB . Spośród grafowych baz danych co najmniej Neo4j i HyperGraphDB oferują transakcje ACID (HyperGraphDB faktycznie używa obecnie Berkeley DB do przechowywania niskiego poziomu).
[…] Klasa nowoczesnych systemów zarządzania relacyjnymi bazami danych, które starają się zapewnić taką samą skalowalną wydajność jak systemy NoSQL do przetwarzania transakcji online (OLTP) w trybie odczytu i zapisu, zachowując jednocześnie gwarancje ACID tradycyjnego systemu baz danych.[1][2][3]
Tak, transakcje ACID obejmujące wiele dokumentów są teraz obsługiwane w MongoDB. Odwiedź stronę mongodb.com/transactions, aby uzyskać więcej informacji i szczegółowe filmy wideo o tym, jak zostały one wdrożone.
W przeciwieństwie do trwałości lub serializacji typu roll-your-own, db4o jest bezpieczny dla transakcji ACID i umożliwia wykonywanie zapytań, replikację i zmiany schematu w czasie wykonywania
Tarantool to w pełni ACID baza danych NoSQL. Możesz wydawać operacje CRUD lub procedury składowane, wszystko będzie uruchamiane w ścisłej zgodności z właściwością ACID. Możesz również o tym przeczytać tutaj: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
Czy Aerospike obsługuje transakcje ACID z wieloma kluczami? AKAIK ogranicza się do transakcji z jednym kluczem.
eonil
1
BergDB to lekka baza danych typu open source NoSQL zaprojektowana od początku do obsługi transakcji ACID. W rzeczywistości BergDB jest „bardziej” ACID niż większość baz danych SQL w tym sensie, że jedynym sposobem zmiany stanu bazy danych jest uruchamianie transakcji ACID z najwyższym poziomem izolacji (termin SQL: „serializowalny”). Nigdy nie będzie żadnych problemów z brudnymi odczytami, niepowtarzalnymi odczytami lub odczytami fantomowymi.
Moim zdaniem baza danych nadal jest bardzo wydajna; ale nie wierz mi, stworzyłem oprogramowanie. Zamiast tego spróbuj sam.
Wiele nowoczesnych rozwiązań NoSQL nie obsługuje transakcji ACID (atomowych, izolowanych aktualizacji z wieloma kluczami), ale większość z nich obsługuje prymitywy, które pozwalają na implementację transakcji na poziomie aplikacji.
Jeśli magazyn danych obsługuje linearyzację według klucza oraz porównywanie i ustawianie (atomowość na poziomie dokumentu), wystarczy zaimplementować transakcje po stronie klienta, a ponadto masz kilka opcji do wyboru:
Jeśli potrzebujesz poziomu izolacji z możliwością serializacji, możesz postępować zgodnie z tym samym algorytmem, którego Google używa dla systemu Percolator lub Cockroach Labs dla CockroachDB . Napisałem o tym na blogu i stworzyłem wizualizację krok po kroku , mam nadzieję, że pomoże ci ona zrozumieć główną ideę algorytmu.
Jeśli spodziewasz się dużej rywalizacji, ale możesz mieć poziom izolacji Read Committed, zapoznaj się z transakcjami RAMP przeprowadzonymi przez Petera Bailisa.
Trzecie podejście polega na wykorzystaniu transakcji kompensacyjnych zwanych również wzorcem sagi. Zostało to opisane pod koniec lat 80. w artykule Sagas, ale stało się bardziej aktualne wraz z rozwojem systemów rozproszonych. Aby uzyskać inspirację, zapoznaj się z wykładem Stosowanie wzoru sagi .
Lista magazynów danych odpowiednich dla transakcji po stronie klienta obejmuje Cassandrę z lekkimi transakcjami, Riak ze spójnymi zasobnikami, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB i inne.
Twórca VoltDB wspomniał, że nie określają siebie jako NoSql, ale bardziej jak NewSql (nadal używają Sql, ale z lepszą implementacją niż te RDBM zbudowane w latach osiemdziesiątych)
Matt W
0
Chociaż jest to tylko wbudowany silnik, a nie serwer, leveldb ma WriteBatch i możliwość włączenia synchronicznych zapisów, aby zapewnić zachowanie ACID.
Nie tylko NoSQL nie jest zgodne z ACID z założenia. Ruch NoSQL obejmuje BASE (zasadniczo dostępny, stan miękki, ostateczna spójność), który jest uważany za przeciwieństwo ACID. Bazy danych NoSQL są często nazywane bazami danych ostatecznych. Aby zrozumieć różnice, należy przejść do twierdzenia CAP (znanego również jako twierdzenie Brewera)
Myślę, że wskaźnik do twierdzenia CAP jest bardzo istotny dla tego pytania!
mxro,
2
Niektóre bazy danych NoSQL mają transakcje ACID.
Eric Bloch,
1
Niektóre noSQL twierdzą, że są zgodne z ACID, ale kiedy zagłębisz się w środku, odkryjesz, że tylko w niektórych szczególnych przypadkach są to ACID, więc IMHO, ponieważ nie ma `` ostatecznie ACID '', zdecydowanie nie są ACID
Ste
1
Zasadniczo niewłaściwie stosujesz CAP. CAP i ACID są w najlepszym przypadku luźno powiązane, ale CAP nie zapobiega temu, by system rozproszony był zgodny z ACID. CAP opisuje wymagane kompromisy w systemie rozproszonym - system NoSQL, który jest silnie spójny, może być niedostępny podczas partycji, ale to nie wyklucza, że jest zgodny z ACID.
Odpowiedzi:
Opublikuję to jako odpowiedź wyłącznie w celu wsparcia rozmowy - Tim Mahy , nawroth i CraigTP zasugerowali opłacalne bazy danych. CouchDB byłby moim ulubionym ze względu na użycie Erlanga , ale są tam inne.
Powiedziałbym, że ACID nie zaprzecza ani nie neguje koncepcji NoSQL ... Chociaż wydaje się, że istnieje trend podążający za opinią wyrażoną przez gołębia , uważam, że koncepcje są różne.
NoSQL zasadniczo dotyczy prostego schematu klucz-wartość (np. Redis) lub schematu w stylu dokumentu (zebrane pary klucz-wartość w modelu „dokumentu”, np. MongoDB) jako bezpośredniej alternatywy dla jawnego schematu w klasycznych RDBMS. Pozwala programistom traktować rzeczy asymetrycznie, podczas gdy tradycyjne silniki wymuszały sztywną identyczność w modelu danych. Jest to tak interesujące, ponieważ zapewnia inny sposób radzenia sobie ze zmianami , aw przypadku większych zestawów danych zapewnia interesujące możliwości radzenia sobie z wolumenami i wydajnością.
ACID zawiera zasady regulujące sposób wprowadzania zmian w bazie danych. W bardzo uproszczony sposób stwierdza (moja własna wersja):
Rozmowa staje się trochę bardziej pobudzająca, jeśli chodzi o ideę propagacji i ograniczeń . Niektóre silniki RDBMS zapewniają możliwość wymuszania ograniczeń (np. Kluczy obcych), które mogą mieć elementy propagacji (a la cascade ). Mówiąc prościej, jedna „rzecz” może mieć związek z inną „rzeczą” w bazie danych, a jeśli zmienisz atrybut jednej z nich, może to wymagać zmiany drugiej (zaktualizowanie, usunięcie,… wiele opcji). Bazy danych NoSQL , skupione głównie (w tej chwili) na dużych ilościach danych i dużym ruchu, wydają się rozwiązywać problem rozproszonych aktualizacji, które mają miejsce (z punktu widzenia konsumenta) w dowolnych ramach czasowych. Jest to w zasadzie wyspecjalizowana forma replikacji zarządzana przeztransakcja - więc powiedziałbym, że jeśli tradycyjna rozproszona baza danych może obsługiwać ACID, to również baza danych NoSQL.
Niektóre źródła do dalszego czytania:
źródło
AKTUALIZACJA (27 lipca 2012 r.): Link do artykułu w Wikipedii został zaktualizowany w celu odzwierciedlenia wersji artykułu, która była aktualna w momencie opublikowania tej odpowiedzi. Zwróć uwagę, że aktualny artykuł w Wikipedii został gruntownie poprawiony!
Cóż, zgodnie ze starszą wersją artykułu Wikipedii na temat NoSQL :
i również:
i
Tak, w skrócie, powiedziałbym, że jedną z głównych korzyści z „NoSQL” magazynu danych jest jego wyraźny brak z ACID właściwości. Co więcej, IMHO, im bardziej ktoś próbuje zaimplementować i wymusić właściwości ACID , tym dalej znajdujesz się od "ducha" magazynu danych "NoSQL" i im bliżej "prawdziwego" RDBMS (mówiąc względnie, oczywiście ).
Jednak wszystko, co zostało powiedziane, „NoSQL” jest terminem bardzo niejasnym i otwartym na indywidualne interpretacje i zależy w dużej mierze od tego, jak bardzo masz purystyczny punkt widzenia. Na przykład, najbardziej współczesny systemy RDBMS rzeczywistości nie stosować się do wszystkich z Edgar F. Codd „s 12 zasad jego modelu relacji !
Przyjmując pragmatyczne podejście, wydaje się, że CouchDB Apache jest najbliżej urzeczywistnienia zgodności z ACID, zachowując jednocześnie luźno powiązaną, nierelacyjną mentalność „NoSQL”.
źródło
Należy upewnić się Państwo zapoznać się z ogólnymi Martin Fowler o bazach NoSQL . I odpowiedni film.
Przede wszystkim możemy wyróżnić dwa typy baz danych NoSQL:
Z założenia większość baz danych zorientowanych na wykresy to ACID !
A co z innymi typami?
W bazach danych zorientowanych na agregaty możemy umieścić trzy podtypy:
To, co nazywamy tutaj Agregatem , jest tym, co Eric Evans zdefiniował w swoim projekcie opartym na domenie jako samowystarczalność jednostek i obiektów wartości w danym ograniczonym kontekście.
Tak więc na poziomie agregacji możemy powiedzieć, że większość baz danych NoSQL może być tak samo bezpieczna jak ACID RDBMS , z odpowiednimi ustawieniami. Ze źródła, jeśli dostroisz serwer pod kątem najlepszej szybkości, możesz wpaść na coś innego niż ACID. Ale replikacja pomoże.
Moim głównym celem jest to, że musisz używać baz danych NoSQL takimi, jakimi są, a nie (tanią) alternatywą dla RDBMS. Za dużo widziałem projektów nadużywających relacji między dokumentami. To nie może być ACID. Jeśli pozostajesz na poziomie dokumentu, tj. W granicach agregatu, nie potrzebujesz żadnej transakcji. Twoje dane będą tak samo bezpieczne, jak w przypadku bazy danych ACID, nawet jeśli nie jest to naprawdę ACID, ponieważ nie potrzebujesz tych transakcji! Jeśli potrzebujesz transakcji i aktualizujesz kilka "dokumentów" na raz, nie jesteś już w świecie NoSQL - więc użyj zamiast tego silnika RDBMS!
jakaś aktualizacja 2019: Począwszy od wersji 4.0, w sytuacjach, które wymagają atomowości w celu aktualizacji wielu dokumentów lub spójności między odczytami wielu dokumentów, MongoDB zapewnia transakcje wielodokumentowe dla zestawów replik .
źródło
FoundationDB jest zgodna z ACID:
http://www.foundationdb.com/
Ma prawidłowe transakcje, dzięki czemu można aktualizować wiele różnych elementów danych w sposób ACID. Jest to podstawa do utrzymania indeksów w wyższej warstwie.
źródło
W tym pytaniu ktoś musi wspomnieć o OrientDB : OrientDB to baza danych NoSQL, jedna z nielicznych, które w pełni obsługują transakcje ACID. ACID jest nie tylko dla RDBMS, ponieważ nie jest częścią algebry relacyjnej. Więc możliwe jest posiadanie bazy danych NoSQL obsługującej ACID.
Tej funkcji brakuje mi najbardziej w MongoDB
źródło
ACID i NoSQL są całkowicie ortogonalne. Jedno nie implikuje drugiego.
Na biurku mam zeszyt, używam go do notowania rzeczy, które mam jeszcze do zrobienia. Ten notatnik jest bazą danych NoSQL. Odpowiadam za pomocą wyszukiwania liniowego z „pamięcią podręczną stron”, więc nie zawsze muszę przeszukiwać każdą stronę. Jest również zgodny z ACID, ponieważ zapewniam, że piszę tylko jedną rzecz na raz i nigdy podczas czytania.
NoSQL oznacza po prostu, że to nie jest SQL. Wiele osób jest zdezorientowanych i myśli, że oznacza to bardzo skalowalne, super szybkie przechowywanie z dzikim zachodem. Tak nie jest. Nie oznacza to przechowywania klucza i wartości ani ostatecznej spójności. Oznacza to tylko „nie SQL”, na tej planecie jest wiele baz danych, a większość z nich nie jest SQL [potrzebne źródło] .
Możesz znaleźć wiele przykładów w innych odpowiedziach, więc nie muszę ich tutaj wymieniać, ale istnieją bazy danych inne niż SQL zgodne z ACID dla różnych operacji, niektóre są tylko ACID dla zapisu pojedynczego obiektu, a niektóre gwarantują znacznie więcej. Każda baza danych jest inna.
źródło
„NoSQL” nie jest dobrze zdefiniowanym terminem. To bardzo niejasna koncepcja. W związku z tym nie można nawet powiedzieć, co jest, a co nie jest produktem „NoSQL”. Nie wszystkie produkty typowo oznaczone tą etykietą to sklepy z kluczową wartością.
źródło
Tak, MarkLogic Server to rozwiązanie NoSQL (baza dokumentów, którą lubię nazywać), które działa z transakcjami ACID
źródło
Dziadek NoSQL: ZODB jest zgodny z ACID. http://www.zodb.org/
Jednak jest to tylko Python.
źródło
Jako jeden z pomysłodawców NoSQL (byłem jednym z pierwszych współpracowników Apache CouchDB i prelegentem na pierwszym wydarzeniu NoSQL, które odbyło się w CBS Interactive / CNET w 2009 r.) Nie mogę się doczekać, gdy nowe algorytmy stworzą możliwości, których wcześniej nie było . Protokół Calvina oferuje nowy sposób myślenia o fizycznych ograniczeniach, takich jak CAP i PACELC .
Zamiast aktywnej / pasywnej replikacji asynchronicznej lub aktywnej / aktywnej replikacji synchronicznej, Calvin zachowuje poprawność i dostępność podczas przestojów repliki, używając protokołu podobnego do RAFT do prowadzenia dziennika transakcji. Ponadto transakcje są przetwarzane deterministycznie w każdej replice, co eliminuje potencjalne zakleszczenia, więc porozumienie jest osiągane tylko w jednej rundzie konsensusu. Dzięki temu jest szybki nawet w przypadku wdrożeń obejmujących wiele chmur na całym świecie.
FaunaDB to jedyna implementacja bazy danych wykorzystująca protokół Calvin, dzięki czemu jest wyjątkowo dostosowana do obciążeń, które wymagają integralności danych podobnej do mainframe ze skalą i elastycznością NoSQL.
źródło
Jeśli szukasz magazynu kluczy / wartości zgodnego z ACID, jest Berkeley DB . Spośród grafowych baz danych co najmniej Neo4j i HyperGraphDB oferują transakcje ACID (HyperGraphDB faktycznie używa obecnie Berkeley DB do przechowywania niskiego poziomu).
źródło
NewSQL
Tę koncepcję autorzy Wikipedii definiują jako:
Bibliografia
[1]Nancy Lynch i Seth Gilbert, „Hipoteza Brewera i wykonalność spójnych, dostępnych usług sieciowych odpornych na partycje” , ACM SIGACT News, tom 33, wydanie 2 (2002), str. 51-59.[2]„Brewer's CAP Theorem” , julianbrowne.com, Źródło 02-Mar-2010[3]"Brewers CAP Twierdzenie o systemach rozproszonych" , royans.netźródło
MongoDB ogłosił, że jego wersja 4.0 będzie zgodna z ACID dla transakcji obejmujących wiele dokumentów.
Wersja 4.2.0 ma wspierać go w konfiguracjach podzielonych na fragmenty.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
źródło
Wspomniano o FoundationDB, która w tamtym czasie nie była oprogramowaniem typu open source. Został udostępniony przez Apple dwa dni temu: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Uważam, że jest zgodny z ACID.
źródło
spójrz na twierdzenie CAP
EDYCJA: RavenDB wydaje się być zgodne z ACID
źródło
Aby dodać do listy alternatyw, inna baza danych NoSQL ACID pełni zgodny jest GT.M .
źródło
Hyperdex Warp http://hyperdex.org/warp/ Warp (funkcja ACID) jest zastrzeżony, ale Hyperdex jest bezpłatny.
źródło
db4o
http://www.db4o.com/about/productinformation/db4o/
źródło
Tarantool to w pełni ACID baza danych NoSQL. Możesz wydawać operacje CRUD lub procedury składowane, wszystko będzie uruchamiane w ścisłej zgodności z właściwością ACID. Możesz również o tym przeczytać tutaj: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
źródło
MarkLogic jest również zgodny z ACID. Myślę, że jest teraz jednym z największych graczy.
źródło
Czekaj skończone.
Zgodna z ACID baza danych NoSQL jest niedostępna ----------- spójrz na citrusleaf
źródło
BergDB to lekka baza danych typu open source NoSQL zaprojektowana od początku do obsługi transakcji ACID. W rzeczywistości BergDB jest „bardziej” ACID niż większość baz danych SQL w tym sensie, że jedynym sposobem zmiany stanu bazy danych jest uruchamianie transakcji ACID z najwyższym poziomem izolacji (termin SQL: „serializowalny”). Nigdy nie będzie żadnych problemów z brudnymi odczytami, niepowtarzalnymi odczytami lub odczytami fantomowymi.
Moim zdaniem baza danych nadal jest bardzo wydajna; ale nie wierz mi, stworzyłem oprogramowanie. Zamiast tego spróbuj sam.
źródło
Wiele nowoczesnych rozwiązań NoSQL nie obsługuje transakcji ACID (atomowych, izolowanych aktualizacji z wieloma kluczami), ale większość z nich obsługuje prymitywy, które pozwalają na implementację transakcji na poziomie aplikacji.
Jeśli magazyn danych obsługuje linearyzację według klucza oraz porównywanie i ustawianie (atomowość na poziomie dokumentu), wystarczy zaimplementować transakcje po stronie klienta, a ponadto masz kilka opcji do wyboru:
Jeśli potrzebujesz poziomu izolacji z możliwością serializacji, możesz postępować zgodnie z tym samym algorytmem, którego Google używa dla systemu Percolator lub Cockroach Labs dla CockroachDB . Napisałem o tym na blogu i stworzyłem wizualizację krok po kroku , mam nadzieję, że pomoże ci ona zrozumieć główną ideę algorytmu.
Jeśli spodziewasz się dużej rywalizacji, ale możesz mieć poziom izolacji Read Committed, zapoznaj się z transakcjami RAMP przeprowadzonymi przez Petera Bailisa.
Trzecie podejście polega na wykorzystaniu transakcji kompensacyjnych zwanych również wzorcem sagi. Zostało to opisane pod koniec lat 80. w artykule Sagas, ale stało się bardziej aktualne wraz z rozwojem systemów rozproszonych. Aby uzyskać inspirację, zapoznaj się z wykładem Stosowanie wzoru sagi .
Lista magazynów danych odpowiednich dla transakcji po stronie klienta obejmuje Cassandrę z lekkimi transakcjami, Riak ze spójnymi zasobnikami, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB i inne.
źródło
YugaByte DB obsługuje rozproszone txns zgodne z ACID, a także zgodność z Redis i CQL API w warstwie zapytań.
źródło
VoltDB jest uczestnikiem, który twierdzi, że jest zgodny z ACID i chociaż nadal używa SQL, jego cele są takie same pod względem skalowalności
źródło
Chociaż jest to tylko wbudowany silnik, a nie serwer, leveldb ma WriteBatch i możliwość włączenia synchronicznych zapisów, aby zapewnić zachowanie ACID.
źródło
Węzeł levelUP jest transakcyjny i zbudowany na leveldb https://github.com/rvagg/node-levelup#batch
źródło
Google Cloud Datastore to baza danych NoSQL obsługująca transakcje ACID
źródło
DynamoDB jest bazą danych NoSQL i zawiera transakcje ACID .
źródło
Nie tylko NoSQL nie jest zgodne z ACID z założenia. Ruch NoSQL obejmuje BASE (zasadniczo dostępny, stan miękki, ostateczna spójność), który jest uważany za przeciwieństwo ACID. Bazy danych NoSQL są często nazywane bazami danych ostatecznych. Aby zrozumieć różnice, należy przejść do twierdzenia CAP (znanego również jako twierdzenie Brewera)
Odwiedź http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
źródło