怠け者のためのアップグレード: PostgreSQL 12 によるパフォーマンスの向上

PostgreSQL 12「世界最高のオープンソース リレーショナル データベース」の最新バージョンは、（すべてが計画通りに進めば）数週間以内にリリースされる予定です。 これは、大量の新機能を備えた新しいバージョンを年に XNUMX 回リリースするという通常のスケジュールに従っており、率直に言って、これは素晴らしいことです。 それが、私が PostgreSQL コミュニティの積極的なメンバーになった理由です。

私の意見では、以前のリリースとは異なり、PostgreSQL 12 には 12 つや XNUMX つの革新的な機能 (パーティショニングやクエリ並列処理など) が含まれていません。 私はかつて、PostgreSQL XNUMX の主な機能は安定性の向上であると冗談を言いました。 ビジネスの重要なデータを管理するときに必要なことはこれではないでしょうか?

しかし、PostgreSQL 12 はそこで終わりではありません。新機能と改善により、アプリケーションのパフォーマンスが向上します。 あとはアップグレードするだけです!

(そうですね、インデックスを再構築するかもしれませんが、このリリースでは、これまでほど怖くありません。)

PostgreSQL をアップグレードして、不必要な手間をかけずにすぐに大幅な改善を享受できるのは素晴らしいことです。 数年前、私は PostgreSQL 9.4 から PostgreSQL 10 へのアップグレードをレビューし、PostgreSQL 10 のクエリ並列処理の向上によりアプリケーションがどのように高速化したかを確認しました。そして最も重要なことは、ほとんど何も必要とされなかったということです (構成パラメータを設定するだけでした) max_parallel_workers).

同意します。アップグレード直後にアプリケーションの動作が向上すると便利です。 PostgreSQL にはユーザーが増えているため、私たちはユーザーを満足させるために非常に努力しています。

では、PostgreSQL 12 への簡単なアップグレードでどのように満足できるのでしょうか? 今から教えます。

インデックス作成の大幅な改善

インデックスを作成しなければ、データベースは発展しません。 情報を素早く見つけるには他にどうすればよいでしょうか? PostgreSQL の基本的なインデックス システムは次のように呼ばれます。 B ツリー。 このタイプのインデックスはストレージ システム用に最適化されています。

単純に演算子を使用します CREATE INDEX ON some_table (some_column)、PostgreSQL は、常に値を挿入、更新、削除する一方で、インデックスを最新の状態に保つために多くの作業を行います。 まるで魔法のように、すべてが自動的に機能します。

しかし、PostgreSQL インデックスには XNUMX つ問題があります。 膨張している 余分なディスク領域を占有し、データの取得と更新のパフォーマンスが低下します。 「肥大化」とは、インデックス構造を非効率的に維持することを意味します。 これは、削除されるガベージ タプルに関連している場合もあれば、そうでない場合もあります。 VACUUM (情報提供してくれた Peter Gaghan に感謝します)ピーター・ジオギーガン））。 インデックスの肥大化は、インデックスが頻繁に変更されるワークロードで特に顕著です。

PostgreSQL 12 では、B ツリー インデックスのパフォーマンスが大幅に向上し、TPC-C などのベンチマークを使用した実験では、使用されるスペースが平均 40% 削減されたことが示されています。 インデックスがはるかに小さいため、B ツリー インデックスの維持 (つまり書き込み操作) だけでなく、データの取得にも費やす時間が短縮されました。

テーブルをアクティブに更新するアプリケーション - 通常は OLTP アプリケーション (リアルタイムのトランザクション処理) - ディスクを使用し、リクエストをより効率的に処理します。 ディスク容量が増えると、インフラストラクチャをアップグレードせずにデータベースの容量を増やす必要があります。

一部のアップグレード戦略では、これらの利点を活用するために B ツリー インデックスを再構築する必要があります (例: pg_upgrade インデックスは自動的に再構築されません)。 PostgreSQL の以前のバージョンでは、テーブル上で大規模なインデックスを再構築すると、その間に変更を加えることができなかったため、大幅なダウンタイムが発生していました。 しかし、PostgreSQL 12 には別の優れた機能があります。コマンドと並行してインデックスを再構築できるようになりました。 同時に再インデックスするダウンタイムを完全に回避します。

PostgreSQL 12 では、インデックス作成インフラストラクチャには他にも改良点があります。 魔法があったもう一つのこと - 先行書き込みログ、別名 WAL (先行書き込みログ)。 先行書き込みログには、障害やレプリケーションが発生した場合に PostgreSQL のすべてのトランザクションが記録されます。 アプリケーションはこれをアーカイブや保存に使用します。 ポイントインタイムリカバリ。 もちろん、先行書き込みログはディスクに書き込まれるため、パフォーマンスに影響を与える可能性があります。

