🤱🏿 👩🏿 ⚒️ リレーショナルデータベースへの競争力のあるアクセス 🛀🏽 🙋 👩🏽‍✈️

コンピューターコンピューティングの同時実行性の問題は非常に複雑です！非常に複雑な理由は、並列プログラムを開発するときに考慮する必要がある膨大な数の詳細にあります。プログラミングでは、エラーの基礎を作成する多くの詳細が既にありますが、並列処理はさらに追加します。

リレーショナルデータベースへの競争力のあるアクセスの問題は、アプリケーションソフトウェア開発者だけでなく、ほとんどすべてのアプリケーションソフトウェア開発者が直面しています。この領域に対するこの需要の結果は、多数の作成されたアーキテクチャパターンの存在です。これにより、このようなプログラムの開発の大きな複雑さにうまく対処できます。以下では、そのようなレシピと、それらの実装が基づいているメカニズムについて説明します。物語はJavaコードの例で説明されますが、ほとんどの資料は言語固有ではありません。この記事の目的は、トピックを完全に網羅するのではなく、主題の紹介として、リレーショナルデータベースへの競合アクセスの問題を説明することです。

競争力のあるアクセスの問題

状況を考慮してください。特定の会計システムでは、書類の保管中に商品の残高の変化を反映する必要があります。議論をより実質的にするために、PostgreSQLで実行する例を提供します。会計システムとテストデータのデータベース構造は次のとおりです。

CREATE TABLE stocks ( id integer PRIMARY KEY, name varchar(256) NOT NULL, quantity decimal(10,2) NOT NULL DEFAULT 0.0 ); CREATE TABLE documents ( id integer PRIMARY KEY, quantity decimal(10,2) NOT NULL DEFAULT 0.0, processed boolean NOT NULL DEFAULT false, stock integer REFERENCES stocks ); INSERT INTO stocks (id, name, quantity) VALUES (1, '', 56.4), (2, '', 26.8); INSERT INTO documents (id, quantity, stock) VALUES (1, 15.6, 1), (2, 26.1, 1);

私たちのドキュメントが倉庫から商品を償却する責任があるとしましょう。アプリケーションコードはドキュメントと残りのデータをロードし、計算を実行して、データベースにデータを保存します。このアクションが1つのアプリケーションによって実行される場合、すべてが正常に行われます。

 SELECT quantity, processed, stock FROM documents WHERE id = 1;

  quantity | processed | stock ----------+-----------+------- 15.60 | f | 1

 SELECT name, quantity FROM stocks WHERE id = 1;

  name | quantity ------+----------  | 56.40

識別子が1のドキュメントのデータと、対応するドキュメントの残りのデータがロードされます。残りの新しい値は、56.40-15.60 = 40.80を書き落として計算され、データは文書の処理に関するメモとともに保存されました。

 UPDATE stocks SET quantity = 40.80 WHERE id = 1; UPDATE documents SET processed = true WHERE id = 1;

しかし、シングルユーザーシステムは長い過去です。現在、ユーザーが並ぶべきビジネスアプリケーションを想像することは不可能です。したがって、2つのドキュメントが同時に処理される状況を考えてみましょう。最初の場合と同様に、アプリケーションはデータベースからデータを読み取ります。

最初のアプリケーション

 SELECT quantity, processed, stock FROM documents WHERE id = 1;

  quantity | processed | stock ----------+-----------+------- 15.60 | f | 1

 SELECT name, quantity FROM stocks WHERE id = 1;

  name | quantity ------+----------  | 56.40

2番目のアプリケーション

 SELECT quantity, processed, stock FROM documents WHERE id = 2;

  quantity | processed | stock ----------+-----------+------- 26.10 | f | 1

 SELECT name, quantity FROM stocks WHERE id = 1;

  name | quantity ------+----------  | 56.40

そして、ここで明らかな問題が発生します。最初のアプリケーションは56.40-15.60 = 40.80を計算し、2番目のアプリケーションは56.40-26.10 = 30.30を計算します。そして、これらの結果のいずれかがデータベースに書き込まれます。最後の更新要求が実行される対象。これは明らかにユーザーが期待するものではありません。この種の問題は、並列プログラミングでよく知られており、競合状態と呼ばれます。このケースは、一般名がread-modify-writeの複合アクションです。

