1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › MySQL: SkySQL…

MySQL / MariaDB und Skalierung

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. MySQL / MariaDB und Skalierung

    Autor: RcRaCk2k 13.04.11 - 20:32

    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.

  2. Re: MySQL / MariaDB und Skalierung

    Autor: fool2 13.04.11 - 21:37

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

  3. Re: MySQL / MariaDB und Skalierung

    Autor: Trockenobst 14.04.11 - 01:28

    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.

  4. Re: MySQL / MariaDB und Skalierung

    Autor: Quantium40 14.04.11 - 02:09

    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.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT-Leiter (m/w/d)
    Hays AG, Nürnberg
  2. IT-Recruiter (m/w/d)
    Cegeka Deutschland GmbH, Neu Isenburg, Köln
  3. Customer Support Representative* Deutsch
    Gameforge AG, Karlsruhe
  4. IT-Spezialist als Software-Entwickler / Tester (Informatiker, Fachinformatiker, Wirtschaftsinformatiker ... (m/w/d)
    tailor-made software GmbH, deutschlandweit (Home-Office möglich)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Ryzen 7 5800X für 469€)


Haben wir etwas übersehen?

E-Mail an news@golem.de