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:
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 :
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”.
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.
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 .
FoundationDB jest zgodna z ACID:
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.
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
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.
„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ą.
Tak, MarkLogic Server to rozwiązanie NoSQL (baza dokumentów, którą lubię nazywać), które działa z transakcjami ACID
Dziadek NoSQL: ZODB jest zgodny z ACID. http://www.zodb.org/
Jednak jest to tylko Python.
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).
Tę koncepcję autorzy Wikipedii definiują jako:
[…] 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]
[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
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
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.
Aby dodać do listy alternatyw, inna baza danych NoSQL ACID pełni zgodny jest GT.M .
Hyperdex Warp http://hyperdex.org/warp/ Warp (funkcja ACID) jest zastrzeżony, ale Hyperdex jest bezpłatny.
db4o
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
MarkLogic jest również zgodny z ACID. Myślę, że jest teraz jednym z największych graczy.
Czekaj skończone.
Zgodna z ACID baza danych NoSQL jest niedostępna ----------- spójrz na citrusleaf
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.
YugaByte DB obsługuje rozproszone txns zgodne z ACID, a także zgodność z Redis i CQL API w warstwie zapytań.
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
Węzeł levelUP jest transakcyjny i zbudowany na leveldb https://github.com/rvagg/node-levelup#batch
DynamoDB jest bazą danych NoSQL i zawiera transakcje 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)
Odwiedź http://www.julianbrowne.com/article/viewer/brewers-cap-theorem