 |
|
| Sybase IQで学ぶデータウェアハウス |
第１回：汎用RDBMSとデータウェアハウスの違い
著者：サイベース 2007/7/5
|
|
|
| 前のページ 1 2 3 次のページ
|
|
| インデックスの違い
|
汎用RDBMSでは、高速化手法の1つとしてインデックスがあります。インデックスは検索条件となるカラムに設定する必要がありますから、データ抽出の視点が多様な、言い換えるとあらゆるカラムが検索条件になり得るようなデータウェアハウスにおいては、下記のような問題が生じることになります。
- インデックス設定対象となるカラムが増えることにより、インデックス領域が膨大となり、データベースが肥大化する
- 肥大化したデータベースは、インデックスのメンテナンス工数やデータロード時間に多大な影響を与える
- 肥大化したデータベースは、ストレージコストを押し上げる
- 所詮、すべてのカラムにインデックスを設定することはできず、設定した範囲内でしか高速化することができない
- インデックス自体はグルーピングや集計の負荷を根本から解決できない。したがって実体化ビュー、サマリーテーブルなどの冗長な結果セットを事前に作成しておく必要に迫られる。結果、ストレージコストをさらに押し上げる
表3：データ抽出が多様な場合の問題点
図3：膨大な量のインデックスが発生する例 （画像をクリックすると別ウィンドウに拡大図を表示します）
このように汎用RDBMSが採用する「テーブル＋インデックス構造」はいたずらにデータベースサイズを膨らませ、ストレージコストやメンテナンスコストを押し上げるだけでなく、データウェアハウスの構造／運用コストを上昇させることになりますが、性能的には投下コストほどの効果を得られないという問題をはらんでいます。
以上をまとめると表4のようになります。
| 汎用RDBMSの実装 |
データウェア
ハウス上の問題 |
現象 |
ユーザへの
インパクト |
ロー単位の
データ管理 |
|
- ストレージ読み出しの長時間化
- メモリ使用効率の悪さ
- 必要CPUの増加
|
- システムの肥大化
- ハードウェアコストの膨張
- ソフトウェア（CPUライセンス）の膨張
- 性能の頭打ち
|
テーブル＋
インデックス
構造 |
- インデックス適用カラムの増加
- 集約テーブルの必要性
|
|
|
表4：まとめ
|
| データ活用のアプローチ「Sybase IQ」
|
このようにデータウェアハウスに求められる要件は、現在の汎用RDBMSでは解決できない点が数多くあります。では、企業にある様々なデータをそのまま眠った資産としておいてよいのでしょうか。本連載では、その解決策としてSybase IQを紹介します。
|
前のページ 1 2 3 次のページ
|
|
|
著者プロフィール
サイベース株式会社
1984年、カリフォルニア州バークレーで設立。情報の管理能力と、卓越したレベルでデータの信頼性とセキュリティを提供し、データセンターからアクションポイントまで、情報の管理と可動化のみに焦点を合わせた最大のグローバルエンタープライズソフトウェア企業として活動。サイベース株式会社は、米国 サイベース社 の日本法人として1991年に設立。
|
|
|
|
|
|
