Wie groß kann eine MySQL-Datenbank werden, bevor die Leistung abnimmt?

StackOverflow https://stackoverflow.com/questions/1276

Frage

Ab wann beginnt eine MySQL-Datenbank an Leistung zu verlieren?

  • Spielt die physische Datenbankgröße eine Rolle?
  • Spielt die Anzahl der Datensätze eine Rolle?
  • Ist der Leistungsabfall linear oder exponentiell?

Ich verfüge über eine meiner Meinung nach große Datenbank mit etwa 15 Millionen Datensätzen, die fast 2 GB belegen.Gibt es auf der Grundlage dieser Zahlen einen Anreiz für mich, die Daten zu bereinigen, oder kann ich gefahrlos zulassen, dass sie noch ein paar Jahre weiter skalieren?

War es hilfreich?

Lösung

Die physische Datenbankgröße spielt keine Rolle.Die Anzahl der Datensätze spielt keine Rolle.

Meiner Erfahrung nach ist das größte Problem, auf das Sie stoßen werden, nicht die Größe, sondern die Anzahl der Abfragen, die Sie gleichzeitig bearbeiten können.Höchstwahrscheinlich müssen Sie zu einer Master/Slave-Konfiguration wechseln, damit die Leseabfragen für die Slaves und die Schreibabfragen für den Master ausgeführt werden können.Wenn Sie dazu jedoch noch nicht bereit sind, können Sie jederzeit Ihre Indizes für die von Ihnen ausgeführten Abfragen optimieren, um die Antwortzeiten zu verkürzen.Außerdem können Sie unter Linux viele Optimierungen am Netzwerk-Stack und Kernel vornehmen, die hilfreich sein werden.

Ich habe meine Kapazität auf bis zu 10 GB steigern lassen, mit nur einer mäßigen Anzahl an Verbindungen, und die Anfragen wurden problemlos verarbeitet.

Ich würde mich zuerst auf Ihre Indizes konzentrieren, dann einen Serveradministrator einen Blick auf Ihr Betriebssystem werfen lassen, und wenn das alles nicht hilft, ist es vielleicht an der Zeit, eine Master/Slave-Konfiguration zu implementieren.

Andere Tipps

Im Allgemeinen ist dies ein sehr subtiles Problem und überhaupt nicht trivial.Ich ermutige Sie zum Lesen mysqlperformanceblog.com Und Hochleistungs-MySQL.Ich glaube wirklich, dass es dafür keine allgemeingültige Antwort gibt.

Ich arbeite an einem Projekt, das über eine MySQL-Datenbank mit fast 1 TB Daten verfügt.Der wichtigste Skalierbarkeitsfaktor ist RAM.Wenn die Indizes Ihrer Tabellen in den Speicher passen und Ihre Abfragen stark optimiert sind, können Sie mit einer durchschnittlichen Maschine eine angemessene Anzahl an Anfragen bedienen.

Die Anzahl der Datensätze spielt eine Rolle, je nachdem, wie Ihre Tabellen aussehen.Es ist ein Unterschied, viele Varchar-Felder zu haben oder nur ein paar Ints oder Longs.

Auch die physische Größe der Datenbank spielt eine Rolle:Denken Sie zum Beispiel an Backups.Abhängig von Ihrer Engine wachsen Ihre physischen Datenbankdateien, verkleinern sich jedoch nicht, zum Beispiel mit innodb.Das Löschen vieler Zeilen trägt also nicht dazu bei, Ihre physischen Dateien zu verkleinern.

Es steckt viel dahinter und wie so oft steckt der Teufel im Detail.

