Einen hervorragenden Freitag allerseits! Es bleibt immer weniger Zeit bis zum Start des Kurses , deshalb teilen wir heute eine weitere nützliche Übersetzung zu diesem Thema.
Im Entwicklungsprozess wurde beeindruckende Arbeit zur Verbesserung der Tabellensektionierung geleistet. Partitionierung von Tabellen — das ist eine Funktion, die in PostgreSQL schon lange existiert, aber, wenn man so will, bis zur Version 10 nicht wirklich nutzbar war, in der sie zu einer sehr nützlichen Funktion wurde. Früher haben wir gesagt, dass die Tabellenvererbung unsere Implementierung der Sektionierung ist, und das stimmt. Allerdings mussten Sie dabei den größten Teil der Arbeit manuell erledigen. Wenn Sie beispielsweise wollten, dass Tuples während des INSERTs in Sektionen eingefügt werden, mussten Sie Trigger einrichten, um dies für Sie zu erledigen. Die Sektionierung durch Vererbung war sehr langsam und schwierig, um zusätzliche Funktionen darüber hinaus zu entwickeln.
In PostgreSQL 10 sahen wir die Geburt der "deklarativen Sektionierung" — eines Features, das viele Probleme löst, die mit der alten Methode der Vererbung nicht gelöst werden konnten. Dies führte zu einem viel leistungsfähigeren Werkzeug, mit dem wir Daten horizontal strukturieren können!
Vergleich der Features
In PostgreSQL 11 gab es eine beeindruckende Reihe neuer Features, die helfen, die Leistung zu steigern und die sektionierten Tabellen für Anwendungen transparenter zu gestalten.
1. Verwendung von beschränkenden Ausnahmen
2. Fügt nur Knoten hinzu
3. Nur für sektionierte Tabellen, die auf nicht sektionierte verweisen
4. Indizes müssen alle Schlüsselsäulen der Sektion enthalten
5. Einschränkungen auf der Sektion auf beiden Seiten müssen übereinstimmen
Leistung
Hier haben wir auch gute Nachrichten! Eine neue Methode wurde hinzugefügt . Dieser neue Algorithmus kann geeignete Sektionen bestimmen, indem er die Bedingung der Anfrage überprüft WHERE. Der vorherige Algorithmus wiederum prüfte jede Sektion, um festzustellen, ob sie der Bedingung entsprechen könnte WHERE. Dies führte zu einer zusätzlichen Erhöhung der Planungszeit mit wachsender Anzahl an Sektionen.
In 9.6, with partitioning using inheritance, routing tuples in a partition was typically done by writing a trigger function that contained a series of IF statements to insert the tuple into the correct partition. These functions could be very slow in execution. With declarative partitioning added in version 10, this started to work much faster.
Using a partitioned table with 100 partitions, we can estimate the performance of loading 10 million rows into the table from 1 BIGINT column and 5 INT columns.
The performance of a query to this table for searching one indexed record and executing DML to manipulate one record (using only 1 processor):
Here we see that the performance of each operation has significantly increased since PG 9.6. Queries SELECT look much better, especially those capable of excluding multiple partitions during query planning. This means that the planner can skip most of the work it had to do earlier. For example, paths for unnecessary partitions are no longer built.
Fazit
Table partitioning is becoming a very powerful feature in PostgreSQL. It allows for quick output of data online and their transition to offline without waiting for the completion of slow massive DML operations.This also means that related data can be stored together, making access to the required data much more efficient. The improvements made in this version would not have been possible without the developers, reviewers, and committers who tirelessly worked on all these features.
Thanks to them all! PostgreSQL 11 looks simply fantastic!
Here's a short but quite interesting article. Share your comments, and don't forget to sign up for , where the course program will be detailed.
Quelle: habr.com
