MySQL / MariaDB und Skalierung

[RcRaCk2k]

Servus Leute!

Da hier gerade die Rede von "Skalierung" auf MySQL / MariaDB ist. Wie kann man bei einer schnell lebenden MySQL / MariaDB Installation in einem Cluster auf Skalierung setzen?

Wie darf man Skalierung verstehen?

Nehmen wir mal an, wir haben eine DB mit 5 Mio Zeilen in einer Tabelle. Die Datendatei beherbergt ca 8 GB Daten (inkl. Index). Nun kommen viele Reads die zwar auf Indexe zugreifen können, aber die Abfrage dennoch eine Sekunde dauert. Nun kommen 100.000 Kunden auf den Server, der Server ist blockiert, da die MySQL max. 100 Nutzer zulässt. Um 100.000 Nutzer mit Daten versorgen zu können würde die Auslieferung 1000 Sekunden benötigen, bis auch der letzte Nutzer seine Daten bekommen hat.

Rechnung: 100.000 Nutzer, 100 Nutzer gleichzeitig, jeder Aufruf eine Sekunde
Mathematik: 100.000 / 100 * 1 Sekunde = 1000 Sekunden

Die Datenbank skaliert also nicht mehr. Nun verteile ich meine Kunden auf 1.000 Server in einem Cluster, damit 100 Nutzer zur gleichen Zeit in einer Sekunde ihre Daten bekommen können.

Dieses Problem kann man ja mittels Replizierung lösen und damit horizontal Skalieren.

Damit die Sache am besten Skaliert, gehe ich so vor, dass ein Aufruf auf den Load-Balancer immer "per request" den Server wechselt. Spricht Nutzer A kann bei jedem Aufruf auf irgendeinen der 1000 Server landen.

Wenn man jetzt einen Online-Shop betreibt, der Kunde sich registriert, dann muss der neue Kunden-Datensatz extremst schnell propagieren, denn sonst greift man auf einen nicht existierenden Datensatz zurück (MySQL lieferte 0 Resultate). Bei 1.000 Server kann die Propagation schon Sekunden in Anspruch nehmen.

Wie kann man diesem Problem Herr werden?
Was habt ihr für Lösungen für solche Datenmengen?

PS: Geht bei dem Beispiel davon aus, dass alle Tabellen auf Indexe und Querys zu 100% optimiert wurden. Nur noch eine horizontale Skalierung kann Abhilfe schaffen.

[fool2]

MySQL Cluster mal angeschaut? Das wird auch von großen Onlineshops eingesetzt.

[Trockenobst]

RcRaCk2k schrieb:
--------------------------------------------------------------------------------
> PS: Geht bei dem Beispiel davon aus, dass alle Tabellen auf Indexe und
> Querys zu 100% optimiert wurden. Nur noch eine horizontale Skalierung kann
> Abhilfe schaffen.

Es gibt Windows/Unix-Server mit 32x8Cores in die Du 2000€ teure
Glasfaser-Netzwerkkarten rein stecken kannst. So ein "Metall" kostet
25.000€ aufwärts. Auf so einer Box kannst Du problemlos 10.000 Kunden/s
fahren. Einige Webseiten haben 1 Million teure Maschinen da stehen
die fahren Problemlos auch 500k/s.

Scale Up (also größere Maschinen) ist ebenso potentiell möglich
wie das Scale Out (also mehrere Maschinen plus Loadbalancer).

Außerdem muss man sich bei solcher Last erst mal ansehen wie das
System läuft - etwa durch dynamische Proxys, die z.B. Webshops
verwenden. So häufig ändert sich z.B. eine Produktbeschreibung
nicht. Große Teile kann man evtl. nur bei Anfrage generieren,
und sonst nur statisch ausliefern. Da kann man viel machen als
nur an der DB rum schrauben.

Replikation wäre eine Möglichkeit. Die andere wäre eine Separation,
d.h. Kunden mit Namen A-F sind auf DB-Node 1 und G-J sind auf
DB-Node 2 etc. Wenn man nicht weiß _was_ die Last ist, kann man
nicht optimieren.

Auch müsste man sich ansehen, ob es wirklich notwendig ist
alles in einer SQLDB vorzuhalten. Ein Wechsel z.B. einer Volltext
Suche zu spezialisierten Suchmaschinen Servern kann eine DB mal
eben um 70% entlasten. Auch könnte der Wechsel von Rails/PHP zu
Java oder eine andere Struktur der Applikation massiv Performance
auf der selben HW rausholen.

