Transaktionen in NoSQL?

77

Ich suche in NoSQL nach Skalierungsalternativen für eine Datenbank. Was mache ich, wenn ich transaktionsbasierte Dinge möchte, die für diese Art von Dingen empfindlich sind?

transactions  nosql 
— Timmy
quelle
3
Zu Ihrer Information ... NoSQL-Datenbanken sind immer noch DBs, sie sind einfach nicht relational. In Bezug auf die Transaktionen ist eine Transaktion einfach die logische Gruppierung von Abfragen und Aktualisierungen. Nicht relationale DBs bieten weiterhin beide Funktionen. Welche Art von Dingen reagieren empfindlich auf welche Dinge?
— Joejoeson
1
Nun, ich möchte Geldtransaktionen durchführen oder zumindest darüber nachdenken. aber ich möchte immer noch etwas Integrität in diesem Sinne.
— Timmy
3
Wie viele Terabyte Daten haben Sie, die Sie nicht für ein Standard-Mainstream-RDBMS mit integrierter Transaktionsunterstützung verwenden können?
— Gbn
@gbn Die Anzahl der TB an Daten hat nichts mit der Notwendigkeit zu tun, NoSQL-DBs zu verwenden. Vielleicht möchte er das EAV-Modell in seiner relationalen Datenbank loswerden.
— Grün

Antworten:

41

Im Allgemeinen haben NoSQL-Lösungen eine geringere Transaktionssemantik als relationale Datenbanken, verfügen jedoch auf einer bestimmten Ebene über Funktionen für atomare Operationen.

Im Allgemeinen bieten diejenigen, die eine Master-Master-Replikation durchführen, weniger Konsistenz und mehr Verfügbarkeit. Man sollte also das richtige Werkzeug für das richtige Problem wählen.

Viele bieten Transaktionen auf der Ebene einzelner Dokumente (oder Zeilen usw.) an. Zum Beispiel gibt es bei MongoDB Atomizität im einzelnen Dokument - aber Dokumente können ziemlich umfangreich sein, so dass dies normalerweise ziemlich gut funktioniert - mehr Infos hier .

— dm.
quelle
5
Einige NoSQL-Datenbanken wie MarkLogic bieten tatsächlich echte ACID-Transaktionen.
— Eric Bloch
5
RavenDB bietet auch echte ACID-Transaktionen.
— Matt Johnson-Pint
5
FoundationDB bietet auch ACID-Transaktionen mit mehreren Schlüsseln in Clustern mit mehreren Knoten.
— Eonil
5
Neo4j ist ein NoSQL-Speicher und bietet ACID-Eigenschaften.
— Nadjib Mami
3
RavenDB bietet keine echten ACID-Transaktionen. Es wird eine schwache Form der Isolation verwendet, die als "Snapshot-Isolation" bezeichnet wird. Es bietet globale Transaktionen über einen externen Koordinator, von der Verwendung wird jedoch abgeraten. Foundationdb.com/acid-claims
— Akira Yamamoto
18

Dies ist die nächste Antwort, die ich gefunden habe und die für jede NoSQL-Datenbank gelten würde. Es ist in einem Blog-Beitrag von 2007 von Adam Wiggins von Heroku.com:

Das alte Beispiel für die Verwendung einer Datenbanktransaktion, um die Überweisung von Geld von einem Bankkonto auf ein anderes zu verpacken, ist Total Bull. Die richtige Lösung besteht darin, eine Liste der Ledger-Ereignisse (Übertragungen zwischen Konten) zu speichern und den aktuellen Saldo als Summe des Ledgers anzuzeigen. Wenn Sie in einer funktionalen Sprache programmieren (oder so denken), ist dies offensichtlich.

Von: http://adam.heroku.com/past/2007/12/17/a_world_without_sql/ (Seine Website eignet sich hervorragend für Ideen zur Skalierbarkeit.)

Ich habe den obigen Absatz wie folgt interpretiert:

  1. Erstellen Sie eine Datenbank für Mitgliedskonten.
  2. Erstellen Sie eine Messaging-Warteschlange. Spitzname es "Hauptbuch".
  3. Fügen Sie Hintergrund-Worker hinzu, um jede Anforderung in der Warteschlange zu erfüllen.

Mehr Info. zu Warteschlangen / Hintergrundarbeitern: http://adam.heroku.com/past/2009/4/14/building_a_queuebacked_feed_reader_part_1/

