PostgreSQLの一般的なエラー。 パート2

PGConf.Russia 2019カンファレンスの最高のレポートのビデオとトランスクリプトを公開し続けます。 Ivan Frolkovの講演の最初の部分では、一貫性のないネーミング、制約、ロジックをデータベースまたはアプリケーションのどこに集中させるのが良いかについてでした。 このパートでは、解析エラー処理、同時アクセス、キャンセル不可の操作、CTEおよびJSONを見つけます。



そのような話をします。 クライアントは次のように述べています。「データベースはゆっくりと動作しており、私たちのアプリケーションは人々にサービスを提供しています。 彼らはフォークのためにここに私たちを上げることを恐れています。」 トランザクション状態でアイドル状態のプロセスが多数あることが判明しました。 アプリケーションはトランザクションを開始し、何もしませんが、トランザクションは完了しません。 一部の外部サービスとやり取りする場合、原則として、これは通常の状況です。 もう1つは、トランザクション状態でのアイドルが長時間続く場合（既に1分以上疑わしい場合）、PostgreSQLは実際には長いトランザクションを好まないため、これは悪いことです。トランザクションは、VACUUMを効果的にブロックします。 テーブルが膨らみ始め、インデックスの効果が低下しています。



この場合、人々はリクエストを正しく記述せず、デカルトの作品を受け取りました-そのようなリクエストは数日間完了しました。 ユーザーはボタンを押して結果を待ち、結果がなければ再度ボタンを押します。

しかし、これは、トランザクションでアイドル状態のプロセスが非常に多い理由を説明しませんでした。 そして、このような状況で登場しました：アプリケーションがデータベースにクロールし、トランザクションを開始し、外部サービスにクロールし、そこでエラーを取得すると、すべてが崩れ、 スタックトレースログに出力し、これを鎮めます。 接続は放棄され、ハングし、干渉したままになります。

それをどうしますか？ まず、常にエラーを処理する必要があります。 エラーが発生した場合、無視しないでください。 PostgreSQLが接続を失った場合、それは良いことです。トランザクションをロールバックすると、生き残ります。 これで停止します。 まあ、まったく編集する時間がないコードがある場合、トランザクションで最大のアイドル状態が残っています-それを置くことができ、非アクティブなトランザクションをノックアウトします。



エラー処理の典型的なケースは次のとおりです。EXCEPTION WHEN OTHERS THAN NULL。 かつて、用語について同僚と議論していました。 私はそれが「すべてを青い炎で燃やす」と翻訳すると言いました、そして、彼は「それはすべて無駄になりました」という意味です。 もし私たちに何か悪いことが起こった場合、たとえすべてがログをifったとしても、完全な沈黙よりはましです。



エラーの処理方法がわからない場合は、インターセプトしないでください。 非常に一般的なプラクティス：エラーをキャッチし、ログに記録して、何も起こらなかったかのように実行しました。 繰り返しますが、お金の取引に従事していて、無視したエラーがある場合、結果は予測できない場合があります。 90年代には、たとえば、幹の森に連れて行くことができました。 今は時代はより柔らかくなりましたが、あまり楽しくありません。



クライアントで操作を行うと、通常は値を返します。すべてが成功したか失敗したかのいずれかです。 そして、各エラーを処理します。 私は人々がplpgsqlコードを特別に書いて、エラーをキャッチし、ログに書いたのを見ました。はい、エラーがあり、かなり失礼で、メッセージテキストを挿入しました。 しかし、SQLSTATEは戻りませんでした。 これは常に行われるため、何かを確認するのを忘れると、問題が発生し始めます。

plpgsqlと他の言語の両方で、誰もが何らかの理由で例外を恐れています。 そして、独自の何かを発明せず、言語の標準機能を使用する場合、通常はすべてうまくいきます。 特にこの問題は、接続が落ちたときによく発生します。 低下し、プロセスがトランザクションでアイドル状態になり 、データベースがいっぱいになり、パフォーマンスが低下します。 ちなみに、そのようなトランザクションはまだロックを残すことがありますが、何らかの理由でこれはそれほど一般的ではありません。 したがって、 最終的にエラーを処理コードに追加し、そこで接続をクリーンアップしてサーバーに返します。



