忍者ブログ
IT関係の小作人労働の日々の日記です。 最近データベースが好きです。 インフラ構築、DB構築、アプリケーション開発・・・何でも屋です。 何でもできそうで、何にもできない。

【データベースの知識】MVCCとロックの関係


データベースの並行性を高める技術「MVCC(Multi-Version Concurrency Control)」。これによって「読み取りと書き込みがブロックされない」仕組みが実現されていますが、すべてのロックが不要になるわけではありません。

1. 更新時の動作とロックの役割

【 基本 】 MVCC環境下でも、データの更新(UPDATE/DELETE)時には「排他ロック」を取得します。これは、複数のトランザクションが同時に同じ行を書き換えてしまう「ロストアップデート」を防ぐためです。

[ 更新のポイント ]
更新時のロック:対象行に対して排他ロックを取得します。原則として「行レベル」でロックされます。
更新 vs 更新:同じ行を更新しようとすると、先行する処理が終わるまで「ロック待ち」が発生します。
必ず行ロックか?:通常は行単位ですが、大量の行を一度に更新する場合やインデックス再構築時には、効率化のため「テーブルロック」へ格上げ(エスカレーション)されることがあります。

2. 「読取り」と「書込み」の関係

【 基本 】 MVCCの最大のメリットは、読み取り(SELECT)がロックを取得しないことです。書き込み中であっても、読み取り側は「その処理が始まる前の古いバージョン(多版)」を参照するため、互いに待ち時間が発生しません。

[ ロックの競合 ]
更新 vs 読み込み:ロック待ちなし(読取り側は古い版を見る)。
読み込み vs 更新:ロック待ちなし。
参照一貫性:スナップショットを見ることで、長時間実行される検索も一貫性が保たれます。

3. まとめ:MVCCとロックの整理

質問の答えを整理すると、以下のようになります。この仕組みにより、高いスループットが実現されています。

[ Q&A 形式での整理 ]
1. 更新の際にロックは取得するか?
→ はい。整合性を守るために必須です。原則として「行ロック」がかかります。
2. 更新と読み込みでロック待ちはあるか?
→ いいえ。MVCCにより、読み取りはロックを無視して実行可能です。
3. 更新と更新でロック待ちは発生するか?
→ はい。同一データへの同時書き込みは、必ず順番待ちが発生します。


基本は「行ロック」ですが、処理の規模によっては「テーブルロック」になる可能性も意識しておくと、より深いデータベース設計が可能になります。


PR

【データベースの知識】直列可能性(Serializability)と線形可能性(Linearizability)


一貫性のあるデータ操作を理解する上で、「直列可能性」と「線形可能性」は非常に重要な概念です。どちらも「正しく動く」ことを保証するためのルールですが、その焦点は異なります。

1. 直列可能性(Serializability)

【 基本 】 複数のトランザクションを並列に実行した結果が、それらを「何らかの順序で一つずつ順番に(直列に)実行した結果」と同じになることを保証します。これは「トランザクション」の境界を守るための概念です。

[ 直列可能性のイメージ ]
T1: [---A---]
T2: [---B---]
並列実行しても、結果が「T1 → T2」または「T2 → T1」の実行結果と一致すればOK。
焦点:複数操作(トランザクション)の整合性
範囲:データベース全体の整合性

2. 線形可能性(Linearizability)

【 基本 】 単一のオブジェクトに対する操作が、「ある一瞬」で完了したかのように見えることを保証します。書き込みが完了した瞬間、その後の読み込みは必ず最新の値を返す必要があります。「リアルタイム性」を重視する概念です。

[ 線形可能性のイメージ ]
書き込み: [--- Write(X=10) ---]
読み込み: [--- Read(X) ---] → 必ず 10 が返る
焦点:単一オブジェクト、単一操作の最新性
範囲:時間軸に沿った最新情報の提供

3. まとめ:違いのポイント

この二つは独立した概念ですが、組み合わせて「厳密な直列可能性(Strict Serializability)」として実装されることもあります。

直列可能性:並列実行しても、順番にやったのと同じ結果になる(マルチステップ重視)
線形可能性:操作が完了した瞬間に全員が最新値を見れる(時間的即時性重視)


システムの要件に応じて、どのレベルの整合性が必要かを見極めることが、堅牢なシステム設計の第一歩となります。


【OSS-DB Silver対策】GRANT文とPUBLICの意味


OSS-DB Silver試験対策シリーズ、今回は権限付与を行うSQL文、`GRANT`で使用される特殊なキーワード「PUBLIC」について解説します。誰に対して権限を与えているのか、その範囲を正確に把握しましょう。

1. GRANT文におけるPUBLICとは

【 基本 】 `GRANT SELECT ON TABLE1 TO PUBLIC` のように記述した場合、この「PUBLIC」は、現在および将来のすべてのユーザ(ロール)を指す特殊なグループとして機能します。

[ PUBLICのポイント ]
全ユーザが対象:個別に権限を与えていないユーザも含め、すべてのユーザが対象となります。
自動適用:PUBLICに権限を付与した後に作成された「新しいユーザ」にも、自動的にその権限が適用されます。
暗黙のグループ:PUBLICという名前の特定のユーザが存在するわけではなく、一種の「全員参加のグループ」として扱われます。

2. 試験対策問題:4択チェック

