Wie groß ist zu groß für eine MySQL-Tabelle?

Question

Ich war schließlich überzeugt, meine kleineren Tabellen in eine große zu legen, aber genau wie groß ist zu groß für eine MySQL-Tabelle?

Ich habe eine Tabelle mit 18 Feldern. Einige sind TEXT, einige sind kurz VARCHAR(16), andere länger VARCHAR(100).

Im Moment bekommen wir ungefähr 200.000 Zeilen pro Tag, das wären 6 Millionen + ein Monat. Wie groß ist zu groß? Ist es wichtig, wie viele Felder Sie haben oder nur Zeilen?

Answer 1

Es gibt nicht eine große allgemeine Lösung für die Frage: „Wie groß ist zu groß“ - solche Bedenken auf häufig abhängig sind, was Sie mit Ihren Daten tun und was Ihre Leistungsüberlegungen sind.

Es gibt einige grundlegende Einschränkungen für die Tabellengrößen. Sie können nicht mehr als 1000 Spalten haben. Deine Aufzeichnungen dürfen nicht größer als 8k sein. Diese Grenzwerte ändern sich je nach Datenbankmodul. (Die hier sind für InnoDB.)

Es klingt wie Sie mehrere verschiedene Datensätze in eine Tabelle zusammengeführt haben. Sie haben wahrscheinlich einige Felder, die Ihnen sagen, zu welchem ​​Datensatz dieser Datensatz gehört, zusammen mit einigen Datenfeldern und einigen Zeitstempelinformationen. Das ist keine sehr breite Aufzeichnung (es sei denn, Sie protokollieren, sagen wir, alle Eingangsparameter jeder Anfrage). Ihr Hauptproblem wird mit Selektivität sein. Eine sinnvolle Indizierung dieser Tabelle wird eine Herausforderung darstellen. Wenn Ihre allgemeinen Felder so selektiv sein können, dass Sie sie verwenden können, um zu den gewünschten Datensätzen zu gelangen, ohne die Tabelle zu konsultieren, wird das ein großer Vorteil sein. (Vgl. Tabelle Scan)

Für so viele Datensätze pro Tag (im Grunde, zwei eine Sekunde den ganzen Tag, und ich nehme an, Sie haben eine Spitzenlastperiode, wo es viel höher ist), wollen Sie auch machen sicher, dass Sie speziell auf Optimierungen bei der Verbesserung der Einführungsgeschwindigkeit. In der Regel sind mehr Indizes = langsamere Einfügungen. Wenn Sie können, sollten Sie in Betracht ziehen, veraltete Datensätze vollständig in einer anderen Tabelle zu archivieren. An früheren Arbeitsplätzen haben wir eine Archivierungsstrategie des letzten Monats, der letzten drei Monate, der letzten sechs Monate jeweils in separaten Tabellen verwendet. Eine andere Idee ist, ältere Datensätze zu löschen. Viele Umgebungen benötigen einfach keine Informationen über ein bestimmtes Datum hinaus. Es ist oft zu teuer, wenn man sich vor drei Monaten an Aufzeichnungen hält.

Schließlich vernachlässigen Sie nicht den physischen Speicher Ihrer Tabelle. Je dünner Ihre Datensätze sind, desto weniger physisches IO muss auftreten, um einen Datensatz lesen (oder auch einfügen) zu können. Sie können Ihre Indizes auf einer separaten physischen Festplatte speichern. Wenn es viele redundante Daten in Ihren Datensätzen gibt, die die komprimierte Tabelle speichern, ist dies möglicherweise eine Geschwindigkeitssteigerung. Wenn Sie etwas Geld zum Brennen haben, sollten Sie den Wert eines guten RAID-Arrays für das Striping Ihrer Daten berücksichtigen.

Also, um Ihre grundlegende Frage zu beantworten: Es ist eine Menge von Aufzeichnungen, aber mit einem sorgfältigen Auge auf das Tuning, wird es kein Problem sein.

Answer 2

Ich denke es hängt im Grunde. Welche MySQL-Version verwenden Sie, welches OS und verwenden Sie MyISAM- oder innoDB-Tabellen? Es ist auch different on 32-bit and 64-bit, und hängt von Ihren Protokollierungseinstellungen ab. Die MySQL manual sagt:

Die effektive maximale Tabellengröße für MySQL-Datenbanken in der Regel von Betriebssystemeinschränkungen auf Dateigrößen bestimmt wird, nicht durch MySQL interne Grenzen

Es gibt weitere Einzelheiten über, was das Diese Grenzen sind auch auf dieser Seite.

Answer 3

