MySQL - oder doch was anderes?

[ascer]

Huhu Leute,



ich wollte mal eine kurze Perspektive von Leuten, die schon länger/intensiver mit Datenbanken arbeiten, als ich es tue.

Es geht um folgendes: Eventuell startet bald ein Projekt, welches doch eine recht erhebliche Datenbank benötigen würde (etwa im Bereich 1-10 Mio. Datensätze pro Jahr).

Reicht MySQL dafür auch noch aus oder gibt es performantere bzw. bessere Lösungen?

Was wären vernünftige Alternativen?



Grüße & Danke

ascer

 

[computerbase107]

Als Hinweis auf das Maximum von MySql: https://dev.mysql.com/doc/refman/5.1/de/table-size.html

 

[Freezedevil]

Alternativen wären beispielsweise DB2 oder Oracle. Ich denke aber auch MySQL wird deine Last stemmen können.

 

[ascer]

Also von der technischen Machbarkeit denke ich auch, dass MySQL das problemlos bewältigt...die Frage ist nur, gehen andere Systeme mit solchen Datenmengen performanter um?

Ich habe bis jetzt immer nur MySQL benutzt und die meisten DBs die ich hatte, besaßen Tausende bis Hunderttausende Einträge..also nicht mal ansatzweise vergleichbar mit dem nun geplanten Projekt.

Dementsprechend weiß ich nicht, wie MySQL einfach von der Performanz her mit diesen Datenmengen umgeht und ob nicht eine andere DB-Engine da ratsamer wäre?

 

[Yuuri]

Statt MySQL kannst du auch MariaDB verwenden.

 

[andy_0]

@ Yuuri
Das ändert aber nichts an der Frage, da MariaDB ja nur der Orcale unabhängige Fork ist.

@ ascer
Ich würde dir empfehlen im Internet nach Performance Berichten zu schauen. Da findest du dann sicherlich gute Vergleiche im Workload zwischen den Datenbanksystemen.

 

[Tobi86]

Ich bin ja ein großer Fan von PostgreSQL. Quasi keine Limits & vollständig ACID-komp..

 

[DasBoeseLebt]

Vllt. sollte der TE noch etwas spezieller werden, bevor hier jede existierende Datenbank genannt wird.
Stumpf Datensätze halten kann jede mehr oder weniger,... aber werden die Daten auch abgefragt und wenn ja, wie oft und in welcher Größe. Läuft die DB nur auf einen Server oder über mehrere verteilt ... usw etc.

 

[andy_0]

Das ist absolut richtig. Das sind alles Informationen, die nur der TE hat. Hat er sie nicht, muss er sie einholen. Es ist sehr wichtig, was die DB alles können muss, was für Transaktionen sie abarbeiten muss und wie viele Transaktionen pro Zeiteinheit mit wie viel Daten pro Transaktion anfallen.

 

[Daaron]

@ Yuuri
Das ändert aber nichts an der Frage, da MariaDB ja nur der Orcale unabhängige Fork ist.

MariaDB ist schon etwas mehr als MySQL mit anderem Namen. Tatsächlich ist MariaDB in einigen Szenarien signifikant schneller als MySQL, aber niemals langsamer. Außerdem kann es ein paar Tricks, die MySQL (stable) noch nicht beherrscht, weil Oracle (mutwillig?) die Weiterentwicklung verschleppen.
Es hat schon seine Gründe, warum z.B. Wikipedia auf MariaDB gewechselt sind. Da es (externe) Stable Repositories für alle größeren Distributionen gibt, gibt es eigentlich keinen Grund mehr, noch auf MySQL zu setzen.

Ich bin ja ein großer Fan von PostgreSQL. Quasi keine Limits & vollständig ACID-komp..

Viel mehr als MySQL/MariaDB kann PostgreSQL auch nicht. Es hat ein paar Vorteile, aber so gravierend sind die oftmals nicht. Kommt alles etwas auf den Anwendungsfall an.


Insgesamt ist das hier wirklich ne Frage nach: Was genau sind das für Datensätze?
Für so manchen Anwendungsfall wäre sogar ein NoSQL-Ansatz sinnig. Das heißt nicht, dass man zwingend auf Redis oder Mongo springen muss. MariaDB 10 hat ein paar Sachen drin, die verdammt nach NoSQL riechen, z.B. Dynamic Columns.

 

[ascer]

Also es werden verschiedene Experimente im Bereich der theoretischen Informatik gemacht (über Petri-Netze) und diese dann gespeichert. Die Daten werden zwar nicht von Millionen von Benutzern á la Facebook aufgerufen, aber es werden immer sehr viele Daten aufgerufen. Später könnte es eventuell bis zu 1.000 Benutzer geben die selten bis häufig sich die Daten anschauen. Es wird sehr viele JOINS und komplexe Abfragen geben, da jeder, der die Projektdaten anschaut, i.d.R. irgend eine Art von Auswertung wünscht um Erkenntnisse aus den Daten zu ziehen.

