Gibt es eine Entscheidungshilfe für die geeigneste Datenbankart nach Anwendungsfall?

asc

Ich habe bislang ausschließlich mit relationallen Datenbanksystemen gearbeitet, weiß aber das diese Datenbankform nicht immer optimal ist. Alternativen gibt es einerseits Einige, die eine ganze Menge unterschiedlicher Ansätze verfolgen, eine wirkliche Entscheidungshilfe wann welcher Ansatz besser/schlechter geeignet ist, habe ich aber bislang nicht gefunden.

Kennt jemand eine Seite oder ein Buch das die Verschiedenen Ansätze kurz vorstellt und eine grobe Empfehlung in welchen Anwendungsfällen bzw. bei welchen Problemstellungen welcher Ansatz besser oder schlechter geeignet ist?

@asc

weiß aber das diese Datenbankform nicht immer optimal ist.

Aus eigener Erfahrung oder weil die coolen Kids das sagen?

Nimm SQL, es sei denn, du kannst ganz konkret sagen, warum eine NoSql Datenbank besser ist.

Hallo. MongoDB nimmt man zum Beispiel weil es webskalierbar ist. Für normale Desktopanwendungen wie du sie erstellt, braucht man das nicht. Schau dir das an: https://www.youtube.com/watch?v=b2F-DItXtZs

Buch: https://www.amazon.de/Datenintensive-Anwendungen-designen-zuverlässige-skalierbare-ebook/dp/B07KW4XBD7

asc

@manni66 sagte in Gibt es eine Entscheidungshilfe für die geeigneste Datenbankart nach Anwendungsfall?:

Aus eigener Erfahrung oder weil die coolen Kids das sagen?
Nimm SQL, es sei denn, du kannst ganz konkret sagen, warum eine NoSql Datenbank besser ist.

Keine eigene Erfahrung, aber Essenz dessen was man inzwischen aus einigen großen Firmen hört. Mag sein das es um spezielle Anwendungsszenarien geht, aber ich würde gerne mal sehen WANN eine SQL-Datenbank ungeeignet ist und wann welche Art der Alternative vielleicht besser geeignet ist (und nicht nur eine einzelbetrachtung wie z.B. MongoDB, sondern eine Art Entscheidungsbaum - oder eine Auflistung mehrerer Szenarien wo die Alternativen gegenüber gestellt werden).

@asc sagte in Gibt es eine Entscheidungshilfe für die geeigneste Datenbankart nach Anwendungsfall?:

was man inzwischen aus einigen großen Firmen hört

Das ist aber genau das Problem. Google hat einen speziellen Anwendungsfall und entwickelt dafür eine angepasste Datenbank. Aber wenn Google es macht muss es ja gut sein und schon glauben alle, NoSql sei der neue Heilsbringer. Das ist einfach nur Herdentrieb. Dafür wird es keinen Entscheidungsbaum geben. Selbst Reddit lläuft (immer noch?) mit PostgreSQL. Web = NoSql ist also nicht als Entscheidungshilfe geeignet.

asc

@manni66 sagte in Gibt es eine Entscheidungshilfe für die geeigneste Datenbankart nach Anwendungsfall?:

Das ist aber genau das Problem. Google hat einen speziellen Anwendungsfall und entwickelt dafür eine angepasste Datenbank. Aber wenn Google es macht muss es ja gut sein und schon glauben alle, NoSql sei der neue Heilsbringer...

Ich rede hier nicht nur von google, sondern einer nicht gerade kleinen Menge von Firmen die Andere DB-Ansätze nutzen. Und ja, es ist sicherlich von den Anwendungsfällen abhängig. Aber ich will weder die Hochlobelei von den jeweiligen DB-Machern hören, noch jemanden der NoSQL direkt als schlecht abstempelt.

Was ich will ist eine Aussage unter welchen Szenarien (Datensatzstruktur, Anwendungsfall...) welche Form von Datenbank ihre Vorteile und Nachteile hat. Und ich will auch nicht pauschal eine NoSQL-Datenbank herauspicken (da es sehr verschiedene Ansätze gibt). Ganz davon abgesehen ist der Hype inzwischen ohnehin vorbei, daher dürften jetzt auch genügend Praxiserfahrungen vorhanden sein.

DocShoe