Die Auswahl, wie viele Spalten in eine einzelne Tabelle eingefügt werden sollen, hängt auch von der Art der Daten ab, die dargestellt werden, und davon, wie wichtig Ihnen die Normalisierung ist. Einige Beziehungen können leicht durch eine Tabelle dargestellt werden; Andere müssen in mehreren kleineren Tabellen ausgeführt werden, insbesondere wenn Sie in Ihrem Dataset eine Mischung aus Eins-zu-Eins-Beziehungen, Ein-zu-Viele-Beziehungen und Viele-zu-Viele-Beziehungen haben.

http://en.wikipedia.org/wiki/Database_normalization

Answer 4

keine Antwort auf genaue Frage ...

Warum waren Sie überzeugt, Ihre kleineren Tabellen in einem großen zu setzen? Was Sie getan haben, heißt "Vertical Partitioning" und kann je nach Situation sehr nützlich sein. Bei vielen großen TEXT- oder BLOB-Feldern kann eine vertikale Partition Ihre abgefragten Daten physisch zusammenhalten und schneller zugänglich sein.

See: http://en.wikipedia.org/wiki/Partition_(database)

Vertikale Partitionierung beinhaltet Tabellen mit weniger Spalten und zusätzliche Verwendung von Tabellen zu erstellen, die verbleibenden Spalten zu speichern. Die Normalisierung umfasst auch das Aufspalten von Spalten über Tabellen hinweg, aber die vertikale Partitionierung geht über diese und Partitionsspalten hinaus, selbst wenn sie bereits normalisiert sind. Es könnte auch ein anderer physikalischer Speicher verwendet werden, um eine vertikale Partitionierung zu realisieren; das Speichern von selten verwendeten oder sehr breiten Spalten auf einem anderen Gerät ist beispielsweise eine Methode der vertikalen Partitionierung. Explizit oder implizit wird diese Art der Partitionierung als "Zeilenaufteilung" bezeichnet (die Zeile wird durch ihre Spalten geteilt). Eine übliche Form der vertikalen Partitionierung besteht darin, dynamische Daten von (schnell zu finden) statischen Daten in einer Tabelle aufzuteilen (langsam zu finden), in der die dynamischen Daten nicht so oft verwendet werden wie die statische. Wenn Sie eine Ansicht über die zwei neu erstellten Tabellen erstellen, wird die ursprüngliche Tabelle mit einer Leistungseinbuße wiederhergestellt. Die Leistung erhöht sich jedoch beim Zugriff auf die statischen Daten, z. für die statistische Analyse

Siehe auch: http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

Answer 5

Überlegen Sie, was Sie mit der Tabelle tun müssen. Wenn die Tabelle rein zum Archivieren ist, müssten Sie niemals ihre Struktur oder irgendetwas ändern. Wenn Sie es für Datenerfassung benötigen, würden Sie erwarten, seine Struktur zu ändern. Versuchen Sie zum Beispiel eine alter Tabelle auf einer Kopie davon zu machen. Erwarten Sie, dass diese Funktion die Leistung verliert, sobald Sie eine Ebene erreicht haben, auf der temporäre Tabellen zu groß werden, um sie im Speicher zu speichern.

Ich war in der gleichen Situation, in der ich aufgrund der Datenmenge die Struktur der Datenbank nicht ändern konnte. Was Sie tun sollten RICHTIG ist jemand, der eine Datenbank auf einer Maschine (d. H. Eine EC2-Instanz) mit der Datenmenge erstellt, die Sie in zwei Jahren erwarten. Lassen Sie sie gefälschte Daten im selben Tabellenformat erstellen. Versuchen Sie, mit dieser Tabelle zu arbeiten und entscheiden Sie, ob die Leistung akzeptabel ist. Wenn es nicht akzeptabel ist, müssen Sie die Dinge so schnell wie möglich ändern.

Wenn ich Sie wäre, würde ich prüfen, Greenplum oder (GridSQL, wenn Sie nicht das Geld zu verbringen). Beide basieren auf PostgreSQL und arbeiten mit vielen Computern zusammen.

Answer 6

Ich habe eine Tabelle mit ~ 98M Zeilen und fügt/löscht den ganzen Tag. Wir führen Aufzeichnungen für 90 Tage ... Ich erwarte, dass dieser Tisch in diesem Monat ~ 100 Millionen Reihen sein wird. Persönlich hätte ich das Datenbankschema anders entworfen, aber es wurde gekauft und wir müssen es intakt halten, damit wir keinen Support für den Anbieter annullieren.

Wir verwenden mysql Replikation (MASTER-MASTER) und führt die Einfügungen/Löschungen auf einem & Ausführen der Abfragen auf dem anderen. Dies hat der Performance wirklich geholfen, da die Löschvorgänge die Tabelle sperren und Abfragen blockieren würden, bevor wir zur Replikation übergehen.

Bei dieser Implementierung treten keine Leistungsprobleme auf.

Ich führe auch eine Tabelle optimize einmal pro Woche ...