さらに、明確に定義された制約がある場合、データベースからではなく、エラーの処理時にアプリケーションから例外をスローできます。 春には、それぞれphpにset_exception_handlerの 例外変換があります 。 フレームワークが提供するツールに注意してください。それらは理由があるように見えます。

だから：あなたが何をすべきかわからないエラーをキャッチしないでください。 エラーに慎重かつ正確に名前を付けます。 エラーを分類します。



個人的には、このような基準で分類します。操作を繰り返すことができます（たとえば、デッドロックが発生した）。 操作を繰り返すことはできません。すでに完了しています。 操作は原則として実行できません。

逆説的に、アプリケーションの観点から見ると、デッドロックが発生する状況、接続が失われる状況、支払いにお金を使い果たした状況は同じ状況です：エラーハンドラーはしばらくしてから操作を再試行します。



一方、彼らがアプリケーションに書くことは、一般に私の仕事ではありません。私はベースに従事しています。 エラーを慎重に処理することをお勧めします。それ以外の場合は、トランザクションでアイドル状態、ラインがロックされている、データベースが膨張しているなどです。

ほとんどの開発者は、データベースのみで作業し、アプリケーションは厳密に連続して操作を実行すると考えています。 奇妙なことに、すべてのリレーショナルDBMSにはプラスになります。これは、標準の分離レベルであるREAD COMMITTEDであり、SERIALIZABLEでなくても、すべてが原則として非常にうまく機能するためです。 同時に、更新が失われると状況が発生します。1つはフォームをロードし、もう1つは同じフォームをロードし、1つは書き込んで保存し、もう1つは古いフォームを保存します。変更は消去されました。 最初は、「どうしてそんなに書いたのに、すべてが失われた」と誓うようになりました。



私の経験から：金曜日に週に一度、2人のマネージャーが支払いをしました。 彼らはすべき
1回おきに変化していましたが、それにも関わらず、一度同時に登り、1人あたり2回の支払いを行いました。 少なくとも競合アクセスエラーの可能性がある場合は、遅かれ早かれ発生します。 問題はいつですか。

さらに、制限に注意を向けます。 トリガーで一意性を提供しようとする方法を繰り返し見てきました。 トリガーを使用してテーブルの一意性を提供しません。 テーブル全体をブロックするか、他の複雑なジェスチャーを行う必要があります。 遅かれ早かれこれにつまずくでしょう。



数回、完全に悪夢のようなことに出くわしました。外部Webサービスがデータベースから呼び出されます。 外部エンティティを変更する操作がいくつかありました。 トランザクションがデータベースでロールバックする可能性があるため、これは悪いことですが、リモートサービスでの操作は拒否されません。

さらに微妙な点はデッドロックです。 想像してみてください：トランザクションを処理し、外部Webサービスを呼び出し、何かを変更した後、デッドロックを取得し、ロールバックし、操作を再度実行し、適切な状況で再度呼び出し、デッドロックが再び発生しますロールバック-それはできます
何回も起こります（私は数百の繰り返しに遭遇しました）。 そして今、あなたはこれらのデッドロックを多かれ少なかれ正確に処理し、操作を繰り返して、2か月以内に誰かに2倍の金額を支払っていることを突然見つけます。



APIが貧弱な支払いサービスに会いました。「そのようなユーザーにそのような金額を支払う」、 関数は結果を返します-支払済/未支払。 第一に、繰り返しの場合に問題があり、第二に、接続が中断された場合の対処方法が明確ではありません。 何らかの理由で、この問題に悩む人はほとんどいません。



スライドの例：このような操作は2段階で実行する必要があります。警告のように-「今すぐ何かをする」 操作自体。



突然中断した場合-あなたは決して知らない、電源を切った-私たちは操作を再実行することができます。 2番目の段階で死亡した場合は、全世界で2度目には実行しません。これは手動で分解できます。 実際、このような操作の大多数は通常初めて動作しますが、これらの手段は理論的なものではありません。 すべてが数か月間正常に機能し、突然管理者がネットワークに精通し始め、サービスが積極的にフラッシュを開始し、問題が始まりました。


スライドには4種類のキャンセルできない操作があります。 後者は非べき等の操作です。 これは非常に悲しいケースです。 初めに、私は彼の操作のdid等性を確実にするためにトリガーですべてを正確にした同志について話しました。


