Entschuldigung für die ignorante Frage, aber welche Art von Anwendungen würde keinen ACID-kompatiblen Datenbankserver erfordern? Ich habe einen SQL Server-Hintergrund, wo ACID immer "da gewesen" war, und jetzt recherchiere ich andere DBMSs. Fast jede Anwendung, die ich mir vorstellen kann, würde Atomizität oder Isolation verlangen. Danke!
Es ist ein Paradoxon, dass jeder RDBMS-Typ denkt, der Himmel würde ohne ACID fallen, aber die meisten NoSQL-Leute implementieren und unterstützen Endbenutzeranwendungen ohne zu denken, "meine Anwendung wäre besser mit ACID". Im Gegensatz zu der Antwort von Marc B sind NoSQL-Datenbanken keine Datenbanken, in denen Aktualisierungen zufällig verloren gehen oder Daten zufällig beschädigt werden. Der Hauptunterschied besteht darin, dass Sie in NoSQL-Datenbanken begrenzte Versionen von Atomity & amp; Isolation usw., aber es erfordert einen exponentiellen Aufwand, Transaktionen beliebiger Komplexität zu implementieren.
Es gibt keinen Grund, warum Sie kein Banksystem mit einer Nicht-ACID-Datenbank implementieren können. Die meisten NoSQL-Datenbanken ermöglichen es Ihnen, Mikrotransaktionen zu verwenden, die Geld von einem Konto abziehen und es einem anderen Konto hinzufügen, mit einer Wahrscheinlichkeit von 0%, dass sich der Gesamtbetrag des Geldes im System ändert.
Um diese Frage im Zusammenhang mit realen Beispielen zu diskutieren, beschreibe ich unsere Anwendung. Meine Firma verkauft Software an weiterführende Schulen, hauptsächlich für die Stundenplanung, aber auch für App-Anrufen, für die Verwaltung von Lehrerabwesenheiten / -ausfällen, Exkursionen und Zimmerbuchungen. Unsere Software basiert auf einer intern entwickelten Nicht-ACID-Datenbank-Engine namens Mrjb (nur intern verfügbar), deren Einschränkungen typisch für NoSQL-Datenbanken sind.
Ein Beispiel für den Unterschied zwischen ACID und NoSQL, der für den Endbenutzer relevant ist, besteht darin, dass, wenn 2 Benutzer versuchen, dieselbe Rolle zur exakt gleichen Zeit zu markieren, eine (sehr) geringe Chance besteht, dass das Endergebnis a lautet Kombination von Daten, die von beiden Benutzern übermittelt wurden. Eine ACID-Datenbank würde garantieren, dass das Endergebnis entweder die Daten eines Benutzers oder die des anderen sind, oder möglicherweise, dass die Aktualisierung eines Benutzers fehlschlägt und eine Fehlermeldung an den Benutzer zurückgibt.
In diesem Fall glaube ich nicht, dass unsere Benutzer sich darum kümmern würden, ob der Abwesenheitsstatus der einzelnen Schüler mit dem Update eines Benutzers oder einer Mischung aus beiden übereinstimmt, obwohl sie besorgt wären, wenn wir Abwesenheitsstatus zuweisen würden im Gegensatz zu den Eingaben der beiden Benutzer. Dieses Beispiel sollte in der Praxis nicht vorkommen, und wenn dies der Fall ist, dann ist es eine "Race-Bedingung", bei der es im Wesentlichen keine richtige Antwort darüber gibt, an welchen Benutzer wir glauben.
In Bezug auf unsere Mrjb-Datenbank wurde die Frage aufgeworfen, ob wir in der Lage sind, Einschränkungen wie "darf ein Schülerobjekt darf nicht ohne ein entsprechendes Familienobjekt existieren" zu implementieren. (Das 'C' in 'ACID' = Konsistenz). Tatsächlich können und halten wir diese Einschränkung - ein weiteres Beispiel für eine Mikrotransaktion.
Ein anderes Beispiel ist das Hochladen einer neuen Version des zyklischen Schulzeitplans (normalerweise ein zweiwöchiger Zyklus), auf dem der Tagesfahrplan basiert. Es wäre schwierig, diese Aktualisierungstransaktion unteilbar zu machen oder zuzulassen, dass andere Transaktionen isoliert von dieser Aktualisierung ausgeführt werden. Also haben wir grundsätzlich die Wahl zwischen "Stoppt die Welt" während dieser großen Transaktion, die ungefähr 2 Sekunden dauert, oder der Möglichkeit, dass ein Student einen Stundenplan mit einer Kombination aus Daten vor und nach der Aktualisierung druckt wahrscheinlich ein 100ms Fenster in dem dies vorkommen könnte). Die Option "Stoppt die Welt" ist wahrscheinlich die bessere Option, aber tatsächlich tun wir Letzteres. Man könnte argumentieren, dass ein gemischter Stundenplan schlimmer ist als ein Zeitplan vor der Aktualisierung, aber in beiden Fällen müssen wir uns darauf verlassen, dass die Schule ein Verfahren zur Benachrichtigung der Schüler über die Änderung des Stundenplans durchführt - ein Student, der einen veralteten Stundenplan bearbeitet ist ein großes Problem, auch wenn es ein konsistenter Zeitplan ist. Beachten Sie auch, dass Studenten ihren Stundenplan normalerweise online anzeigen. In diesem Fall wird das Problem stark reduziert.
Ich habe auch eine "Dateisystem-basierte Blob-Datenbank" für Ссылка geschrieben, um ihre Gehirnscans zu speichern. Dies ist eine wichtige Datenbank und eine, die keine ACID-Eigenschaften hat, obwohl sie ein RDBMS für andere Daten über ihre Subjekte verwenden.
Zur Erinnerung, unser Unternehmen wird hier beschrieben: Ссылка und unsere NoSql-Technologie wird hier beschrieben (als Technik beschrieben): Ссылка . Es gab Bedenken, dass es sich bei diesem Beitrag um Spam handelte, der unserer Firma einen Stecker gab, aber ich würde argumentieren, dass (a) die gestellte Frage nicht nur theoretisch beantwortet werden kann - Sie brauchen Beispiele aus der Praxis und (b) Zurückhaltung Identifizierende Informationen über das Produkt oder die Datenbanktechnologie sind nicht geeignet.
Was die anderen Antworten zu fehlen scheinen, ist, dass die allgemeingültige Alternative zu ACID nicht "nichts" ist, sondern etwas, das heißt eventuelle Konsistenz (manchmal mit dem Spitznamen BASE).
Wenn Leute sagen, dass sie ACID-Semantiken benötigen, ist es oft, was sie wirklich meinen, zumindest aus der Sicht einer Domäne / Geschäftsanforderungen, einfach Datenintegrität . Sie möchten sicherstellen, dass Daten nicht verloren gehen oder beschädigt werden. Viele NoSQL-Datenbanken bieten immer noch diese Garantie, sie stellen sie nur auf andere Weise und zu ihren eigenen Bedingungen bereit.
Es ist sicherlich möglich, eine NoSQL- oder BASE-Datenbank als unsichere Alternative zu einer SQL- oder ACID-Datenbank zu verwenden, wenn Sie sie einfach als "Nicht-ACID-Datenbank" behandeln. Eine fundierte Entscheidung bedeutet, dass Sie verstehen, was auf der Anwendungsebene getan werden muss, um den Mangel an grobkörnigen Transaktionen zu kompensieren und die Stärken von EC zu nutzen. Einige gebräuchliche Techniken sind:
Optimistische Parallelität , die bereits verwendet wird, um das Sperren in einer Transaktionsumgebung zu minimieren.
Idempotenz von Operationen, so dass es, wenn eine lang andauernde Operation auf halbem Wege scheitert, einfach so sein kann immer wieder versucht, bis es gelingt.
Lang laufende Transaktion Techniken mit kompensierende Transaktionen , die in verteilten Systemen oft sagas genannt werden, wobei mehrere unabhängige Transaktionen nach einer Korrelations-ID gruppiert werden und der Status der gesamten Operation unabhängig verfolgt wird. Oft verwenden diese tatsächlich die ACID-Semantik für den Saga-Status selbst, aber das ist viel leichter als ein zweiphasiges Commit.
Wenn Sie viel Zeit mit der Arbeit an verteilten Systemen verbringen - selbst wenn diese mit ACID-Semantiken für jedes der einzelnen Subsysteme verfügbar sind - werden Sie viele dieser Techniken kennenlernen Verwalten Sie systemübergreifende Vorgänge, weil ohne sie Sie Leistung einfach verwischen (denken Sie an BizTalk und BPEL).
Sobald Sie etwas Erfahrung damit haben, werden Sie feststellen, dass es tatsächlich sehr sinnvoll ist und oft einfacher ist als die ACID-Semantik anzuwenden. Computing-Prozesse sind nur Modelle für reale Prozesse, und reale Prozesse können manchmal im Midstream fehlschlagen. Du hast einen Flug gebucht, aber plötzlich gehst du nicht mehr. Wie geht's? Sie kündigen ab. Vielleicht bekommst du dein Geld zurück, vielleicht auch nicht, oder vielleicht ist es etwas dazwischen - das sind deine Geschäftsregeln. Oder vielleicht hast du deine Buchung begonnen, bist aber abgelenkt oder abgelenkt worden oder dein Strom ist ausgegangen, und jetzt ist deine Sitzung abgelaufen. Wie geht's? Ganz einfach, du fängst von vorne an.
Um die Frage wirklich anzugehen, antworte ich so:
Sie benötigen ACID Semantik wenn:
Sie können vernünftigerweise erwarten, dass mehrere Benutzer oder Prozesse gleichzeitig an den gleichen Daten arbeiten.
Die Reihenfolge, in der Transaktionen angezeigt werden, ist äußerst wichtig;
Sie können niemals veraltete Daten tolerieren, die dem Benutzer angezeigt werden.
Es gibt erhebliche und / oder direkte Kosten für unvollständige Transaktionen (z. B. ein Finanzsystem, bei dem unausgewogene Summen schwerwiegende Folgen haben können).
Auf der anderen Seite benötigen Sie nicht ACID-Semantik, wenn:
Benutzer neigen dazu, Aktualisierungen nur für ihre eigenen privaten Daten durchzuführen oder gar keine Aktualisierungen durchzuführen (nur anhängen).
Es gibt keine implizite (geschäftliche) Reihenfolge der Transaktionen. Zum Beispiel, wenn zwei Kunden um den letzten Artikel im Lager konkurrieren, ist es eigentlich egal, wer sie tatsächlich bekommt.
Benutzer werden dazu neigen, sich jeweils für Sekunden oder Minuten auf demselben Bildschirm zu befinden, und werden daher nach veralteten Daten suchen auf jeden Fall (dies beschreibt eigentlich die meisten Anwendungen).
Sie haben die Möglichkeit, unvollständige Transaktionen einfach aufzugeben; Es hat keinen negativen Effekt, dass sie vorübergehend oder teilweise dauerhaft in der Datenbank herumstehen.
Die Quintessenz ist, dass sehr wenige Anwendungen wirklich ACID-Semantik überall benötigen. Für viele Anwendungen sind sie jedoch irgendwo erforderlich - oft in isolierten Taschen wie dem Saga-Status oder Nachrichtenwarteschlangen.
Wenn Sie das nächste Mal eine neue Anwendung oder ein neues Feature entwerfen, sollten Sie darüber nachdenken, ob es möglich ist, eine atomare / isolierte "Transaktion" als eine asynchrone "Ereigniskette" mit einem kleinen zusätzlichen Status zu modellieren Binde sie alle zusammen.In einigen Fällen lautet die Antwort no , aber Sie werden überrascht sein, wie oft die Antwort yes ist.
Sie zahlen einen Leistungspreis für die ACID-Semantik. In Fällen, in denen Sie eine sehr große Datenmenge verwalten und gelegentliche Inkonsistenzen akzeptieren (d. H., Sie übertragen kein Geld), können Nicht-ACID-Lösungen (wie die meisten NoSQL-Lösungen) vorzuziehen sein.
Facebook war eines von mehreren hochkarätigen Unternehmen, die diesen Kompromiss früh gemacht haben. Tatsächlich schrieben sie Cassandra als Datenspeicher, der besser zu ihren Datenbedürfnissen passte, und Cassandra unterstützt explizit keine ACID-Semantik.
>Tags und Links database acid rdbms-agnostic