処理するドキュメント（処理済みフィールド）をチェックし、実際のアプリケーションでこれを行わなければならない場合、チェックにもかかわらず、ドキュメントが2回処理される可能性があります。すべてが競合状態でもありますが、異なる種類のcheck-then-act操作です。さらに、更新要求の間隔では、データベースは一貫性のない状態にあります。つまり、ドキュメントアクションは既に完了していますが、ドキュメントは処理済みとしてマークされていません。

その結果、データベースへの不正な競合アクセスで発生する最も一般的な問題が2つあります。これは、読み取り/変更/書き込みの競合状態が発生した場合に発生する変更の損失です。そして、更新リクエスト間のデータの一貫性のない状態。

DBMSメカニズム

リレーショナルデータベースへの競争力のあるアクセスのための特定のレシピを議論するには、DBMSとプログラミングツールが提供する低レベルのメカニズムに精通している必要があります。これらは、実装のベースとなる技術要素です。主な要素は、トランザクションとロックです。それらについてさらに説明します。

トランザクションと分離レベル

トランザクションは、トランザクションをロールバックまたは確認する機能を備えたデータベースと対話するための単一の操作シーケンスです。トランザクションは、変更の一貫性の問題を解決する手段になる可能性があり、レースの状況を許可しません。最初または両方の問題を解決するためのトランザクションの適合性は、分離レベルによって異なります。分離は、単一の操作によって行われた変更が競合する操作にどのように/いつ表示されるかを定義するプロパティです。

SQL標準では、非コミット読み取り、コミット読み取り、繰り返し読み取り、シリアル化の4つの分離レベルを定義しています。それらはすべて、最低許容レベルの断熱材を備えています。これらのレベルの基本的なプロパティは、名前から明らかなはずです。さまざまなDBMSが、さまざまな方法で分離タイプのサポートを実装する場合があります。主なことは、各実装では、レベルで規定されているよりも厳しくない分離を許可しないことです。たとえば、PostgreSQLは内部で2つの分離レベルのみをサポートします：コミットの読み取りとシリアライズ可能です。これらの分離レベルを使用して、上記の例で説明した問題を解決することを検討してください。

Read Committed Isolation Level（PostgreSQLでデフォルトで使用）を使用すると、データ状態の一貫性の問題を解決できます。これは、トランザクション内で行われたすべての変更が、現在のトランザクションの後、競合するトランザクションから見えるようになるという事実により達成されます。

 BEGIN; SELECT quantity, processed, stock FROM documents WHERE id = 1; SELECT name, quantity FROM stocks WHERE id = 1; --    UPDATE stocks SET quantity = 40.80 WHERE id = 1; UPDATE documents SET processed = true WHERE id = 1; COMMIT;

しかし、このようなトランザクションは、競争力のあるオペレーションの実行における競合の状態に関する問題を解決しません。このような状況では、別のレベルの分離が役立ちます-シリアライズ可能。これは可能な解決策ですが、それだけではありません。 PostgreSQLのSerializable分離レベルの実装の動作は、名前と完全には一致していません。つまり、Serializable分離レベルを持つすべてのトランザクションは順次実行されません。代わりに、トランザクションをコミットするときに、データが変更されたときに競合がチェックされ、競合するトランザクションによってデータが既に変更されている場合、現在のトランザクションは失敗します。

 BEGIN ISOLATION LEVEL SERIALIZABLE; SELECT quantity, processed, stock FROM documents WHERE id = 1; SELECT name, quantity FROM stocks WHERE id = 1; --    UPDATE stocks SET quantity = 40.80 WHERE id = 1; UPDATE documents SET processed = true WHERE id = 1; COMMIT;

上記のトランザクションは、レースの状況とデータの一貫性の両方に関する問題を解決します。このアプローチの特徴は、このトランザクションを実行するコードが、トランザクションの完了後にのみ成功について学習することです。そして、失敗の結果として、トランザクションが成功するか、アクションの実行を拒否する決定が下されるまで、すべてのアクションと計算を繰り返す必要があります。繰り返しのために大量のリソースが消費されるため、この動作は大きな競合負荷では不十分です。この動作は、楽観的同時実行制御と呼ばれます。