Der Kunde (auch bekannt als Mitglied oder Kunde) führt die folgenden Schritte aus, um Geld herauszunehmen:

  1. Senden Sie eine Anfrage, um Geld herauszunehmen.
  2. Die Anfrage wird an den Server gesendet.
  3. Der Server stellt es in eine Warteschlange. Die Nachricht lautet: "Nehmen Sie 5.000 US-Dollar heraus."
  4. Dem Kunden wird angezeigt: "Bitte warten Sie, bis die Anfrage erfüllt ist ..."
  5. Client-Computer fragen den Server alle 2 Sekunden ab und fragen: "Wurde die Anforderung erfüllt?"
  6. Auf dem Server erfüllen Hintergrundmitarbeiter frühere Anforderungen anderer Mitglieder auf First-In / First-Out-Weise. Schließlich erhalten sie die Anfrage Ihres Kunden, Geld herauszunehmen.
  7. Sobald die Anfrage erfüllt wurde, erhält der Kunde eine Nachricht mit seinem neuen Kontostand.

Sie können Heroku.com verwenden, um schnell ein kleines Modell zu erstellen, wenn Sie mit Node.js oder Ruby / Rack vertraut sind.

Die allgemeine Idee scheint ziemlich einfach und viel besser zu sein als die Verwendung von in die Datenbank eingebrannten Transaktionen, die die Skalierung sehr schwierig machen.

Haftungsausschluss: Ich habe dies noch nicht implementiert. Ich habe aus Neugier über diese Dinge gelesen, obwohl ich sie praktisch nicht brauche. Ja, @gbn hat Recht, dass ein RDBMS mit Transaktionen wahrscheinlich für die Bedürfnisse von Timmy und mir ausreichen würde. Trotzdem würde es Spaß machen zu sehen, wie weit Sie NoSQL-Datenbanken mit Open-Source-Tools und einer How-to-Website namens " A Tornado of Razorblades " bringen können.

— da01
quelle
35
Scheint eine seltsame Kritik am Beispiel der "Hallo Welt" für Transaktionen zu sein. Was passiert, wenn beim Erstellen eines der "Ledger-Ereignisse" etwas fehlschlägt? Dann wäre der Kontostand für dieses Konto falsch. Dies klingt für mich nicht nach einem praktikablen Ersatz für Transaktionen.
— a_horse_with_no_name
21
Die verlinkte Webseite zeigt ein erstaunliches Maß an Unkenntnis über die Notwendigkeit von ACID in praktisch allen Finanzsystemen. Erstens spricht der Artikel für "Leistung", während er die Leistungskosten ignoriert, die entstehen, wenn JEDE EINZELNE TRANSAKTION aus dem Verlauf gelesen werden muss, um eine neue Transaktion zu verarbeiten. Zweitens, und was noch wichtiger ist, wie funktioniert diese Lösung in einem Fall, in dem CONCURRENT-Anforderungen auf demselben Konto ausgeführt werden und ein Geschäftsvorgang aus Aktualisierungen mehrerer Entitäten besteht? Was passiert, wenn der Server mitten in der Verarbeitung stirbt?
— Andrew nicht der Heilige
2
Hier geht es um zweiphasige Commits. Google herum und Sie werden sehen, dass Sie Konsistenz ohne Transaktionen erhalten können.
— Papipo
2
Andrew, was passiert, wenn Ihre Kartentransaktion auf halbem Weg fehlschlägt? Haben Sie jemals einen Kontoauszug mit einer umgekehrten Transaktion gesehen?
— Alistair
16

NoSQL deckt eine Vielzahl von Tools und Diensten ab, darunter Schlüsselwert-, Dokument-, Grafik- und Breitspaltenspeicher. Sie versuchen normalerweise, die Skalierbarkeit des Datenspeichers zu verbessern, indem sie normalerweise die Datenverarbeitung verteilen. Transaktionen erfordern ACID- Eigenschaften für die Ausführung von Benutzeroperationen durch DBs. ACID schränkt ein, wie die Skalierbarkeit verbessert werden kann: Die meisten NoSQL-Tools lockern die Konsistenzkriterien der Operationen, um Fehlertoleranz und Verfügbarkeit für die Skalierung zu erhalten, was die Implementierung von ACID-Transaktionen sehr schwierig macht.

Eine häufig zitierte theoretische Argumentation für verteilte Datenspeicher ist das CAP-Theorem : Konsistenz, Verfügbarkeit und Partitionstoleranz können nicht gleichzeitig erreicht werden. SQL-, NoSQL- und NewSQL-Tools können nach dem, was sie aufgeben, klassifiziert werden. Eine gute Figur könnte hier gefunden werden .

Eine neue, schwächere Reihe von Anforderungen, die ACID ersetzen, ist BASE ("grundsätzlich verfügbar, weicher Zustand, eventuelle Konsistenz"). Eventuell konsistente Tools ("eventuell geben alle Zugriffe auf einen Artikel den zuletzt aktualisierten Wert zurück") sind in Transaktionsanwendungen wie dem Bankgeschäft jedoch kaum akzeptabel. Hier wäre eine gute Idee, speicherinterne, spaltenorientierte und verteilte SQL / ACID-Datenbanken zu verwenden, zum Beispiel VoltDB ; Ich schlage vor, sich diese "NewSQL" -Lösungen anzusehen.