【 問題 】 次のSQL文を実行した場合の「PUBLIC」の説明として、最も適切なものはどれですか?
GRANT SELECT ON TABLE1 TO PUBLIC;

問題:GRANT文の付与対象に指定された「PUBLIC」が指す範囲を選びなさい。

1. データベースを作成した所有者(オーナー)のみを指す。

2. システム管理権限(スーパーユーザ)を持つユーザのみを指す。

3. その時点で存在するユーザのみを指し、後から作成されたユーザは含まれない。

4. すべてのユーザ(ロール)を指し、将来作成される新しいユーザも含まれる。

3. 正解と解説

正解:4

【 解説 】
1. 理解のコツ: `PUBLIC` は「全員」という意味です。PostgreSQLでは、個々のユーザに権限を割り当てる手間を省くために、全ユーザに共通の権限を与えたい時にこれを使用します。
2. 復習の視点: 逆に権限を取り消したい場合は `REVOKE SELECT ON TABLE1 FROM PUBLIC;` と記述します。デフォルトで一部のオブジェクトにはPUBLICに権限が割り当てられていることもあるため、セキュリティ設定の際にも重要な知識となります。


4. まとめ

「PUBLIC = 全ユーザ(未来のユーザも含む)」。このシンプルな定義を覚えておけば、SQLの権限問題で迷うことはありません。試験では「既存のユーザのみ」というひっかけ選択肢がよく出るので、注意してくださいね!


【データベースの知識】アクセスログで記録すべき主要項目


データベースの運用やセキュリティ監査において、記録されたアクセスログは非常に重要な役割を果たします。今回は、トラブルシューティングや不正アクセス検知のために、最低限取得しておくべき主要な項目を確認しましょう。

1. ログ取得の構成要素

【 基本 】 データベースへの操作を漏れなく追跡するには、「いつ」「誰が」「どこから」「何をしたか」を明確にする必要があります。これらの情報を正確に記録することで、事後解析の精度が向上します。

[ 記録すべき主な項目 ]
日時:操作が行われた正確なタイムスタンプです。
接続元アドレス:クライアントのIPアドレスやホスト名を特定します。
アカウント:DBにログインしたユーザー名やスキーマ名です。
対象オブジェクト:アクセスしたテーブル、ビュー、インデックス名などです。
SQL文:実行された具体的なDMLやDDLの内容です。
バインド値:SQLに渡された具体的なパラメータ値です。
実行結果:成功、失敗(エラーコード)、および処理の成否です。

2. サンプル:アクセスログの出力イメージ

実際の運用では、以下のような形でデータが蓄積されます。特にバインド値の記録は、後から特定のデータ操作を再現・特定する際に不可欠です。

[ ログ出力例 ]
・日時:2026-04-24 20:42:00
・接続元:192.168.1.100
・アカウント:APP_USER
・対象:EMPLOYEE_TABLE
・SQL文:SELECT * FROM EMPLOYEE_TABLE WHERE EMP_ID = :1
・バインド値:'E999'
・実行結果:SUCCESS (1 row selected)


これらの項目を適切に管理することで、パフォーマンス分析や不審なアクセスの早期発見に繋がります。


【OSS-DB Silver対策】データベースユーザの管理と仕様<


OSS-DB Silver試験対策シリーズ、今回は「データベースユーザ」についてです。OSのユーザ管理と何が違うのか、その適用範囲はどこまでなのかを整理しましょう。

1. データベースユーザの3大原則

【 基本 】 PostgreSQLのユーザ(ロール)管理には、OSの管理とは独立した以下のルールがあります。

OSユーザとの関係:OS上のユーザアカウントとは完全に別物です。ただし、便宜上同じ名前に設定して運用することは可能です。
適用範囲:データベースユーザは、特定のデータベース内だけでなく「データベースクラスタ全体」で共通のオブジェクトです。
パスワード:認証に使用するパスワードも、OSのログインパスワードとは独立して管理されます。

2. 試験対策問題:4択チェック

【 問題 】 PostgreSQLにおける「データベースユーザ」の説明として、最も適切なものは次のうちどれですか?

問題:データベースユーザの仕様に関する正しい記述を選びなさい。

1. データベースユーザはOSのユーザアカウントと同期しているため、OS側に存在しない名前は使用できない。

2. データベースユーザは特定のデータベース内に作成されるため、他のデータベースへ接続する際は再作成が必要である。

3. データベースユーザはデータベースクラスタ全体で共通であり、そのパスワードはOSのパスワードとは独立している。

4. セキュリティの観点から、データベースユーザ名をOSユーザ名と同じにすることは禁止されている。

3. 正解と解説

正解:3

【 解説 】
理解のコツ: PostgreSQLの世界には独自の「名簿(ロール)」があると考えましょう。一度作成したユーザは、同じクラスタ内の DB_A にも DB_B にも(権限さえあれば)アクセスできます。
復習の視点: 「OSユーザと同じ名前にしても良い(1の否定)」や「パスワードは別(3の後半)」という点は、実務での環境構築をイメージすると覚えやすくなります。例えば、OSがLinuxでユーザが postgres であっても、DB内のパスワードを全く別に設定するのは一般的ですね。


4. まとめ

「データベースユーザはクラスタ共通の独立した存在」。この一言に尽きます。OSの管理体系と切り離して考えることで、PostgreSQLのユーザ管理の仕組みがスッキリ理解できるはずです!