Die Datenbankgröße ist wichtig.Wenn Sie über mehr als eine Tabelle mit mehr als einer Million Datensätzen verfügen, nimmt die Leistung tatsächlich ab.Die Anzahl der Datensätze hat natürlich Einfluss auf die Leistung: MySQL kann bei großen Tabellen langsam sein.Wenn Sie eine Million Datensätze erreichen, treten Leistungsprobleme auf, wenn die Indizes nicht richtig eingestellt sind (z. B. keine Indizes für Felder in „WHERE-Anweisungen“ oder „ON-Bedingungen“ in Joins).Wenn Sie 10 Millionen Datensätze erreichen, treten Leistungsprobleme auf, selbst wenn alle Indizes richtig sind.Hardware-Upgrades – das Hinzufügen von mehr Speicher und mehr Prozessorleistung, insbesondere Arbeitsspeicher – helfen oft dabei, die gravierendsten Probleme zu reduzieren, indem sie die Leistung zumindest bis zu einem gewissen Grad wieder steigern.Zum Beispiel 37 Signale gingen von 32 GB RAM auf 128 GB RAM für den Basecamp-Datenbankserver.

Ich würde mich zuerst auf Ihre Indizes konzentrieren und dann einen Serveradministrator einen Blick auf Ihr Betriebssystem werfen lassen. Wenn das alles nicht hilft, ist es möglicherweise Zeit für eine Master/Slave-Konfiguration.

Das ist richtig.Eine andere Sache, die normalerweise funktioniert, besteht darin, einfach die Datenmenge zu reduzieren, mit der wiederholt gearbeitet wird.Wenn Sie über „alte Daten“ und „neue Daten“ verfügen und 99 % Ihrer Abfragen mit neuen Daten funktionieren, verschieben Sie einfach alle alten Daten in eine andere Tabelle – und schauen Sie sie sich nicht an ;)

-> Schauen Sie mal vorbei Partitionierung.

2 GB und etwa 15 Millionen Datensätze sind eine sehr kleine Datenbank – ich habe viel größere Datenbanken auf einem Pentium III(!) ausgeführt und alles lief immer noch ziemlich schnell.Wenn Ihres langsam ist, handelt es sich um ein Datenbank-/Anwendungsdesignproblem, nicht um ein MySQL-Problem.

Es ist irgendwie sinnlos, über „Datenbankleistung“ zu sprechen. „Abfrageleistung“ ist hier ein besserer Begriff.Und die Antwort lautet:Dies hängt von der Abfrage, den verarbeiteten Daten, den Indizes, der Hardware usw. ab.Mit der EXPLAIN-Syntax können Sie sich ein Bild davon machen, wie viele Zeilen gescannt werden und welche Indizes verwendet werden.

2 GB gelten nicht wirklich als „große“ Datenbank – es handelt sich eher um eine mittlere Größe.

Achten Sie auch auf komplexe Verknüpfungen.Neben dem Transaktionsvolumen kann auch die Transaktionskomplexität ein wichtiger Faktor sein.

Das Refactoring schwerer Abfragen bietet manchmal eine große Leistungssteigerung.

Ich wurde einmal aufgefordert, mir ein MySQL anzusehen, das „nicht mehr funktionierte“.Ich habe festgestellt, dass sich die DB-Dateien auf einem mit NFS2 gemounteten Network Appliance-Filer befanden und eine maximale Dateigröße von 2 GB hatten.Und tatsächlich hatte die Tabelle, die keine Transaktionen mehr akzeptierte, genau 2 GB auf der Festplatte.Aber was die Leistungskurve angeht, wurde mir gesagt, dass es wie ein Champion funktionierte, bis es überhaupt nicht mehr funktionierte!Diese Erfahrung ist für mich immer eine schöne Erinnerung daran, dass es immer Dimensionen gibt, die über und unter denen liegen, die man von Natur aus vermutet.

Ein zu berücksichtigender Punkt ist auch der Zweck des Systems und der Daten im Alltag.

Beispielsweise sind für ein System mit GPS-Überwachung von Autos keine relevanten Abfragedaten aus den Positionen des Autos in den vergangenen Monaten erforderlich.

