Warum NICHT partitionieren?

Wann möchte man eine Datenbank NICHT partitionieren? (Denken Sie an MySQL-Partitionierung )

In meinem Fall

• Ich werde mit ein paar Millionen Zeilen beginnen, es sollte von dort wachsen.
• Primärschlüssel in einem Zeichenfeld, das als häufigste Einschränkung für Abfragen dient (und Suchvorgänge sind häufig - mindestens einige pro Sekunde).
• Der Primärschlüssel wird als Partitionsschlüssel gehasht
• Jede Zeile, die in den oben genannten häufigen Abfragen abgerufen wird, wird aktualisiert
• Weniger häufige Suchvorgänge (anhand von Datumsspalten oder anderen) müssen alle Partitionen treffen

Läuft die Suche nicht bis zum letzten Punkt parallel , ist dies also in allen Fällen ein Gewinn ? Was sind die Nachteile der Partitionierung? Warum ist es nicht etwas, das JEDER standardmäßig verwendet, zumindest wenn Sie mehr als eine Million Datensätze betrachten?

UPDATE - Ich habe die Antwort von zgguy ausgewählt, aber beachten Sie, dass ich meine eigene Antwort mit den Ergebnissen meiner eigenen Forschung hinzugefügt habe, einschließlich eines Links zu einer wirklich guten Antwort auf eine ähnliche Frage, die für mich sehr nützlich war.

Es gibt keine Silberkugel für Leistungsprobleme, und Partitionierung ist auch keine.

Jede Partition ist im Wesentlichen eine Tabelle für sich. Daher werden Abfragen, die so geschrieben sind, dass die Datenbank nur in einer Partition nach Zeilen suchen kann, schneller. Der Unterschied kann bei Abfragen, die die gesamte große Tabelle scannen müssten, sehr groß sein, kann sich jedoch darauf beschränken, nur eine Partition in der partitionierten Tabelle zu scannen. Bei eindeutigen Schlüsselsuchen ist der Unterschied viel geringer.

Abfragen, bei denen Indexsuchen so verwendet werden, dass die Datenbank alle oder die meisten Tabellenpartitionen (Indexpartitionen) besuchen muss, werden jedoch erheblich langsamer ausgeführt.

Parallele Ausführung ist ein Thema für sich. Wenn Sie große Chargen über Nacht ausführen und die gesamte Maschine für diesen einzelnen Job benötigt, ist die Parallelisierung eine gute Sache. In einem OLTP-System, in dem die Datenbank ständig Abfragen von vielen gleichzeitigen Benutzern bearbeitet, möchten Sie jedoch nicht, dass ein Benutzer alle Ressourcen belegt.

Die Antwort hier ist gut geschrieben und enthält ähnliche Argumente wie die Antwort von zgguy. Wenn Sie durch Partitionierung nicht viel davon profitieren, profitieren Sie von einem Szenario mit nur einer Maschine, bei dem die häufigsten Suchvorgänge auf dem Primärschlüssel oder ähnlichem basieren (weil indizierte Suchvorgänge sollten genauso schnell sein).

Tatsächlich scheint ein allgemeiner Ratschlag zu sein, dass der Hauptgrund für die Partitionierung tangential und hauptsächlich verwaltungsbezogen ist: Trennen Sie Ihre Daten beispielsweise nach Datum, wenn Sie von Zeit zu Zeit alte Datensätze löschen müssen. Obwohl festgestellt wurde, dass dies auch Ihrer Suchleistung zugute kommen kann, wenn Ihre Daten so sind, dass fast alle Abfragen nur kürzlich hinzugefügte Datensätze treffen.

Ich habe auch erwähnt, dass MySQL niemals etwas parallel macht (wäre schön, einige Links oder weitere Erklärungen dazu zu sehen).

Ich habe noch niemanden gesehen, der darüber gesprochen hat, ob Schreibaktivitäten unterschiedliche Überlegungen hinzufügen oder nicht.

Das allererste, was mir in den Sinn kommt, ist das Beschneiden von Partitionen . Wenn dies nicht der Fall ist, können Ihre Abfragen dies verwenden.

Benötigen Sie das Löschen einer großen Datenmenge aus der Tabelle, da die Partitionierung Ihnen helfen würde? Obwohl alt, aber dieser Beitrag von Peter hat wenige Punkte zu beachten.

und eine andere Sache, die man sich vorstellen kann, ist die Benutzerfreundlichkeit für einfache Tabellen ... Die Partitionierung erfordert zusätzliche Arbeit und Wartung.