Anders gesagt: wenn Du erstmal 1 Million Kunden pro Tag hast,
hast Du auch das Geld die Leute dafür zu bezahlen sie schon
100 solche Systeme gebaut haben und dir genau sagen können was
Du brauchst. Das musst du dir nicht alles per Halbwissen
zusammen stöpseln.

[Quantium40]

RcRaCk2k schrieb:
--------------------------------------------------------------------------------
> Nehmen wir mal an, wir haben eine DB mit 5 Mio Zeilen in einer Tabelle. Die
> Datendatei beherbergt ca 8 GB Daten (inkl. Index). Nun kommen viele Reads
> die zwar auf Indexe zugreifen können, aber die Abfrage dennoch eine Sekunde
> dauert. Nun kommen 100.000 Kunden auf den Server, der Server ist blockiert,
> da die MySQL max. 100 Nutzer zulässt. Um 100.000 Nutzer mit Daten versorgen
> zu können würde die Auslieferung 1000 Sekunden benötigen, bis auch der
> letzte Nutzer seine Daten bekommen hat.
8GB schreien nach einem Umzug der Datenbank in den RAM.
Abfragen, die je 1s dauern deutet übrigens auf sehr schlechtes Datenbankdesign, ungünstige Indexe oder nicht optimierte Abfragen hin.
Tip: WHERE-Klauseln werden von rechts nach links aufgelöst und die am weitesten rechts stehende sollte soviel Zeilen wie möglich ausschliessen. Indexe funktionieren nur gut, wenn die Daten sehr verschieden sind. Viele gleiche Daten in einer Spalte sind für die Indizierung ungeeignet.
Was auch dem Tempo helfen kann ist ein LIMIT n (n=Anzahl) am Ende um die Ergebnismenge zu begrenzen.
MySQL lässt übrigens nahezu beliebig viele parallele Nutzer zu. Man muss nur die max connections in der Konfiguration entsprechend anpassen.

> Rechnung: 100.000 Nutzer, 100 Nutzer gleichzeitig, jeder Aufruf eine
> Sekunde
> Mathematik: 100.000 / 100 * 1 Sekunde = 1000 Sekunden
> Die Datenbank skaliert also nicht mehr. Nun verteile ich meine Kunden auf
> 1.000 Server in einem Cluster, damit 100 Nutzer zur gleichen Zeit in einer
> Sekunde ihre Daten bekommen können.
> Dieses Problem kann man ja mittels Replizierung lösen und damit horizontal
> Skalieren.
1000 Server wäre bei der geringen Datenmenge übertrieben, aber grundsätzlich ginge das.

> Damit die Sache am besten Skaliert, gehe ich so vor, dass ein Aufruf auf
> den Load-Balancer immer "per request" den Server wechselt. Spricht Nutzer A
> kann bei jedem Aufruf auf irgendeinen der 1000 Server landen.
Das ist eher suboptimal. Da der Server innerhalb gewisser Grenzen Ergebnisse vorheriger Abfragen im Cache hält und bestimmte Abfragen beim selben Nutzer zum selben Ergebnis führen, ist es durchaus sinnvoll, wenn man versucht, einen Nutzer auf einem Server zu halten.

> Wenn man jetzt einen Online-Shop betreibt, der Kunde sich registriert, dann
> muss der neue Kunden-Datensatz extremst schnell propagieren, denn sonst
> greift man auf einen nicht existierenden Datensatz zurück (MySQL lieferte 0
> Resultate). Bei 1.000 Server kann die Propagation schon Sekunden in
> Anspruch nehmen.
Du solltest versuchen hochvariable Daten von (semi)statischen Daten zu trennen.
Wenn du einen Nutzer auf einem Server halten kannst und nicht ständig auf andere Server umverfrachtest, besteht die Möglichkeit, ein mehrstufiges Verfahren zu nutzen.
Du hättest dafür z.B. die Warendaten des Shops auf jedem Server aber die Kundendaten erstmal nur zentral. Wenn die Abfrage der Kundendaten an einen der Server gelangt, muss dieser sich diese Daten einmalig holen und dies auf dem Masterserver vermerken. Damit liefen alle Änderungen/Abfragen dieser Daten für eine gewisse Zeit bis zum nächsten Sync mit dem Master nur über den entsprechenden Frontend-Server.

> Wie kann man diesem Problem Herr werden?
> Was habt ihr für Lösungen für solche Datenmengen?
8GB ist doch noch übersichtlich.
Wie gesagt - ab damit in den RAM und das bißchen ist kein Thema mehr.

> PS: Geht bei dem Beispiel davon aus, dass alle Tabellen auf Indexe und
> Querys zu 100% optimiert wurden. Nur noch eine horizontale Skalierung kann
> Abhilfe schaffen.