— csaba
quelle
"Die meisten dieser Tools geben die Konsistenz und damit die ACID auf" Es scheint, Sie verwechseln die Gewissenhaftigkeit wie bei ACID mit der Konsistenz wie bei CAP. C in CAP bedeutet, dass alle Replikate der Daten gleich sind. während C in ACID ein vager und mehrdeutiger Begriff ist ... im Allgemeinen widerspricht die Verfügbarkeit ACID nicht. Ein Beispiel für Google Spinner beweist es.
— Alexey
Die ACID-Konsistenz erfordert, dass Transaktionen, da eine Reihe von Client-Vorgängen nur aus gültigen Datenbankzuständen stammen und in diesen enden können. Es ist nur ähnlich wie C in der GAP, also ist das richtig, diese sind nicht gleich und widersprechen sich nicht. Es ist nur sehr schwer, ACID-Transaktionen in einem AP-System zu implementieren, was normalerweise aus Gründen der Skalierbarkeit angenommen wird. Ich formuliere meine Antwort neu. Wenn ich jetzt zurückblicke, finde ich, dass der CAP-Satz und die CAP-Kategorien zu vage waren und keine wirkliche Hilfe bei der Kategorisierung dieser Tools bieten. Ich denke, CAP bleibt nur ein interessantes theoretisches Beispiel für verteilte Systemdesign-Kompromisse.
— Csaba
13

Ich wollte nur zu Geldtransaktionsratschlägen zu diesem Thread Stellung nehmen. Transaktionen sind etwas, das Sie wirklich für Geldtransfers verwenden möchten.

Das Beispiel, wie die Überweisungen durchgeführt werden, ist sehr schön und ordentlich.

Im wirklichen Leben kann die Überweisung von Geld jedoch Gebühren oder Zahlungen auf andere Konten beinhalten. Personen erhalten Boni für die Verwendung bestimmter Karten, die von einem anderen Konto stammen, oder sie erhalten Gebühren von ihrem Konto auf ein anderes Konto im selben System. Die Gebühren oder Zahlungen können je nach Finanztransaktion variieren, und Sie müssen möglicherweise ein Buchhaltungssystem einrichten, das die Gutschrift und Belastung jeder Transaktion sofort anzeigt.

Dies bedeutet, dass Sie mehr als eine Zeile gleichzeitig aktualisieren möchten, da das Guthaben auf einem Konto auf einem oder mehreren Konten abgebucht werden kann. Zuerst sperren Sie die Zeilen, damit sich vor dem Update nichts ändern kann, und stellen dann sicher, dass die geschriebenen Daten mit der Transaktion übereinstimmen.

Deshalb möchten Sie wirklich Transaktionen verwenden. Wenn beim Schreiben in eine Zeile etwas schief geht, können Sie eine ganze Reihe von Aktualisierungen rückgängig machen, ohne dass die Finanztransaktionsdaten inkonsistent enden.

— Zahlungsingenieur
quelle
1
Es gibt andere, wohl bessere Möglichkeiten, um mit den Nebenwirkungen der Transaktion umzugehen. Die Transaktion ist das ursprüngliche Ereignis. Solange sie atomar aufgezeichnet wird, kann jeder andere Fehler oder jedes andere Problem auf dieses Ereignis zurückgeführt werden.
— Chris Nicola
6

Das Problem bei einer Transaktion und zwei Vorgängen (z. B. einer zahlt 5.000 USD, der zweite erhält 5.000 USD) besteht darin, dass Sie zwei Konten mit derselben Priorität haben. Sie können nicht ein Konto verwenden, um das zweite zu bestätigen (oder in umgekehrter Reihenfolge). In diesem Fall können Sie garantieren, dass nur ein Konto korrekt ist (das bestätigt wird), das zweite (das bestätigt) möglicherweise fehlgeschlagen ist. Schauen wir uns an, warum es fehlschlagen kann (mit der Nachricht aproatch wird der Absender vom Empfänger bestätigt):

  1. Schreiben Sie + $ 5.000 auf das Empfängerkonto
  2. Wenn Erfolg - schreiben Sie - $ 5.000 auf das Absenderkonto
  3. Wenn dies fehlschlägt, versuchen Sie es erneut oder brechen Sie die Nachricht ab oder zeigen Sie sie an

Es wird garantiert, bis auf # 1. Aber wer garantiert, wenn # 2 fehlschlägt? Gleiches gilt in umgekehrter Reihenfolge.