Ich kann hier nur von Postgres berichten, in den letzten Versionen ist da eine sehr gute JSON Unterstützung dazugekommen. Damit haste quasi eine NoSQL Datenbank in einer SQL Datenbank. Über MongoDB kann ich nur Schlechtes berichten, zumindest unter Windows und für MongoDB 2.x. Die sind inzwischen bei V4 angekommen und haben sicherlich Vieles verbessert, aber meine Erfahrungen mit V2 haben mich soweit abgeschreckt, dass ich es eigentlich nicht mehr benutzen möchte.

Mechanics

Ich hatte bisher nicht wirklich viele gute Erfahrungen gemacht, habe mich damit aber auch nicht so intensiv beschäftigt (u.a. wegen, weil mir vieles von vornherein nicht gefällt).
Ich/wir machen auch nicht wahnsinnig viel mit Datenbanken und haben oft keine sehr komplexen Anforderungen. Die wichtigsten Kriterien sind für mich so gut wie immer Performance, und an zweiter Stelle "Einfachheit". Das zweite bezieht sich auf Szenarien wie, ich hab hier irgendeine Datenstruktur und will die irgendwie wegserialisiert haben und will da nicht irgendwelchen hässlichen Sql Code dafür schreiben.
Bei der Performance schaut es für mich so aus, als ob diese ganzen Datenbanken nur dann schnell wären, wenn man viele Instanzen hinstellt. Das war für mich meist das K.O. Kriterium. Wenn man nur eine Instanz haben will, dann ist es viel zu viel Overhead, und keine direkt wahrnehmbaren Vorteile.
Ansonsten kann auch Sqlite mit Json arbeiten, habe ich auch schon mal benutzt. Und das hat meist weniger Overhead.

hustbaer

@asc Ich kann dir keine Erfahrungen (mit NoSQL) anbieten, bloss Vermutungen. Plus ich weiss nicht was die diversen NoSQL Datenbanken mittlerweile so alles können.

Vermutung: Wenn du eine SQL Datenbank so verwendest wie man eine NoSQL DB verwenden würde, wird der Performance-Nachteil davon nicht so krass schlimm sein. Zum Bleistift:

Clustern der DB
Verteilung der einzelnen Rows auf verschiedene Files die auf verschiedenen Disk-/SSD-Stapeln liegen
Verzicht auf "unnötige" Normalisierung
Verzicht auf teure Abfragen (üble Joins, Range- oder gar Table-Scans etc.) die bloss "nice to have" sind
Zeugs was nicht wirklich als extra Feld notwendig ist in eine JSON/XML Spalte stopfen
...

Nur ist es dann halt meisten so, dass man viele dieser Dinge nicht macht, da sie in der SQL Welt halt "pfui" sind.

