Menü
Avatar von Bitschnipser
  • Bitschnipser

mehr als 1000 Beiträge seit 14.01.2016

Re: kein Wunder - die geben nur buzzwords von sich und wollen damit reich werden

Exxtreme2 schrieb am 12.06.2019 15:13:

Bitschnipser schrieb am 12.06.2019 12:13:

Was nützt mir das, wenn es nicht wirklich funktioniert?
"Nicht wirklich" im Sinne von: Es ist nicht zuverlässig genug, dass man sich darauf verlassen und auf Vorkehrungen gegen die üblichen Fehlerfälle verzichten kann.

?

Bitschnipser schrieb am 12.06.2019 12:13:

Und genau DIESE Garantie macht Datenbanken schrecklich langsam.
Obendrein anfällig für sich gegenseitig behindernde Prozesse - B kann nicht schreiben, bevor A nicht fertig ist. Selbst dann nicht, wenn sie unterschiedliche Spalten des gleichen Datensatzes verändern wollen.
Obendrein kriegt man noch Deadlock-Risiken.

Das Heimtückische ist, dass diese Dinge erst ab einer gewissen Gesamtkomplexität zum Problem werden. Tante Ernas Strickjackenladen wird diese Sorte Problem nie kriegen.

Schrecklich langsam ist hier wiederum abhängig davon welche Anforderungen man so hat. Wenn ich Facebook, Google oder Netflix wäre dann würde ich auch keine ACID-Datenbank einsetzen. Aber ein Mittelständler mit 100 MA? Für den hat ACID weit mehr Vorteile denn Nachteile.

Hängt ein bisschen davon ab, was der macht.
Ich habe auch schon Sachen erlebt, wo der Nachtlauf doch zu langsam wurde und man eben nicht einfach so einen billigen Zweitserver danebenstellen konnte, sondern man musste die DB-Queries selber optimieren. Womit man dann DB-abhängig wurde.
Wobei das eher 1000 als 100 MA waren, so gesehen: Ja, es ist auch eine Frage dessen, wie weit man skalieren muss.
Aber wenn dein 100-MA-KMU auf 1000 MA skalieren muss, wird er mit der DB Schwierigkeiten kriegen. Was dann Leuten wie dir und mir die Frühstücksbrötchen bezahlt, man soll also nicht zu laut klagen - aber ideal ist das halt nicht.

Und dass man unterschiedliche Spalten eines Datensatzes von mehreren Prozessen verändert? Das klingt nach einer extrem stark denormalisierten Datenbank.

Nein, überhaupt nicht. Der eine ändert die Adresse und der andere die Umsatzstatistik.

Und ja, ACID-Datenbanken brauchen ein gutes Modell und gut gewählte Indizes um sowas zu vermeiden bzw. stark zu minimieren. Was wiederum recht viel Disziplin erfordert denn stark normalisierte Datenbanken sind ätzender beim Entwickeln.

Nach drei bis fünf Jahren kannst du das mit dem guten Modell einfach vergessen. Da ist das Modell dann nicht mehr anpassbar.

Och, wie "schnell" solche Sachen sind sieht man auf Facebook. Da bekomme ich auch Meldungen als "neu" angezeigt, die bereits mehrere Stunden alt sind. Das kann mit eventual consistency immer passieren.

Dann liegt das nicht an Eventual Consistency, sondern an Bugs im Auswahlalgorithmus.

"Ultraschnell" hat man mit einer Wahrscheinlichkeit < 100%. Und darauf muss man die Software und/oder die Geschäftsprozesse anpasen.

Natürlich, aber das sollte man sowieso.
Man muss ja die Gelegenheit haben, Fehler zu korrigieren; d.h. für die DB mag die Transaktion ja durch sein, aber das Geschäft muss die geschäftliche Transaktion immer noch rückabwickeln bzw. korrigieren können.
D.h. wenn man sich die Abläufe in den Geschäften anschaut, sind die alle, alle, alle auf eventual consistency ausgelegt (schließlich hat man in einer Firma mit Außenstellen auch genau die gleichen Probleme einer verteilten Datenhaltung, vor 50 Jahren ging das halt mit Papier und Kurier, aber die Probleme waren dieselben). Wenn man in der Software die Geschäftsprozesse mit Eventual Consistency abbildet, ist man dann sogar näher an den realen Prozessen dran als mit ACID (das ist natürlich nur tendenziell ein Vorteil, aber es ist einer).

Das Problematische an eventuel consistency ist ja nicht, dass die Daten mit einer Verzögerung da sein können, sondern dass semantisch zusammenhängende Daten unterschiedliche Laufzeit haben können. Sprich, kann sein, dass die Rechnung unvollständig ist weil nicht alle erforderlichen Daten zur Rechnungserstellung vorhanden waren. Was wiederum bedeutet man muss evtl. hinterher eine zweite Rechnung hinterherschicken, die die fehlenden Positionen enthält etc.

Und genau das brauch ich ja im manuellen Geschäftsleben auch.

Passiert dir mit ACID nicht. Du packst die gesamte Bestellung in eine Transaktion und dann ist das Ding entweder vollständig drin oder gar nicht. Und dann kann garantiert eine Rechnung für diese eine Bestellung generiert werden.

Und wenn meine ACID-DB spinnt, weil der Administrator auf den falschen Knopf gedrückt hat oder der Entwickler einen Bug drin hat und die Nested Transaction gar nicht stattfindet, dann fällt das System auf die Schnauze.
Perfiderweise nur dann, wenn irgendwelche ungewöhnlichen Dinge laufen, dann kommt das nämlich immer dann obendrauf, wenn man es sowieso nicht brauchen kann.

(Ein Stück weit steckt hier auch die Chaos-Monkey-Philosophie drin: Wenn Ausfälle so selten sind, dass der Entwickler die nie erlebt, dann programmiert er auch nicht für die, und dann bricht alles gleichzeitig zusammen, wenn man doch noch einen Ausfall hat; hat man ein System, in dem man notfalls täglich einen Teilausfall provoziert, programmieren die Entwickler ganz anders, viel defensiver, und es kommt ein insgesamt wesentlich robusteres System heraus.)

D.h. das Falsche an ACID ist nicht, dass man Konsistenz macht, das Falsche ist, dass man sie *sofort* haben will. Das ist mehr, als man meistens braucht.

Ich sehe das nicht als "falsch" an sondern als intuitiv für die Benutzer. Auch wenn das einige Nachteile bei der Umsetzung nach sich ziehen kann.

Intuition ist arg subjektiv.
Obendrein stark von den Erfahrungen abhängig.
Ich hab noch nie einen Entwickler gesehen, der seine Transaktionen in der Software von selbst wiederholbar gestaltet hat (was man z.B. bei Oracle tun muss, weil da jede Transaktion aufgrund von technischen Interna der DB fehlschlagen kann - das passiert aber erst, wenn die DB ernsthaft Last hat, also produktiv läuft, beim Testen erlebt man das nicht.)

Bewerten
- +
Anzeige