Dies ist jedoch möglich, um ohne Transaktionen und mit NoSQL sicher zu sein. Sie dürfen immer eine dritte Entität verwenden, die von Sender- und Empfängerseite bestätigt wird, und garantieren, dass Ihre Operation ausgeführt wurde:

  1. Generieren einer eindeutigen Transaktions-ID und Erstellen einer Transaktionsentität
  2. Schreiben Sie + $ 5.000 auf das Empfängerkonto (unter Bezugnahme auf die Transaktions-ID).
  3. Bei Erfolg - Status der zu sendenden Transaktion festlegen
  4. Schreiben - 5.000 USD auf das Konto eines sedierten Kontos (unter Bezugnahme auf die Transaktions-ID)
  5. Bei Erfolg - Status der zu empfangenden Transaktion festlegen

Dieser Transaktionsdatensatz garantiert, dass das Senden / Empfangen von Massagen in Ordnung war. Jetzt können Sie jede Nachricht anhand der Transaktions-ID überprüfen. Wenn der Status empfangen oder abgeschlossen wurde, berücksichtigen Sie dies für das Benutzerguthaben.

— alexey28
quelle
1
Was ist, wenn die Schritte 3 und 5 fehlschlagen? Dies erhöht die Komplexität, weshalb DB-Transaktionen so nützlich sind.
— Fähigkeit M2
Normalerweise verlässt sich ein solches System nie nur auf die SQL-Fähigkeit, eine Transaktion zu validieren. Und auch in realen Szenarien erfolgen Kredit- und Debitgeschäfte meist über Zeit- und Bankgeschäfte hinweg - was über SQL- oder NOSQL-Funktionen hinausgeht. Dies kann nur durch eine gut gestaltete Architektur sichergestellt werden, die für Transaktionen innerhalb eines Systems oder über Systeme hinweg reibungslos funktioniert die Systeme.
— Kalpesh Popat
Ich finde diesen Ansatz gut. Wir müssen jedoch auch daran denken, die Transaktionsteile verteilt auszuführen (ein Teil läuft beispielsweise in Mikrodienst 1 und ein anderer Teil beispielsweise in Mikrodienst 2, der auf einem Server in einer anderen Domäne in der Cloud ausgeführt wird ). Ohne eine Art Hintergrundjob, der diese Transaktionen verarbeitet, indem der Status der zugeordneten Datensätze auf mehreren Servern entsprechend festgelegt wird, sind die verteilten Transaktionen in NoSQL schwierig (aber unvermeidlich).
— Prasad
1

Sie können in einer SQL-Datenbank immer einen NoSQL-Ansatz verwenden. NoSQL scheint im Allgemeinen "Schlüssel- / Wertdatenspeicher" zu verwenden: Sie können dies jederzeit in Ihrem bevorzugten RDBMS implementieren und somit die guten Dinge wie Transaktionen, ACID-Eigenschaften, Unterstützung durch Ihren benutzerfreundlichen DBA usw. beibehalten, während Sie die Vorteile von NoSQL-Leistung und Flexibilität realisieren zB über eine Tabelle wie

CREATE TABLE MY_KEY_VALUE_DATA
(
    id_content INTEGER PRIMARY KEY,
    b_content  BLOB
);

Der Bonus ist, dass Sie hier zusätzliche Felder hinzufügen können, um Ihren Inhalt in andere, ordnungsgemäß relationale Tabellen zu verlinken, während Ihr umfangreicher Inhalt weiterhin im Hauptfeld BLOB (oder TEXT, falls zutreffend) verbleibt.

Persönlich bevorzuge ich eine TEXT-Darstellung, damit Sie nicht an eine Sprache für die Arbeit mit den Daten gebunden sind. Wenn Sie beispielsweise serialisiertes Java verwenden, können Sie beispielsweise von Perl aus auf den Inhalt zugreifen, um Berichte zu erstellen. TEXT ist auch einfacher zu debuggen und arbeitet im Allgemeinen als Entwickler.

— Brian
quelle
1

Werfen Sie einen Blick auf Scalaris, eine No-SQL-Datenbank mit starker Konsistenz und implementierten Transaktionen.

— Julian Hille
quelle
1

Aus diesem Grund erstelle ich eine NoSQL Document Store-Lösung, um "echte" Transaktionen in Unternehmensanwendungen mit der Kraft eines unstrukturierten Datenansatzes verwenden zu können. Werfen Sie einen Blick auf http://djondb.com und fügen Sie jede Funktion hinzu, die Sie für nützlich halten.

— Kreuz
quelle
0

Sie können optimistische Transaktionen zusätzlich zur NoSQL-Lösung implementieren, wenn sie Compare-and-Set unterstützt. Ich habe ein Beispiel und eine Erklärung auf einer GitHub- Seite geschrieben, wie es in MongoDB gemacht wird, aber Sie können es in jeder geeigneten NoSQL-Lösung wiederholen.

— rystsov
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.