会議では、人々は共通テーブル式について、それがどれほど良いかについて話します。 残念ながら、PostgreSQL CTEは無料ではありません。彼らは自分でwork_memを必要とします。 少量のサンプルがあれば、一般的には大丈夫です。 そして、突然大きくなると、問題が始まります。 多くの場合、CTEは一種のミニビューとして使用されます。そのため、アプリケーションを何らかの形で構成できます。 CTEは非常に需要があります。





一時的なビューを作成することはできますが、残念ながら、各ビューはpg_classの行を使用します。これが非常に頻繁に使用される場合、ディレクトリの膨張に問題がある可能性があります。
この場合、パラメーター化されたビューを作成するか、クエリを動的に作成することをお勧めしますが、残念ながら内部からのPostgreSQLでは、これはあまりクールではありません。



通常、JSONは優れたトーンで話されますが、JSONのアプリケーションには何でもプッシュする傾向があります。 原則として、すべてがうまく機能します。 一方、データはJSONから取得されますが、高速ですが、列ほど高速ではありません。 さらに悪いことに、大きなJSONがあり、それがTOASTで発行されている場合。 そこからJSONを取得するには、TOASTからJSONを取得する必要があります。

すべての列がJSONである場合、機能的なインデックスも作成されますが、そこから抜け出す必要があります。 データベースが大きい場合、 ビットマップインデックススキャンがある場合、ボリュームが大きくなるとさらに悪化します。 次に、文字列ではなくページ全体へのリンクがあり、ページから何を取得するかを理解するために、PostgreSQLはRecheckを作成します。つまり、TOASTから行を持ち上げて、この値が存在するかどうかを確認します。スキップするか、スキップしません。 小さい列でうまく機能する場合、JSONでこれは大きな問題です。 JSONに夢中になる必要はありません。



-複数のユーザーが文字列を使用しているときにチェックする方法は？ どんなオプションがありますか？

-まず、フォームに行を表示する前に、すべての列の値を減算し、それらが変更されていないことを確認できます。 2番目のオプション、より便利：ハッシュを計算する
特に、列が大きくて太い場合があるため。 そして、ハッシュはそれほど大きくありません。

-ユーザーは何が起こっているのかを理解できるように、制約は良い名前と呼ばれるべきだと言います。 ただし、制約名には60文字の制限があります。 多くの場合、これでは十分ではありません。 これに対処する方法は？

-自制して戦うと思う。 PostgreSQLでは、これは特別なタイプの長さ64です。原則として、より長い長さに再コンパイルできますが、これはあまり良くありません。

-レポートで、あなたは私たちがアーカイブで何かをする必要があるという事実に興味をそそられました。 古くなったデータをアーカイブするには、どのメカニズムが最も正しいと考えられますか？

-冒頭で述べたように、デューデリジェンスですべてが機能します。 どちらの方法が最も便利なのか、それを使用してください。


タイミング：レポートのパート2は25:16から始まります

-複数のユーザーが並行して呼び出す特定の手順があります。 このプロシージャの並列実行を制限する方法、つまりすべてをビルドする方法
ユーザーが手順を完了するまで次のユーザーは使用を開始できません

-正確に手順？ それとも十分なトランザクションですか？

-何らかのトランザクションで呼び出されるのはプロシージャです。

-オブジェクトにロックをかけることができます。 たとえば、同時に3つ以下の状態になった場合、問題が発生します。 しかし、これは実現可能です。 通常、トランザクションロックを使用しますが、非トランザクションロックも可能です。

-アーカイブデータにもう一度戻りたいです。 あなたは話しました
アプリケーションからのデータも使用できるようにストレージオプションをアーカイブします。 別のアーカイブデータベースを作成するだけでした。 他にどんなオプションがありますか？

-はい、アーカイブデータベースを作成できます。 関数を記述して、ビューにラップすることができます。 関数では、必要なことは何でもできます。アーカイブデータベースにアクセスしたり、ディスクからファイルを取得したり、外部Webサービスにアクセスしたり、これらすべてを組み合わせたり、ランダムデータを自分で生成したりできます。想像力によってのみ制限されます。

-アーカイブデータに関する質問：パーティションを使用できます。11番目のバージョンの新しいチップ。テーブル全体をパーティションに分割し、パーティションをデタッチしてアーカイブのままにします。 アクセスすることもできます。

「もちろん、なぜですか。」 次のスピーカーに譲ります。