PostgreSQL 12 では、インデックス構築中に GiST、GIN、および SP-GiST インデックスによって作成される WAL レコードのオーバーヘッドが削減されました。 これにより、いくつかの具体的な利点が得られます。WAL レコードが占有するディスク領域が減り、災害復旧やポイントインタイム リカバリ時などにデータがより速く再生されます。 アプリケーションでこのようなインデックスを使用する場合 (たとえば、PostGIS ベースの地理空間アプリケーションでは GiST インデックスが頻繁に使用されます)、これは、ユーザー側で何の努力も必要とせずにエクスペリエンスを大幅に向上させるもう XNUMX つの機能です。

パーティショニング - より大きく、より良く、より速く

PostgreSQL 10の導入 宣言的パーティショニング。 PostgreSQL 11 ではさらに使いやすくなりました。 PostgreSQL 12 ではセクションのスケールを変更できます。

PostgreSQL 12 では、特にテーブル内に数千のパーティションがある場合、パーティショニング システムのパフォーマンスが大幅に向上しました。 たとえば、クエリが何千ものパーティションを持つテーブル内の少数のパーティションにのみ影響を与える場合、クエリははるかに高速に実行されます。 パフォーマンスが向上するのは、この種のクエリだけではありません。 また、複数のパーティションを持つテーブルに対する INSERT 操作がいかに高速であるかにも気づくでしょう。

を使用してデータを記録する COPY - ちなみに、これは素晴らしい方法です データの一括ダウンロード ここに例があります JSONの受信 — PostgreSQL 12 のパーティションテーブルもより効率的になりました。 COPY ではすでにすべてが高速でしたが、PostgreSQL 12 では完全に速くなります。

これらの利点のおかげで、PostgreSQL ではさらに大きなデータ セットを保存し、簡単に取得できるようになります。 そしてあなたの側には何の努力もありません。 時系列データの記録など、アプリケーションに多くのパーティションがある場合、簡単なアップグレードでパフォーマンスが大幅に向上します。

これは正確には「アップグレードしてお楽しみください」という改善ではありませんが、PostgreSQL 12 ではパーティション化されたテーブルを参照する外部キーを作成できるため、パーティション化を快適に行うことができます。

WITH クエリが大幅に改善されました

時 組み込みの共通テーブル式にパッチが適用されました (別名 CTE、別名 WITH クエリ) についての記事を書くのが待ちきれませんでした。 PostgreSQL を使用したアプリケーション開発者はどれほど満足していたか。 これは、アプリケーションを高速化する機能の XNUMX つです。 もちろん、CTE を使用する場合を除きます。

SQL の初心者は CTE を好んで使用することがよくありますが、特定の方法で CTE を作成すると、命令型プログラムを作成しているように感じられます。 個人的には、これらのクエリを書き換えて回避するのが好きでした без CTE を高め、生産性を向上させます。 今ではすべてが異なります。

PostgreSQL 12 では、特定のタイプの CTE を副作用なしでインライン化できます (SELECT)、リクエストの終わり近くで XNUMX 回だけ使用されます。 書き直した CTE クエリを追跡すると、ほとんどがこのカテゴリに分類されます。 これにより、開発者は明確なコードを作成し、高速に実行できるようになります。

さらに、PostgreSQL 12 は、何もしなくても SQL 実行自体を最適化します。 おそらく今はそのようなクエリを最適化する必要はないでしょうが、PostgreSQL がクエリの最適化に取り組み続けていることは素晴らしいことです。

ジャストインタイム (JIT) - 現在はデフォルトです

PostgreSQL 12 システムのサポート付き Llvm JIT コンパイルはデフォルトで有効になっています。 まずはサポートを受けられる JIT 一部の内部操作、そして XNUMX 番目に、選択リスト (SELECT の後にある) 内の式 (最も単純な例は x + y) を含むクエリ、集計、WHERE 句を含む式などでは、JIT を使用してパフォーマンスを向上させることができます。

PostgreSQL 12 では JIT がデフォルトで有効になっているため、パフォーマンスは自然に向上しますが、JIT が導入された PostgreSQL 11 でアプリケーションをテストして、クエリのパフォーマンスを測定し、調整が必要かどうかを確認することをお勧めします。

PostgreSQL 12 の残りの新機能についてはどうですか?

PostgreSQL 12 には、標準 SQL/JSON ルート式を使用して JSON データを検査する機能から、パラメーターを使用した多要素認証まで、優れた新機能が多数あります。 clientcert=verify-full、コラムなどを作成しました。 別記事にするのに十分です。

PostgreSQL 10 と同様に、PostgreSQL 12 はアップグレード直後から全体的なパフォーマンスが向上します。 もちろん、独自のパスを設定することもできます。PostgreSQL 10 で行ったように、改善を有効にする前に、本番システムで同様の条件でアプリケーションをテストしてください。PostgreSQL 12 がすでに予想よりも安定しているとしても、テストを怠らないでください。アプリケーションを運用環境にリリースする前に、徹底的にテストします。

出所： habr.com