it-swarm-eu.dev

Wie hilft die Tabellenpartitionierung?

Ich habe Schwierigkeiten, die Vor- und Nachteile der Tabellenpartitionierung zu verstehen. Ich bin im Begriff, mit der Arbeit an einem Projekt zu beginnen, das 8 Tabellen enthalten würde, und eine davon wird die Hauptdatentabelle sein, die 180 bis 260 Millionen Datensätze enthalten wird. Da es sich um eine ordnungsgemäß indizierte Tabelle handelt, denke ich darüber nach, die Tabellendatensätze auf 20 Millionen zu beschränken. Auf diese Weise müsste ich 9-13 Tabellen erstellen.

Aber ich bin mir nicht ganz sicher, wie es die Leistung verbessern wird, weil sie auf demselben Computer sitzen (32 GB RAM)?

Ich benutze MySQL und Tabellen wären MyISAM und große Tabellen hätten einen Index für das ID-Feld und es gibt keine weiteren Komplexitäten wie Volltextsuche usw.

Bitte beleuchten Sie auch die Tabellenpartitionierung im Vergleich zur Datenbankpartitionierung.

28
Rick James

Das Folgende ist nur wahnsinnig schimpfen und toben ...

Wenn Sie alle Daten in einer Tabelle belassen (keine Partitionierung), haben Sie O (log n) Suchzeiten mit einem Schlüssel. Nehmen wir den schlechtesten Index der Welt, den Binärbaum. Jeder Baumknoten hat genau einen Schlüssel. Ein perfekt ausbalancierter Binärbaum mit 268.435.455 (2 ^ 28 - 1) Baumknoten hätte eine Höhe von 28. Wenn Sie diesen Binärbaum in 16 separate Bäume aufteilen, erhalten Sie 16 Binärbäume mit jeweils 16.777.215 (2 ^ 24 - 1). Baumknoten für eine Höhe von 24. Der Suchpfad wird um 4 Knoten reduziert, was einer Höhenreduzierung von 14,2857% entspricht. Wenn die Suchzeit in Mikrosekunden angegeben ist, ist eine Reduzierung der Suchzeit um 14,2857% gleich Null bis vernachlässigbar.

In der realen Welt hätte ein BTREE-Index Treenodes mit mehreren Schlüsseln. Jede BTREE-Suche würde eine binäre Suche innerhalb der Seite mit einer möglichen Abweichung von einer anderen Seite durchführen. Wenn beispielsweise jede BTREE-Seite 1024 Schlüssel enthält, ist eine Baumhöhe von 3 oder 4 die Norm, in der Tat eine kurze Baumhöhe.

Beachten Sie, dass eine Partitionierung eines Tisches die Höhe des bereits kleinen BTREE nicht verringert. Bei einer Aufteilung von 260 Millionen Zeilen besteht sogar die hohe Wahrscheinlichkeit, dass mehrere BTREEs dieselbe Höhe haben. Die Suche nach einem Schlüssel kann jedes Mal alle BTREE-Stammseiten durchlaufen. Nur einer erfüllt den Pfad des benötigten Suchbereichs.

Erweitern Sie dies nun. Alle Partitionen befinden sich auf demselben Computer. Wenn Sie nicht für jede Partition separate Festplatten haben, haben Sie Festplatten-E/A- und Spindeldrehungen als automatischen Engpass außerhalb der Partitionssuchleistung.

In diesem Fall bringt Ihnen die Partitionierung nach Datenbank auch nichts, wenn id der einzige Suchschlüssel ist, der verwendet wird.

Die Partitionierung von Daten sollte dazu dienen, Daten zu gruppieren, die sich logisch und zusammenhängend in derselben Klasse befinden. Die Leistung beim Durchsuchen jeder Partition muss nicht im Vordergrund stehen, solange die Daten korrekt gruppiert sind. Wenn Sie die logische Partitionierung erreicht haben, konzentrieren Sie sich auf die Suchzeit. Wenn Sie nur Daten nach ID trennen, wird möglicherweise nie auf viele Datenzeilen zum Lesen oder Schreiben zugegriffen. Nun, das sollte eine wichtige Überlegung sein: Suchen Sie alle IDs, auf die am häufigsten zugegriffen wird, und partitionieren Sie sie damit. Alle IDs, auf die seltener zugegriffen wird, sollten sich in einer großen Archivtabelle befinden, auf die durch Indexsuche für die Abfrage "Einmal in einem blauen Mond" weiterhin zugegriffen werden kann.

Die Gesamtwirkung sollte darin bestehen, mindestens zwei Partitionen zu haben: eine für häufig aufgerufene IDs und die andere für die übrigen IDs. Wenn die häufig aufgerufenen IDs ziemlich groß sind, können Sie diese optional partitionieren.

32
RolandoMySQLDBA

200 Millionen Zeilen liegen sicherlich in dem Bereich, in dem Sie von der Tabellenpartitionierung profitieren könnten. Abhängig von Ihrer Bewerbung können Sie einige der unten aufgeführten Vorteile nutzen:

  • Einfaches Löschen alter Daten Wenn Sie Datensätze löschen müssen, die älter als (z. B.) 6 Monate sind, können Sie die Tabelle nach dem Datum partitionieren und dann ältere Partitionen austauschen. Dies ist viel schneller als das Löschen von Daten aus einer Tabelle und kann häufig auf einem Live-System durchgeführt werden. Im Fall des OP kann dies für die Systemwartung hilfreich sein.

  • Mehrere Datenträger Durch Partitionierung können Sie Daten aufteilen, um den Festplattenverkehr aus Gründen der Geschwindigkeit auf mehrere Datenträger zu verteilen. Mit einem modernen RAID-Controller ist dies wahrscheinlich kein Problem für das OP.

  • Schnellere Tabellen- und Bereichsscans Eigentlich sollte ein Betriebssystem so etwas nicht tun, aber ein Data Warehouse oder ein ähnliches System führt diese Art von Abfrage in großen Mengen durch. Tabellenscans verwenden hauptsächlich sequentiellen Festplattenverkehr. Daher sind sie in der Regel die effizienteste Methode zur Verarbeitung einer Abfrage, die mehr als einige Prozent der Zeilen in einer Tabelle zurückgibt.

    Durch die Partitionierung durch einen gemeinsamen Filter (normalerweise zeit- oder periodenbasiert) können große Teile der Tabelle aus solchen Abfragen entfernt werden, wenn das Prädikat anhand des Partitionierungsschlüssels aufgelöst werden kann. Außerdem kann die Tabelle auf mehrere Volumes aufgeteilt werden, was bei großen Datenmengen zu erheblichen Leistungssteigerungen führen kann. Normalerweise ist dies kein Problem für Betriebssysteme.

Für die Zwecke des OP wird durch Partitionierung wahrscheinlich kein großer Leistungsvorteil für betriebliche Abfragen erzielt, sie kann jedoch für die Systemverwaltung nützlich sein. Wenn eine erhebliche Anforderung besteht, Aggregate über große Datenmengen hinweg zu melden, kann ein geeignetes Partitionierungsschema dabei hilfreich sein.

Die Partitionierung ermöglicht gleichzeitige Reorgs nach Partition, wenn alle Ihre Indizes partitioniert sind. Wenn nicht, sind die Partitionen immer noch viel kleiner und benötigen weniger Arbeitsbereich für die Neuorganisation. Und intern kann jedes "gute" DBMS parallel zu partitionierten Tabellen arbeiten. Das beinhaltet wahrscheinlich NICHT MySQL oder MyISAM, obwohl ....

1
Bill