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. :oops:

[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.

[stahli]

Ich weiß, dass man sich als Nutzer nicht darum kümmern muss und war nur mal daran interessiert, etwas über einige Grundsätze zu erfahren.

[mkinzler]

Kurze Doku über die Transaktionsverwaltung per Versioniereung (FireBird/Interbase) wird aber auch von Oracle und MSSQL unterstützt.

https://firebirdsql.org/file/documen...cy_control.pdf

Die meisten DBMS verwenden aber einen Transaktionslog, in dem Änderungen an eingetragen werden. (werden am Ende einer Transaktion entweder bei Commit ausgeführt (und bei Rollback aus Log gelöscht) oder Rollback zurückgenommen ( und bei Commit aus Log gelöscht).

[joachimd]

Aufbau Datenspeicherung und Index anhand eines betagten DBFs: https://guru-home.dyndns.org/dBase.html

[stahli]

Danke Euch.

Das letzte trifft mein Niveau besser. ;-) Schaue ich mir mal durch.

[TiGü]

https://www.amazon.de/Datenbanksyste...dp_ob_title_bk

[Frickler]

Zum Thema Transaktionen: wenns ein bisschen ins Detail gehen darf, hätte ich hier eine Doku zu Transaktionen in Firebird:

https://ib-aid.com/en/transactions-i...ts-resolution/

[Luckie]

Zitat:

Zitat von stahli (Beitrag 1453532)

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

Nein, nein. Alles im grünen Bereich. Es ist durchaus ein interessantes Thema. Man kann nur lernen. Aber das Problem ist eben, dass das Thema Datenbank eben sehr umfangreich ist.

[p80286]

Zitat:

Zitat von stahli (Beitrag 1453539)

Ich weiß, dass man sich als Nutzer nicht darum kümmern muss und war nur mal daran interessiert, etwas über einige Grundsätze zu erfahren.

Definiere Grundsätze! Grundsätzlich ist ein Porsche 911 aus den 60ern das gleiche Auto wie ein VW Käfer. Und was heute als 911 angesprochen wird gehorcht den gleichen Grundsätzen. Trotzdem sollte es ein Ding der Unmöglichkeit sein den aktuellen 911 am Beispiel des Käfers von 1963 zu erklären. (sehen wir mal vom Heckmotor und der damit verbundenen Schwerpunktverschiebung ab)

Nicht umsonst spricht man heute vom DBMS und nicht mehr nur von Datenbanken. Auch wenn das Prinzip "Datenspeicherung und Rückgabe" gleich geblieben ist. Kannst Du davon Ausgehen, das z.B. Indizierung und Speicherung in Clipper/DBase anders gelöst wurde als in Oracle und MS-SQL (und wo steht Firebird und Mysql und ....).

Oder nimm Multiuser/Multitasking. Hierfür braucht es komplexere Verwaltungsstrukturen als für ein Embedded-Single-User-System.
Beachtenswert ist hier, das die Oberfläche der DB (z.B. SQL-Dialekt) gleich sein kann. Aber die Fehler (z.B. Deadlock) nicht gleich sind.

Einen Oberfächlichen Einstieg bieten vllt. die Wikipediaartikel z.B.
https://de.wikipedia.org/wiki/Datenbank
https://de.wikipedia.org/wiki/Relationale_Datenbank
Gruß
K-H