午前Ⅱ対策
トランザクション
サブトランザクション
親トランザクションの中で定義される「部分的なトランザクション」
コミットしても親がコミットされなければ無効
サブトランザクション内で COMMIT を実行 → いったんその部分は「確定した扱い」になる
でも親トランザクションが ROLLBACK されたら、サブトランザクションの結果も巻き戻される
多版同時実行制御(MVCC：MultiVersion Concurrency Control)
トランザクションからの読書き要求に対して、トランザクション開始時点における同じデータのスナップショットを提供するというアプローチにより、トランザクションの同時実行制御を行う仕組み
ざっくり言うと 「みんなが同時にDBを使っても、他人の書きかけを見ずに済むように、過去のバージョンを残しておく仕組み」。
同時実行制御における楽観的制御法
データに対してのロックを行わず、更新対象のデータをあらかじめ取得しておき、更新直前までに変化していないことを確認することにより、データの整合性を保証する方法です。同時実行されるトランザクション間でデータの干渉が少ないときに有効な方法となり得ます。
更新直前にデータが変わっていたら、「競合した！」と判断し、ロールバックしてやり直し。
２相コミット
第1フェーズ
他のサイトに更新可能かどうかを確認する
第2フェーズ
全サイトからの合意が得られた場合に更新を確定する
1つでもNGなら → 全サイトに「ロールバックして」と指示
2相ロック方式
拡張フェーズ（成長段階）
トランザクションが必要なロックを取得していく段階
（この間はロック解除はできない）
縮小フェーズ（縮小段階）
いったんロックを解放し始めたら、その後は新しいロックは取れない
「全部ロックを取りきってから → 解放していく」流れで進める方式。
これを守るとスケジュールが直列化可能になる（=矛盾しない）。
隔離性水準
読取異常（不整合）の種類
ダーティリード (Dirty Read)
他のトランザクションがまだコミットしてないデータを読んじゃう。
→ 後でロールバックされると「存在しない値」を読んだことになる。
ノンリピータブルリード (Non-Repeatable Read)
同じ行を2回読んだのに、間に他トランザクションが更新して値が変わってしまう。
→ 「さっき読んだのと違う…」ってなる。
ファントムリード (Phantom Read)
同じ検索条件で再実行したら、間に他トランザクションがINSERT/DELETEして件数が変わっちゃう。
→ 「さっきは10件だったのに今は12件ある…」ってなる。
分離レベルと異常の関係表
| 分離レベル | ダーティリード | ノンリピータブルリード | ファントムリード | 特徴 |
|---|---|---|---|---|
| READ UNCOMMITTED | 発生する | 発生する | 発生する | 最も緩い。未コミットの変更も見える。 |
| READ COMMITTED | 発生しない | 発生する | 発生する | コミット済みだけ読める。多くのDBのデフォルト。 |
| REPEATABLE READ | 発生しない | 発生しない | 発生する | 同じ行を読めば同じ値が返る。ただし新しい行の出現は防げない。 |
| SERIALIZABLE | 発生しない | 発生しない | 発生しない | 完全に直列実行したのと同じ結果になる。最も厳格で遅い。 |
ロールバック・ロールフォワード
| 項目 | ロールバック | ロールフォワード |
|---|---|---|
| 目的 | 失敗したトランザクションの取消 | 障害からの復旧 |
| 対象 | 実行中トランザクション | バックアップ後～障害直前までの更新 |
| 利用ログ | UNDOログ | REDOログ |
| イメージ | 「やっぱナシ！」 | 「やり直して追いつく！」 |
チェックポイント方式（Checkpoint）
意味
DBMS が定期的に「この時点までの更新はディスクに書き出したよ！」と記録する仕組み。
これにより障害復旧のときに、ログを「最初から全部」使わなくても済む。
チェックポイント以降のログだけを追えば最新に戻れる。
障害復旧の流れ（バックアップ＋ログ＋チェックポイント）
バックアップをリストア
例えば昨晩のフルバックアップを復元。
ロールフォワード
更新後の値（REDOログ）
チェックポイント以降の更新ログを順に適用して、障害直前まで追いつく。
ロールバック
更新前の値（UNDOログ）
障害時にまだコミットしていなかったトランザクションを取り消す。
ロック関連
共有ロック（Sロック）
読み取り専用。他トランザクションも共有ロックなら同時に読める。更新は不可。
専有ロック（Xロック）
読み書きどちらも独占。他トランザクションはアクセス不可。
デッドロック
お互いに相手のロック解除を待って永久に進まない状態。
→ DBMSが検出してどちらかを強制的にロールバックする。
その他いろいろ
Indexed Database API(IndexedDB)
利用者のWebブラウザ内に永続的なデータベースを構築し、Webアプリケーションから利用するための一連のAPI仕様
IndexedDBでは、キーと値の組を格納し、キーに基づいてインデックス化されたオブジェクトを保存・取得・更新・削除することができるほか、トランザクション処理、カーソル処理なども定義されています。
CAP定理：
一貫性・可用性・分断耐性の3つの特性のうち、最大でも同時に2つまでしか満たすことができないとする定理
Apache Spark：
大量のデータに対する並列分散処理機能（並列性・耐障害性）を提供するオープンソースソフトウェアで、ビッグデータの活用を支えるフレームワークとして注目されています。Apache Sparkではデータを抽象的に扱うためRDD(Resilient Distributed Dataset)と呼ばれるデータ構造が用意され、このRDDに対して処理を記述していきます。キャッシュやインメモリにより、MapReduceと比較して、反復処理やデータの再利用でもストレージI/OやネットワークI/Oが少ないのが特徴です。
データレイク：必要に応じて加工するために，データを発生したままの形で格納して蓄積する。
ダイス：
多次元データベースの中から縦軸と横軸を指定して2次元の表にする操作
CEP(Complex Event Processing：複合イベント処理)
刻々と発生する膨大なデータをリアルタイムで解析し、条件に合致したものだけを処理する技術の総称
BASE特性
分散DBやNoSQL で「ACID特性を完全には守らない代わりに、スケーラビリティや可用性を重視する考え方」
-
Basically Available（基本的に利用可能）
システム障害や部分的な不具合があっても、基本的にはサービスを提供し続ける。
例：ノードが1つ落ちても残りで処理を続行。 -
Soft state（ソフトな状態）
状態は一時的に不整合があっても良い。
つまり「即座に整合性が取れていなくても許す」。
例：あるノードではまだ古いデータを返すかもしれない。 -
Eventual consistency（結果整合性）
時間が経てば最終的には全ノードで整合性が保たれる。
ただし即時には整合性が保証されない。
例：ショッピングサイトで「在庫が0」になったのに、他ノードではまだ「在庫あり」と返す場合があるが、最終的には同期されて一致する。
| 項目 | ACID特性（従来RDB） | BASE特性（NoSQLなど） |
|---|---|---|
| 一貫性 | 厳格に保証 | 最終的に保証（Eventual） |
| 可用性 | 整合性を優先して止めることもある | 障害があっても基本稼働（Available） |
| 状態 | 常に一貫した状態 | 一時的に不整合を許す（Soft state） |