問題タブ [database-locking]

私が現在持っているロックのフローは、 のSELECT ... FOR UPDATE後にINSERT. 例えば

SELECT上記では、複数の呼び出し元が同時にクリティカル セクションに入るのを防ぐために何かの排他ロックを取得すると予想していましたが、デフォルトでは、InnoDB はテーブルまたはインデックス ギャップの共有ロックのみを取得するようです。2 つの並行トランザクションが同時にこれを試みると、両方が共有ロックを取得できますが、一方は挿入しようとするとデッドロック エラーで失敗します。

同時読み取りを防ぐために、このコードを標準の悲観的ロックのように動作させる方法はありますか?

注: 場合によっては、一意のインデックスでこの問題を解決できることは承知していますが、一意のインデックスが不十分な 2 つのインスタンスに遭遇しました (1) 列の 1 つが null 可能で、正確に 1 つの null 値が必要な場合と (2) ) 特定のキーを持つ行が 10 未満になるように、行に関する別の不変条件を保証したい場合。

Spring Boot に基づいており、PostgreSQL 9.6 データベースに依存しているアプリケーションの場合、Spring Batch を使用して、n秒ごとに実行する必要があるいくつかの操作をスケジュールしています (カスタマイズ可能ですが、通常は数秒から数分の範囲です)。その結果、1 日の終わりにはシステムによって多くのジョブが実行され、Spring Batch によって多くの情報が保持されます。

実際のところ、私はこれらのジョブを歴史化することにあまり興味がないので、最初は Spring Batch のインメモリ バージョンを使用して、そのような (私にとって) 役に立たない情報が永続化されるのを回避しました。

ただし、リソースの少ない環境で小さなnを実行する構成の場合、このアプローチではパフォーマンスの問題が発生するため、データベースの方法で試すことにしました。

残念ながら、これらのテーブルは非常に急速に大きくなるため、クリーンアップ手順を実装して、たとえば 1 日以上経過したすべてのデータを削除したいと考えています。

ここで問題が発生します。実際、これらのテーブルをロックしているものがない場合でも (つまり、メイン アプリケーションがダウンしており、誰もデータベースと対話していません)、テーブルをクリーンアップするのに永遠に時間がかかり、その理由が本当に理解できません。

Spring Batch (4.0.1) は、これらのテーブルを生成するために次の PG スクリプトを提供します。

参照の優先順位を尊重することで、次の削除を実行してこれらのテーブルをクリーンアップしようとします。

最初の 4 つのテーブルではすべて問題ありませんが、 BATCH_JOB_EXECUTIONのテーブルに到達するとすぐに、数十万行を削除するのに 30 分ほどかかります。さらに悪いことに、最初の 5 つのテーブルからすべてを削除した後、最後のテーブル (現在は何もリンクされていません) にはさらに多くの時間がかかります。

この単純な操作が完了するまでに時間がかかる理由がわかりますか? もちろん、制約違反をチェックする必要がありますが、不当に遅いようです。

さらに、不要なジョブ情報でディスク領域を浪費することなく、Spring Batch を使用するより良い方法はありますか?