データベース設計物理的データ格納方式

データベース設計
物理的データ格納方式
講師：福田剛志
fukudat@fukudat.com
http://www.fukudat.com/
データベース設計
1
典型的なコンピュータシステム
プロセッサ
P
...
M
C
コントローラ
1次記憶
RAM
...
2次記憶
ディスク
テープ etc
データベース設計
2
記憶階層 (memory hierarchy)
キャッシュ
メインメモリ
2次記憶
3次記憶
データベース設計
3
記憶容量 (storage capacity)
典型的容量 (バイト)
1015
1013
1011
109
electronic
secondary
electronic
main
magnetic,
optical
disks
online
tape
nearline offline
tape & tape
optical
disks
107
105 cache
103
10-9
10-6
10-3
データベース設計
103
10-0
アクセス時間 (秒)
4
記憶コスト (storage cost)
104
cache
ドル/MB
102
electronic
main
electronic
secondary
100
online
tape
magnetic,
optical
disks
10-2
nearline
tape &
optical
disks
offline
tape
10-4
10-9
10-6
10-3
データベース設計
103
10-0
アクセス時間 (sec)
5
典型的なディスク構造 (structure of typical disks)
…
ヘッドアセンブリ
セクタ
ギャップ
用語：
プラッタ，ヘッド，シリンダ，トラック，セクタ，ブロック，ギャップ
データベース設計
6
ディスク上のブロックデータのアドレス
•
•
•
•
物理ディスク番号
シリンダ番号
ヘッド番号
セクタ番号
セクタ
…
データベース設計
7
ディスクアクセスにかかる時間
(disk access latency)
ブロックXを
くれ！
?
ブロックＸが
メモリ上に
到着
アクセス時間 (access time) =
シーク時間 (seek time) +
回転遅延 (rotational delay) +
転送時間 (transfer time) +
その他
データベース設計
8
シーク時間 (seek time)
時間
ヘッドが目的のトラックに移動する時間
3 or 5x
隣のシリンダに
移動する時間
x
1
移動するシリンダ数
N
典型的な時間: 10 ms ～ 40 ms
データベース設計
9
回転遅延 (rotational delay)
ヘッド位置
ほしいブロック
E[回転角] = ½回転
E[回転遅延] = 4.16 ms (7200 RPM)
= 2.00 ms (15K RPM)
データベース設計
10
転送時間 (transfer time)
• 転送速度 t = 1 ～ 100 MB/s
• 転送時間 = ブロックサイズ / t
典型的な時間 = 1KB / 10MB/s = 0.1 ms
データベース設計
11
その他の遅延
• I/O命令を実行する CPU 時間
• I/O コントローラでの待ち時間
• バス，メモリの競合待ち時間
典型的な時間: 0 ms
データベース設計
12
連続アクセスの場合は?
(sequential access)
• これまでは，ランダムアクセスを考えてきた．
• では，次のブロックを読む場合はどうなる?
次のブロックを
ブロックサイズ
=
+ 無視できる
読み出す時間
転送速度
ギャップを読み飛ばす
トラックを切り替える
（たまに）
データベース設計
13
まとめ
• ランダムアクセス時間～ 40 ms
• 連続アクセス時間～ 1 ms
• 書き込み時間は，読み込み時間と同じくらい
（参考）
– メモリにアクセスする時間～ 0.5µs
– キャッシュにアクセスする時間～ 1 ns
ディスクアクセスは「桁違い」に遅い．
データベース・アルゴリズムの主目的はI/Oを減らすこと．
データベース設計
14
データの物理的表現方法
データ項目
レコード
ブロック
ファイル
メモリ
データベース設計
15
データ項目 (data items)
• 固定長のデータ項目 (fixed length items)
– 整数，実数，文字など
• 可変長データ項目 (variable length items)
– 文字列
– 固定長に変換する = 最大長
– データの前に長さをつける
データベース設計
16
レコード (record)
• 関係したデータ要素 (data item) の集まり
– ここのデータ要素をフィールドと呼ぶ
– リレーショナルモデルの行（タプル）に相当
• 例えば): 社員レコード
– 社員番号フィールド
– 社員名フィールド
– 所属コードフィールド
データベース設計
17
レコードの表現
• 選択肢:
– 固定フォーマット vs 可変フォーマット
– 固定長 vs 可変長
データベース設計
18
固定フォーマット
• スキーマから以下の情報がわかる
– 要素数
– 各フィールドの型
– フィールドの順序
– (フィールドの説明)
データベース設計
19
例: 固定フォーマット & 固定長
•
社員レコード：
(1) 社員番号 2 byte 整数
(2) 社員名
10 文字
(3) 所属コード: 2 byte 整数
55 s m i t h
02
83 j o n e s
01
データベース設計
スキーマ
レコード
20
可変フォーマット (variable format)
• レコード自身がフォーマットを含んでいる
– 自己記述 (self-describing)
データベース設計
21
例: 可変フォーマット & 可変長
46 4 S 4
F O RD
社員名を
意味するコード
文字列タイプ
文字数
フィールド数
社員番号フィールドを
意味するコード
整数型
2 5 I
フィールド番号の代わりにフィールド名(文字列)を用いても良い
データベース設計
22
可変フォーマットが役立つ場合
•
•
•
•
疎 (sparse) なデータ
繰り返しフィールド
フォーマット進化
データ交換
しかし，スペース効率が悪い
データベース設計
23
ブロック
• レコードをどのようにブロックにつめるか
ブロック長は
固定とする
• ブロック
...
ファイル
ファイルは一つと
仮定 (今のところは)
データベース設計
24
選択肢
(1) レコードの切れ目
(2) 分割レコード vs 非分割レコード
(3) クラスタリング
(4) 分割レコード
(5) 順序付け
(6) 間接参照
データベース設計
25
(1) レコードの切れ目
(record separation)
ブロック
•
R1
R2
R3
(a) 切れ目が自明 (固定長レコードの場合)
(b) 特別なマークを使う
(c) レコード長をつける
•
•
各レコードに
ブロックヘッダに
データベース設計
26
(2) 分割レコード vs 非分割レコード
(spanned vs unspanned)
• 非分割レコード (unspanned record)
レコードは必ず一つのブロックに収まらなければ
ならない
ブロック 1
ブロック 2
R1
R2
R3
R4 R5
• 分割レコード： (spanned record)
ブロック 1
ブロック 2
R1
R2
R3
(a)
R3
R4
(b)
データベース設計
R5
R6
R7
(a)
27
分割レコードの中
R1
R2
R3
(a)
レコードの残りを
指し示すポインタ
が必要
R3
R4
(b)
R5
R6
R7
(a)
続きを意味する印
が必要 (+ どこか
らつながっている
か)
データベース設計
28
分割 vs 非分割
(spanned vs unspanned)
• 非分割が簡単だが，スペース効率が悪い
• レコードサイズ > ブロックサイズのとき
分割が必須
データベース設計
29
(3) クラスタリング
(clustering)
• 異なる種類のレコードを混在させる
– 例: 組織，社員を同じブロック内に許す
組織
d1
社員
e1
社員
e2
• どうして混合させるか?
– クラスタリング (clustering) の効果
– 同時にアクセスされるレコードが同一ブロックにある
とうれしい．
データベース設計
30
例
Q1: SELECT 組織名, 社員名
FROM 組織, 社員
WHERE 組織.depcode = 社員．depcode
• 都合のよいブロック
組織, 組織名=基礎研究所, depcode=021
社員,名前=福田, depcode=021...
社員,名前=山本, depcode=021...
社員,名前=吉田, depcode=021...
データベース設計
31
都合の悪い例
Q2: SELECT *
FROM 組織
• クラスタリングすると，遅くなってしまうこともある．
データベース設計
32
(4) 分割レコード
(split record)
固定レコードのブロック
可変レコードのブロック
R1 (a)
R1 (b)
R2 (a)
R2 (b)
R2 (c)
データベース設計
33
(5) 順序付け
(sequencing)
• ファイル（とブロック）内のレコードの順序を，ある
キーフィールドの値で，ソートする
– 順序ファイル (sequential file)
• どうして順序付けするのか?
– 効率よく順番に読むことができるから
– 例えば，マージジョイン (merge-join) で使用する
データベース設計
34
順序づけの選択肢
(a) 物理的に連続に配置
R1
R1の次
(b) リンクでつなぐ
R1
R1の次
データベース設計
35
(6) 参照
(indirection)
• どうやってレコードを参照するか?
レコード
たくさんの選択肢:
直接
データベース設計
間接
36
純粋に物理的方法
レコード
アドレス
または ID
=
デバイス番号
シリンダ番号
ヘッド番号
セクタ番号
ブロック内オフセット
データベース設計
ブロック
ID
37
純粋に間接的方法
• レコードID = 任意のビット列
マップ
レコードID
アドレス
ID
物理
アドレス
データベース設計
38
トレードオフ
• 柔軟性
– レコードの移動 (削除，挿入により発生する)
• コスト
– 間接アドレスを物理アドレスに変換
物理参照
間接参照
中間にいろいろな選択肢がある
データベース設計
39
例: ブロック内の間接参照
外部から
レコード R3 への
ポインタ
ヘッダー
ブロック:
空き領域
R3
R4
R1
R2
データベース設計
40

Download Report