Q&A
> データベースも非同期です。
データベースエンジンは何を使っていますか？
前提
非同期の Web API を作成しています。同ユーザーが短期間に連続でアクセスした際、並行処理が行われ、データに不整合が発生します。
例えば以下のようなテーブルがあった場合、
| id | user_id | number |
|---|---|---|
| 0 | A | 0 |
| 1 | A | 1 |
| 2 | A | 2 |
| 3 | B | 0 |
| 4 | B | 1 |
ユーザーAが新規レコードの追加をほぼ同時にリクエストしたとします。
- req1: レコード数のクエリ(count -> 3)
- req2: レコード数のクエリ(count -> 3)
- req1: レコード追加(number=3)
- req2: レコード追加(number=3)
このように並行処理され、結果は以下のようになります。
| id | user_id | number |
|---|---|---|
| 0 | A | 0 |
| 1 | A | 1 |
| 2 | A | 2 |
| 3 | B | 0 |
| 4 | B | 1 |
| 5 | A | 3 |
| 6 | A | 3 |
質問
楽観的ロックを行えば解決すると思いますが、ネットの情報ではほぼ全て複数ユーザーによるリソースアクセスへの話であって、同じユーザーによる同時アクセスに対して楽観的ロックを行って良いものかと悩んでいます。
また楽観的ロックを行うとしても、同じユーザーによる連続リクエストは全てのエンドポイントにおいても気を付けなければならないため、対応として場当たり的だと感じてしまいます。（おそらく「データを読み込み、そのデータを処理して、書き込む」ような処理すべてに気を使わなければなりません。）
どのように解決するのが妥当なのでしょうか？
補足情報
Python のフレームワーク FastAPI で開発しています。データベースは PostgreSQL, ドライバは asyncpg, ORMは SQLAlchemy です。
Python: 3.9
FastAPI: 0.71.0
asyncpg: 0.25.0
SQLAlchemy: 1.4.29
PostgreSQLです。
> 同じユーザーによる同時アクセスに対して楽観的ロックを行って良いものかと悩んでいます。
ロックを行った場合、どのような点が問題になると考えているのでしょうか？
大きな問題はないとは思いますが、ネットの情報では複数ユーザーに対して楽観的ロックの話をしていて、同じユーザーに対して楽観的ロックを行うのは正しい対応なのか不安です。
また、「データを読み込み、そのデータを処理して、書き込む」ような処理すべてに楽観的ロックが必要になるため、複数ユーザーのアクセスは想定していないのに、ほとんどのテーブルにversionカラムを追加しなければならないです。(ORMを利用しているので楽観的ロックの実装は必要ないのですが)
あくまで楽観的ロックは並行処理のためのもので、ユーザーが1人か複数人かはあまり関係ないのでしょうか？
ロックする必要があるのは、DB上の同一データを同時に読み書きするのを防ぐためですので、ユーザーが1人か複数人かはまったく関係ありません。
今回のデータについても、ロックをすればいいと思いますし、楽観的/悲観的のどちらを使うのかについては、それぞれの利/不利を考えて採用すればいいでしょう。
また、トランザクションレベルで管理すれば「「データを読み込み、そのデータを処理して、書き込む」ような処理すべてに気を使わなければなりません」というのも緩和されるでしょう。
コメント、ありがとうございます。非常に助かります。
> ロックする必要があるのは、DB上の同一データを同時に読み書きするのを防ぐためですので、ユーザーが1人か複数人かはまったく関係ありません。
なるほど、やはりロックはユーザーが複数なのかどうかは無関係の仕組みなんですね。多くの情報はあくまで分かりやすさのために複数人という状況を持ち出していただけでしたか。
> また、トランザクションレベルで管理すれば「「データを読み込み、そのデータを処理して、書き込む」ような処理すべてに気を使わなければなりません」というのも緩和されるでしょう。
ここに関して、トランザクションでは複数のリクエストの並行処理における整合性は担保されないように思うのですが、なにか方法があるということでしょうか？
「トランザクションでは複数のリクエストの並行処理における整合性は担保されない」と思う理由がわかりませんが、トランザクションは複数の処理をまとめた1つの処理として扱う仕組みなので、ロック取得>トランザクション実行>ロック解放で処理できます。
パフォーマンスへの影響を少なくするために粒度を下げていくと細かく制御する必要があったりしますが。
「トランザクションでは複数のリクエストの並行処理における整合性は担保されない」→ 少し言葉が抜けてたかもしれません。トランザクションを張るだけではという意味ですね。
つまりトランザクションは途中で失敗した場合、ロールバックして整合性を担保するものとして話しています。
もしかすると、TakaiYさんの言う「トランザクションレベルで管理する」というのはトランザクション単位で悲観的ロックをかければ良いという話でしたか？
[トランザクション単位で悲観的ロックをかければ良いという話でしたか？]
はい。▽そうです。
わかりました。ご丁寧にありがとうございました。勉強になりました
回答1件
0
ベストアンサー
結果は以下のようになります。
データベースレベルでuser_idとnumberに複合UNIQUE制約をかければ、フロントエンドプログラムをどう実行しようが、このような重複データを入れようとした時点でエラーとなります。
投稿2022/08/28 02:17
総合スコア145183
あなたの回答
tips
プレビュー