上記の例は、ビジネスロジックがアプリケーションコードに完全に実装され、データベースがストレージとしてのみ機能するという前提に基づいています。

パフォーマンスに影響するトランザクションの使用における重要な詳細は、その長さです。トランザクションは長すぎてはなりません。トランザクションが速く完了するほど、システムのパフォーマンスが向上します。このコメントは、少数のユーザーがいるアプリケーションでドキュメントの編集を実行するコードにとって重要ではない場合があります。ただし、たとえば、データベースと対話し、多数のクライアントで使用されるWebサービスの状況では、これは重要です。

ロック

並列プログラミングでは、ロックメカニズムを使用して実行スレッドを制御します。ロックを使用すると、特定の領域へのアクセスをシリアル化できます。 DBMSは、データへのアクセスを制御するロックメカニズムもサポートしています。 PostgreSQLの例を使用して、このメカニズムの可能性を考えてみましょう。

PostgreSQLは多くの種類のロックをサポートしています。主な特徴は、現在の種類のロックと競合する多くの種類のロックです。競合とは、競合するタイプのロックと一緒に現在のロックをキャプチャできないことを意味します。さらに、ロックは明示的と暗黙的に分けられます。明示的ロックとは、lockキーワードと、更新または共有、つまりユーザーが指定した共有のためのクエリ修飾子を使用して、クエリで実行されるロックです。暗黙的ロックは、さまざまな要求（選択、更新、挿入、変更など）の間にキャプチャされるロックです。 PostgerSQLは、アドバイザリロックと呼ばれる別の種類のロックもサポートしています。

ロックは、リクエストが実行されてから現在のトランザクションが終了するまでキャプチャされます。たとえば、仮想会計システムでは、操作が実行される残りの部分に対応するstocksテーブルの行とドキュメントテーブルの行で排他ロックを取得することが可能であり、それによって現在のトランザクションのみがこのデータにアクセスできることを保証します。

 BEGIN; SELECT quantity, processed, stock FROM documents WHERE id = 1 FOR UPDATE; SELECT name, quantity FROM stocks WHERE id = 1 FOR UPDATE; --    UPDATE stocks SET quantity = 40.80 WHERE id = 1; UPDATE documents SET processed = true WHERE id = 1; COMMIT;

上記のコードは、ドキュメントおよび株式テーブルの行のロックをキャプチャします。この場合、更新用のキーワードがクエリに追加され、選択データが選択されます。これは、更新のための行の明示的なブロックです。この場合、テーブル全体をブロックしても効果はありません。一般に、テーブルをロックする必要があるのは、データを含む大規模な操作の場合のみであり、これらは非常にまれなケースです。そうしないと、すべての呼び出しがシリアル化されるため、競合アクセスでパフォーマンスの問題が発生します。

すでにロックされている領域のロックをキャプチャしようとすると、ロックが解除されるまでリクエストがブロックされます（デフォルト）。または、デッドロックの場合、エラーメッセージが返されます。ブロックされた要求から制御を返す間隔を設定することも、ロックを取得できないことに関するメッセージをすぐに受信することもできます（nowait）。

競争コントロールの種類

競合制御は、競合サイトでの並列実行スレッドが相互作用するルールです。競争管理は、計算結果の正確性を保証する必要があります。追加の目標は、特定のケースで可能な限り迅速に結果を取得することです。競合制御は通常、競合処理の時間に応じて、楽観的（楽観的）、悲観的（悲観的）、および部分的楽観的（半楽観的）のタイプに分類されます。

楽観的な競争制御には、アクションの潜在的な競合のチェックが含まれます。たとえば、ユーザーはリポジトリにデータを要求して変更し、その後、変更を保存しようとします。リポジトリ内のデータの現在のバージョンが、変更が行われたデータのバージョンに対応する場合、競合は発生せず、データを保存できます。反対の場合、競合が発生し、アクションを再実行するか、アクションを拒否することで処理されます。楽観的な競争制御は、競争力のあるアクセスに対する競争が比較的少ない良好なパフォーマンスを提供します。

