Re: 質問 -- セッション操作 - 提案された同期方法の実現可能性? - メーリングリスト pgsql-general (2023)

家>メーリングリスト

エイドリアンさん、コメントありがとうございます。私の返信は以下に掲載されています。スティーブ-----元のメッセージ-----差出人: "Adrian Klaver" 宛先: "Melvin Davidson" ; 「Pavel Stehule」Cc: 「Steve Petrie、P.Eng.」 ;送信日: 2016 年 1 月 3 日日曜日 4:38 PM件名: Re: [全般] 質問 -- セッション操作 - 提案された同期方法の実現可能性?> 01/ 2016 年 3 月 01:32 PM、Melvin Davidson は次のように書きました:>> 他の人も指摘しているように、セッション データをテーブルに保存することは>> 良い考えではありません。 TRUNCATE を使用した場合でも、vacuum full を使用しない限り、使用されているすべてのスペースを再利用することはできません。さらに言えば、>> 実際には:>>http://www.postgresql.org/docs/9.4/interactive/sql-truncate.html>> "TRUNCATE は、一連のテーブルからすべての行を迅速に削除します。各テーブルに対する無修飾の DELETE と同じ効果がありますが、実際にテーブルをスキャンしないため、より高速です。さらに、ディスク領域がすぐに再利用されます。後続の VACUUM 操作を必要とするのではなく、> これは大きなテーブルで最も役立ちます。">これを確認しておくと良いでしょう。 TRUNCATE は DELETE /.AUTOVACUUM / VACUUM よりもはるかに高速です。そのため、セッション オペレーション システムが (たとえば 31 個の) セッション コンテキスト テーブルのプールを使用する場合、セッションコンテキスト データ ストアへのアプリのアクセスを中断することなく、超高速の tableTRUNCATE コマンドを実行できます。テーブルのプール (例: 31) 内の他の多くのセッション コンテキスト テーブルはオンラインのままであり、TRUNCATE 操作中にアプリで利用できるためです。たとえば、セッション操作は、セッション コンテキスト テーブル。各セッション コンテキスト行のイメージが占有している場合、たとえば1000 バイトの場合、セッション オペレーション システムは 1 つの簡単なテーブル TRUNCATE コマンドで 30 MB のストレージをファイル システムにリサイクルします。行ごとに骨の折れる AUTOVACUUM / VACUUM プロセスを実行する代わりに、これは長期間存続する価値の高いデータ資産に適しています。アプリはセッション コンテキストデータ行に対して INSERT / SELECT / UPDATE コマンドのみを使用します。アプリはこれらの行に対して DELETE コマンドを使用しません。セッション操作には、テーブル TRUNCATE を実行する前に、セッション コンテキスト コンテキスト テーブルに「無効な」セッション コンテキスト行イメージのみが含まれていることを確認するための他の手段があります。> 問題は次のとおりです。>> 「TRUNCATE は、操作対象の各テーブルに対して ACCESS EXCLUSIVE ロックを取得します。>テーブル上の他のすべての同時操作をブロックします。RESTART> IDENTITY が指定されている場合、再起動されるシーケンスは同様に排他的にロックされます。テーブルへの同時アクセスが必要な場合は、代わりに DELETE コマンドを使用する必要があります。"> > 私の提案は、TRUNCATE コマンドのこの欠点 (テーブルに対する ACCESS EXCLUSIVE ロックが必要である) を、次の 2 つの設計アイデアによって利点に変えることです。 (例: 31 個の) セッション コンテキスト テーブルのプールを使用すると、アプリのアクセスを中断することなく、超高速の tableTRUNCATE コマンドを使用して、大量のセッション コンテキスト行イメージのストレージ スペースを定期的にファイル システムにリサイクルできるようになります。セッションコンテキストデータストア。プール (たとえば 31 個) テーブル内の他の多くのセッション コンテキスト テーブルは、セッション操作によって一時的にオフラインになる 1 つの「デッド」テーブルに対する TRUNCATE 操作中、常にオンラインのままでアプリから利用できるためです。2 。 TRANSACTION /SAVEPOINT セマンティクスを使用して、シーケンス ジェネレーターの使用を同期する手段として、明示的な LOCK TABLE ... IN ACCESS EXCLUSIVE MODE コマンドを使用します。このアイデアは、アプリによってグローバルにアドレス指定可能な多数のシーケンス ジェネレーターをクイック アクセスの「イテレーター」** として使用し、アプリによる個々のセッション コンテキスト テーブルの効率的かつ規則的な使用を支援することです。(**この設計における「イテレーター」は、基礎となる 64 ビット整数シーケンス ジェネレーターの上位ビットにあるピギーバック反復子の固定値メタデータ。反復子が必要とする増分数値範囲に必要な整数精度の量に余る上位ビット。 .)そして、私の最初の投稿の目的は、上記のポイント 2 で想定した同期を実現するために、シーケンス ジェネレーターの使用を SQLtransaction / セーブポイント セマンティクスと調整するために、私が提案する疑似コードを批評するようこのフォーラムに依頼することでした。著者は postgres の初心者で、ほんの少し表面をなぞっただけの SQL アプリ開発者です (ただし、経験豊富なソフトウェア エンジニアです)。>> 必ずセッション データを保存する必要があります。それなら、>> TEMPORARY テーブルに保存すればよいのではありませんか。 >>> セッションが終了するとメモリが自動的にクリーンアップされますか?>>>http://www.postgresql.org/docs/9.4/static/sql-createtable.html>>>>>> 2016 年 1 月 3 日日曜日、午後 3 時 43 分、Pavel Stehule > > は次のように書きました:>>>> こんにちは。 >>>> 2016-01-03 20:46 GMT+01:00 Steve Petrie、工学博士>> >:>>>> __>> *Postgres フォーラムへのご挨拶。*>> この投稿は、以前のフォーラム スレッド -- 件名>> 「[/GENERAL] postgres テーブルをマルチライターとして使用>> マルチアップデータ キュー/」 に開始されたものです。 2015 年 11 月 23 日、投稿者>> Chris Withers chris@simplistix.co.uk>> 。 >> このスレッドへの最後の投稿は、George Neuner>> > によって 2015 年 12 月 1 日に行われたと思います。>> 興味深い関連スレッドが、以前に開始されました -- subject>> /「[全般] セッションに postgresql を使用する/」、2015 年 10 月 7 日>> by John Tiger > >.>>> >>> 話が逸れてしまい申し訳ありませんでした。でも、>> セッション データに Postgres を使用するのは良い考えですか? Postgres を短期間のデータに使用すると、>> 負荷が高くなるとパフォーマンスの問題が発生する可能性があります。>>>> よろしく >>>> Pavel>>>> * * *>> * * *>> にいくつか投稿しました。私は>> php Webサイトアプリケーションをmysqlから>> postgresに移行する作業をしているので、上記の最初のスレッドです。この移行の重要な目的は、>> postgres テーブルを使用してセッション コンテキスト データを>> 行、アクティブな Web サイト訪問者ごとに 1 行ずつ保存する良い方法を見つけることです。>> 1 つのアドバイス (他の多くの役立つアドバイスの中でも) I >> を上記の最初のスレッドから削除したのは、セッション終了時にセッション コンテキスト テーブルの行>> 画像ストレージをリサイクルする手段として >> DELETE コマンドの使用を回避するためでした。>> 代わりに TRUNCATE コマンドを使用します。セッション コンテキスト>> テーブル全体。セッション コンテキスト行>> イメージ ストレージ スペースを迅速かつ効率的にリサイクルしてファイル システムに戻すため、そのスペースは>> すぐに再利用できます。>> * * *>> * * *>>それ以来、私は、シンプルで信頼性が高く、>> 高性能の「セッション オペレーション システム」(SOS) を実現するために、postgres>> テーブルをセッション コンテキスト ストアとして使用する方法の設計に取り組んできました。>> postgres ベースの SOS の場合、セッション ワークロードのスループットを最大化するための 2 つの重要な原則に従います>> 容量:>> *原則 #1*: *1.1* 頻繁、迅速、およびリサイクルを行うには、TRUNCATE TABLE コマンドのみを使用します。 >> ファイルシステムに効率的に戻り、>> セッションコンテキスト行の古いイメージによって占有されているセッションコンテキストテーブルストレージスペース。そして *1.2* は、このリサイクルのために>> DELETE / AUTOVACUUM / VACUUM コマンドをまったく使用しません。>> *原則 #2*: *2.1* さまざまな>> グローバルにアドレス指定可能な高速アクセス「イテレータ」にシーケンス ジェネレータを使用します* *、>> php Web サイト アプリ (およびその PL/pgSQL 関数) を提供します。 >> 適切な個別のセッション コンテキスト テーブルにアクセスします。 *2.2* アクセス>> は、セッション コンテキスト テーブルのプールからテーブルに付与されます。各>> プールには、すべて同じ動作状態にあるテーブルがあります。>> 原則 1 の欠点は、>> の複雑さがかなり追加されることです。セッション>> コンテキスト データ行を保存するために、複数のテーブルを管理します。>> 原則 2 の欠点は、シーケンス ジェネレータが SQL トランザクション/セーブポイント セマンティクスにおいて>> 役割を持たないことです。そのため、明示的な>> 同期の準備が必要であり、>> 複雑さがさらに増します。>> (** 「イテレータ」は、>> シーケンス整数の上位ビットに余分な不必要な精度を使用することによって、シーケンス ジェネレータから派生します。>>値、「反復子」メタデータをエンコードするため -- このメタデータを複数の>> 同時に実行するアプリ実行制御フロー パスで利用できるようにする >> 効率的な方法として。)>> * * *>> * * *>> *の目的この電子メールは、フォーラム メンバーによる批判のために、>> 複数の同時アクター間で、上記の「反復子」(シーケンス ジェネレーター) の使用を同期する>> ための提案されたアプローチを (>> 擬似コードで) 提示することを目的としています。ウェブサイト php アプリ セッション操作シナリオ。*>> 私は postgres の初心者なので、この>> postgres フォーラムのメンバーが親切にも>> (煮詰めて簡略化した) 疑似コードを調べて批評してくれることを期待しています。 >> (この説明では、「プロセス」という用語は、>> プログラム実行制御の 1 つの形式として、オペレーティング システムに実装される「プロセス」を特に指すものではありません。>> > プログラム実行制御の別の形式として「スレッド」を使用します。 >> この説明では、「プロセス」という用語は、>> 他のプログラム実行パスと同時に実行できる>> 任意のプログラム実行パスの一般的な意味を意味します。)>> 以下に示す疑似コードの例では、2 つの同時実行>>プロセス (セッション プロセス、監視プロセス) は >> 同じテーブル *sql_table_01* 上で動作し、テーブル *sql_table_01* の動作>> 状態の「バージョン」番号としてシーケンス ジェネレーター>> *sql_sequence_01* を使用します。>> >> *質問: _監視プロセス_ ステップ sup.2 (下記) では、>> コマンド:*>> **>> */LOCK TABLE sql_table_01 IN ACCESS EXCLUSIVE MODE;/*>> **>> *確実に_セッション プロセス_は、ステップ ses.1 で>> シーケンス ジェネレータ sql_sequence_01 から値を読み取っていますが、>> _ステップ ses.6 の実行を開始することはありません_:*>> **>> */SELECT currval('sql_sequence_01'); /*>> **>> *監視プロセスに _completed step>> sup.2:_*>> **>> */LOCK TABLE sql_table_01 IN ACCESS EXCLUSIVE MODE;/*>> *__* >> *_ただし、ステップ sup.4_:*>> **>> */COMMIT TRANSACTION;/*>> **>> *???*>>>> 本質的に、アイデアは便乗することです。 >> シーケンス ジェネレータ *sql_sequence_01* の使用、主>> プロセスの LOCK TABLE */sql_table_01/* コマンドの同期。>> セッション プロセスに、>> 上で実行する INSERT / SELECT / UPDATE コマンドがあると仮定します。同じテーブル (>> LOCK TABLE コマンドによってブロックされるコマンド)。>> * * *>> * * *>> これは _session process_ の疑似コードです (行の折り返しを避けるために、広い表示>> ウィンドウを使用します) :>> *セッションプロセス>> * --------------->> テーブル*sql_table_01の行のINSERT / SELECT / UPDATE>> *----------- -------------------------------------------------- >> |>> *ses.0* |(テーブル *sql_table_01* の行を更新することを決定します)。>> |>> *ses.1* | /SELECT currval(*'sql_sequence_01*');/>> /ses.2/ | $save_seq1 = (*ses.1* で取得したシーケンスの値);>> |>> *ses.3* | /SAVEPOINT *session_savepoint*;>> / |>> *ses.4* | /SELECT ... FROM *sql_table_01* FOR UPDATE;>> / |>> *ses.5* | /UPDATE *sql_table_01* ...;>> / |>> *ses.6* | /SELECT currval(*'sql_sequence_01*');>> /*ses.7* | $save_seq2 = (ses.6 で取得した seq の値);>> |>> | /*>> |作業単位をコミットしても安全ですか?>> | (つまり、テーブル>> | *sql_table_01* の動作状態は変更されていませんか?)>> | */>> *ses.8* | if ($save_seq1 == $save_seq2)>> | /*>> |はい -- 安全にコミットできます>> | (シーケンス *sql_sequence_01* は変更されません)。 */>> | {>> *ses.9* | /RELEASE セーブポイント *session_savepoint*;>> / | }>> |その他>> | /*>> |いいえ -- コミットするのは安全ではありません>> | (シーケンス *sql_sequence_01* が変更されました>> | 作業単位を放棄して再試行してください)。>> | */>> | {>> *ses.10*| /ROLLBACK TO SAVEPOINT *session_savepoint*;>> / | }>> |>> | /* 完了 */>> |>> -------------------------------------- ---------->> * * *>> * * *>> これは _supervisoty process_ の疑似コードです (回避するには、広い>> 表示ウィンドウを使用してください)行折り返し):>>>> *監視プロセス>> * ------------------->> テーブル sql_table_01 の動作状態を変更>> ------- -------------------------------------------------- ---->> |>> *補足0* | (テーブル>> | *sql_table_01* の動作状態を変更することを決定します。)>> |>> *sup.1* | /トランザクションを開始します;/>> |>> | /*>> |テーブル sql_table_01 への他のすべてのアクセスをブロックします。>> | */>> *補足 2* | /LOCK テーブル sql_table_01 をアクセス排他モードで;>> / | ...>> | ... (テーブル sql_table_01 の操作状態を変更します>> | ...>> | ... 例: /TRUNCATE ONLY TABLE sql_table_01;/)>> | ...>> |>> | /*>> |アドバンスシーケンス>> | *sql_sequence_01>> * | table>> の動作状態を示します。 *sql_table_01>> * | >> | */>> |>> *補足 3* | /SELECT nextval('*sql_sequence_01'*);>> / |>> | /*>> |テーブルの EXCLUSIVE MODE ロックを解除します>> | sql_table_01.>> | */>> *補足 4* | /トランザクションをコミット;>> / |>> | /* 完了 */>> |>> -------------------------------------- ---------->> * * *>> * * *>> 上記の疑似コードを含む PDF を添付します。>>>> * 添付ファイル < eto_sql_pg - セッション コンテキスト ストレージ - 8.1>> テーブルへのプロセス アクセスの同期 - 20160103.odt>>>>>> セッション オペレーション システム (SOS) の設計ドキュメントは>> かなり進んでいますが、まだ一般配布の準備ができていません。 >> フォーラムのメンバーが現在のドラフト状態の設計ドキュメントのコピーを見たい>> 場合は、お気軽にオフラインで私に電子メールを送って >> PDF コピーをリクエストしてください。>> よろしくお願いします。>> *スティーブ* >>>>>> -->> pgsql-general メーリング リスト経由で送信>> (pgsql-general@postgresql.org>> )>> サブスクリプションを変更するには: >>http://www.postgresql.org/mailpref/pgsql-general>>>>>>>>>>>> -->> *メルビン・デイヴィッドソン*>> 私は空想する権利を留保します。 >>> 私のファンタジーを共有したいかどうかは、完全にあなた次第です。>>> --> Adrian Klaver> adrian.klaver@aklaver.com