Daher können die Daten zur möglichen Abfrage an andere historische Tabellen übergeben werden und die Ausführungszeiten der täglichen Abfragen verkürzt werden.

Ich verwalte derzeit eine MySQL-Datenbank auf der Cloud-Infrastruktur von Amazon, die auf 160 GB angewachsen ist.Die Abfrageleistung ist in Ordnung.Was zu einem Albtraum geworden ist, sind Backups, Wiederherstellungen, das Hinzufügen von Slaves oder alles andere, was den gesamten Datensatz oder sogar DDL für große Tabellen betrifft.Es ist problematisch geworden, einen sauberen Import einer Dump-Datei zu erhalten.Um den Prozess stabil genug für die Automatisierung zu machen, mussten verschiedene Entscheidungen getroffen werden, um der Stabilität Vorrang vor der Leistung zu geben.Wenn wir jemals eine Wiederherstellung nach einer Katastrophe mithilfe eines SQL-Backups durchführen müssten, wären wir tagelang außer Betrieb.

Die horizontale Skalierung von SQL ist ebenfalls ziemlich mühsam und führt in den meisten Fällen dazu, dass Sie es auf eine Weise verwenden, die Sie wahrscheinlich nicht beabsichtigt hatten, als Sie sich entschieden haben, Ihre Daten überhaupt in SQL zu speichern.Shards, Lese-Slaves, Multi-Master usw. sind alles wirklich beschissene Lösungen, die alles, was Sie jemals mit der Datenbank machen, komplexer machen, und keine davon löst das Problem;mildert es nur in gewisser Weise.Ich würde Ihnen dringend empfehlen, die Verlagerung einiger Ihrer Daten aus MySQL (oder wirklich jedem SQL) in Betracht zu ziehen, wenn Sie sich einem Datensatz einer Größe nähern, bei der solche Dinge zu einem Problem werden.

Wenn die Datenbank nicht richtig gestaltet ist, kann sich die Leistung bereits nach wenigen tausend Zeilen verschlechtern.

Wenn Sie über geeignete Indizes verfügen, geeignete Engines verwenden (verwenden Sie MyISAM nicht, wenn mehrere DMLs erwartet werden), Partitionierung verwenden, je nach Verwendung den richtigen Speicher zuweisen und natürlich über eine gute Serverkonfiguration verfügen, kann MySQL sogar Daten im Terabyte-Bereich verarbeiten!

Es gibt immer Möglichkeiten, die Datenbankleistung zu verbessern.

Es hängt von Ihrer Abfrage und Validierung ab.

Ich habe zum Beispiel mit einer Tabelle mit 100.000 Medikamenten gearbeitet, die eine Spalte „Generischer Name“ enthält, in der mehr als 15 Zeichen für jedes Medikament in dieser Tabelle enthalten sind. Ich habe eine Abfrage gestellt, um die generischen Namen von Medikamenten zwischen zwei Tabellen zu vergleichen. Die Abfrage dauert Die Ausführung dauert mehr Minuten. Wenn Sie die Medikamente anhand des Medikamentenindex und einer ID-Spalte (wie oben erwähnt) vergleichen, dauert es nur wenige Sekunden.

Die Datenbankgröße spielt in Bezug auf Bytes und die Anzahl der Tabellenzeilen eine Rolle.Sie werden einen großen Leistungsunterschied zwischen einer leichten Datenbank und einer mit Blobs gefüllten Datenbank feststellen.Einmal blieb meine Anwendung hängen, weil ich Binärbilder in Felder einfügte, anstatt Bilder in Dateien auf der Festplatte zu behalten und nur Dateinamen in die Datenbank einzufügen.Das Durchlaufen einer großen Anzahl von Zeilen ist hingegen nicht kostenlos.

Nein, das spielt keine Rolle.Die MySQL-Geschwindigkeit beträgt etwa 7 Millionen Zeilen pro Sekunde.Man kann es also durchaus skalieren

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top