Seite 1 von 1

Datenbanken, SQL, NoSQL, Skalierbarkeit

Verfasst: Fr Feb 09, 2018 6:25 pm
von Kmitska
Hallo zusammen,

ich würde gerne eine Unterhaltung über Datenbanken starten, die hoffentlich mir und später anderen bei der Entscheidung bzw. Auswahl einer Datenbank für ein Projekt helfen wird.

Die erste Frage lautet, was so eine MySQL oder PostgreSQL Datenbank aushalten kann. Ich weiß, es bezieht sich immer auf den Rechner und dessen Umgegbung aber habt ihr dazu Beispiele? Interessante Fragen wären:
- Ab wie viel GB Daten sollte man sich generell Gedanken machen über die Skalierung
- Kann man sich bei SQL Datenbanken z.B. bei PostgreSQL auf Lösungen wie PostgreSQL-xl verlassen, wenn es um Clustering geht und kennt sich jemand genug aus, um sagen zu können, wie viel Aufwand eine solche Anpassung in sich hat?

Ich würde gerne ein anderes Problem ansprechen, was zugleich der Hauptunterschied zwischen den Alternativen ist. Nehmen wir MongoDB und PostgreSQL als Beispiel. MongoDB benutzt man gerne in Web-Anwendungen weil es sich durch BSON gut eignet. Aber wie ich finde ist MongoDB wieder problematisch, wenn man ständig Daten referenziert um Redunanz zu vermeiden. Dieses Problem hätten wir bei Postgre nicht, da würde eine JOIN-Operation das Problem lösen. Insofern gibt es bei MongoDB minimum zwei Anfragen. Die Frage ist dann, ob man trotzdem MongoDB verwenden kann? Einen Vorteil hat MongoDB ja immerhin, bietet eingebaute Sharding und Replicate Funktionen an. Bei PostgreSQL habe ich nur von Postgres-xl gehört, kenne mich aber nicht aus.

Man sagt dass NoSQL's sich nicht komplett an ACID Prinzipien halten. Inwiefern würde dies die Anwendung beeinflussen? Kann man also bei NoSQL falsche Daten erwarten?

Und nebenbei: Welche Datenbanken würdet ihr für die folgenden Fälle nehmen und wieso? Würde mich sehr freuen, wenn ihr auf die Skalierbarkeit eingehen könnt.
- Reservierungssystem
- Lagerhaussoftware

Danke und Gruß

Re: Datenbanken, SQL, NoSQL, Skalierbarkeit

Verfasst: Fr Feb 09, 2018 6:45 pm
von Xin
Kmitska hat geschrieben:Die erste Frage lautet, was so eine MySQL oder PostgreSQL Datenbank aushalten kann. Ich weiß, es bezieht sich immer auf den Rechner und dessen Umgegbung aber habt ihr dazu Beispiele? Interessante Fragen wären:
- Ab wie viel GB Daten sollte man sich generell Gedanken machen über die Skalierung
Ich bin kein Datenbankspezialist, aber GB ist hier vermutlich die falsche Einheit.

Ich würde von Komplexität sprechen.
Kmitska hat geschrieben:- Kann man sich bei SQL Datenbanken z.B. bei PostgreSQL auf Lösungen wie PostgreSQL-xl verlassen, wenn es um Clustering geht und kennt sich jemand genug aus, um sagen zu können, wie viel Aufwand eine solche Anpassung in sich hat?
Hier wäre wohl ein Testlauf erforderlich.

Die Frage ist vor allem, wieviel Last soll die Datenbank denn überhaupt aushalten?
Eine normale Website interessiert eine DB nicht. Ebay hingegen ist schon eine dicke Hausnummer.
Kmitska hat geschrieben:Dieses Problem hätten wir bei Postgre nicht, da würde eine JOIN-Operation das Problem lösen. Insofern gibt es bei MongoDB minimum zwei Anfragen. Die Frage ist dann, ob man trotzdem MongoDB verwenden kann?
Hier kommen wir wieder zu Komplexität.
Ein Fremdschlüssel ist ja auch nicht anderes als eine Referenz. Du sparst halt die zweite Anfrage. Es bleibt die Frage, wie die DB eine komplexe Anfrage aufarbeitet und ob zwei billige Anfragen billiger sind als eine komplexe.
Kmitska hat geschrieben:Man sagt dass NoSQL's sich nicht komplett an ACID Prinzipien halten. Inwiefern würde dies die Anwendung beeinflussen? Kann man also bei NoSQL falsche Daten erwarten?
ACID: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit

Wenn Du mehrere Anfragen starten musst, hast Du dazwischen eventuell inkonsistente Daten, die eine andere Abfrage abholen könnte.

Das wäre meine Vorstellung des Problems. Ich habe mit MongoDB aber noch nicht gearbeitet, kenne also nicht die exakten Fallstricke.
Kmitska hat geschrieben:Und nebenbei: Welche Datenbanken würdet ihr für die folgenden Fälle nehmen und wieso? Würde mich sehr freuen, wenn ihr auf die Skalierbarkeit eingehen könnt.
- Reservierungssystem
- Lagerhaussoftware
Ich würde das beides als klassische SQL-Reviere bezeichnen, weil die Daten sehr tabellarisch sind.

Bevor Du Datenbanken clustern musst, müssen die DBs wirklich sehr, sehr groß werden.
Keine Ahnung, was Du vorhast, aber auch Google fing mal klein...

Da Du nicht schreibst, was Du vorhast, würde ich mit einer Zwischenschicht anfangen, die Deine Datenbankabfragen sammelt, in SQL ausdrückt und dann abschickt. Solltest Du wechseln wollen, musst Du nur noch diesen Wrapper anfassen. Sowas würde ich aus Prinzip so handhaben, ich will ja nicht überall SQL in meinem Code verstreut haben.

Hier wäre ja eher die Frage, was Du eigentlich tun willst. Entsprechend wäre dann zu überlegen, welche Datenbank auf Dein Szenario spezialisiert wäre.