リレーショナルデータベースの高速化への挑戦

福嶋愼一(日立製作所) 2006年03月13日 16時49分

  • このエントリーをはてなブックマークに追加

 今では、PCのデータベースでも、データベースと言えば、簡単な2次元の表形式でデータ表現されるリレーショナルデータベースが常識となっている。また、本連載の第4回で解説されているような企業や公共機関での基幹業務を実行するオンライントランザクションシステムにおいても、そのデータベースとして広く使用されるまでに至っている。

 しかしながら、1970年にE.F.Codd博士が現在のリレーショナルDBの原点となるリレーショナル・データモデルに関する歴史的な論文を発表してから、今日のように、多数の利用者から同時にアクセスされ高速処理を要する基幹業務システムのデータベースとして当たり前のように利用されるようになるまでには、実用化・高速化に向けての種々の工夫や取り組みがあった。

 今回は、リレーショナルDBを実現するデータベース管理システム(DBMS)の初期の製品が出てきたメインフレーム時代に、リレーショナルDBの実用化や高速化の問題に対してどのような取り組みを行ったのか、そのいくつかを紹介したい。

基幹業務には構造型DB、
リレーショナルDBはその補完

 リレーショナルDBが出現する前のデータベースは「構造型DB」と呼ばれるものであった。構造型DBのデータ構造には、データにアクセスする構造(アクセスパス)が取り込まれていて、階層構造のものやネットワーク構造のものがある。

 構造型DBでは、ユーザーがデータの論理的な配置を意識しながら、対象となるデータの1件1件に対する操作を指示するインターフェースであるため、業務処理プログラムを書くユーザー側の負担は増えるものの、DBMS側はユーザーの指示に従って個々のデータ操作を高速に実行することに専念すればよく、高速処理を要求される基幹業務システムのデータベースとして多用された。

 これに対して、リレーショナルDBでは、データ構造は簡単な2次元の表形式(テーブル)で表現され、データの配置に関係なくデータを集合として捉えて、ユーザーが行いたいデータ操作を集合演算として一括して指示するインターフェースである。別の見方をすれば、データベース構造からのデータの論理的な独立、仮想化を実現したものと言える。

図1 リレーショナルDBと構造型DB

 構造型DBではユーザーが「How to do」をDBMSに指示するのに対して、リレーショナルDBではユーザーは「What to do」を指示する。このため、ユーザー側の負担は構造型DBに比べて大幅に減少するものの、逆にDBMS側では、ユーザーの「What to do」の指示を解釈して最適な「How to do」を見つけて実行するための処理が必要となり、構造型DBMSに比べてデータ操作の処理時間を要する要因が本質的に内在すると言える。

 このため、リレーショナルDBMS製品が出てきた初期は、基幹業務システムのデータベースは構造型DBを使用し、その構造型DBから業務データを抽出して、情報サービスなどの非定型業務にリレーショナルDBを補完的に使用するという利用形態であった。

リレーショナルDBMSの高速化への取り組み

 リレーショナルDBMSは、上述のように構造型DBMSに比べて本質的に処理時間を要する要因を含んでいるため、一般的に初期の製品では、特にレコード1件を対象とするトランザクション処理において、当時の構造型DBMSと比較して性能が劣っていて、メインフレームのCPUの実行性能を示すMIPS(Million Instructions Per Second)を使って“MIPS Eater”と揶揄されることもあった。

 しかしながら、以下のようなリレーショナルDBMSの高速化への取り組みを経て、基幹業務にも性能的に十分耐えうるリレーショナルDBMSに発展していった。

 既に述べたように、リレーショナルDBでは操作対象のデータにアクセスする道筋はユーザーからは指定されないという問題がある。ユーザーはデータベース言語SQL(Structured Query Language)を使って、例えば、あるテーブルからデータを取り出すのであれば、SELECT文を使って「このテーブルからこういう条件を満たすデータを検索して取り出せ」というように、「What to do」をDBMSに指示するだけである。DBMS側では、ユーザーから指示されたSQL文を解析し、指示されたデータ操作を最適に実行する方法を決めて、データ操作を実行する。これは、技術的にはプログラミング言語のコンパイラと実行時ルーチンの処理を併せて行うようなものである。

 このデータ操作の最適化問題は、コンパイラの最適化問題と類似するものがあるが、基本的には、データベースへのアクセス手順が複数存在する時に、より高速に処理可能なアクセス手順を決定することである。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

この記事を読んだ方に

関連キーワード
クラウド基盤

関連ホワイトペーパー

連載

CIO
ITアナリストが知る日本企業の「ITの盲点」
シェアリングエコノミーの衝撃
デジタル“失敗学”
コンサルティング現場のカラクリ
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「展望2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
エンドポイントセキュリティの4つの「基礎」
企業セキュリティの歩き方
サイバーセキュリティ未来考
ネットワークセキュリティの要諦
セキュリティの論点
スペシャル
エンタープライズAIの隆盛
インシュアテックで変わる保険業界
顧客は勝手に育たない--MAツール導入の心得
「ひとり情シス」の本当のところ
ざっくり解決!SNS担当者お悩み相談室
生産性向上に効くビジネスITツール最前線
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell Technologies World
AWS re:Invent
AWS Summit
PTC LiveWorx
吉田行男「より賢く活用するためのOSS最新動向」
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]