Noch eine Weile später werden dann KI-Robots simuliert, die aufgrund einem Teil der Daten dann verschiedene Algorithmen zur Wegfindung benutzen. Dort sähe es dann so aus, dass tendenziell weniger Datensätze auf einmal abgerufen werden, dafür aber sehr viele simulierte KI-Robots gleichzeitig Daten abrufen (da sich alle gleichzeitig bewegen).

Die Daten selbst werden auf einem Uniserver liegen...soweit mir bekannt ist das ein virtueller der sich auf 4 physikalische stützt...genaue Kenntnisse über die Architektur darüber habe ich nicht.

Bei den Datensätzen handelt es sich in der Masse um Integerwerte (i.d.R. 2 Byte lang), ein paar Doubles und noch weniger CHARs (i.d.R. 30 Zeichen lang, manche kürzer).

 

[Daaron]

Da hier wohl sogut wie keine Schreibvorgänge ablaufen lohnt sich ein separater Schreib-Server (als Master) wohl nicht. Dafür solltest du trotzdem über einen Cluster von unabhängigen Maschinen nachdenken, die jeweils genug RAM haben, um den gesamten Table Space zu lagern. Hast du erst einmal die kompletten Tabellen im Cache, dazu noch die häufigsten Queries, gibt es kaum noch Geschwindigkeitsgrenzen.

Vermeide ORDER BY, verwende LIMIT wo es möglich ist und sorg für klare Indizes. Das reicht dann schon.... Den Rest erledigt ein Load Balancer.

 

[ice-breaker]

Daaron du solltest dir PostgreSQL dann doch nochmal im Detail ansehen. Im Grunde sind beides Datenbanken, stimmt. Aber PostgreSQL implementiert dann fast alles aus de SqL Standard weggelassen hat oder was in MySQL echt dämlich umgesetzt wurde (z.B. nur 1 Trigger pro DML Befehl pro Tabelle).


Egal wie man es dreht und wendet, wenn man ne ziemlich einfache Datenbank designt, machen beide kaum einen Unterschied. Wenn man in die Details geht wie CHECK-Constraints, eigene Datentypen, Schemafree, Online-DDL-Operationen (was MySQL endlich in Angriff nimmt) oder Stored Procedures tuen sich schon Unterschiede auf.


Sollte die Datenbank in Richtung OLAP genutzt werden, würde ich aber auf jedenfall PostgreSQL empfehlen, sonst kann man auch sehr gut MySQL nehmen. Nur der Query-Optimizer von MySQL ist eben einer der schlechtesten der großen RDBMS. Für OLTP kein Problem, da hat man immer "simple" Abfragen, die auch nie lsnge laufen - das worauf MySQL am stärksten optimiert. Abr wirklich viele Joins mit großen Datenmengen kommt da nicht so gut.


Disclaimer: Ich nutze beide Datenbanken intensiv und mag auch beide. Aber zu behaupten sie sind im Grunde gleich ist eben fatal, da gibts schon große Unterschiede.

 

[hasugoon]

Also von MySQL würde ich hier großen Abstand nehmen. Mit PostgreSQL bist du schon einmal ganz gut bedient - alternativ könnte ich mir hier auch ganz gut eine Graph-Datenbank (z.B. Neo4j) vorstellen. Vorausgesetzt die Netze sollen auch in der Datenbank gespeichert werden oder geht es hier nur stumpf um irgendwelche Ergebnisdaten, welche aus anderen Systemen kommen?

 

[ice-breaker]

So pauschal kann man das aber nicht sagen
Der TE hat imho noch immer zu ungenau das Thema beschrieben. Aber wenn er wirklich "komplexe Queries" ausführen will, könnte ihn der Query Optimizer von MySQL schon die eine oder andere schlaflose Nacht kosten.

Eine GraphDB kann schon sinnvoll sein, wie Intel gerade festgestellt hat ([1], [2]), benötigt die Graph Datenbank Neo4j aber auch einiges an Wissen zur Optimierung.

Wo ich den Artikel gerade wieder geöffnet habe, ein Column Store könnte auch ziemlich passend sein, also wenn es wirklich in die OLAP-Richtung geht. Mit MonetDB gibts da auch eine ziemlich gute OpenSource Lösung.


Das Glaskugel raten hat einiges gemeinsam: Solange man nicht weiß, was genau gemacht werden soll, ist es auch schwierig eine gute Empfehlung zu geben. Ein RDBMS ist sicherlich schonmal ein guter Anfang, man sollte sich nur nicht darauf versteifen, mit der Zeit können andere Lösungen für das Problem deutlich sinnvoller sein. Und gerade Column Stores können einen massiven Performance-Zuwachs bieten (teilweise > 100x) durch die ganz andere Art der Speicherung und dem daraus resultierenden viel geringeren IO-Aufwand (und der besseren Kompression).