z.T. was aktuelle NoSQL Datenbanken können bzw. nicht können, was ich eben nicht weiss:
Ich weiss z.B. nicht was da an Relational Integrity/Joins geht. Beispiel warum das interessant wäre: Sagen wir du hast User und Channels, und jeder User kann beliebig viele Channels abonnieren. In einer SQL DB machst du dafür normalerweise einen eigenen "UserChannelSubscriptions" Table. Wenn du jetzt beim Laden des Users auch immer wissen willst wie viele und welche Channels er abonniert hat, dann brauchst du dafür zwei SELECTs (bzw. ein SELECT mit einem JOIN, was auf's gleiche rauskommt).
Das ist doof, weil die DB aus zwei Tables lesen muss. Bzw. je mehr solche "Listen" dazukommen, umso schlechter.

In NoSQL kann man jetzt alles in das eine User-Objekt reinstopfen - die Subscriptions sind halt einfach ein Array irgendwo in dem JSON/XML-Blob.
Was ich jetzt nicht weiss ist, ob man auf solche Arrays in einer NoSQL DB dann auch Indexe machen kann, mittels derer man effizient die Liste aller User bekommen kann die Channel X abonniert haben. Wenn das geht, dann wäre das ein grosser Vorteil von NoSQL Datenbanken. Denn dann hätte man den Vorteil dass man alles was man typischerweise von einem User braucht mit einem einzigen "select" bekommt, aber trotzdem performant seine Relationen in beide Richtungen "navigieren" kann.

In relationalen DBs dagegen kannst du sowas oft machen, und zwar mit XML Spalten (bzw. vermutlich auch JSON) und entsprechenden Indexen auf diese Spalten. Wie performant das dann mit grösseren Datensets ist kann ich nicht sagen. Bei MS SQL aus dem Jahre Schnee (=2005) war allerdings es so, dass man XML Indexe nur "ganz oder gar nicht" machen konnte. D.h. wenn man haufenweise unnötigen Ranz in einer XML Spalte hatte mit dazwischen 2-3 Werten für die man nen Index braucht, dann war das doof. Weil der ganze Ranz den Index aufgebläht hat. Konnte man aber natürlich "mit Hand" aufteilen. Also zwei XML Spalten machen, eine mit Index drauf und eine für den ganzen Ranz wo man keinen Index drauf braucht. Wobei das natürlich total doof ist wenn sich Dinge ändern, und man auf einmal auf einen weiteren Teil vom "Ranz" auch einen Index braucht.

Genau sowas, also die Subscriptions eines Users in einer SQL DB statt in einem "UserChannelSubscriptions" Table in einem XML-Blob in der User-Tabelle abzuspeichern, ist dann aber ganz grosses Pfui. Und alle werden ganz laut schreien wenn man den Vorschlag bringt es so zu machen. Womit wir dann wieder da wären wo sich diverse Unterschiede hauptsächlich dadurch ergeben, dass man mit SQL DBs unterschiedlich arbeitet, weil es halt einfach so üblich ist - und nicht weil es sein muss oder optimal ist.

asc

Das was hier als NoSQL-Datenbank vorrangig genannt wird ist nur eine Subform (MongoDB z.B. Dokumentenbasiert, aber es gibt eine ganze Reihe anderer Ansätze), und auch die Vermutungen von hustbaer sowie die Ergänzungen von Postgres hört sich ählich an.

Ich hatte halt gehoft das jemand eine Gegenüberstellung der einzelnen Datenbanktypen kennt, der grobe Typs gibt, wann welche Form geeignet und für welche Szenarien ideal ist.

Ich habe inzwischen ein paar Seiten gefunden, die zumindest in die Richtung des Erhofften gehen.

Übersicht (u.a. auch benennung und Gegenüberstellung unterschiedlicher NoSQL-Ansätze, wie KeyValue, Graph, Document und Column-Familie).

Entscheidungshilfen:

Auch wenn ich mich schon sehr lange mal mit dem Thema NoSQL auseinander setzen wollte, bin ich eigentlich erst wegen vielen Anwendungsbeispielen die CQRS nutzen über das Thema gestolpert. Da werden häufig NoSQL- und SQL-Datenbanken in Kombination eingesetzt. Beispiel: NoSQL als Schreib-Speicher wo jede Datensatzänderung hinterlegt wird (und jeweils nur die Änderungen umfasst), was u.A. Undo/Redo erleichtert und automatisch auch eine Historie mit sich bringt. SQL als Lesespeicher (erzeugt aus den NoSQL-Stand) für schnelle Zugriffe.

In dem Zusammenhang habe ich für mich einen weiteren sehr interessanten Artikel gefunden, der auch mit Technologien arbeitet, die für mich ohnehin in Betracht kommen (wie Entity Framework Core): https://www.thereformedprogrammer.net/ef-core-combining-sql-and-nosql-databases-for-better-performance/ (Hier interessanterweise genau umgekehrt zu dem Gespann was ich bislang am häufigsten gefunden habe: NoSQL als Lesespeicher und SQL als Schreibspeicher).

Mechanics

@asc sagte in Gibt es eine Entscheidungshilfe für die geeigneste Datenbankart nach Anwendungsfall?:

unterschiedlicher NoSQL-Ansätze, wie KeyValue, Graph, Document und Column-Familie)

Ich finde die Unterschiede aber gar nicht so groß, zumindest subjektiv. Bis auf Graphdatenbanken, aber das ist ein Spezialfall.
Ansonsten... Ich kann eine Key Value Datenbank mit einem eindeutigen Key und einem Json Objekt als Value nehmen. Oder eine Dokumenten-Datenbank. Ebenfalls mit einem eindeutigen Key + Json Dokument. Und Column Store ist jetzt auch nicht großartig anders.

Die Frage ist für mich eher, was will ich damit erreichen, und was erhoffe ich mir davon.
Und das lief bei mir bisher fast immer darauf hinaus, dass ich entweder Sqlite hernehme (mehr oder weniger als Key-Value mit Json als Value, evtl. paar Json Indizes), oder vielleicht mal LevelDb.