悲観的な競争管理には、アクションを実行する前に潜在的な競合をチェックすることが含まれます。つまり、保護された領域で競合する実行スレッドがシリアル化されます。これにより、競争力のあるアクセスのための高い競争力で生産性が向上します。

部分的に楽観的は、両方のアプローチが同時に適用される混合型です。

建築パターン

この時点で、読者は競合アクセスの問題とそれらを解決するDBMSメカニズムの一般的な概念を理解しているはずです。このセクションでは、データベースへの競争的アクセスの問題に対するソリューションを表すアーキテクチャパターンに焦点を当てます。以下は完全な説明ではなく、一般的なアイデアと例です。詳細な説明については、記事の下部にあるリンクをクリックしてください。

DBMSを使用する場合、データはアプリケーションのメモリに読み込まれ、それらを使用して、またはそれらを介してアクションが実行されます。アクションの結果は、原則として保存し直す必要があります。この間、何が変更されたかを知るために、データの変更に関する情報を保存する必要があります。さらに、作成および削除されたオブジェクトに関する情報を保存する必要があります。もちろん、データベース内のすべての変更をすぐに反映できます。この場合、次の問題が発生します。システムトランザクションには非常に長い時間がかかり、データベースへの変更に対するロックがトランザクション全体にわたって保持されるため、競合アクセス中に競合が発生します。データベースとの対話は多くの小さな部分に分割されますが、これも効果がありません。データ変更の追跡の問題を解決するために、作業単位パターンについて説明します。このパターンは、すべての変更を追跡し、変更をデータベースに適用して、その状態を行った変更と一致させるオブジェクトを記述します。

 public class UnitOfWork { private List<DomainObject> newObjects; private List<DomainObject> updatedObjects; private List<DomainObject> deletedObjects; /** *   * @return     */ public DomainObject create() { DomainObject domainObject = new DomainObject(); newObjects.add(domainObject); return domainObject; } /** *     * @param domainObject   */ public void update(DomainObject domainObject) { updatedObjects.add(domainObject); } /** *     * @param domainObject   */ public void remove(DomainObject domainObject) { deletedObjects.add(domainObject); } /** *      */ public void commit() { // SQL     INSERT insert(newObjects); // SQL     UPDATE udpate(updatedObjects); // SQL     DELETE delete(deletedObjects); } //  insert, update, delete   }

上記は、作業単位パターンの最も単純な実装です。 DomainObjectsは、適切なアクションが実行されたときにUnitOfWorkオブジェクトに登録できます。ビジネストランザクションが完了した後、アプリケーションはUnitOfWorkオブジェクトのcommitメソッドを呼び出します。

通常、ビジネストランザクションには長い時間がかかります。原則として、複数のシステムトランザクションに拡張されます。この理由はすでに上で述べた-長いロックキャプチャの問題。 DBMS同期メカニズムは1つのシステムトランザクション内でのみ機能するため、独自の同期メカニズムを実装する必要があります。これは、いくつかのシステムトランザクションの上で動作します。この問題を解決するために、楽観的および悲観的なタイプの競合制御を実装する2つの楽観的オフラインロックおよび悲観的オフラインロックパターンについて説明します。

ユーザーが編集フォームを開いて、ドキュメントで数分間作業し、結果を保存するとします。これは、ビジネストランザクションの典型的な例です。

楽観的な競争管理の状況を考慮してください。編集結果の保存中に競合が検出された場合、ユーザーには変更されたデータと追加のアクションを選択するダイアログが通知されます。 Optimistic Offline Lockパターンは、一般的な場合、バージョン管理されたデータメカニズムに依存する変更制御メカニズムを記述します。変更が保存されるたびに、データベース内のデータのバージョンが、変更が行われたバージョンと比較されます。これらのバージョンが等しい場合、現在のバージョンが変更され、結果が保存されます。そうでない場合、競合が発生し、アクションを繰り返すかキャンセルすることで処理されます。

 public class DomainObject { private Integer id; private Integer version; private Object data; //   } public class UnitOfWork { // ,   public void update(List<DomainObject> updatedObjects) throws SQLException { PreparedStatement ps = connection.prepareStatement( "update domain_objects set data = ?, version = version + 1 " + "where id = ? and version = ?" ); for (DomainObject domainObject: updatedObjects) { ps.setObject(1, domainObject.getData()); ps.setInt(2, domainObject.getId()); ps.setInt(3, domainObject.getVersion()); if (ps.executeUpdate() == 0) { throw new RuntimeException(" "); } } } }

上記のコードは、上記のOptimistic Offline Lockパターンを使用したupdateメソッドの実装を示しています。この実装では、変更されたオブジェクトのリストはバージョン検証とともに保存されます。バージョンが変更された場合、テーブルの単一のレコードは更新されず、この例では例外がスローされます。この例外は、競合する実行スレッドによってレコードが既に更新されている競合に対応しています。

悲観的な競合制御の場合、悲観的なオフラインロックパターンの実装を以下に示します。

 class DomainObject { private Integer id; private Boolean blocked; private Object data; //   } public class UnitOfWork { // ,   public void update(List<DomainObject> updatedObjects) throws SQLException { PreparedStatement updateStatement = connection.prepareStatement( "update domain_objects set data = ?, blocked = false " + "where id = ? and blocked = true" ); for (DomainObject domainObject: updatedObjects) { updateStatement.setObject(1, domainObject.getData()); updateStatement.setInt(2, domainObject.getId()); updateStatement.executeUpdate(); } } public DomainObject get(Integer id) throws SQLException { PreparedStatement updateStatement = connection.prepareStatement( "update domain_objects set blocked = true " + "where id = ? and blocked = false" ); updateStatement.setInt(1, id); if (updateStatement.executeUpdate() == 1) { PreparedStatement selectStatement = connection.prepareStatement( "select * from domain_objects where id = ?" ); selectStatement.setInt(1, id); ResultSet result = selectStatement.executeQuery(); //result    //  DomainObject    result return new DomainObject(); } else { throw new RuntimeException("  "); } } }

提示されたコードでは、データベースからデータを受信すると、ブロックされたフィールドにロックが設定されます。既に設定されている場合は例外がスローされ、そうでない場合は結果が返されます。さらに、オブジェクトを更新すると、ロックがリセットされます。この実装は、すべてのレベルのトランザクション分離で機能します。ロックのキャプチャ後にデータが保存される場合。

提示された実装は、説明を説明するだけであり、実際のアプリケーションでの使用を目的としていません！

ビジネスレベルのロックアウトポリシー

ブロッキングポリシーは、データへの同時アクセスを管理するルールです。この段落では、DBMSおよびプラットフォーム同期メカニズムへのクエリのレベルではなく、ビジネスレベルでロックのポリシーを扱います。ロックポリシーはビジネスロジックに関連している必要があることに注意してください。そして、あなたは競争のために後で質問することはできません。たとえば、特定のドキュメントを単独で編集する必要があることをスコープが示すシステムでは、ビジネスロジックがこの要件の知識を持っている必要があります。ビジネスエリアのこのような要件の実装の場合、同期メカニズムの助けを借りてのみ、アプリケーションでのビジネスレベルの実装はいくつかの部分に分割されますが、これはあまり良くありません。まず、このようなシステムのサポートは複雑であるため、組み込みのDBMSプロシージャを使用してパフォーマンスを最適化するオプションは非常に一般的ですが、第二に、長いシステムトランザクションには問題があります。つまり、アプリケーションがビジネストランザクションと同時にシステムトランザクションを開いたままにできないようにすることができません。ビジネストランザクションの責任範囲は、アプリケーションのビジネスロジックにあります。したがって、ビジネストランザクションのロックポリシーは、ビジネスロジックとは別に考慮することはできません。

(en)

Patterns of Enterprise Application Architecture (Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford)

PostgreSQL Concurrency Control

Concurrency control

Isolation level

リレーショナルデータベースへの競争力のあるアクセス