Wie groß kann eine MySQL-Datenbank werden, bevor die Leistung nachlässt

  • Ab wann verliert eine MySQL-Datenbank an Leistung?

    • Ist die Größe der physischen Datenbank von Bedeutung?
    • Ist die Anzahl der Datensätze von Bedeutung?
    • Ist eine Leistungsverschlechterung linear oder exponentiell?

    Ich habe meiner Meinung nach eine große Datenbank mit ungefähr 15 Millionen Datensätzen, die fast 2 GB beanspruchen. Gibt es aufgrund dieser Zahlen einen Anreiz für mich, die Daten zu bereinigen, oder kann ich sicher sein, dass die Skalierung noch ein paar Jahre fortgesetzt wird?

    28 January 2016
    davejalUltimateBrent
13 answers
  • Die physische Datenbankgröße spielt keine Rolle. Die Anzahl der Datensätze spielt keine Rolle.

    Meiner Erfahrung nach ist das größte Problem, das Sie ausführen werden, nicht die Größe, sondern die Anzahl der Abfragen, die Sie bearbeiten können Zeit. Wahrscheinlich 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 jedoch noch nicht dazu bereit sind, können Sie Ihre Indizes immer für die Abfragen anpassen, die Sie ausführen, um die Antwortzeiten zu beschleunigen. Außerdem gibt es viele Optimierungsmöglichkeiten, die Sie in Bezug auf den Netzwerkstack und den Kernel in Linux tun können.

    Ich hatte meine bis zu 10 GB, mit nur einer moderaten Anzahl von Verbindungen und es hat die Anforderungen gut verarbeitet.

    Ich würde mich zuerst auf Ihre Indizes konzentrieren, dann einen Serveradministrator auf Ihr Betriebssystem untersuchen lassen, und wenn dies alles nicht hilft, könnte es helfen Zeit, eine Master / Slave-Konfiguration zu implementieren.

    31 July 2013
    NTDLS
  • Im Allgemeinen ist dies eine sehr subtile Angelegenheit und überhaupt nicht trivial. Ich empfehle Ihnen, mysqlperformanceblog.com und Hochleistungs-MySQL . Ich glaube wirklich, dass es hierfür keine generelle Antwort gibt.

    Ich arbeite an einem Projekt, das eine MySQL-Datenbank mit fast 1 TB Daten enthält. Der wichtigste Skalierbarkeitsfaktor ist RAM. Wenn die Indizes Ihrer Tabellen in den Speicher passen und Ihre Abfragen stark optimiert sind, können Sie eine angemessene Anzahl von Anforderungen mit einer durchschnittlichen Maschine abwickeln.

    Die Anzahl der Datensätze ist abhängig davon, wie Ihre Tabellen aussehen. Es ist ein Unterschied, viele Varchar-Felder oder nur ein paar Ints oder Longs zu haben.

    Die physische Größe der Datenbank ist ebenfalls wichtig: Denken Sie zum Beispiel an Backups. Je nach Engine wachsen Ihre physischen Datenbankdateien, schrumpfen jedoch nicht, zum Beispiel mit innodb. Das Löschen einer großen Anzahl von Zeilen hilft also nicht dabei, Ihre physischen Dateien zu verkleinern.

    Es gibt viele Probleme bei diesen Problemen, und da der Teufel in vielen Fällen in den Details steckt.

    12 May 2017
    Elnur Abdurrakhimovsvassr
  • Die Datenbankgröße ist wichtig . Wenn Sie mehr als eine Tabelle mit mehr als einer Million Datensätzen haben, nimmt die Leistung tatsächlich ab. Die Anzahl der Datensätze beeinflusst natürlich die Leistung: MySQL kann bei großen Tabellen langsam sein . Wenn Sie eine Million Datensätze erreichen, erhalten Sie Leistungsprobleme, wenn die Indizes nicht richtig gesetzt sind (z. B. keine Indizes für Felder in "WHERE-Anweisungen" oder "ON-Bedingungen" in Joins). Wenn Sie 10 Millionen Datensätze erreichen, werden Sie mit Leistungsproblemen konfrontiert, auch wenn Sie alle Ihre Indizes richtig haben. Hardware-Upgrades - mehr Speicher und mehr Prozessorleistung, insbesondere Arbeitsspeicher - helfen häufig, die schwerwiegendsten Probleme zu reduzieren, indem sie die Leistung zumindest bis zu einem gewissen Grad wieder erhöhen. Zum Beispiel 37 Signale gingen von 32 GB RAM auf 128 GB RAM für den Basecamp-Datenbankserver.

    25 November 2013
    0x4a6f4672
  • Ich würde mich zuerst auf Ihre Indizes konzentrieren, dann einen Serveradministrator auf Ihr Betriebssystem überprüfen lassen, und wenn dies alles nicht hilft, könnte es Zeit für eine Master / Slave-Konfiguration sein.

    Das stimmt. Eine andere Sache, die normalerweise funktioniert, ist, die Datenmenge zu reduzieren, mit der wiederholt gearbeitet wird. Wenn Sie "alte Daten" und "neue Daten" haben und 99% Ihrer Abfragen mit neuen Daten arbeiten, verschieben Sie einfach alle alten Daten in eine andere Tabelle - und betrachten Sie sie nicht;)

    - & gt; Schauen Sie sich die Partitionierung an.

    15 February 2017
    BlaMSanganabasu
  • 2 GB und etwa 15 Millionen Datensätze sind eine sehr kleine Datenbank - ich habe viel größere auf Pentium III (!) ausgeführt und alles ist noch ziemlich schnell gelaufen. Wenn Ihre langsame ist, handelt es sich um eine Datenbank / Anwendung Design-Problem, kein MySQL-Problem.

    05 August 2010
    ian
  • Es ist sinnlos, von "Datenbankleistung" zu sprechen. "Abfrageleistung" ist hier ein besserer Begriff. Und die Antwort lautet: Es hängt von der Abfrage ab, von den Daten, für die sie ausgeführt wird, von Indizes, von Hardware usw. Sie können eine Vorstellung davon bekommen, wie viele Zeilen durchsucht werden und welche Indizes mit der EXPLAIN-Syntax verwendet werden.

    2 GB zählen nicht wirklich als "große" Datenbank - sie sind eher mittelgroß.

    06 August 2008
    deadprogrammer
  • Ich war einmal dazu aufgerufen, sich eine Mysql anzusehen, die "aufgehört hat zu arbeiten". Ich entdeckte, dass sich die DB-Dateien auf einem Network Appliance-Dateiserver befanden, der mit NFS2 geladen wurde und eine maximale Dateigröße von 2 GB hatte. Und tatsächlich war die Tabelle, die keine Transaktionen mehr angenommen hatte, genau 2 GB auf der Festplatte. Aber in Bezug auf die Leistungskurve wurde mir gesagt, dass es wie ein Champion funktionierte, bis es überhaupt nicht funktionierte! Diese Erfahrung dient mir immer als schöne Erinnerung daran, dass es immer Dimensionen oberhalb und unterhalb der von Ihnen natürlich vermuteten Größe gibt.

    06 August 2008
    jj33
  • Ein zu berücksichtigender Punkt ist auch der Zweck des Systems und der täglichen Daten.

    Zum Beispiel für ein System mit GPS-Überwachung von Fahrzeugen ist nicht relevant Abfragedaten von den Positionen des Autos in den vergangenen Monaten.

    Daher können die Daten zu anderen historischen Tabellen zur möglichen Abfrage weitergegeben werden und die Ausführungszeiten des Tages auf reduzieren Tagesabfragen.

    06 December 2012
    alditisVipul Shah
  • Achten Sie auch auf komplexe Joins. Die Komplexität von Transaktionen kann zusätzlich zum Transaktionsvolumen ein großer Faktor sein.

    Die Umgestaltung starker Abfragen bietet manchmal einen großen Leistungsschub.

    04 August 2008
    saint_groceon
  • Ich verwalte derzeit eine MySQL-Datenbank in 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, Hinzufügen von Slaves oder andere Elemente, die sich auf das gesamte Dataset oder sogar DDL für große Tabellen beziehen. Der saubere Import einer Dump-Datei ist problematisch geworden. Um den Prozess stabil genug für die Automatisierung zu machen, mussten verschiedene Entscheidungen getroffen werden, um die Stabilität der Leistung vorzuziehen. Wenn wir uns mit einem SQL-Backup jemals von einem Notfall erholen mussten, wären wir tagelang ausgefallen.

    Das horizontale Skalieren von SQL ist auch ziemlich schmerzhaft und führt in den meisten Fällen zur Verwendung Es ist in einer Weise, die Sie wahrscheinlich nicht beabsichtigten, als Sie Ihre Daten überhaupt in SQL ablegen wollten. Shards, Read Slaves, Multi-Master usw. sind alles wirklich beschissene Lösungen, die alles, was Sie jemals mit der DB machen, komplexer machen, und keiner von ihnen löst das Problem. mildert es nur in gewisser Weise. Ich würde stark vorschlagen

    30 June 2017
    Rich Remer