データベース設計 物理的データ格納方式 講師: 福田 剛志 [email protected] 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を くれ! ? ブロック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
© Copyright 2024 Paperzz