2021-01-17 用課題¶
- 先に進む前に録画してあるか確認しよう
進捗¶
- 前回の進捗
- 基礎知識編:P.319 6.5.3 その他の DML 文
- 本編:04-01「期待値をコードで表す」まで
- 今回の進捗
- 基礎知識編:P.326 ビューの更新
- 本編:04-02「よくある条件付き確率密度関数(確率分布)」まで
課題¶
- オリジナルコンテンツへのリンク
- 勉強会のコンテンツまとめ:GitHub へのリンク
- matplotlib を忘れないように、簡単なグラフをいくつか描いてみてください。
- TeX でいろいろな式を書いてみましょう。
- 勉強の日常組み込み系
- Julia:The Little Book of Julia Algorithmsを読んでみることにしました。適当に話します。
- そのうち取り組む事案:黒木さんの Julia での統計ネタ
- 応用情報の本を一日2ページくらい眺めてみてください。毎日やれば大体 1 年で読み終わります。
**# TODO - AWS のハンズオン - 公式のハンズオン: 無料でできるハンズオンもたくさんある - 東大の AWS クラウド講義資料を眺めてみてください。せっかくなので状況を見て(私の勉強も兼ねて)「勉強会前半パート」で取り上げようと思います。(とりあえず当面はやらない感じにする?) - 面白そう:Julia での機械学習アルゴリズム本 - Algorithms for Optimization by Mykel J. Kochenderfer and Tim A. Wheeler @mitpress
自分用メモ¶
- 遅延型方程式に対するコメント追加
- matplotlib のチュートリアルを読もうの会
- 公式情報に触れる重要性
- 古い情報が古いと書いてあったりする:たとえば
pylab
- Gallery
- 見ていて面白い
- 「どこをいじるとどう変わるか」が視覚的にわかる
- 公式情報なのできちんとアップデートしてくれている(はず)
- 公式情報にソースがあるので自分でいろいろ書き換えていて破滅したとき、必ずオリジナルを復元できる
- 実際に競プロの問題をいくつか解いてみましょう。
Matplotlib¶
- 本当に簡単な図を描く
- これを参考に scipy お絵描き
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
日々の勉強¶
Julia¶
- The Little Book of Julia Algorithms
- リポジトリの対象ディレクトリ:ここ
- その他参考
IT 基礎知識¶
- 応用情報の本を一日2ページくらい眺めてみてください。毎日やれば大体 1 年で読み終わります。
- ネットワークの話もいい加減飽きたので、しばらく DB の話
復習¶
- 3 つのスキーマ
- ユーザーが見るレベル
- 正規化などをかけておいたデータベースにもっていけるレベル
- 個々のデータベースに合わせた具体的なレベル
- インメモリの DB:コンピューターの基本的なハードウェア構成と意味を復習しよう
本の記述を追いかける¶
P.408 7.8 交換方式¶
P.408 パケット交換方式¶
- 回線交換方式と対になる概念
- 回線交換方式:通信を行うノード間で物理的な通信路を確保してから通信する
- 例:電話
- パケット交換方式について
- データ送信するノードはデータをパケットに区切る。
- ひとつひとつのパケットにヘッダを付けて送信。
- ネットワーク内ではパケット交換機にパケットがたまる
- ネットワークの状況に応じて順次送られる
パケット通信のメリット・デメリット¶
メリット¶
耐障害性 - 通信路を固定しないため,迂回経路が取れる。 - パケット交換機にデータが蓄積されているため,復旧まで待てる。 - パケット多重 - 1 対 1 の通信で回線を占有する必要がないため,1つの回線を多くのノードで共有でき,回線を効率的につかえる - 異機種間接続性 - パケット交換機で中継するときにプロトコル変換・速度変換でエンドノードどうしが同じプロトコルをサポートしていなくても通信できる
デメリット¶
- ネットワーク内の蓄積交換処理による遅延
- 蓄積交換処理による遅延解消のために主に回線の帯域を広げることで対応してきた
- 構造上,完全には遅延をなくせない
- パケット到着順序の不整合
P.408 ATM 交換方式¶
- ATM(Asynchronous Transfer Mode:非同期転送モード)
- 遅延のない回線交換方式とパケット交換方式の利点を得たい
- パケット交換方式の発展
- 遅延の原因をつぶす:特にパケットの多様性
- 多種多様なパケットに対応するために,パケット交換機はソフトウェア処理が必要 ^ ATM での工夫の一例:最も特徴的なのは,パケット(ATMではセルという)の長さをヘッダ部 5 バイト,ペイロード 48 バイトの53バイトに統一
- パケット解析がハードウェアだけでできる。
- ソフトウェアは不要になった。
- Wikipedia から
- 当初の意図に反して非常に複雑な技術になってしまった
- ATM は次世代の主流にならず限定的な使用にとどまった
- ATM の設計思想は MPLS へと引き継がれた
- 汎用のレイヤ 2 のパケットスイッチングのプロトコルとして、ルーターを介したIPの通信網で利用されている。
P.408 ペイロード(payload)¶
- データ通信で本来転送したいデータ本体の部分、ボディを指す。
- ATM ではペイロードのサイズを固定して処理を簡素化
- 難点:パケット全体に占めるペイロードのサイズが相対的に小さくオーバヘッドが大きい
P.410 輻輳¶
- フレームリレー:パケット交換方式の一種
- 1 つの回線を多数のユーザで共有。
- 回線がもつ潜在的な伝送能力(ワイヤスピード)を十分に引き出すうえで効果がある
- 輻輳:ユーザの利用が一時期に集中すると,ワイヤスピードを超えるパケットがネットワーク上に流れる
- ネットワークが輻輳状態になるとスループットが落ちる
- フレームリレーサービスを提供する事業者は,ネットワークが輻輳状態に陥ってスループットが低下しても最低限保証する通信速度を決めている
- CIR(Committed Information Rate:認定情 報速度)
P.370 7 ネットワーク¶
- 確か 7.4 から始めた気がするので 7 章はじめから
P.370 7.1.1 OSI基本参照モデル¶
- 改めて復習
- OSI(Open System Interconnection)基本参照モデル- 異なる設計思想・世代のシステムと円滑に通信するのが目的に標準化
- プロトコルの単機能化,交換の容易さが目的
- 階層化のおかげで一部の階層の技術体系が変わっても、その階層だけ取り替えればいい
- コスト・リスクを小さくする
P.370 プロトコルとサービス¶
- N 層:それぞれの階層のこと
- エンティティ:N 層に存在する通信機器などの実体
- この言葉はいろいろなところで出てきていろいろな意味で使われる
- もちろん気分的には適当な実体を指すことが多い
- プロトコル:N 層に属するエンティティが通信するための取り決め
- 上位の層が下位の層を利用しながら通信する
- 別の階層間のエンティティどうしが通信する窓口が必要
- これを提供するのが下位層:この機能をサービスと呼ぶ
- プロトコルに沿った仕様で製品を開発すれば別のベンダの機器でも通信できる
- 参考:ベンダーロックイン
特定ベンダー(メーカー)の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のこと。
出来上がった情報システムの正確な仕様が、システムを開発・構築したベンダーにしか解らなくなる場合がある。結果、システムの保守・拡張・改修等の際、現存システムを開発・構築したベンダーに引き続き発注せざるを得なくなる。
- 「Excel で行政に提出する書類を作れ」事案もそれ。
- Apple 製品で身の回りを固めるのも同じ。
- 「多様性が大事」事案でもある。
7.1.2 TCP/IPプロトコルスイート¶
- プロトコル同士には相性がある
- 「ネットワーク層がこのプロトコルならトランスポート層はこのプロトコルにしておくとトラブルが少ない」
- 一般に同じ団体が作ったプロトコルはセットで使われることが多い
- このセットがプロトコルスイート ^ 最も代表的なのは IP を中心に組まれた TCP/IP プロトコルスイート
- 独自の階層モデルをもつ
P.372 TCP/IPの通信¶
- データをパケットに区切る
- 各パケットにヘッダを付けて送信
- ヘッダは各階層ごとに付加されて次の階層へと渡される
- 各ヘッダにはその階層で必要となる送信元や送信先,大きさ,順番などパケット自体に関する情報を含む
- TCPヘッダを付加したパケット:TCP セグメント
- IP ヘッダを付加したパケット:IP パケット
- MACヘッダを付加したパケット:MAC フレームあるいはイーサネットフレーム
P.372 MAC(Media Access Control)アドレス¶
- イーサネットや FDDI で使用される物理アドレス
- イーサネット (Ethernet):コンピューターネットワークの規格の1つ。オフィスや家庭で一般的に使用されている有線LAN (Local Area Network) の技術規格
- FDDI:LAN でデータ転送を行うための標準の一つ
- Fiber distributed data interface
- データリンク層
- 同じネットワークに接続された隣接ノード間の通信で相手を識別するために使う
- MACアドレスの長さ:6バイト
- 先頭24ビットの OUI(ベンダID)
- 後続24ビットの固有製造番号(製品に割り当てた番号)
- MAC アドレスは機器が固有にもつ番号
- 必ず一意に定まるように IEEE が管理
P372 ポート番号¶
- トランスポート層にでノード内のアプリケーションの識別に使う識別子番号
- 0-65535の範囲
- TCP/IPではパケット交換方式でデータをやり取りする
- よく使われるアプリケーションについてのポート番号は Well-Known ポートとして標準化
- TCP・UDPそれぞれで 0-1023 番までの番号を割り当てている
- SSH:TCP22番
- Telnet:TCP23番
- SMTP:TCP25番
- HTTP:TCP80番
- POP3:TCP110番
- IMAP4:TCP143番
- HTTPS :TCP443番
- NTP:UDP123番
- SNMP:UDP161番
- SNMP Trap :UDP162番
- セキュリティ対策のために標準とはポート番号を変えることもある
- Web 開発の本を読んでいると、いろいろな都合から http のポートを 80 以外にしていることもよくある。
- 80 の場合はポートを指定しなくてもいい
- 例:http://localhost/hoge/fuga
- 例:http://localhost:5000/hoge/fuga
- 80 の場合はポートを指定しなくてもいい
P.373 ネットワーク間の通信¶
- 同じネットワークに接続されたノード間はデータリンク層(第 2 層)の通信
- ネットワークを超えたノード間はネットワーク層(第 3 層)の通信 -実際に図 7.1.4 を見よう
- どこが IP アドレスでのやりとりか?
- どこが MAC アドレスでのやり取りか?
P.374 7.2 ネットワーク接続装置と関連技術¶
P.374 7.2.1 物理層の接続¶
P.374 リピータ¶
- ネットワーク上を流れる電流の増幅装置・整流装置
- 物理層:第 1 層
- データ通信はネットワーク上を流れる電流
- ケーブルが長いと電流が減衰・波形が乱れが起きる
- データが読み取れなくなる
- これを増幅するのがリピータ
- 大昔の電話は距離が遠いと音が小さく聞こえにくかった
- まさにこの減衰が問題
- リピータは 1:1 で繋ぐ
- 現在では複数のノードを接続できるマルチポートリピータ(ハブ)が使われるのが一般的
P.374 7.2.2 データリンク層の接続¶
- 第2層
P374 ブリッジ¶
- データリンク層に位置
- ネットワーク上を流れているフレーム(情報の単位)の MAC アドレスを認識して通信を中継する
- 接続されているノードをコリジョンドメイン(セグメント)という単位に分割
- MAC アドレスで判定したフレームのあて先のあるセグメントだけにフレームを送信
- 無駄なトラフィックの回避
- ポートの記憶
- 通信のたびにある MAC アドレスをもつノードがどのポート に接続されているか学習
- 次回の通信時には余分なポートには通信を中継しない。
- ブリッジの動作
- あて先MACアドレスをもとにMACアドレステーブルを参照する
- あて先MACアドレスの接続ポートがフレームを受信したポー トと別ポートであれば,そのポートにフレームを送信し
- 同一ポートであればフレームを破棄する
- あて先MACアドレスが記憶されていない場合やブロードキャス トアドレス(FF-FF-FF-FF-FF-FF)の場合は,受信ポート以外のすべてのポートにフレームを送信する
P.375 スイッチングハブ¶
- レイヤ2スイッチ(L2スイッチ)とも呼ばれる
- データリンク層に位置
- ブリッジと同じ働きをする
- MAC アドレスを認識してフレームのあて先を決めて通信を行います。
- 試験での問われ方
- スイッチングハブはフレームの蓄積機能、速度変換機能や交換機 能をもっている。
- このようなスイッチングハブと同等の機能をもち,同じプロトコル階層で動作する装置はどれか
- 答えは「ブリッジ」
P.375 ブロードキャストストリーム¶
- データリンク層で動作するブリッジやスイッチングハブなどの LANスイッチはブロードキャストフレームを受信ポート以外 のすべてのポートに転送
- これらの機器をループ状に接続し冗長化させると信頼性はあがる
- ブロードキャストフレームは永遠に回り続けながら増える
- 最終的にはネットワークダウンを招く
- この現象をブロードキャストストームという
- ブロードキャストストームを防ぐプロトコル:スパニングツリープロトコル(Spanning Tree Protocol:STP)
- ループを構成している一部のポートを通常運用時にはブロック(論理的に切断)する
- ネットワーク全体をループをもたない論理的なツリー構造にする
P.376 ネットワーク層の接続¶
- 第 3 層(レイヤ 3)
P.376 ルータ¶
- ルータはネットワーク層(第 3 層)に位置する
- あて先IPアドレスを見てパケットの送り先を決め通信を制御する
- IP のローカルネットワークの境界線に設置して利用され,ネットワークの基本単位として機能
- 世界中に散在しているローカルネットワークどうしをルータが結ぶ
- 全体としてインターネットというインフラが機能
- ルータで分けられたネットワークの単位をブロードキャストドメインという
- ルータがパケットを受け取ったあと
- あて先IPアドレスを見る
- 自分のネットワークあてであれば,破棄
- 他のネットワークあてであれば転送
- どのルータへ送ればあて先のネットワークへの通信が速く行えるかを判断することを経路制御(ルーティング)
- ルータはそのための経路表(ルーティングテーブル)を備えている
P.376 デフォルトゲートウェイ¶
- 会社Aのネットワークに属するPCは会社BのPCと直接通信できない
- 会社AのPCは他ネットワークへの接点であるルータAに転送を依頼
- デフォルトゲートウェイ:会社AのPCから見て直近のルータA
- 自分と直接接続していない相手と通信するときはすべてデフォルト ゲートウェイを中継する
P.376 ルーティング¶
- 経路表(ルーティングテーブル)の作成方法
- 手作業で作る:スタティックルーティング
- ルーティングプロトコル利用:ルータ同士が経路情報を交換し、自立的に経路表を作るダイナミックルーティング
- ダイナミックルーティングのための代表的なルーティングプロトコル:RIP、OSPF
- RIP:ディスタンスベクタ型(距離ベクトル型)
- ルーティングテーブルの情報(経路情報)を一定時間間隔で交換しあう
- あて先ネットワークにいたるまでに経由するルータの数(ホップ数)最小経路を選ぶ
- あて先に到達可能な最大ホップ数は 15
- これを超えた経路は採用されない
- OSPF:リンクステート型
- コストを経路選択の要素に取り入れ、コスト最小経路を選ぶ
- コスト値は,回線速度を基に自動的に算出されるが手動設定もできる
- コスト算出式「コスト=100Mbps/経路の通信帯域(bps)」
- コスト計算例は P.377 の図を見ること
P.377 ルータの冗長構成¶
- ルータを冗長構成のために使うプロトコル:VRRP(Virtual Router Redundancy Protocol )
- 同じ LAN に接続された複数のルータを仮想的に 1 台のルータ として見えるようにして冗長構成を実現する
- 複数のルータでグループ(VRRP グループ)を作る
- VRRP グループごとに仮想 IP アドレスと仮想 MAC アドレスを割り当て
- PC などのノードは仮想ルータの IP アドレスに対して通信
- 通常時はグループのマスタルータが仮想ルータの IP アドレス(仮想 IP アドレス)を保持
- マスタルータに障害が発生すると他のバックアップルータがこれを継承
P.377 レイヤ3スイッチ(L3スイッチ)¶
- ルータと同じネットワーク層(第 3 層)の通信機器
- 特徴
- ルータ:ソフトウェアで転送処理
- レイヤ 3 スイッチ:専用ハードウェアで転送処理
- 高速処理できる:大容量のファイルを扱うファイルサーバへのアクセスなど
P.378 トランスポート層以上の層の接続¶
P.378 ゲートウェイ¶
- トランスポート層(第 4 層)-アプリケーション層(第7層)でネットワーク接続するための装置
- 第 3 層のネットワーク層まででエンドツーエンド(E2E)の通信は完成する
- E2E = 通信を行う二者、あるいは、二者間を結ぶ経路全体
- エンドツーエンド原理:高度な通信制御や複雑な機能は末端のシステムが担い、経路上のシステムは単純に信号やデータの中継・転送だけすべし
- TCP/IP ネットワークの原理
- 誤り訂正・フロー制御・再送:TCP 層(第4層、トランスポート層)など上位側の機器やソフトウェア・プロトコル
- 単純な送受信・転送処理:IP 層(第3層、ネットワーク層)
- ゲートウェイ:第 4 層のトランスポート層以上が違う LAN システム相互間のプロトコル・データ形式の変換を担う
- ゲートウェイはアプリケーションプロトコルの内容を 解釈できる
- アプリケーションヘッダの不正な情報混入を検出可能
- ファイアウォール・プロキシサーバもゲートウェイの一種
P.378 L4スイッチ・L7スイッチ¶
- L4スイッチ(レイヤ4スイッチ)はトランスポート層(第4層)の装置
- 定義としてはゲートウェイ
- 機能的にはレイヤ2スイッチ・レイヤ3スイッチの延長上
- ルータやレイヤ3スイッチはIPアドレスを参照して経路制御する
- L4スイッチではTCPポート番号やUDPポート番号も経路制御判断に使える:第4層の機器だから
- L7スイッチ:アプリケーション層(第7層)までの情報を使って通信制御する
P.379 7.2.5 VLAN¶
- VLAN(Virtual LAN:仮想LAN)
- スイッチ(レイヤ2スイッチ,レイヤ3スイッチ)で物理的な接続形態とは独立に仮想的なLANグループを構成する仕組み,あるいはそう構成されたLAN
- 複雑な形態のネットワークを楽に構築できる
- サブネット構成も柔軟に変えられる
P.380 データリンク層の制御とプロトコル¶
- データリンク層:第2層
P.380 7.3.1 メディアアクセス制御¶
- 複数のデータを1つのケーブルを通して送受する場合,データの衝突(コリジョン)を回避するための制御が必要
- これがメディアアクセス制御(Media Access Control:MAC)
コリジョン(衝突)¶
イーサネットや無線LANで複数の端末が送信し、データが衝突する現象を指す。旧式のイーサネット規格では、端末同士を接続するときに1組の通信路で双方向の通信を行う半二重通信のため、送信と受信を同時に行うことができない。送信と受信をその都度切り替えて行うので、端末がお互いデータを送信してしまうと衝突する可能性が高くなる。
P.380 CSMA/CD¶
- CSMA/CD:Carrier Sense Multiple Access with Collision Detection:搬送波感知多重アクセ ス/衝突検出)の略。
- イーサネットで採用されている方式
- 衝突検知方式を採用
- イーサネット:IEEE 802.3として標準化されている LAN規格
- CSMA/CD
- 各ノードは伝送媒体が使用中かどうかを調べて,使用中でなければデータを送りはじめる
- 複数のノードが同時に通信しはじめるとデータの衝突が起こる
- 衝突を検知し,一定時間(ランダム)待った後で,再送
- 一定の距離以上のケーブルでは衝突が検知できない
- CSMA/CD方式の限界
- トラフィックが増加するにつれて衝突が多くなる
- 再送が増え,さらにトラフィックが増加する悪循環に陥る可能性がある
- 特に伝送路の使用率が30%を超えると実用的でなくなる
P.381トークンパッシング方式¶
- トークンによる送信制御を行う方式で
- トークンバス方式
- トークンリング方式
P.381 トークンパッシング方式¶
- ネットワーク上をフリートークンと呼ばれる送信権のためのパケットが巡回する
- フリートークンを獲得したノードだけが送信できるので衝突を避けられる
- ふつうはコンセントレータ(集線器)でネットワ ークとノードを結ぶ
- トークンパッシング方式を採用したLAN規格
- 例:FDDI:Fiber Distributed Data Interface
- FDDIは物理媒体に光ファイバを利用し,最大100Mビ ッ ト/秒の通信
- 特徴
- 伝送媒体上では衝突しない
- トラフィックが増えるにつれてトークンを獲得しにくくなり,少しずつ遅延時間が増える
- 衝突による再送制御の必要がないため伝送路の使用率に対する遅延時間の増加率はCSMA/CD方式より緩やか
P.382 TDMA 方式¶
- TDM(時分割多重)
- ネットワーク上にデータを送信する時間を割 り当てる(タイムスロット)
- タイムスロットごとに別のデータを送って多重化する
- TDM によるアクセス制御が TDMA
- TDMA(Time Division Multiple Access:時分割多重アクセス)
- CSMA/CD・トークンパッシング方式と並ぶ主要なデー タリンク技術
- TDMA ではネットワーク(伝送路)を使える時間を細かく区切る
- 割り当てられた時間は各ノードが独占する方式
- TDMAはコネクション型の通信
P.382 7.3.2 無線LANのアクセス制御方式¶
P.382 CSMA/CA方式¶
- CSMA/CA:Carrier Sense Multiple Access with Collision Avoidance、搬送波感知多重アクセス/衝突回避
- 無線 LAN の制御方式
- CSMA/CD との違い:「衝突検出」が「衝突回避」になった
- 無線 LAN:物理層媒体は電波で衝突の検出は不可能だから回避する
- 特徴
- 送信ノードは使いたい周波数帯の使えるか確認後、必ずランダムな時間だけ待ってから送信をはじめる
- 待ち時間をバックオフ制御時間とよぶ
- 衝突してフレームが壊れても検出できない
- データを受け取ったノードは ACK を返す
- 送信ノードは使いたい周波数帯の使えるか確認後、必ずランダムな時間だけ待ってから送信をはじめる
P.328 RTS/CTS¶
- 無線 LAN の話
- 隠れ端末問題
- 他のノードのデータ送信を感知できないことがある
- 通信ノード間の距離が遠い
- ノード間に障害物がある
- 回避のための RTS/CTS 方式
- 無線 LAN ノード
- データ送信前にRTS(Request ToSend:送信リクエスト)をアクセスポイントに送信
- これを受理したアクセスポイントがCTS(Clear to Send:送信OK)を返信
- 他のノードは CTS を傍受して自分以外の別のノードに送信権があると解釈
- データ送信を延期
- 無線LANノードはアクセスポイントからCTSを受信したらデータ送信開始します
- 衝突抑制:CTSに書かれた他のノードに対する送信抑制時間を使う
- データ送信開始前にデータ送信のネゴシエーシ ョンとして RTS/CTS 方式を使った CSMA/CA を CSMA/CA with RTS/CTS とよぶ
P.383 無線LANの動作モード¶
- 無線 LAN の動作モード:図7.3.4参照
- 2 つのモードがある
- インフラストラクチャモード:無線LANノードがアク セスポイントを通じて相互に通信
- アドホックモード:アクセスポイントなしに無線LANノードどうしが直接通信
P.383 COLUMN FDMA,CDMA¶
- 表7.3.1:多元接続する技術グループ
- TDMA とセット
- FDMA
- ある周波数帯をさらに細かい周波数帯に分割
- 接続できる端末数を増やす技術
- CDMA
- 周波数も時間も分割しない
- 符号で各端末の通信を識別・分離
- 接続できる端末数を増やす
P.383 7.3.3 データリンク層の主なプロトコル¶
- 第 2 層
P.384 ARP¶
- ARP(Address Resolution Protocol):通信相手のIPアドレスからMACアドレスを取るためのプロトコル
- ARPの動作
- ブロードキャストで目的IPアドレスを指定したARP要求パケットをLAN全体に流す
- ブロードキャスト:ネットワークに参加するすべての機器に同時に信号やデータを送ること
- 各ノードは自分のIPアドレスと比較
- 一致したノードだけARP応答パケットに自分のMACアドレスを入れて返す(ユニキャスト)
- ブロードキャストで目的IPアドレスを指定したARP要求パケットをLAN全体に流す
- 参考:GARP(Gratuitous ARP)
- 主な目的:自身に設定するIPアドレスの重複確認・ARPテ ーブルの更新
- 目的IPアドレスに自身が使うIPアドレスを指定し,MACアドレスを問い合わせる
P.384 RARP¶
- Reverse-ARP:逆アドレス解決プロトコル
- MACアドレスからIPアドレスを取る
- 電源オフ時にIPアドレスを保持できない(IPアドレスを保持するハードディスクをもたない)機器が電源オン時に自分のMACアドレスから自身に割り当てられているIPアドレスを知るために使う
- RARP サーバー
- MACアドレスとIPアドレスの対応表を持ったサーバー(RARPサーバー)が必要
P.384 PPP¶
- PPP:Point to Point Protocol
- 2 点間をポイントツーポイントでつなぐためのデータリンクプロトコル
- WANを介して2つのノードをダイヤルアップ接続するときに使う
- ネットワーク層(第3層)とネゴシエーションする NCP(ネットワーク制御プロトコル)とリンクネゴシエーションするLCP(リンク制御プロトコル)からなる
- NCP:Network Control Protocol
- LCP:Link Control Protocol
- リンク制御やエラー処理機能を持つ
P.384 PPPoE¶
- PPPoE:PPP over Ethernet
- PPPと同等な機能をイーサネット(LAN)上で実現するプロトコル
- PPPフレームをイーサネットフレームでカプセル化して実現
P.384 7.3.4 IEEE 802.3規格¶
- メディアアクセス制御に CSMA/CD 方式を使う LAN についての標準
- OSI基本参照モデルにおけるデータリンク層(第 2 層)と物理層(第 1 層)のプロトコルおよびサービスを規定
- OSI 基本参照モデルでのデータリンク層を LLC 副層と MAC 副層の2つに分割
- 物理層での LAN で使う伝送媒体や MAC 副層でのフレーム構成や衝突検出の仕組みを規定
- ツイストケーブルの企画が表 7.3.2 にまとまっている
P.386 7.4 ネットワーク層のプロトコルと技術¶
- もうやった
P.319 6.5.3 その他の DML 文¶
P.319 INSERT文¶
- 表に行を挿入する:2つ方法がある
- 参考:本の P.319
- 挿入する値をVALUES句で指定する
- 問合せの結果をすべて挿入する
- (DBMS によるかもしれないが)個別INSERTと一括INSERTもある:パフォーマンスでよく問題になる
- 一部の列に対して INSERT
- どの列に対して挿入するのか列名リストで指定
- 省略された列の値はDEFAULT制約があればその既定値、そうでなければNULL値
- NULL はなるべく使うのをやめよう
- DEFAULT は P.322 表 6.6.1
1 2 |
|
1 |
|
P.319 UPDATE文¶
- 表中のデータを変更
- 列の変更値を直接指定する
- 変更値をCASE式で決める
- 副問合せの結果を変更値にする
- SET句には変更したい列の値を「列名 = 変更値」の形で指定
- 1 つのUPDATE文で複数の列の値を変えるときはカンマ(,)で区切って指定
- WHERE句を省略すると表中のすべての行が変わる
- ふつうはやらない
- WHERE句を指定すれば条件に合った行だけ変わる
1 2 3 4 |
|
P.320 DELETE文¶
- 表中の行を削除する
- 表中の全行を削除しても表自体は残る
- 表を削除するのはDROP文
- WHERE句を省略すると表中のすべての行が削除される
- WHERE句を指定するとその条件に一致した行だけを削除できる
P.320 参照関係をもつ表の更新¶
- 関連する2つの表の間に参照制約が設定できる
- 被参照表の主キー(候補キー)にない値を参照表の外部キーに追加できない
- 被参照表の行の削除・変更時に制約が出る:図6.5.10参照
- 参照動作指定:削除・変更時の制約は明示的に指定できる
- 次節のCREATE TABLE文を参照
- REFERENCES句(参照指定)の後に次の構文で指定
参照動作指定 REFERENCES 被参照表(参照する列リスト) ON DELETE 参照動作] [ON UPDATE 参照動作] (*[ ]内は省略可能)
- 指摘できる参照動作:表 6.5.5 の 5つ
- デフォルトは NO ACTION
P.320 補足¶
- 参照制約
- 外部キーの値が被参照表の主キーあるいは主キー以外の候補キーに存在することを保証する制約。
- 関連する2つの表の間に参照制約を設定する目的:データ矛盾を起こすような行の追加や削除・変更を排除するため
- REFERENCES指定:p322-324を参照
- データの整合性を保つための制約
- 一意性制約
- 参照制約
- データ項目のデータ型や桁数に関する形式制約
- データ項目が取り得る値の範囲に関するドメイン制約がある。
P.322 6.6 データ定義言語(DDL)¶
P.322 6.6.1 実表の定義¶
P.322 CREATE TABLE文¶
- 表の定義は CREATE TABLE 文
- 基本構文は P.322 参照
P.322 列制約¶
- 表を構成する列に対する制約
- 参考:表6.6.1
- 一意性制約:同一表内に同じ値が複数存在しないことを保証する制約
- 主キーとなる列には一意性制約とNOT NULL制約を加えたPRIMARY KEY指定
- 主キー以外の候補キーにも一意性制約がある
- 一般にNULL(ナル)値は重複値とは扱われない
- 候補キーにはNULL値を許すUNIQUE指定
- 参照制約:外部キーの値が被参照表に存在することを保証する制約
- 外部キー:REFERENCES指定(参照指定)す。
P.323 表制約¶
- 一意性制約・参照制約・検査制約は表制約(表定義の要素として定義される制約)にもできる
- 列制約:1つの列に対する制約
- 主キーや外部キーが複数列から構成される場合、これを列制約として定義できない
- このときは表制約を使う
P.323 主なデータ型¶
- 一般的な文字型,数値型は覚えておくといい
P.324 実表の定義例¶
- P.324 の社員表と部門表を定義を見てみよう
P.325 6.6.2 ビューの定義¶
P.325 ビューとは¶
- 実表:ディスク装置上にあり実際にデータが格納される表
- ビュー:実表の一部または複数の表から必要な行や属性(列)を取り出してあたかも1つの表 であるかのように見せかけた仮想表
- 利用者から見れば実表と同じ
- データを検索するだけなら制約はあっても同じように操作できる
- ビューのメリット
- あくまでも仮想の表:対象となった元の表(基底表)の列名と別の名前で定義できる
- ビューに定義することで情報を公開
- ビューに定義しないことで情報を非公開にできる
- 元の表に新たな列が追加されても既存のビューには影響がなく再定義する必要がない
- ビューは仮想的な表
- 一般には実体化されずデータ格納領域をとら ない。
- 実表のように実体化されるビューもある:体現ビュー(materialized view)
- 参考
P.325 CREATE VIEW文¶
- ビューの定義:CREATE VIEW文による:詳細は本の P.325
- ビュー:対象となる実表(あるいは他のビュー)からSELECT文で必要データを導出する方法で定義される定義するビューの列名に命名規則はない
- 列数はAS句に続くSELECTで問い合わせた結果の列数と同じでなければならない
- 列名は省略可能:省略した場合はSELECTで問い合わせた結果の列名がそのまま定義される
- ビューに対する参照や更新処理
- ビューの対象となった表(基底表)に対す る参照あるいは更新処理に変換されて実行される
P.326 ビューの定義例¶
- 本の P.326 参照
- 社員表と部門表から社員コードと社員名、その社員が所属する部門名からなる表をビュー「社員表2」
- JOIN して必要なカラムだけ取り出す
P.326 ビューの更新¶
- ビューへの更新処理 ビュー定義を基にビューが参照している表(基底表)への対応する処理に変換されて実行
- 更新のための条件
- 更新にかかる実際の表が更新可能
- 更新される表の列や行が一意に決まる
- 更新できないビューの例
- SELECT句で式、集合関数、DISTINCT を使ったSELECT文で定義されている
- ・GROUP BY句やHAVING句を使ったSELECT文で定義されている
P.327 6.6.3 オブジェクト(表)の処理権限¶
- スキーマに定義された実表やビューはそのスキーマ所有者(作成者)にしか処理権限が与えられない
- 複数の利用者がデータベースを利用できるようにしたければ、スキーマ所有者以外にも処理権限を付与する必要がある
- データベース管理ユーザーは全権を持っていて危険な処理もできてしまう
- できることを制限したユーザーで操作したい
- オブジェクト(表)の処理権限
- 読取(SELECT)権限
- 削除(DELETE)権限
- 挿入(INSERT)権限
- 更新(UPDATE)権限
- cf. スキーマ
- 1つのデータベースの枠組み
- スキーマ内に複数の表やビューを定義できる
P.327 処理権限の付与¶
- 権限の付与:GRANT文による
- GRANTの基本構文は次の通り
1 |
|
- 権限指定
- 4 つの処理権限(SELECT,INSERT,UPDATE,DELETE)
- ALL PRIVILEGES(すべて)を指定できる
- 権限を複数付与する場合はカンマ(,)で区切って指定
P.327 処理権限の取消し(変更)¶
- 一度付与された権限を取消し(変更)できる
- 権限の取消しはREVOKE文
- REVOKEの基本構文
1 |
|
P.328 6.7 埋込み方式¶
P.328 6.7.1 埋込みSQLの基本事項¶
P.328 静的SQLと動的SQL¶
- 静的 SQL:あらかじめ決められたSQL文をプログラム中に埋込んで実行する方式
- 実際のアプリケーションではあまり見かけない
- 非カーソル処理:データベースの表から1行を取り出すこと
- 次のような SELECT 文
- この
INTO
を見たことがない
SELECT 社員名, 年齢 INTO :name, :age FROM 社員表 WHERE 社員コード = '100';
- 動的 SQL:実行する SQL 文がプログラム実行中でな ければ決まらない場合に SQL 文を動的に作成し実行する方式
- 上の社員コードがふつう変わる:それが「動的」。
- この動的な部分に変なコードを埋め込むとまずいというのがセキュリティ問題で、例えば SQL インジェクションの問題。
P.328 ホスト変数¶
- ホスト変数:データベースとプログラムのインタフェースとなる変数
- 埋め込み SQL では SQL を実行すると取り出されたデータをINTO句で指定したホスト変数に格納する
- ホスト変数は通常の変数としてもアクセスできる
- 出力関数で表示
- 入力関数で値を入力してそれをSELECT文の条件としても使える
P.329 6.7.2 カーソル処理とFETCH¶
P.329 カーソル処理¶
- 「SELECT・・・・INTO・・・」形式では,1行のデータしか取り出せない
- (見たことがないのでイメージがつかない)
- 検索結果が複数行の場合は1行ずつ取り出せるカーソル処理を使う
- カーソル処理は SQL 文で問い合わせた結果をあたかも1つのファイルであるかのようにとらえる
- FETCH文でそこから1行ずつ取り出す方式
- 1つのSELECT文に対してカーソルを宣言(定義)
- カーソルのオープンでSELECT文が実行
- カーソルで1行ずつ取り出せる
- FETCH文で繰返し行を取り出して処理
- 終了したらカーソルを閉じる
P.330 FETCHで取り出した行の更新¶
- 参考:図 6.7.2:FETCHで取り出した行の更新処理
- FETCH文で取り出した行を更新あるいは削除する場合,FETCH文のあとに続くUPDATE文やDELETE文のWHERE句 に「WHERE CURRENT OF カーソル名」と指定する。
- (FETCH 文を見たことがないのでイメージつかない)
P.330 処理の確定と取消し¶
- 一連のデータを更新している途中でエラーが出た場合
- それまでの更新処理を取り消して元に戻す必要がある
- 整合性を取らないといけない:いわゆるロールバックが必要
- トランザクションが正常終了したときは「コミット」する:更新処理の確定
P.331 6.8 データベース管理システム¶
P.331 6.8.1 トランザクション管理¶
P.331 トランザクションとは¶
- 複数の利用者が同時にデータベースにアクセスしてもデータが矛盾してはいけない
- この仕組みがトランザクション管理
- トランザクション:データの整合性を取るための SQL 処理の最小単位
- 「回復の単位(Unit of Re-covery)」とも呼ぶ
P.331 ACID 特性¶
- トランザクション処理は原子性・一貫性・隔離性・耐久性の 4 特性が必要
- 厳密な一貫性(完全一貫性)が必要
- トランザクションではそのすべての処理が完了するか(All)、あるいはまったく実行されていない状態か(Nothing)のどちらか一方で終了しなければならない
- これは,COMMIT(正常終了),、ROLLBACK(異常終了)で実現できる
- COMMIT(コミット):更新処理を確定し、データベ ースへの反映を保証する
- ROLLBACK(ロールバック):更新処理をすべて取 消し,トランザクション開始時点の状態へ戻す
- 参考:結果整合性
- 完全一貫性に対する概念
- 分散トランザクションやいわゆる NoSQL で使われる
- 参考:分散トランザクション
- トランザクション管理するべきテーブルが複数のデータベースにまたがっているとき
- すべてのデータベースをロールバックしなければいけない
P.331 表 6.8.1 ACID 特性¶
- 原子性(Atomicity)
- 更新処理トランザクションが正常終了した場合だけデータベースへの反映を保証する
- 異常終了時は処理が何もなかった状態に戻す
- 一貫性(Consistency)
- トランザクションの処理によってデータベース内のデ ータに矛盾が生じないこと
- 常に整合性のある状態が保たれていること
- 隔離性(Isolation)
- 複数のトランザクションを同時(並行)に実行した場合 と,順(直列)に実行した場合の処理結果が一致するこ と
- 独立性ともいう
- トランザクションのスケーリング:複数のトランザクションを同時実行してもそれが正しい順で実行されるように順序づけること
- 基本は並行実行の結果と直列実行の結果が等しくなるように調整する
- ロック:直列可能性を保証する方法
- 耐久性(Durability)
- いったん正常終了したトランザクションの結果はそ の後に障害が発生してもデータベースから消失しないこと
- トランザクションの再実行を必要としないこと
P.332 6.8.2 同時実行制御¶
- 同時実行制御(並行性制御):複数のトランザクションを同時に実行しても矛盾を起こすことなく処理を実行するメカニズム
- 実現する方法:ロック・多版同時実行制御・時刻印アルゴリズム
- 多版同時実行制御に対してロックによる通常の同時実行制御を単版同時実行制御という
P.331 ロック¶
- 複数のトランザクションを同時実行してもその結果はトランザクションを直列実行した結果と同じでなければならない(ACID 特性の隔離性)
- 同時実行制御が行われない環境では結果が変わる場合もある
- 例:図 6.8.1 を見ること
- トランザクションTR1とトランザクションTR2が同じデータaを①→②の順に読み込む
- それぞれのトランザクションでデータaを③→④の順に更
- COMMITした場合トランザクションTR1がデータaを「a+5→10」に更新してもトランザクションTR2が aの値を「a+10→15」に更新してしまう
- トランザクションTR1における更新内容が失われる
- これを変更消失(ロストアップデート)という
- こうした問題を防ぐための対処法
- データベース管理システムではデータaにロック(鍵)をかける
- 咲にデータaをアクセスしたトランザクションの処理が終了するか、あるいはロックが解除されるまでほかのトランザクションを待たせる制御をする
- 参考 ダーティリード:他のトランザクションが更新中のコミットされていないデータを読み込むこと
P.333 デッドロック¶
- P.250 5.2.5 も参考にすること
- デッドロック:複数のデータに対してロックしようとして互いにロックの解除を待ち続けてしまう
- 例:図 6.8.2
- データA、B、Cを専有して処理するトランザクションTR1,TR2,TR3がある
- 各トランザクションは処理の進行に合わせて表に示される順(①→②→③)にデータを専有
- トランザクション終了時に3つの資源を一括して解放
- トランザクションTR1とトランザクションTR2はデッドロックを起こす可能性がある
- 再び図 6.8.2 を見る
- データを専有する順序が等しいトランザションTR1とTR3の間ではデッドロックは起こらない
- 異なる順や逆順でデータを専有するトランザクション間ではデッドロックが起きうる
- デッドロックが起きたときロールバックなどで 1 つのトランザクションを強制的に終了させてデッドロックを解除する
P.334 ロック方式¶
- 2相ロック方式・木規約
- ロック方式
- 第1相:使用するデータすべてにロックをかける
- 第2相:処理後にロックを解除する
- トランザクション内でのロック・解除はそれぞれ1回だけ
- 直列可能性は保証されるがデッドロック発生の可能性は 残る
- 木規約
- データに順番をつけてその順番どおりにロックをかける
- デッドロックが起きず、直列可能性を保証する
- データへの順番づけには木(有向木)を使う
- トランザクションの同時実行性が低くなるため特殊な用途で使う(どんなところで使うのだろう?)
- 参考:有向木
- 方向をもった有向グラフ(の 1 つ)
- データ構造とアルゴリズムを勉強しよう
- データベースは検索の便宜もあってデータ構造とアルゴリズムが大事
P.334 ロックの種類¶
- 占有ロック・共有ロックの 2 モード
- DBMS でトランザクションの同時実行性を高めるため
- 専有ロック
- データ更新するときに使うロック
- データに対するほかのトランザクションからのアクセスは一切禁止
- 共有ロック
- ふつうデータの読取りの際に使用されるロックで
- 参照だけを許可
- 表 6.8.2 参照:2 つのロックモードの組み合わせによる同時実行の可否
- 専有:占有または排他ともいう
- 共有:共用ともいう
- 共有ロックで同時実行性を高める
- 先行トランザクションがロックしたデータを後続トランザクションが参照できる
- 待ちがなくなり同時実行性が高まる
- たいていのシステムでは書き込みよりも読み込みの方が多い
P.335 ロックの粒度¶
- ロックをかける単位:表・ブロック・行
- ブロック:物理的なIOの単位
- ロックの単位をロックの粒度という。
- 粒度が小さければ小さいほど同時実行性があがる代わりにロックの回数が多くなり、ロック制御のためのオーバーヘッドが増える
- 粒度が大きいほどロックの解除待ちが長くなり、同時実行性が下がる
P.336 多版同時実行制御(MVCC:MultiVersion Concurrency Control)¶
- 同時実行性を高めつつ一貫性のあるトランザクシ ョン処理を実現する仕組み
- ふつう専有ロック中(更新中)のデータは参照できない
- 後続トランザクションはロックの解除を待つ
- 多版同時実行制御での対処
- 更新中のデータに対する参照要求に更新前(トランザクション開始前)の内容を返す
- 後続トランザクションを待たずに処理できる
- 専有ロックと共有ロックの同時確保で同時実行性を高める一方で、後続トランザクションには現在からさかのぼったある時点における一貫性のあるデータを提供する
- 整合性を欠いたデータの参照を防げる
参考:整合性を欠いたデータの参照¶
- ダーティリード
- アンリピータブルリード
- 再度読み込んだデータが他のトランザクションで更新されている
- 前回読み込んだ値と一致しない
- フ ァ ン ト ム リ ー ド
- 再度読み込んだデータの中に他のトランザ クションによって追加・削除されたデータがある
- 前回と検索結果が変わる
P.335 時刻印アルゴリズム¶
- ロック制御をせずに同時実行制御を行う方法としての時刻印(タイムスタンプ)アルゴリズム
- トランザクションが発生した時刻 T とデータのもつ読込み時刻 Tr、あるいは書込み時刻 Tw を比較して読み書きを判断する
- 読み込みの場合
- Tw≦T のときだけ読み込む
- 読み取ったあとは読み込み時刻 Tr にトランザクション発生時刻 T を設定
- 書き込みの場合
- Tw≦T かつ Tr≦T のときだけ書き込む
- 書き込み後、書込み時刻 Tw にトランザクション発生時刻Tを設定
- 参考:P.336 図 6.8.4
参考:楽観ロック¶
- 楽観的方式:ロック制御をしない他の方法
- 仮定:同じデータへのアクセス(更新要求)はめったに発生しない
- 処理を進めて更新直前にほかのトランザクションでそのデータが更新されたかどうかを確認する
- 更新された場合はロールバックする
- 実装例
- データベースに「更新回数」のようなカラムを持たせる
- データ取得時に更新回数も送る
- データ更新するときは更新回数つきでサーバーにリクエストを出す
- 更新回数が同じなら更新する
- 更新回数が違うなら更新要求を却下する
- ほぼ同じタイミングで複数の更新要求が出ることはあり、このときは更新が重複して異常が出る
- これが起きない(起きにくい)というのが最初に書いた「同じデータへの更新要求はめったに発生内」という仮定
P.336 障害回復管理¶
P.336 障害の種類¶
- データベースに発生する障害の三大分類
- 媒体障害:記憶媒体の故障でデータが消失
- システム障害:DBMSやOSのバグ・オペレータの誤操作によるシステムダウン
- トランザクション障害:プログラムのバグ・デッドロック発生でのトランザクションの強制終了など、実行中のトランザクションが異常終了
P.336 目標復旧時点¶
- RPO:Recovery Point Objective
- システム再稼働時に障害発生前のどの時点の状態に復旧させるかを示す概念で、データ損失の最大許容範囲
- 目標復旧時間(RTO、Recovery Time Objective)
- 災害による業務の停止が深刻な被害とならないために許容される時間
P.336 事前対策¶
- 障害回復:障害からデータベースを復旧して一貫性が保たれた元の状態に戻すこと
- 障害回復には次のファイルを事前に取得しておく必要がある
- ログファイル
- 障害やバグ対策の基本
- トランザクション処理でデータベースが更新されるとき,更新前ログ、更新後ログなどの更新履歴(変更情報)を取り、時系列に記録する
- ジャーナルファイル、ジャーナルログともいう
- 大量に出るので復旧や原因追及に必要十分な要素をピックアップする必要がある
- ログファイル容量などを見て自動でファイルが切り替わる(ローテーション)
- バックアップファイル
- 媒体障害に備えてデータベースとログファイルを定期的に別の媒体にバックアップ(退避)する
- データベースのバックアップは定期的に取る
- ログファイル切り替え時にログファイルのバックアップも取る
- ふつうn個のログファイルに対してログデータをログファイル1から順に書き込む
- ログファイル1が一杯になるとログファイル2へと切り替える(ローテーション)
- このタイミングでバックアップ
P.337 参考 バックアップの種類¶
- フルバックアップ:すべてのデータをバックアップする
- 差分バックアップ:直前のフルバックアップ からの変更分だけをバックアップする。
- 増分バックアップ:直前のフルバックアップ または増分バックアップからの変更分だけをバックアップする。
- メリット・デメリット
- フルバックアップは何も考えずにドカンと復旧できるが容量を食う
- 差分バックアップはバックアップに使う容量を減らせるが、復旧時に手間がかかる
P.337 媒体障害からの回復¶
- 媒体障害発生時:バックアップファイルとログファイルの更新後ログを使ってロールフォワード処理でデータ ベースを回復させる
- 参考:P.338 図6.8.6
- T1:バックアップファイル取得
- T2:媒体障害発生
- バックアップファイルを別の媒体にリストア、T1時点に復帰
- T1-T2間の更新データ回復:ログファイルの更新後ログによるデータベースの各レコードを順番に再現するロールフォワード処理
- 参考:差分バックアップ方式採用時
- フルバックアップファイルをリストア
- 直近の差分バックアップファイルのデータを追加
- 更新後ログでロールフォワード
P.338 トランザクション障害からの回復¶
- アプリケーションプログラムのバグやデッドロックを解除するための強制終了などでアプリケーションが異常終了したとき
- ログファイルの更新前ログを使ったロールバック処理でデータベースの内容をトランザクション開始時点の状態に戻す
- 参考:P.338 図6.8.7
- データxとyを更新しなければならないトランザクションがT1で開始
- データyの更新を行う前にT2で異常終了
- このままではデータxとyのつじつまが合わない
- T1からT2の間に行われたxの更新を取り消す必要が出る
- ログファイルの更新前ログによるロールバック処理 でトランザクション開始時点(T1)の状態に戻す
- 参考:データとログをメモリ上にバッファリングしている場合
- まだCOMMITされていないトランザクションはログ・バッファの内容で自動的にロールバック(ROLLBACK)される
P.339 システム障害からの回復¶
- 現在のデータベース管理システムでのディスクの入出力効率向上のための工夫
- データとログをメモリ上にバッファリング
- まずデータベース・バッファに対してデータの更新
- ある時間間隔でデータベース・バッファの内容をデータファイル(データベース)へ書き出す
- 書き出し時点を行った時点:チェックポイント
- チェックポイントの発生:トランザクションのCOMMITとは非同期で、トランザクションがCOMMITされてもデータベース・バッファの内容はデータファイルに書き出されない
- チェックポイント発生時、稼働中のトランザクション情報もログファイルに書き出される
ログ・バッファの内容¶
- トランザクションのCOMMITまたはチェックポイント発生でログファイルに書き出される
- システム障害発生時の問題
- データファイルに書き出されていないデータベース・バッファ上の更新データの消失
- P.340 図6.8.9 の TR2
- システム障害が発生した時点でCOMMITされていない
- データベース・バッファの内容が消失しても問題ない:再処理で対応
- 問題になるのはチェックポイント(T1)の前に開始されたTR1
- TR1はシステム再立上げ後に更新前ログを用いたロールバック処理で
- トランザクション開始時点の内容に戻す
図6.8.10の例¶
- チェックポイント(T1)後
- システム障害発生(T2)前にCOMMITされたトランザクションTR3,TR4による更新内容はまだデータファイルに書き出されていない
- システム障害が発生した直前のチェックポイント(T1)まではデータベースの内容が保証されている
- ここから更新後ログを用いてロールフォワード処理によって回復
- システム障害における障害回復はシステム障害 発生時のトランザクションの状態に応じて変わる
- チェックポイントを作ることでそれまで行われてきた更新内容はすべてデータベース・バッファからデータファイルに書き出される
- システム障害が発生してもチェックポイント以降の更新後ログだけでロールフォワード処理で回復できる
- 回復時間が短縮される
P341 6.8.4 問合せ処理の効率化¶
P.341 インデックス¶
- インデックス():データベースへのアクセス効率を上げるために使う
- 例えばデータ構造とアルゴリズムの意味で「木」を作っている
- 一般に検索対象の項目にインデックスをつけるとアクセス(検索)速度はあがる
- しかしシステム全体のパフォーマンスが遅くなることがある
- インデックスをつけるとインデックスの更新が走る
- この処理がどれだけパフォーマンスに影響するかが問題
- インデックスのつけ方はきちんと考える必要がある
- 参考
- 各データに複数の索引語を付けて検索時に具体的な値を与えることで,その値を含むすべてのデータを高速かつ簡単に検索できるように編成
- 蓄積された索引ファイルを転置ファイル(inverted file:インバ ーテッドファイル)という。
P.341 POINT インデックス設定時の留意点¶
- アクセス頻度の高い列(検索でよく使う項目)に張る
- いわゆる内部 ID 系(これは主キーとして勝手にインデックスがつく・つける)
- 更新頻度の多い列に対してインデックスを張らない
- 外部 ID としてのメールアドレス・ログイン ID に張ることは多い
- 行数の少ない表に対してインデックスを張っても効果は低い
- データのとり得る値の種類が少ない(データ値の重複が多い)列に対して張っても効果は低い
- それでも張ることはある
- 「推測するな。計測せよ。」
- データ値の重複に大きな偏りがある場合は効果が低い
- 初期のデータ挿入など多くの行を挿入するときはいったんインデックスを削除するといい
- 参考
- インデックスには重複を許さないユニークインデックスと重複を許 すデュプリケートインデックスがある
- 主キー項目にはユニークインデックスが張られる
P.341 上記POINTの④,⑤について¶
- P.342 表はインデックスを張ったある項目Xの値とその行数
- [例1]と[例2]を比べる
- データのとり得る種類は両方とも同じ
- [例2]のほうが重複の程度が平準
- [例1]のほうが大きく偏っている
- インデックスで1項目当たりの平均の検索効率の向上が期待できるのは[例2]
- ただしあくまで一般論
P.342 例1・例2の検索効率を確率的に考える¶
- [例1]の場合
- 検索条件が「項目X=A」である確率は(20/1200)
- Aの検索はインデックスが使える
- 目的のデータを検索するにはさらに20件を順次検索する必要が ある
- このときの最大比較回数は20
- 「項目X=B」の場合、1項目当たりの検索効率(期待値)は次の式で求められる
- (20/1,200)×20+(40/1,200)×40+(80/1,200)×80 +(160/1,200)×160+(300/1,200)×300+(600/1,200)×600=403
- [例2]の場合
- 1項目当たりの検索効率(期待値)は(200/1,200)×200×6=200
- 確率的意味からも[例2]のほうが検索効率がいい
- 参考
- 効率を下げる重複が多い値で検索する機会がほとんどない場合、実際の効率は例1の方が大きい可能性がある
- いつでも実際のケースでどうかを考える必要がある
- 参考
- インデックスを張った項目を検索条件にして絞り込んだ選択率が10〜20%を大きく超える場合,インデックスの効果はあまり期待できない
P.343 連結インデックス¶
TODO