###### tags: `TransactionalInformationSystems`

# 1章 イントロ、及びハードウェアのさらっとした説明

トランザクション処理の発祥はDBMSから。特にオンライントランザクション処理(OLTP)を要する送金処理や飛行機予約などで必要とされてきた。

ただ、ここで扱うトランザクションは保存されたデータの処理に限らず、例えばeコマースにおける顧客と販売者、金融機関への通知といったAtomicityが必要とされる他の処理も含まれる

リファレンスアーキテクチャとして、クライアント、アプリケーションサーバ、データサーバの3者を考える

- アプリケーションサーバはいわゆるrequest brokerで、本書ではあくまで抽象的に言及
- データベースのデータはSQLで取り扱うにしろStored procedureで取り扱うにしろ、最終的にサーバの二次記憶のデータベースページに記録される前提とする

特定のモデルに依存しないため、本書では2章の計算モデルでもっと抽象的に考える

Transactional Information SystemがACID特性を備えるために必要とする操作
- begin: トランザクションを開始する
- commit: トランザクションの結果を永久化する
- rollback: トランザクションを失敗としてabortする

ACID特性のためにに必要なコンポーネント
- concurrency control: トランザクションの分離性を保つための制御コンポ
- recovery: トランザクションの原子性と耐久性を保つためのコンポ

性能要件
- high throughput
- short response times

重要なのはconcurrecy controlやrecoveryがこれらのボトルネックにならないようにすることなので、可能であればいくらでも並列にトランザクションを実行できるのが望ましい

## 1.5 データベースサーバのアーキテクチャ概要

データベースシステムのレイヤ構成

- ストレージ : ページを管理する、キャッシュも独自に作成
- アクセス : インデックスの管理とデータレコードの操作
- クエリ実行 :
- クエリ解析&最適化 : クエリ解析、実行計画の立案と最適化
- 言語インタフェース : SQLなどのパースと認証などの処理

これら階層化されたプログラムを、複数のスレッドを生成してリクエストごとに並列実行するのが基本

### データがどのように保存されているか

各レコードはバイト列としてページに詰められている。ただし、可変長なデータ型もあるので、レコードの延長、収縮、移動が必要になる場合がある。

DBMSはインデックスなどで各レコードへのポインタを持っているため、このポインタが書き換わるようなことは避けたい。

これは間接的にポインタを持つことで解決できる。具体的には、インデックス側ではrecord ID(RID)として、ページ番号とslot array(page trailer)のスロット番号の組を保持する。
slot arrayはページ内の各レコードへの完全なアドレスを持っている。ページ内でのレコード移動だけならslotの中身書き換えだけで完結する。ページをまたいだ移動の場合は、slotだけ元の位置に残して、レコード移動先の位置を参照する。

これによって高々2回のページアクセスで各レコードにアクセスできるようになる

(BLOBの取り扱い) データを分割してページに保存し、レコードにはBLOBが保存されているページリストを格納するのが最もシンプル

連続するページを複数確保したextentを複数作りextent tableで参照する

### データがどのようにアクセスされているか

テーブルフルスキャンの話とインデックスの話

B+木の一貫性を維持することは不可欠(簡単に壊れる)で、concurrency controlとrecoveryにとって大きな課題なので1章分使って触れる

## 1章総括

トランザクションとは本質的に、アプリケーションプログラムと複数のトランザクションサーバの間の契約で、複数のリクエストを単一の論理的な単位としてまとめて取り扱うためのものである。