Datenbanken und Datenstrukturen

[Basic Runtime]

Hallo, Leute!

Die Sache ist die, ich interessiere mich seit einiger Zeit für Datenbanken und ehrlich gesagt hab ich so gut wie nur Lehrbuchwissen, d.h. ich habe gerade mal die Grundlagen durch und da hauptsächlich nur Orcale und paar Grundrisse von einigen NoSQL DBMSe.. Nach einiger Zeit rumtüfteln an meinem Dummy-Host, habe ich festgestellt, dass ich Probleme habe die Infrastruktur stabil zu halten, das heißt dass bei dynamischen Dat5enprozessen, das heißt wenn ich imemr Accounts erstelle, oder sonst was, dass sich der Leistungsanspruch entweder zu hoch sind oder dass Daten verloren gehen. Ich bin mir ziemlich sicher, dass es nicht an der phyiaklscihen Ebene liegt, sondern halt auf der konzeptionellen Ebene, vielleicht auch Fehler bei der Normalisierung oder so.
Jedenfalls ohne viel ins Detail zu gehen, wie wichtig ist es im Punkto "Datenstrukturen" nach Problemen bezüglich in Datenbanken weiterzuforschen, sind denn Sachen wie ksort, radixsort, B-Baum usw wichtig? Denn ich habe mich halt mit Datenbanken viel beschäftigt und etwas Assemblersprachen (also alles rein Hardware-nah), nur leider so gut wie nichts mit Datenstrukturen. Hat da jemand ein Herz für Noobs?

 

[Hellblazer]

Jedenfalls ohne viel ins Detail zu gehen, wie wichtig ist es im Punkto "Datenstrukturen" nach Problemen bezüglich in Datenbanken weiterzuforschen, sind denn Sachen wie ksort, radixsort, B-Baum usw wichtig?

Sicherlich nett zu wissen, wie das im Hintergrund abläuft. Je nachdem was du machen willst, vielleicht sogar wichtig, aber wenn du einfach nur ein DBMS in der Praxis einsetzen willst, kann man das vernachlässigen. Da solltest du dir lieber Normalisierung und Transaktionen anschauen. Damit sind auch deine Probleme der Performance und der verlorenenen Datensätze lösbar.
Dazu dann vielleicht noch ein paar Sicherheitsaspekte (SQL-Injection vermeiden...).

 

[benneq]

Die Datenstruktur ist das A und O für die Wahl der richtigen Datenbank!

Natürlich kann ich alles in einer relationalen DB abbilden, genauso wie auch in einem Key-Value-Store oder einer Graphdatenbank. Aber man setzt heutzutage nicht grundlos auf Polyglot Persistence: Je nach dem, ob man einfach ein Log schreiben will, oder ein Netz von z.B. Personen aufbauen will oder viele unstrukturierte Dokumente hat, gibt es halt für jeden Anwendungsfall eine Datenbank, die sich für den Use Case optimal nutzen lässt.

D.h. in Sachen Performance und Query-Logik ist es sehr wohl sinnvoll eine passende DB zu nutzen. Zumindest wenn das Projekt und die Datenmenge groß genug ist, dass es sich lohnt sich in etwas Unbekanntes einzuarbeiten.

Am Beispiel Social Media Plattform kann man immer recht gut Beispiele konstruieren, wo der Mehrwert verschiedener Datenbanken auffällt. Z.B. würde es ewig dauern die Verknüpfung zwischen 2 beliebigen Personen zu finden, wenn man einen Key-Value-Store benutzt. Auch eine relationale Datenbank ist dafür nicht optimal. Hier bietet sich eine Graphdatenbank wie Neo4j an. Ein Query dafür ist hier ein, zwei Zeilen lang.
Wenn man aber nun Personen anhand ihrer hinterlegten Informationen finden will, bringt einem der Graph natürlich gar nichts. Hier würde sich dann z.B. eine auf Lucene basierende Datenbank mit Reverse Index wie Elasticsearch oder Solr anbieten. (Die beiden sind inzwischen auch so mächtig, dass man dort sehr bequem und effizient Aggregationen und so ausführen kann).
Meist hängt an so einem Profil aber auch eine große undurchsuchbare (oder unstrukturierte) Datenmenge, mit der man den Suchindex nicht zumüllen will, wie Bilder und andere Binärdaten. Sowas könnte man dann einfach in einem Key-Value- oder Document-Store ablegen (z.B. Redis oder MongoDB).
Natürlich kann man Binärdaten auch einfach im Dateisystem ablegen, allerdings hat man dann wieder eine neue Herausforderung in Hinsicht auf Sharding, Replikation, Ausfallsicherheit. Da ist z.B. MongoDB's GridFS verdammt bequem.

Wenn die Datenstrukturen so egal wären, könnte man auch einfach alles in einer riesigen Textdatei ablegen und jedes mal darin suchen und sich die richtigen Daten rausziehen, aber das ist natürlich höchst ineffizient und fehleranfällig, dazu auch nicht wirklich gut ausbaufähig/erweiterbar.

Aber grundsätzlich sollte man sich vorher klar darüber sein, was man wirklich braucht. So ein Stack aus 2-3 Datenbanken kostet verdammt viel Arbeit und noch mehr Denkarbeit, damit die Daten auch die gewünschte Konsistenz aufweisen. Für kleine Projekte reicht es im Normalfall einfach MySQL oder MongoDB als Datenbank für alles zu benutzen. Klar muss man dann hier und da mal Abstriche machen. Es ist am Ende halt immer eine Kosten-Nutzen-Rechnung.