Wie hilft die Tabellenpartitionierung?


28

Ich habe Schwierigkeiten, die Idee der Vor- und Nachteile der Tabellenaufteilung zu verstehen. Ich beginne mit der Arbeit an einem Projekt mit 8 Tabellen, von denen eine die Hauptdatentabelle mit 180 bis 260 Millionen Datensätzen sein wird. Da es sich um eine ordnungsgemäß indizierte Tabelle handelt, denke ich darüber nach, die Tabellendatensätze auf 20 Millionen zu beschränken, damit 9 bis 13 Tabellen erstellt werden können.

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

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.

Informieren Sie sich auch über die Partitionierung von Tabellen und Datenbanken.


Bitte erläutern Sie, welche Art der indizierten Suche für eine andere Tabelle als die ID durchgeführt wird. Sie erfahren, welche Art der Partitionierung durchgeführt werden muss.
RolandoMySQLDBA

Es wird nur id sein.
Rick James

'Only id' sagt uns immer noch nichts. Wie sind die IDs auf den Bereich aller IDs verteilt? Fragen Sie hauptsächlich nach den neueren, ist es wirklich verteilt? Wird der Datenzugriff hauptsächlich gelesen oder hauptsächlich geschrieben? All dies sind wichtige Fragen, auf die wir Antworten benötigen, bevor wir Ihnen spezifisch helfen können. Trotzdem sind die Antworten unten wirklich nützlich :)
Walter Heck

1
Hier sind meine Gefühle 5 Jahre nach dem Start dieses Threads.
Rick James

Antworten:


32

Das Folgende ist einfach nur verrückt zu schimpfen und zu schwärmen ...

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ärer Baum mit 268.435.455 (2 ^ 28 - 1) Baumknoten hätte eine Höhe von 28. Wenn Sie diesen binären Baum in 16 separate Bäume aufteilen, erhalten Sie 16 binäre Bä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% nicht zu vernachlässigen.

In der realen Welt hätte ein BTREE-Index Treenodes mit mehreren Schlüsseln. Bei jeder BTREE-Suche wird eine binäre Suche innerhalb der Seite ausgeführt, wobei möglicherweise auf eine andere Seite verwiesen wird. Wenn zum Beispiel jede BTREE-Seite 1024 Schlüssel enthält, wäre eine Baumhöhe von 3 oder 4 die Norm, tatsächlich eine kurze Baumhöhe.

Beachten Sie, dass eine Aufteilung eines Tisches die Höhe des bereits kleinen BTREE nicht verringert. Bei einer Aufteilung von 260 Millionen Zeilen besteht sogar die große Wahrscheinlichkeit, dass mehrere BTREEs mit derselben Höhe vorhanden sind. Die Suche nach einem Schlüssel durchläuft möglicherweise jedes Mal alle Stamm-BTREE-Seiten. Nur einer wird den Pfad des benötigten Suchbereichs erfüllen.

Nun erweitern Sie diese. Alle Partitionen befinden sich auf demselben Computer. Wenn Sie nicht für jede Partition separate Datenträger haben, haben Sie Disk I / O- und Spindeldrehungen als automatischen Engpass außerhalb der Partitionssuchleistung.

In diesem Fall bringt Ihnen die Datenbankparitionierung auch dann nichts, wenn id der einzige verwendete Suchschlüssel ist.

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

Insgesamt sollten mindestens zwei Partitionen vorhanden sein: eine für IDs, auf die häufig zugegriffen wird, und die andere für die übrigen IDs. Wenn die IDs, auf die häufig zugegriffen wird, ziemlich groß sind, können Sie diese optional partitionieren.


16

200 Millionen Zeilen sind sicherlich in dem Bereich, in dem Sie von der Tabellenpartitionierung profitieren können. Abhängig von Ihrer Anwendung können Sie auf einige der unten aufgeführten Vorteile setzen:

  • Leichte Löschung alter Daten Wenn Sie Datensätze löschen müssen, die älter als 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 Falle des OP kann dies für die Systemwartung hilfreich sein.

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

  • Schnellere Tabellen- und Bereichsüberprüfungen In Wirklichkeit sollte ein Betriebssystem so etwas nicht tun, aber ein Data Warehouse oder ein ähnliches System wird diese Art von Abfrage in der Menge durchführen. Tabellenscans verwenden hauptsächlich sequenziellen Datenverkehr auf der Festplatte. Daher sind sie in der Regel die effizienteste Methode zum Verarbeiten einer Abfrage, die mehr als ein paar Prozent der Zeilen in einer Tabelle zurückgibt.

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

Für die Zwecke des OP ist es unwahrscheinlich, dass die Partitionierung einen großen Leistungsvorteil für betriebliche Abfragen erzielt, aber für die Systemverwaltung nützlich sein kann. Wenn es eine wesentliche Anforderung gibt, Aggregate über große Datenmengen hinweg zu melden, kann ein geeignetes Partitionsschema Abhilfe schaffen.


1

Die Partitionierung ermöglicht gleichzeitige Neuordnungen nach Partition, wenn alle Ihre Indizes partitioniert sind. Andernfalls sind die Partitionen immer noch viel kleiner und benötigen weniger Arbeitsbereich für die Neuorganisation. Intern kann jedes "gute" DBMS parallel zu partitionierten Tabellen arbeiten. Das schließt wahrscheinlich NICHT MySQL oder MyISAM ein, tho ....


MySQL führt keine parallele Verarbeitung durch, auch wenn es sich um eine Partitionierung handelt. MySQL indiziert nur eine Partition. daher UNIQUEund FOREIGN KEYsind in partitionierten Tabellen nicht wirklich verfügbar. Partitionierung auf MyISAM versus InnoDB - kein Unterschied zu den in diesem Thread behandelten Dingen.
Rick James
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.