Interne Arbeitsweise von Datenbanken für Dummies

[stahli]

Kennt jemand eine gute Erklärung, wie Datenbanken grundsätzlich arbeiten?

Also insbesondere:
- Wie werden Transaktionen realisiert?
- Wie werden Indizes berechnet und gespeichert?
- Wie werden Datenverluste/Inkonsistenzen bei Stromausfällen minimiert?
- Diesbezügliche interne Unterschiede SQL/noSQL?

Am liebsten wäre mir ein deutsches Video.

Ich fände es einfach mal spannend, etwas darüber zu erfahren.

[Der schöne Günther]

Ich glaube Bücher sind da noch Videos überlegen.

[mkinzler]

Das sind alles Implementierungdetail, um die man sich im Normalfall nicht kümmern muss. Das ist ja der Vorteil eines DBMS. Es bietet einem eine Schnittstelle und kümmert sich um den Rest.

Zitat:

- Wie werden Transaktionen realisiert?

Kommt darauf an, welches DBMS.
Transaktionslog, Datensatzversionierung, ...

Zitat:

- Wie werden Indizes berechnet und gespeichert?

Kommt darauf an, welches DBMS.
Baum, Hashtable, ...

Zitat:

- Wie werden Datenverluste/Inkonsistenzen bei Stromausfällen minimiert?

Kommt darauf an, welches DBMS.
Memory, Cache, ...

Zitat:

- Diesbezügliche interne Unterschiede SQL/noSQL?

Kommt darauf an, welches DBMS.

[stahli]

Mir geht es mehr darum, mal so eine grundsätzliche Idee zu haben.

Mal ein Beispiel: Gegeben ist eine Anwendung mit ein paar Mio Datenobjekten, Personen, Konten, Überweisungen.

Die Objekte sind alle im Speicher in 3 Listen, natürlich mit gegenseitigen Referenzierungen.


Jetzt ist die Frage, wie man Transaktionen umsetzen kann und die Daten sicher speichert - ganz grundsätzlich.


Indizes zu berechnen ist wohl weniger das Problem.
Dazu wird eine neue Liste erzeugt, die die Ids der Objekte in einer anderen Reihenfolge speichert.

Für Transaktionen würde ich neue Listen erzeugen, die eine aufsteigende Transaktionsnummer verwalten und Objekte mit geänderten Daten oder einem Löschkennzeichen erhalten.
Unter Beim abrufen von Daten wird in den Originallisten gelesen und in der eigenen offenen Transaktionsliste. Fremde offene Transaktionslisten oder nachträglich committete fremde Transaktionslisten werden ignoriert.

Irgendwann müssen abgeschlossene Transaktionslisten in die Originalliste eingearbeitet werden.

Eine Speicherung auf die Festplatte ist natürlich auch notwendig, was nur stückweise erfolgen kann (also Tabelle löschen und komplett neu schreiben geht natürlich nicht).

Was ist aber, wenn in so einem Moment der Strom ausfällt.


Solche grundsätzlichen Dinge fände ich mal interessant.

[jobo]

@stromausfall
Damit ist man beim Kern einer Transaktion. Die ist erst abgeschlossen und wird als solche markiert, wenn das letzte Bit geschrieben ist.
Ansonsten passiert das, was vielleicht auch nicht trivial ist: Die Datenbank ist nach dem Neustart auf dem letzten gültigen Stand vor dem Stromausfall (außer der war mit einer Spannungsspitze verbunden und hat den alten Schreiblesekopf irgendwo ins metall gehauen)

Die wichtigen Prinzipien eine DB nennen sich ACID.
NoSQL's gibt es viele und wahrscheinlich sind die wenigsten ACID-Konform. Mongo kann seid einiger Zeit (paar Monaten?) Transaktionen (Da hab ich als erster Hurra gerufen- > wusste vorher gar nicht, dass die das meistens nicht können. Jetzt weiß ich: Wenn überhaupt, kann ich mir mal MongoDB anschauen)

Summa Sumarum ist es sicher oft unterschiedlich implementiert, wie MKinzler schon sagte und es ist m.E. sehr komplex, soetwas selbst umzusetzen. Multiuser, Transaktionen, Atomizität, .. usw. ist schon ein Akt. Und dabei redet man natürlich nicht nur von etwas RAM, sondern von GB großen Files bis in den TB Bereich.

[stahli]

Ja, vermutlich ist das doch alles zu komplex, um das mal so grundsätzlich abhandeln zu können.

Bezüglich MongoDB habe ich mir auch schon einiges angesehen.
Inzwischen denke ich aber, dass man bei sehr strukturierten Arbeitsdaten mit vielen Relationen (siehe mein Beispiel oben) aufeinander doch mit relationalen Datenbanken besser dran ist (lässt ja auch der Name vermuten ).

Das werde ich dann zu gegebener Zeit aber sicher mal austesten müssen...

[Andreas13]

Hallo,
Bücher sind wirklich besser als nur ein Video. Ein recht verständliches und gutes Buch könnte ich Dir dazu empfehlen:
1):
Redaktion Toolbox (Herausgeber): Datenbanken mit Delphi: Design, Implementierung und Publikation (2002)
https://www.amazon.de/Datenbanken-mi...6499039&sr=8-1
Es ist zwar ein betagtes Buch, aber die Grundprinzipien werden auf 750 Seiten sehr gut erklärt und mit Pascal-Quellcode unterfüttert.

2):
Solltest Du das Benutzerhandbuch der B-Tree Shell von der Enz EDV-Beratung (Bad Homburg) aus dem Jahr 1990 (+ Quellcode dazu von Ralf Nagel + B-Tree Filer von Turbo Power Software: https://sourceforge.net/projects/tpbtreefiler/ ) irgendwo auftreiben können, dann kannst Du dort etliche Geheimnisse & bis heute gültigen Tricks erfahren, die z.T. in modernen Datenbanken wie „NexusDB“ oder „Absolute Database“ (= Embedded DB) verwendet werden.
Gruß, Andreas

[mkinzler]

Oder den Sourcecode aktueller (OpenSource) Datenbanken wie FireBird, PosGresSQL, MariaDB usw.

[stahli]

Danke Euch, aber ich wollte keine 700 Seiten Buch oder Quelltext durcharbeiten...
... nur etwas mundgerechte "Häppchen für Dummies"

War vermutlich etwas zu naiv.

[mkinzler]

Der Vorteil eines DBMS ist ja gerade, dass man sich nicht um diue Details kümmen muss. Wie der Hersteller des DBMS dies dann implementiert ist ja seine Sache. Wenn die Implementierung so simple wäre, wäre ja niemand bereit viel Geld für ein DBMS auszugeben.