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

MySQL / MariaDB und Skalierung

  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. Zum Login

Stellenmarkt
  1. SIZ GmbH, Bonn
  2. über duerenhoff GmbH, Raum Stuttgart
  3. WDS GmbH, Lippstadt
  4. Amprion GmbH, Dortmund

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Kaufberatung (2020): Die richtige CPU und Grafikkarte
Kaufberatung (2020)
Die richtige CPU und Grafikkarte

Grafikkarten und Prozessoren wurden 2019 deutlich besser, denn AMD ist komplett auf 7-nm-Technik umgestiegen. Intel hat zwar 10-nm-Chips marktreif, die Leistung stagniert aber und auch Nvidia verkauft nur 12-nm-Designs. Wir beraten bei Komponenten und geben einen Ausblick.
Von Marc Sauter

  1. SSDs Intel arbeitet an 144-Schicht-Speicher und 5-Bit-Zellen
  2. Schnittstelle PCIe Gen6 verdoppelt erneut Datenrate

Programmieren lernen: Informatik-Apps für Kinder sind oft zu komplex
Programmieren lernen
Informatik-Apps für Kinder sind oft zu komplex

Der Informatikunterricht an deutschen Schulen ist in vielen Bereichen mangelhaft. Apps versprechen, Kinder beim Spielen einfach an das Thema heranzuführen. Das können sie aber bislang kaum einhalten.
Von Tarek Barkouni

  1. Kano-PC Kano und Microsoft bringen Lern-Tablet mit Windows 10

Europäische Netzpolitik: Die Rückkehr des Axel Voss
Europäische Netzpolitik
Die Rückkehr des Axel Voss

Elektronische Beweismittel, Nutzertracking, Terrorinhalte: In der EU stehen in diesem Jahr wichtige netzpolitische Entscheidungen an. Auch Axel Voss will wieder mitmischen. Und wird Ursula von der Leyen mit dem "Digitale-Dienste-Gesetz" wieder zu "Zensursula"?
Eine Analyse von Friedhelm Greis

  1. Mitgliederentscheid Netzpolitikerin Esken wird SPD-Chefin
  2. Nach schwerer Krankheit FDP-Netzpolitiker Jimmy Schulz gestorben

  1. Stuttgart: Vodafone bringt LTE im UMTS-Bereich in die U-Bahn
    Stuttgart
    Vodafone bringt LTE im UMTS-Bereich in die U-Bahn

    Stuttgart erhält besseres Netz in der U-Bahn durch LTE bei 2.100 MHz. Vodafone hat hier die Projektführung. Der Bereich war eigentlich für den UMTS-Betrieb vorgesehen.

  2. Gegen Huawei: Telefónica Deutschland setzt auf Open-RAN-Architektur
    Gegen Huawei
    Telefónica Deutschland setzt auf Open-RAN-Architektur

    Auch wenn Telefónica Deutschland Huawei verteidigt, will man gerne unabhängig werden. Dafür will der Konzern auch in Deutschland Open RAN einsetzen.

  3. 10-nm-Prozessor: Intel-Benchmarks zeigen Ice-Lake-Rückstand
    10-nm-Prozessor
    Intel-Benchmarks zeigen Ice-Lake-Rückstand

    Eigentlich wollte Intel demonstrieren, wie viel besser die eigenen Ultrabook-Chips verglichen mit AMDs (alten) Ryzen-Modellen abschneiden. Dabei zeigt sich aber auch, dass die 10-nm-Ice-Lake-Prozessoren zumindest CPU-seitig langsamer sind als ihre 14-nm-Comet-Lake-Pendants.


  1. 19:02

  2. 18:14

  3. 17:49

  4. 17:29

  5. 17:10

  6. 17:01

  7. 16:42

  8. 16:00