JP2008225575A - 計算機負荷見積システム、計算機負荷見積方法 - Google Patents

計算機負荷見積システム、計算機負荷見積方法 Download PDF

Info

Publication number
JP2008225575A
JP2008225575A JP2007059055A JP2007059055A JP2008225575A JP 2008225575 A JP2008225575 A JP 2008225575A JP 2007059055 A JP2007059055 A JP 2007059055A JP 2007059055 A JP2007059055 A JP 2007059055A JP 2008225575 A JP2008225575 A JP 2008225575A
Authority
JP
Japan
Prior art keywords
records
information
block
record
query
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007059055A
Other languages
English (en)
Other versions
JP5088668B2 (ja
Inventor
Morio Sasaki
盛朗 佐々木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2007059055A priority Critical patent/JP5088668B2/ja
Priority to US12/042,844 priority patent/US7805410B2/en
Publication of JP2008225575A publication Critical patent/JP2008225575A/ja
Application granted granted Critical
Publication of JP5088668B2 publication Critical patent/JP5088668B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】計算機システムのデータベースに対するアクセス時の負荷を見積もること。
【解決手段】記憶装置には、複数のレコードを有するテーブルの構造を定義する構造情報D1と、テーブルに対するクエリD3の条件変数の確率分布を示す第1分布情報D4と、テーブルの要素の確率分布を示す第2分布情報D2とが格納される。レコード数算出モジュール20は、構造情報D1、第1分布情報D4及び第2分布情報D2に基づいて、複数のレコードのうち条件変数で規定される条件に適合するレコード数の平均値を算出する。アクセス回数算出モジュール30は、算出されたレコード数の平均値に基づいて、クエリD3に応じてアクセスされるブロックの数を算出する。
【選択図】図3

Description

本発明は、データベースを備える計算機システムの負荷を見積もるための技術に関する。
計算機上に構築されたデータベースの運用/管理を行うためのソフトウエアとして、「データベース管理システム(DBMS: Database Management System)」が一般的に知られている。そのデータベース管理システムにおいては、「クエリ(query)」と呼ばれるコマンドが使用される。クエリとは、データベースに対する処理要求を表す文字列であり、データの検索、更新、削除などを指定する文字列である。例えば、データ検索クエリは、検索対象のテーブルやデータの抽出条件を指定する。データベースの一種であるリレーショナルデータベースの場合、クエリは、SQL(Structured Query Language)で記述される(非特許文献1参照)。
図1及び図2を参照して、一般的なクエリ処理を説明する。図1には、あるリレーショナルデータベース内のあるテーブルTBLが示されている。テーブルTBLは複数のレコード(行)を有しており、各レコードは3つのカラムCOL1〜COL3から構成されている。例えば、第1カラムCOL1はIDを示し、第2カラムCOL2は商品名を示し、第3カラムCOL3は価格を示している。
また、図1には、クエリの一例が示されている。クエリは、データベースに対するアクセス方法を示す「アクセス種」、アクセス対象を示す「ターゲット」、アクセス対象が含まれる領域を示す「スコープ」、及びアクセス対象の条件を示す「条件節」を含んでいる。「アクセス種」としては、“select(データ読み出し)”、“update(データ更新)”、“insert(レコード挿入)”、“delete(レコード削除)”などが挙げられる。図1に示された例の場合、クエリは、「テーブルTBLから、価格500〜1000のレコード(ターゲット“*”はカラムCOL1〜COL3の全てを意味する)を読み出すこと」を指示している。
そのクエリに従って、DBMSは、テーブルTBLから条件を満たすレコードを読み出す。図1に示された例の場合、3つのレコード(ID=1,ID=3123,ID=9998)が該当する。テーブルTBLの各レコードは実際には記憶領域(メモリ等)に格納されており、DBMSはその記憶領域にアクセスすることになる。
図2は、記憶領域へのアクセスを説明するための図である。一般的に、記憶領域はブロック単位で管理され、アクセス時には、必要なブロックに含まれるデータがまとめて読み出される。テーブルTBLのデータが格納されているブロックは、特に「テーブルブロック」と参照される。例えば、3つのレコード(ID=1,3123,9998)は、テーブルブロックBL−j,BL−i,BL−kのそれぞれに格納されている。従って、DBMSは、少なくとも3つのテーブルブロックBLにアクセスする必要がある。
また、記憶領域内には膨大なデータが格納されており、その膨大なデータへのアクセスを容易にするために「メタデータ」が利用される場合がある。メタデータとは、記録データの“索引(インデックス)”である。メタデータ自身も、記憶領域内の所定のブロックに格納されている。メタデータによる索引は階層的に構築されており、最下位の階層の索引は「リーフブロック」と呼ばれるブロックに格納されている。複数のリーフブロックを束ねる上位階層の索引、すなわちリーフブロックの索引は、「ブランチブロック」と呼ばれるブロックに格納されている。
図2に示されるように、リーフブロックは複数のエントリを有しており、各エントリはキー値とポインタから構成されている。本例において、キー値は、第3カラムCOL3の値(価格)を示しているとする。各リーフブロックにおいて、複数のエントリは、キー値に基づいてソートされている。ポインタは、キー値が格納されているレコードの先頭アドレスを指し示す。尚、第3カラムCOL3の値(キー値)が複数のレコード間で同じ場合、その同じキー値に対して異なるポインタが割り当てられる。
メタデータが利用可能な場合、DBMSは、そのメタデータを参照することによってテーブルブロックにアクセスする。すなわち、DBMSは、メタデータを参照して読み出し対象のキー値に対応づけられたポインタP3、P4、P5を取得した後、それらポインタP3、P4、P5が指し示すアドレスにアクセスする。この場合、DBMSは、全体として5つのブロック(ブランチブロック、リーフブロック、テーブルブロックBL−i、BL−j、BL−k)にアクセスする必要がある。
以上に説明されたように、DBMSはクエリに従って、記憶領域内の必要なブロックにアクセスし、そのブロックのデータをまとめて読み出す。あるブロックへのアクセスは、以下「ブロックアクセス」と参照される。また、あるクエリ処理に必要なブロックアクセスの回数は、以下「ブロックアクセス回数」と参照される。また、そのクエリ処理に必要なブロックからのデータ読み出しは、以下「フェッチ」と参照される。
あるクエリ処理におけるフェッチの負荷量は、ブロックアクセス回数、すなわちクエリの内容に大きく依存する。例えば、多数のデータを処理対象とするクエリの場合、多数のブロックアクセスを実行する必要があり、フェッチの負荷量は大きくなる。フェッチの負荷量は、DBMSが構築された計算機システムの処理能力を大きく左右する。従って、計算機システムの運用においては、フェッチの負荷量、すなわちブロックアクセス回数を適正な値に抑えることが重要である。
データベース管理システム(DBMS)に関連する一般的な技術として、次のものが知られている。
特許文献1には、クライアントサーバ型のデータベースシステムが開示されている。サーバ計算機システムには、データベースに対する具体的な処理履歴をログ情報として蓄積するログファイルが用意される。サーバ計算機システムは、クライアント計算機システムからの新たな処理要求に応答してログファイルを参照し、その処理要求に類似している他の処理要求に関するログ情報をクライアント計算機システムに通知する。クライアント計算機システムは、処理要求に応じて通知されるログ情報に基づいて、処理要求実現時の見積処理性能を提示する。
特開平9−97200号公報 「Oracle Database パフォーマンス・チューニング・ガイド」,10gリリース1(10.1)、部品番号:B12449−01
上述の通り、計算機システムの処理性能の観点から、フェッチの負荷量、すなわちブロックアクセス回数を適正な値に抑えることが重要である。従って、ブロックアクセス回数を見積もることができる技術が望まれる。
以下に、[発明を実施するための最良の形態]で使用される番号・符号を用いて、[課題を解決するための手段]を説明する。これらの番号・符号は、[特許請求の範囲]の記載と[発明を実施するための最良の形態]との対応関係を明らかにするために括弧付きで付加されたものである。ただし、それらの番号・符号を、[特許請求の範囲]に記載されている発明の技術的範囲の解釈に用いてはならない。
本発明の第1の観点において、計算機負荷見積システムが提供される。その計算機負荷見積システムは、データベースに対するアクセス時の負荷を見積もる。具体的には、計算機負荷見積システムは、記憶装置(120)、レコード数算出モジュール(20)、及びアクセス回数算出モジュール(30)を備える。
記憶装置(120)には、構造情報(D1)、第1分布情報(D4)、及び第2分布情報(D2)が格納される。構造情報(D1)は、複数のレコードを有しデータベースに含まれるテーブルの構造を定義する。第1分布情報(D4)は、そのテーブルに対するクエリ(D3)の条件変数の確率分布を示す。第2分布情報(D2)は、そのテーブルの要素の確率分布を示す。
レコード数算出モジュール(20)は、上記構造情報(D1)、第1分布情報(D4)及び第2分布情報(D2)に基づいて、複数のレコードのうち条件変数で規定される条件に適合するレコードの数の平均値を算出する。算出された平均値は、クエリに応じて選択される平均的なレコード数である。アクセス回数算出モジュール(30)は、その平均的なレコード数に基づいて、クエリに応じてアクセスされるブロックの数、すなわちブロックアクセス回数を算出する。
このように、本発明によれば、テーブルの構造を示す情報や、要素及びクエリに関する統計的な情報を利用することにより、ブロックアクセス回数を見積もることが可能となる。例えば、計算機システムの構築前や、計算機システムが使用不可能な場合、実際のテーブルの要素値を知ることはできない。そのような場合であっても、本発明によれば、ブロックアクセス回数を見積もることが可能である。あるいは、データベースが巨大な場合、実際のテーブルを参照してブロックアクセス回数を測定するためには非常に長い時間を要する。一方、本発明によれば、ブロックアクセス回数を簡便に、且つ、短時間で見積もることが可能となる。
本発明の第2の観点において、計算機負荷見積方法が提供される。その計算機負荷見積方法は、(A)複数のレコードを有しデータベースに含まれるテーブルの構造を定義する構造情報(D1)を、記憶装置(120)から読み出すステップと、(B)テーブルに対するクエリの条件変数の確率分布を示す第1分布情報(D4)を、記憶装置(120)から読み出すステップと、(C)テーブルの要素の確率分布を示す第2分布情報(D2)を、記憶装置(120)から読み出すステップと、(D)構造情報(D1)、第1分布情報(D4)及び第2分布情報(D2)に基づいて、複数のレコードのうち条件変数で規定される条件に適合するレコードの数の平均値である選択レコード数を算出するステップと、(E)選択レコード数に基づいて、クエリに応じてアクセスされるブロックの数を算出するステップと、を有する。
本発明の第3の観点において、上記計算機負荷見積方法をコンピュータに実行させるプログラムが提供される。
本発明によれば、クエリ処理に伴って発生するブロックアクセス回数を見積もることが可能となる。
1.第1の実施の形態
1−1.構成
図3は、本発明の第1の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。本実施の形態に係る計算機負荷見積システムは、クエリ解析モジュール10、レコード数算出モジュール20、ブロックアクセス回数算出モジュール30、及び出力モジュール60を備えている。モジュール10〜30は、ブロックアクセス回数見積モジュール40を構成している。そのブロックアクセス回数見積モジュール40には、データ構造情報D1、論理分布情報D2、クエリ情報D3、変数分布情報D4、レコード配置情報D5、及びメタデータ構造情報D6が入力情報として入力される。また、場合によっては、デフォルト情報D7が入力される。まず、それら入力情報に関して詳しく説明する。
図4には、あるテーブルSAMPLEと、そのテーブルSAMPLEに対するクエリの一例が示されている。テーブルSAMPLEは、負荷見積対象である計算機システムのデータベース(例えば、リレーショナルデータベース)に含まれる。計算機システムの構築前であれば、テーブルSAMPLEは使用予定のテーブルである。本実施の形態において、テーブルSAMPLEの各要素は未定であってよく、また、必要とされない。但し、テーブルSAMPLEの型や構造に関しては、計算機システムの構築前であっても定義することができる。その定義を示すのが、データ構造情報D1である。
データ構造情報D1は、テーブルSAMPLEの型や構造、総レコード数を示している。例えば図4において、データ構造情報D1は、(1)データベース中にテーブルSAMPLEが存在すること、(2)そのテーブルSAMPLEの各レコードは、4バイトの数値カラムCOL1、24バイトの文字列カラムCOL2、4バイトの数値カラムCOL3から成ること、(3)そのテーブルSAMPLEの総レコード数は10万であること、を示している。更に、データ構造情報D1は、(4)データベースが実際に格納される記憶領域上のテーブルブロックの1つあたりのサイズ(有効ブロックサイズ)も示している。図4に示された例では、有効ブロックサイズは8000バイトである。このように、データ構造情報D1は、データベースやテーブルに関連する構造を定義している。
上述の通り、テーブルSAMPLEの各要素は未定であってよい。しかしながら、テーブルSAMPLEの各要素が取り得る値の分布は、あらかじめ定義することができる。その定義を示すのが、論理分布情報D2である。具体的には、論理分布情報D2は、テーブルSAMPLEが有し得る値を統計的に示している、すなわち、テーブルSAMPLEの要素の確率分布を示している。例えば図4において、論理分布情報D2は、「第3カラムCOL3の要素は、範囲0〜999,999の値を一様な確率でとること」を示している。
クエリ情報D3は、テーブルSAMPLEに対する所定のクエリを示している。そのクエリはSQLで記述され、「アクセス種」、「ターゲット」、「スコープ」、及び「条件節」を含んでいる。例えば図4において、クエリ情報D3は、あるクエリ“select * from SAMPLE where COL3 between :a and :b”を示している。記号*は、カラムCOL1〜COL3の全て、すなわちレコードを意味する。従って、このクエリは、“テーブルSAMPLEから、第3カラムCOL3の値が範囲a〜bにあるレコードを読み出すこと”を指示している。このようなクエリに伴って発生するブロックアクセス回数を見積もることが、本発明の目的の1つである。
クエリの条件節中の変数a,bは、以下「条件変数」と参照される。上記論理分布情報D2に対応して、条件変数a,bが取り得る値の分布もあらかじめ定義することができる。その定義を表すのが、変数分布情報D4である。具体的には、変数分布情報D4は、条件変数a,bが有し得る値を統計的に示している、すなわち、条件変数a,bの確率分布を示している。例えば図4において、変数分布情報D4は、(1)条件変数aが範囲0〜999,999の値を一様な確率でとること、及び(2)条件変数bは条件変数aに0〜99の値を一様な確率で加えた値であること、を示している。尚、条件変数は離散的であってもよい。
図5は、データベースが実際に格納される記憶領域上のブロック構成を概念的に示している。ブロックは、所定のサイズを有する物理記憶領域であり、ブロックアクセス時には、そのブロックに含まれるデータがまとめて読み出される(フェッチ)。上記テーブルSAMPLEのデータは、複数のテーブルブロックBLにわたって格納される。各テーブルブロックBLの有効ブロックサイズ(例えば8000バイト)は、上述のデータ構造情報D1で定義されている。
レコード配置情報D5は、テーブルSAMPLEのレコードがテーブルブロックBLに対してどのように配置されるかを示す。つまり、レコード配置情報D5は、テーブルブロックBLへのレコードの配置方法を示す。例えば、レコード配置情報D5は、「テーブルSAMPLEの各レコードは、第3カラムCOL3の値に拘わらず、ランダムに配置される」という“ランダム配置”を示す。または、レコード配置情報D5は、「テーブルSAMPLEの各レコードは、第3カラムCOL3の値順にシーケンシャルに配置される」という“シーケンシャル配置”を示してもよい。あるいは、レコード配置情報D5は、“ランダム配置”な度合いと“シーケンシャル配置”な度合いを示すパラメータPを示していてもよい。
また、データベースにおいてメタデータが利用されてもよい。メタデータは、テーブルブロックBLに格納されるデータの索引であり、図5に示されるようなツリー状の階層構造を有している。そのような索引は、ツリーインデックスと呼ばれる場合もある。ツリーインデックスの最下位の階層の索引は、リーフブロックLBLに格納される。各リーフブロックLBLは複数のエントリを有しており、各エントリは「キー値」と「内部アドレスポインタ」から構成される。内部アドレスポインタは、キー値が格納されているレコードの先頭アドレスを指し示す。各リーフブロックLBLにおいて、複数のエントリはキー値に基づいてソートされる。また、ツリーインデックスの上層の索引は、リーフブロックLBLの索引であり、ブランチブロックBBLに格納される。
メタデータ構造情報D6は、メタデータの型や構造を定義している。データ構造情報D1の場合と同様に、本実施の形態において、メタデータの各要素は未定であってよく、また、必要とされない。例えば図5において、メタデータ構造情報D6は、(1)第1カラムCOL1と第3カラムCOL3に対してツリーインデックスが使用されること、(2)ブランチブロックBBLやリーフブロックLBLの有効ブロックサイズが8000バイトであること、及び(3)内部アドレスポインタのサイズは6バイトであること、を示している。
デフォルト情報D7は、論理分布情報D2、変数分布情報D4、及びレコード配置情報D5のデフォルト設定を示す。論理分布情報D2、変数分布情報D4、及びレコード配置情報D5のいずれかが用意されていない場合、その不足している情報は、デフォルト情報D7が示すデフォルト設定で補われる。
以上に説明された入力情報D1〜D7は、例えば、設計仕様書や運用中の計算機システムの運用情報から得られる。そして、それら入力情報D1〜D7は、所定の記憶装置に格納される。
再度図3を参照して、ブロックアクセス回数見積モジュール40は、所定の記憶装置から上述の入力情報D1〜D7を読み出す。そして、ブロックアクセス回数見積モジュール40は、それら入力情報D1〜D7を用いることによって、クエリ情報D3が示すクエリ処理に必要なブロックアクセス回数を見積もり、その見積値を示すブロックアクセス回数情報D10を作成する。出力モジュール60は、作成されたブロックアクセス回数情報D10を、表示装置やプリンタ等の出力装置に出力する。
以下、各モジュールによる処理を、更に詳細に説明する。
1−2.第1の処理例
図6は、本実施の形態に係る計算機負荷見積システムによる処理を示すフローチャートである。図6に示されたフローに沿って、処理の一例を説明する。入力情報D1〜D6は、図4及び図5に示されたものであるとする。レコード配置情報D5は、“ランダム配置”を示しているとする。
ステップS1〜S3:入力情報の読み込み
まず、ブロックアクセス回数見積モジュール40は、記憶装置から入力情報D1〜D6を読み込む(ステップS1)。論理分布情報D2、変数分布情報D4、レコード配置情報D5のいずれかが空の場合(ステップS2;Yes)、不足情報がデフォルト情報D7から読み込まれる(ステップS3)。本例の場合、不足情報は無いので、処理はステップS10に進む。
ステップS10:クエリ解析処理
次に、クエリ解析モジュール10は、データ構造情報D1とクエリ情報D3を受け取る(図3参照)。そして、クエリ解析モジュール10は、データ構造情報D1を参照しながらクエリ情報D3が示すクエリを解析し、クエリから「アクセス種」、「ターゲット」、「スコープ」、及び「条件節」を抽出する。図4で示されたように、本例におけるクエリは、“select * from SAMPLE where COL3 between :a and :b”である。この場合、「アクセス種」は、Select(読み出し)である。「スコープ」は、データ構造情報D1で定義されているテーブルSAMPLEである。「条件節」は、「データ構造情報D1で定義されている第3カラムCOL3の値が、条件変数aとbとの間の範囲であること」である。読み出し対象の「ターゲット」は、全カラム、すなわちレコード(行)である。
ステップS20:選択レコード数の算出
次に、レコード数算出モジュール20は、データ構造情報D1、論理分布情報D2、及び変数分布情報D4を受け取る(図3参照)。更に、レコード数算出モジュール20は、クエリ解析モジュール10から、抽出された「アクセス種」、「スコープ」、及び「条件節」を受け取る。そして、レコード数算出モジュール20は、受け取った情報に基づいて、読み出し対象のレコードの数を統計的に見積もる。つまり、レコード数算出モジュール20は、テーブルSAMPLEの複数のレコードのうち、条件変数a、bで規定される条件に適合するレコードの数を統計的に算出する。
図4で示された例において、変数分布情報D4は、条件変数aが範囲0〜999,999の値を一様な確率でとることを示している。また、変数分布情報D4は、条件変数で規定される数値幅(選択幅)b−aが範囲0〜99の値を一様な確率でとることを示している。図7は、これら条件変数aや数値幅b−aの確率分布関数を示している。図7において、横軸は条件変数aや数値幅b−aを示し、縦軸は確率密度f(a)やf(b−a)を示している。本例では、読み出し条件を示す数値幅b−aは0〜99であり、その確率分布は一様である。従って、図7に示されるように、数値幅b−aの平均値は“50”であることがわかる。すなわち、平均的に、数値幅50に相当するレコード群がテーブルSAMPLEから選択されることがわかる。以下、その平均値“50”は、「平均選択幅」と参照される。
また、図4で示された例において、論理分布情報D2は、第3カラムCOL3の要素が範囲0〜999,999の値を一様な確率でとることを示している。図8は、第3カラムCOL3の値の分布を概念的に示している。図8において、横軸は各レコードを示し、縦軸は第3カラムCOL3の値を示している。図8で示されるように、第3カラムCOL3の値は、0〜999,999の範囲にわたって一様に分布している。また、データ構造情報D1から、総レコード数が100,000であることがわかる。従って、第3カラムCOL3の数値幅10(=100万/10万)につき、平均的に1レコードが存在することがわかる。言い換えれば、1レコードあたりに第3カラムCOL3が取り得る数値幅の平均値は“10”であることがわかる。以下、その平均値“10”は、「レコード幅」と参照される。
このように、数値幅10につき平均的に1レコードが存在する状況で、数値幅50に相当するレコード群が選択され、読み出される。従って、本例のクエリに応じて、テーブルSAMPLEから平均的に5レコードが読み出されると見積もられる。この見積値“5”は、以下「選択レコード数」と参照される。レコード数算出モジュール20は、受け取った情報を用いて上述の平均選択幅“50”とレコード幅“10”を算出する。そして、レコード数算出モジュール20は、平均選択幅“50”をレコード幅“10”で割ることによって、選択レコード数“5”を算出することができる。算出された選択レコード数“5”が、読み出し条件に適合するレコード数の平均値であり、読み出し対象のレコード数の見積値である。
ステップS30:ブロックアクセス回数の算出
次に、ブロックアクセス回数算出モジュール30は、データ構造情報D1、レコード配置情報D5、及びメタデータ構造情報D6を受け取る(図3参照)。更に、ブロックアクセス回数算出モジュール30は、レコード数算出モジュール20から上記選択レコード数を受け取り、クエリ解析モジュール10から「ターゲット」及び「条件節」を受け取る。そして、ブロックアクセス回数算出モジュール30は、受け取った情報に基づいてブロックアクセス回数を算出する。具体的な処理は、次の通りである。
まず、データ構造情報D1から、各レコードが4バイトの数値カラムCOL1、24バイトの文字列カラムCOL2、4バイトの数値カラムCOL3から成ることがわかる(図4参照)。つまり、1レコードのサイズは32バイトである。また、データ構造情報D1は、1つのテーブルブロックBLの有効ブロックサイズが8000バイトであることを示している。従って、1つのテーブルブロックBLの容量は、250レコード分に相当することがわかる(図5参照)。更に、データ構造情報D1は、テーブルSAMPLEの総レコード数が100,000であることを示している。従って、テーブルSAMPLEの全レコードを格納するために必要なテーブルブロックBLの総数は、“400(=100,000/250)”と算出される。
図5で示されるように、テーブルSAMPLEの全レコードは、400個のテーブルブロックBL−0〜BL−399にわたって格納されると推測される。アクセス回数算出モジュール30は、これら400個のテーブルブロックBL−0〜BLL−399のうち、クエリに応じてアクセスされるテーブルブロックBLの数を算出する。このとき、アクセス回数算出モジュール30は、クエリの実行計画毎に、アクセスされるテーブルブロックBLの数を算出する。「実行計画」とは、クエリをどのように実行するか示すプランである。本例の読み出しクエリの場合、実行計画は、読み出し対象のデータの探索方法を意味し、その探索方法としては、「全件検索」、「索引検索」、及び「キー検索」が挙げられる。
ステップS31:全件検索
全件検索の場合、全てのテーブルブロックBL−0〜BL−399に対して読み出しアクセスが発生する。つまり、全件検索の場合のブロックアクセス回数は400回である(図5参照)。アクセス回数算出モジュール30は、テーブルブロックBLの総数“400”を、全件検索の場合のブロックアクセス回数として算出する。
ステップS32:
索引検索は、図5で示されたメタデータによるツリーインデックスを利用した検索である。アクセス回数算出モジュール30は、今回のクエリ処理においてメタデータが利用可能かどうかを判定する。メタデータが利用不可能の場合(ステップS32;No)、ステップS30は終了する。本例の場合、メタデータ構造情報D6が入力されており、且つ、そのメタデータ構造情報D6が、「条件節」に現れる第3カラムCOL3に対してツリーインデックスが付与されていることを示している。従って、索引検索が可能である(ステップS32;Yes)。
ステップS33:索引検索
図5を参照して、索引検索の場合のブロックアクセス回数の算出方法を説明する。第3カラムCOL3に対して与えられるツリーインデックスにおいて、キー値は第3カラムCOL3の要素値である。その第3カラムCOL3のサイズが4バイトであることが、データ構造情報D1に示されている。また、内部アドレスポインタのサイズが6バイトであることが、メタデータ構造情報D6に示されている。従って、リーフブロックLBLやブランチブロックBBLの1エントリのサイズは10バイトである。更に、メタデータ構造情報D6は、リーフブロックLBLやブランチブロックBBLの有効ブロックサイズが8000バイトであることを示している。従って、リーフブロックLBLやブランチブロックBBLの各々は、800個のエントリを有していることがわかる。更に、データ構造情報D1は、テーブルSAMPLEの総レコード数が100,000であることを示している。従って、その総レコード数の索引を構築するために、125(=100,000/800)のリーフブロックLBL−0〜LBL−124が必要であることがわかる。
125個のリーフブロックLBL−0〜LBL−124に対する索引は、800エントリ有する1個のブランチブロックBBLで十分である。従って、ブロックアクセス回数算出モジュール30は、ブランチブロックBBLに対するアクセス回数は“1回”であると見積もる。
また、本例において選択レコード数は“5”である。つまり、テーブルSAMPLEのうち読み出し対象のレコード数は“5”である。1つのリーフブロックLBLは800エントリ有しており、その800エントリはキー値に基づいてソートされている。従って、読み出し対象の5レコードに対応する5エントリは、ある1つのリーフブロックLBL−m内に含まれている確率が極めて高い。従って、ブロックアクセス回数算出モジュール30は、リーフブロックLBLに対するアクセス回数は“1回”であると見積もる。
また、本例において、レコード配置情報D5は、「各レコードは、第3カラムCOL3の値に拘わらずランダムに配置される」という“ランダム配置”を示す。よって、読み出し対象の5レコードは、400個のテーブルブロックBL−0〜BL−399のうち互いに異なる5個のテーブルブロックBLに記録されている確率が極めて高い。従って、ブロックアクセス回数算出モジュール30は、テーブルブロックBLに対するアクセス回数は“5回”であると見積もる。
このように、索引検索の場合、1個のブランチブロックBBL、1個のリーフブロックLBL、及び5個のテーブルブロックBLに対して、合計7回の読み出しアクセスが発生する(図5参照)。すなわち、ブロックアクセス回数算出モジュール30は、索引検索の場合のブロックアクセス回数を“合計7回”と算出する。これは、メタデータが格納されるブロックへのアクセス回数と上述の選択レコード数との和に相当する。
ステップS34:キー検索
メタデータが利用可能であり、且つ、クエリの「ターゲット」がツリーインデックスのキー値そのものであれば、キー検索を実行することが可能である。キー検索の場合、テーブルブロックBLまでアクセスする必要はなく、リーフブロックLBLまでのアクセスでターゲットを読み出すことが可能である。本例の場合、クエリの「ターゲット」が全カラムであるため、ブロックアクセス回数算出モジュール30は、キー検索は不可能であると判断する。もし、「ターゲット」が全カラムではなく第3カラムCOL3であれば、ブロックアクセス回数は“合計2回”となる。
以上に説明されたように、ブロックアクセス回数算出モジュール30は、クエリの実行計画毎にブロックアクセス回数を算出する。このブロックアクセス回数が、データベースアクセス時の計算機システムの負荷に相当する。ブロックアクセス回数算出モジュール30は、負荷の観点から最適な実行計画を選択してもよい。本例の場合、最適な実行計画は、ブロックアクセス回数が7回である索引検索である。
ステップS40:ブロックアクセス回数情報
このようにして、ブロックアクセス回数見積モジュール40は、クエリ情報D3が示すクエリに伴って発生するブロックアクセスの回数を見積もる。結果として、見積もられたブロックアクセス回数を示すブロックアクセス回数情報D10が作成される。図9は、本例において作成されるブロックアクセス回数情報D10を示している。ブロックアクセス回数情報D10は、実行計画毎に見積もられたブロックアクセス回数を示している。また、ブロックアクセス回数情報D10は、最適な実行計画が索引検索であることも示している。
ステップS60:出力
出力モジュール60は、ブロックアクセス回数情報D10を、ディスプレイやプリンタといった出力装置に出力する。以上に説明された処理フローは、クエリごとに実行される。結果として、多数のクエリに関して、ブロックアクセス回数情報D10が得られる。
1−3.第2の処理例
次に、他の処理例を説明する。第2の処理例では、第1の処理例とは異なる論理分布情報D2と変数分布情報D4が入力される。それ以外の入力情報は、第1の処理例と同じである。
図10は、既出の図7に対応する図であり、本例における変数分布情報D4を概念的に示している。本例において、変数分布情報D4は、(1)条件変数aが範囲0〜249,999の値をとる確率が0.5であり、その確率分布が一様であること、(2)条件変数aが範囲250,000〜999,999の値をとる確率が0.5であり、その確率分布が一様であること、及び(3)数値幅(選択幅)b−aが範囲0〜99の値を一様な確率でとることを示している。第1の処理例の場合と同様に、数値幅b−aの平均値、すなわち、「平均選択幅」は50である。
図11は、既出の図8に対応する図であり、本例における論理分布情報D2を概念的に示している。本例において、論理分布情報D2は、(1)第3カラムCOL3の要素が0〜499,999の値をとる確率が0.2であり、その確率分布が一様であること、及び(2)第3カラムCOL3の要素が500,000〜999,999の値をとる確率が0.8であり、その確率分布が一様であること、を示している。つまり、図11に示されるように、第3カラムCOL3の大多数は500,000〜999,999の値を取り、残りが0〜499,999の値を取る。言い換えれば、値0〜499,999は全10万レコードのうち2万レコードだけで分担され、値500,000〜999,999は全10万レコードのうち8万レコードで分担される。従って、範囲0〜499,999の場合、レコード幅は25(=50万/2万)であり、範囲500,000〜999,999の場合、レコード幅は6.25(=50万/8万)である。
この場合、ステップS20の処理結果が、第1の処理例と異なってくる。ステップS20において、レコード数算出モジュール20は、平均選択幅をレコード幅で割ることによって選択レコード数を算出する。図10で示されるように、条件変数aが範囲0〜249,999の値をとる確率は0.5であり、その場合の選択レコード数は“0.5×(50/25)=1”と算出される。同様に、条件変数aが範囲250,000〜499,999の値をとる確率は0.5/3であり、その場合の選択レコード数は“0.5/3×(50/25)=1/3”と算出される。条件変数aが範囲500,000〜999,999の値をとる確率は0.5×2/3であり、その場合の選択レコード数は“0.5×2/3×(50/6.25)=8/3”と算出される。従って、選択レコード数の合計は“4(=1+1/3+8/3)”となる。つまり、レコード数算出モジュール20は、クエリに応じてテーブルSAMPLEから平均的に4レコードが読み出されると見積もる。
その後の処理は、第1の処理例と同じである。図12は、本例において作成されるブロックアクセス回数情報D10を示している。本例の場合、索引検索の場合のブロックアクセス回数は“合計6回”と見積もられている。
1−4.第3の処理例
更に他の処理例を説明する。第3の処理例では、レコード配置情報D5は、「テーブルSAMPLEの各レコードは、第3カラムCOL3の値順にシーケンシャルに配置される」という“シーケンシャル配置”を示す。それ以外の入力情報は、第1の処理例と同じである。従って、ステップS20において、レコード数算出モジュール20は、選択レコード数“5”を算出する。ステップS30中、索引検索の場合のブロックアクセス回数の算出処理(ステップS33)の結果が、第1の処理例と異なってくる。
ランダム配置の場合、読み出し対象の5レコードはそれぞれ異なるテーブルブロックBLへ配置されると推測されるため、テーブルブロックBLへのアクセス回数は、選択レコード数と同じ5回と見積もられた。一方、シーケンシャル配置の場合、読み出し対象の5レコードは連続的に配置されるため、テーブルブロックBLへのアクセス回数はより少なくなるはずである。図13は、本例における読み出し対象の5レコードの様々な配置例を示している。図13中、2つのテーブルブロックBL1、BL2が示されている。上述の通り、各テーブルブロックは、250レコード分の記憶領域を有している(図5参照)。
図13中のパターン(A)の場合、5レコードは、テーブルブロックBL1中の第1〜第5記憶領域に配置されている。パターン(C)の場合、5レコードは、テーブルブロックBL1の第246〜第250記憶領域に配置されている。パターン(B)は、パターン(A)とパターン(C)の中間のパターンである。これらパターン(A)〜パターン(C)の場合、読み出し対象の5レコードは、1つのテーブルブロックBL1に配置される。つまり、テーブルブロックBLへのアクセス回数は1回である。
一方、図13中のパターン(D)の場合、5レコードは、テーブルブロックBL1中の第247〜第250記憶領域とテーブルブロックBL2中の第1記憶領域に配置されている。パターン(E)の場合、5レコードは、テーブルブロックBL1中の第250記憶領域とテーブルブロックBL2中の第1記憶領域〜第4記憶領域に配置されている。これらパターン(D)、(E)の場合、読み出し対象の5レコードは、2つのテーブルブロックBL1、BL2に配置される。つまり、テーブルブロックBLへのアクセス回数は2回である。
図13から明らかなように、テーブルブロックBLへのアクセス回数が1回であるパターンは246種類存在し、2回であるパターンは4種類存在する。従って、テーブルブロックBLへのアクセス回数の“平均値(期待値)”は、式:1×246/250+2×4/250から“1.016”と算出される。
上記式を一般化すると次の通りである。ここで、1テーブルブロックBLあたりの総レコード数(250)を“A1”とする。また、選択レコード数(5)を“A2”とする。更に、テーブルブロックBLへのアクセス回数の平均値(1.016)を“A3”とする。この場合、上記式はA3=1×(A1−(A2−1))/A1+2×(A2−1)/A1と表される。この式を整理することにより、次の式が得られる。
A3=1+(A2−1)/A1
この式から分かるように、選択レコード数A2が1の場合、テーブルブロックBLへのアクセス回数の期待値A3は1である。右辺の定数項「1」は、選択レコードが存在する以上、少なくとも1回のアクセスが存在することを意味する。選択レコード数A2が増加するにつれて、期待値A3も増加する。
ブロックアクセス回数算出モジュール30は、上記式に基づいて、テーブルブロックBLへのアクセス回数の期待値A3を算出する。更に、ブロックアクセス回数算出モジュール30は、算出された期待値A3に、メタデータが格納されるブロックへのアクセス回数(2回)を加算する。結果として得られる値3.016(=1.016+2)が、索引検索の場合のブロックアクセス回数である。その他の処理は、第1の処理例と同じである。図14は、本例において作成されるブロックアクセス回数情報D10を示している。
1−5.第4の処理例
更に他の処理例を説明する。第4の処理例では、レコード配置情報D5は、“ランダム配置”と“シーケンシャル配置”の両方を指定する。それ以外の入力情報は、第1の処理例と同じである。本例の場合、ランダム配置とシーケンシャル配置の双方の場合のブロックアクセス回数が一度に算出される。図15は、本例において作成されるブロックアクセス回数情報D10を示している。索引検索が行われる際のブロックアクセス回数は、ランダム配置の場合に最大となり、シーケンシャル配置の場合に最小となる。従って、本例では、索引検索の場合のブロックアクセス回数の分布範囲が得られると言える。
1−6.第5の処理例
更に他の処理例を説明する。第5の処理例では、レコード配置情報D5は、“ランダム配置”な度合いと“シーケンシャル配置”な度合いを示すパラメータPを示す。このパラメータPは、テーブルブロックBLへのアクセス回数A3を補正するパラメータである。ランダム配置の場合のアクセス回数A3(5回)をMAXとし、シーケンシャル配置の場合のアクセス回数A3(1.016回)をMINとする。本例では、アクセス回数A3は、式:MIN+(MAX−MIN)×Pで算出される(0≦P≦1)。
1−7.効果
以上に説明されたように、本実施の形態によれば、クエリ処理に伴って発生するブロックアクセス回数を見積もることが可能となる。その処理において、テーブルの各要素は未定であってよい。テーブルの構造を示す情報や、要素及びクエリに関する統計的な情報を利用することにより、ブロックアクセス回数を簡単に見積もることができる。クエリ処理におけるフェッチの負荷量は、ブロックアクセス回数に大きく依存する。従って、ブロックアクセス回数を見積もることは、フェッチの負荷量を見積もることと等価である。
例えば、計算機システムの構築前には、実際のテーブルの要素値を知ることはできない。そのような場合であっても、ブロックアクセス回数やフェッチ負荷量を見積もることが可能である。もし、計算機システムの構築後に、フェッチ負荷量が適正値を超えていることが発覚した場合、計算機システムを再度構築し直す必要がある。本実施の形態によれば、あらかじめブロックアクセス回数やフェッチ負荷量を予測することにより、そのような事態を回避することが可能となる。従って、設計者の負担が軽減される。
また例えば、計算機システムが使用不可能な場合にも、本実施の形態は適用可能である。あるいは、本実施の形態は、データベースが巨大な場合にも有効である。データベースが巨大な場合、実際のテーブルを参照してブロックアクセス回数を測定するためには非常に長い時間を要する。本実施の形態によれば、ブロックアクセス回数を簡便に、且つ、短時間で見積もることが可能となる。
ブロックアクセス回数は、クエリの内容によって大きく異なる。多数のクエリに関して本実施の形態に係る処理を適用することにより、負荷量が大きくなるクエリを検知することが可能となる。言い換えれば、計算機資源を多量に消費し、性能不足の要因となり得る負荷量の大きいクエリを特定することが可能となる。設計者は、特定されたクエリによる負荷量が軽減されるように、データベースの設計仕様(例えばメタデータ構造)を変更することができる。あるいは、設計者は、負荷量の大きいクエリも処理できるように、計算機システムを設計することもできる。また、本実施の形態によれば、クエリの実行計画毎にブロックアクセス回数が見積もられ出力される。これにより、どの実行計画を採用するか比較検討することが可能となる。
2.第2の実施の形態
本発明の第2の実施の形態では、第1の実施の形態で予想されたブロックアクセス回数から、更にクエリ処理の負荷量や計算機システムの処理性能が見積もられる。第1の実施の形態と同様の構成には同じ符号が付され、重複する説明は省略される。
2−1.構成
図16は、第2の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。本実施の形態に係る計算機負荷見積システムは、第1の実施の形態における構成に加えて、性能見積モジュール50を備えている。その性能見積モジュール50には、ブロックアクセス回数情報D10と負荷量情報D8が入力される。場合によっては、デフォルト負荷量情報D9が入力される。
図17は、負荷量情報D8の一例を示している。負荷量情報D8は、1ブロックに対するアクセス(フェッチ)に要する計算機負荷と、その他の処理に要する計算機負荷を示す。計算機負荷は、例えばCPU時間で与えられる。例えば図17において、負荷量情報D8は、(1)1ブロックアクセスあたりのCPU時間が0.001msであること、及び(2)その他の処理に対するCPU時間が0.1msであることを示している。この負荷量情報D8は、例えば、設計仕様書や運用中の計算機システムの運用情報から得られる。また、この負荷量情報D8は、所定の記憶装置に格納される。
デフォルト負荷量情報D9は、計算機負荷のデフォルト設定を示す。負荷量情報D8が特に指定されていない場合、デフォルト負荷量情報D9が負荷量情報D8として用いられる。
2−2.処理例
図18は、本実施の形態に係る計算機負荷見積システムによる処理を示すフローチャートである。図16〜図18を参照して、本実施の形態における処理の一例を説明する。負荷量情報D8は、図17で示されたものであるとする。
ステップS1〜S40:
まず、第1の実施の形態と同様に、ブロックアクセス回数見積モジュール40が、入力情報D1〜D6に基づいて、ブロックアクセス回数情報D10を作成する。作成されるブロックアクセス回数情報D10は、例えば、上述の第1の処理例で作成されたものと同じであるとする(図9参照)。当然、他の処理例で作成されるブロックアクセス回数情報でもよい。
ステップS50:
次に、図16に示されるように、性能見積モジュール50は、記憶装置からブロックアクセス回数情報D10及び負荷量情報D8を読み込む(ステップS51)。負荷量情報D8が空の場合(ステップS52;Yes)、デフォルト負荷量情報D9が読み込まれる(ステップS53)。本例の場合、負荷量情報D8が与えられているので(ステップS52;No)、処理はステップS54に進む。
ステップS54:
性能見積モジュール50は、ブロックアクセス回数情報D10が示すブロックアクセス回数と、負荷量情報D8が示す1ブロックアクセスあたりのCPU時間との乗算を行う。その乗算により得られる値は、フェッチのCPU時間に相当する。更に、性能見積モジュール50は、算出されたフェッチのCPU時間に、負荷量情報D8が示すその他の処理に対するCPU時間を加える。その加算により得られる値が、1つのクエリ処理に要するCPU時間である。また、性能見積モジュール50は、算出されたCPU時間に基づいて、計算機システムの処理性能(例えばスループット)を算出する。
例えば、全件検索の場合、ブロックアクセス回数は“400”である。従って、フェッチのCPU時間は0.4ms(=0.001ms×400)と算出される。クエリ処理のCPU時間は0.5ms(=0.4ms+0.1ms)と算出される。スループットは2000tps(=1000/0.5ms)である。
また、索引検索の場合、ブロックアクセス回数は“7”である。従って、フェッチのCPU時間は0.007ms(=0.001ms×7)と算出される。クエリ処理のCPU時間は0.107ms(=0.007ms+0.1ms)と算出される。スループットは9345tps(=1000/0.107ms)である。
このようにして、性能見積モジュール50は、ブロックアクセス回数情報D10と負荷量情報D8に基づいて、クエリ処理に必要なCPU時間(負荷量)やクエリ処理のスループットを算出する。算出されたCPU時間やスループットが、計算機システムの「性能指標」である。性能見積モジュール50は、得られた性能指標を示す性能指標情報D20を作成する。図19は、本例において作成される性能指標情報D20を示している。図19において、性能指標情報D20は、実行計画毎に、ブロックアクセス回数、CPU時間、及びスループットを示している。また、性能指標情報D20は、最適な実行計画が索引検索であることも示している。
ステップS60:出力
出力モジュール60は、性能指標情報D20を、ディスプレイやプリンタといった出力装置に出力する。以上に説明された処理フローは、クエリごとに実行される。結果として、使用予定の多数のクエリに関して、ブロックアクセス回数や性能指標が得られる。
2−3.効果
本実施の形態によれば、第1の実施の形態と同じ効果が得られる。更に、クエリ処理の負荷量や計算機システムの性能指標を見積もることが可能となる。
3.計算機負荷見積システム
以上に説明された計算機負荷見積システムは、コンピュータシステムにより実現される。図20は、計算機負荷見積システム100の構成の一例を示している。計算機負荷見積システム100は、プロセッサ110、記憶装置120、入力装置130、出力装置140、ネットワークインタフェース150、及びメディアドライブ160を備えている。プロセッサ110はCPUを含み、各種処理を行う。記憶装置120として、RAMやハードディスクが例示される。入力装置130として、キーボードやマウスが例示される。出力装置140として、表示装置やプリンタが例示される。
記憶装置120には、上述のデータ構造情報D1、論理分布情報D2、クエリ情報D3、変数分布情報D4、レコード配置情報D5、メタデータ構造情報D6、デフォルト情報D7、負荷量情報D8、デフォルト負荷量情報D9が格納される。それら情報D1〜D9は、入力装置130により入力されてもよいし、ネットワークインタフェース150を介して提供されてもよい。また、記憶装置120は、本実施の形態に係る処理フローにより作成されるブロックアクセス回数情報D10や性能指標情報D20が格納される。
記憶装置120には更に、計算機負荷見積プログラムPROが格納される。この計算機負荷見積プログラムPROは、プロセッサ110によって実行されるソフトウエアである。計算機負荷見積プログラムPROは、例えば、コンピュータ読み取り可能な記録媒体に記録されており、メディアドライブ160によって読み込まれる。
プロセッサ110は、計算機負荷見積プログラムPROを実行することによって、本発明に係る処理を実現する。つまり、プロセッサ110と計算機負荷見積プログラムPROとの協働により、上述のクエリ解析モジュール10、レコード数算出モジュール20、ブロックアクセス回数算出モジュール30、ブロックアクセス回数見積モジュール40、性能見積モジュール50、及び出力モジュール60が提供される。各モジュールは、必要な情報を記憶装置120から読み出し、上述の処理を実現する。出力モジュール60は、作成されたブロックアクセス回数情報D10や性能指標情報D20を、出力装置140に出力させる。このようにして、本発明に係る処理が実現される。
図1は、一般的なクエリ処理を説明するための概念図である。 図2は、一般的なブロックアクセスを説明するための概念図である。 図3は、本発明の第1の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。 図4は、第1の処理例を説明するための概念図である。 図5は、第1の処理例を説明するための概念図である。 図6は、第1の実施の形態に係る計算機負荷見積方法を示すフローチャートである。 図7は、第1の処理例を説明するための概念図である。 図8は、第1の処理例を説明するための概念図である。 図9は、第1の処理例において得られるブロックアクセス回数情報を示すテーブルである。 図10は、第2の処理例を説明するための概念図である。 図11は、第2の処理例を説明するための概念図である。 図12は、第2の処理例において得られるブロックアクセス回数情報を示すテーブルである。 図13は、第3の処理例を説明するための概念図である。 図14は、第3の処理例において得られるブロックアクセス回数情報を示すテーブルである。 図15は、第4の処理例において得られるブロックアクセス回数情報を示すテーブルである。 図16は、本発明の第2の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。 図17は、負荷量情報を示す図である。 図18は、第2の実施の形態に係る計算機負荷見積方法を示すフローチャートである。 図19は、性能指標情報を示すテーブルである。 図20は、本発明の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。
符号の説明
10 クエリ解析モジュール
20 レコード数算出モジュール
30 ブロックアクセス回数算出モジュール
40 ブロックアクセス回数見積モジュール
50 性能見積モジュール
60 出力モジュール
D1 データ構造情報
D2 論理分布情報
D3 クエリ情報
D4 変数分布情報
D5 レコード配置情報
D6 メタデータ構造情報
D7 デフォルト情報
D8 負荷量情報
D9 デフォルト負荷量情報
D10 ブロックアクセス回数情報
D20 性能指標情報
100 計算機負荷見積システム
110 プロセッサ
120 記憶装置
130 入力装置
140 出力装置
150 ネットワークインタフェース
160 メディアドライブ
PRO 計算機負荷見積プログラム

Claims (12)

  1. データベースの負荷を見積もるための計算機負荷見積システムであって、
    複数のレコードを有し前記データベースに含まれるテーブルの構造を定義する構造情報と、前記テーブルに対するクエリの条件変数の確率分布を示す第1分布情報と、前記テーブルの要素の確率分布を示す第2分布情報と、が格納される記憶装置と、
    前記構造情報、前記第1分布情報及び前記第2分布情報に基づいて、前記複数のレコードのうち前記条件変数で規定される条件に適合するレコードの数の平均値である選択レコード数を算出するレコード数算出モジュールと、
    前記選択レコード数に基づいて、前記クエリに応じてアクセスされるブロックの数を算出するアクセス回数算出モジュールと
    を備える
    計算機負荷見積システム。
  2. 請求項1に記載の計算機負荷見積システムであって、
    前記構造情報は、前記複数のレコードの総数、及び前記複数のレコードの各々のサイズを示す
    計算機負荷見積システム。
  3. 請求項2に記載の計算機負荷見積システムであって、
    前記条件変数は、数値幅を規定し、
    前記第1分布情報は、前記数値幅の確率分布を示しており、
    前記レコード数算出モジュールは、前記第1分布情報に基づいて、前記数値幅の平均値である平均選択幅を算出し、
    前記レコード算出モジュールは、前記レコードの総数と前記第2分布情報に基づいて、1レコードあたりに前記要素が取り得る数値幅の平均値であるレコード幅を算出し、
    前記レコード数算出モジュールは、前記平均選択幅を前記レコード幅で割ることによって前記選択レコード数を算出する
    計算機負荷見積システム。
  4. 請求項3に記載の計算機負荷見積システムであって、
    前記記憶装置には更に、ブロックへの前記複数のレコードの配置方法を示す配置情報と、索引検索に利用されるメタデータの構造を定義するメタデータ構造情報とが格納され、
    前記アクセス回数算出モジュールは、前記選択レコード数、前記配置情報及び前記メタデータ構造情報に基づいて、前記アクセスされるブロックの数を算出する
    計算機負荷見積システム。
  5. 請求項4に記載の計算機負荷見積システムであって、
    前記配置情報は、前記複数のレコードが前記要素に拘わらずランダムに配置されることを示し、
    前記アクセス回数算出モジュールは、前記メタデータが格納されるブロックへのアクセス回数と前記選択レコード数との和を、前記アクセスされるブロックの数として算出する
    計算機負荷見積システム。
  6. 請求項4又は5に記載の計算機負荷見積システムであって、
    前記配置情報は、前記複数のレコードが前記要素の値順にシーケンシャルに配置されることを示し、
    1ブロックあたりに格納されるレコード数がA1であり、前記選択レコード数がA2であるとき、
    前記アクセス回数算出モジュールは、式:A3=1+(A2−1)/A1に基づいて値A3を算出し、更に、前記メタデータが格納されるブロックへのアクセス回数と前記値A3との和を、前記アクセスされるブロックの数として算出する
    計算機負荷見積システム。
  7. 請求項2乃至6のいずれかに記載の計算機負荷見積システムであって、
    前記アクセス回数算出モジュールは、前記レコードの総数、前記各レコードのサイズ、及び1ブロックのサイズに基づいて、前記複数のレコードの全てを格納するために必要なブロックの総数を算出し、
    前記アクセス回数算出モジュールは、前記算出されたブロックの総数を、全件検索時の場合の前記アクセスされるブロックの数として算出する
    計算機負荷見積システム。
  8. 請求項1乃至7のいずれかに記載の計算機負荷見積システムであって、
    前記アクセスされるブロックの数を表示する表示装置を更に備える
    計算機負荷見積システム。
  9. 請求項1乃至7のいずれかに記載の計算機負荷見積システムであって、
    性能見積モジュールを更に備え、
    前記記憶装置には更に、1ブロックに対するアクセスに要する計算機負荷を示す負荷量情報が格納され、
    前記性能見積モジュールは、前記計算機負荷と前記アクセスされるブロックの数とに基づいて、前記クエリの処理に必要な負荷を算出する
    計算機負荷見積システム。
  10. 請求項9に記載の計算機負荷見積システムであって、
    前記クエリの処理に必要な負荷を表示する表示装置を更に備える
    計算機負荷見積システム。
  11. データベースの負荷を見積もるための計算機負荷見積方法であって、
    (A)複数のレコードを有し前記データベースに含まれるテーブルの構造を定義する構造情報を、記憶装置から読み出すステップと、
    (B)前記テーブルに対するクエリの条件変数の確率分布を示す第1分布情報を、前記記憶装置から読み出すステップと、
    (C)前記テーブルの要素の確率分布を示す第2分布情報を、前記記憶装置から読み出すステップと、
    (D)前記構造情報、前記第1分布情報及び前記第2分布情報に基づいて、前記複数のレコードのうち前記条件変数で規定される条件に適合するレコードの数の平均値である選択レコード数を算出するステップと、
    (E)前記選択レコード数に基づいて、前記クエリに応じてアクセスされるブロックの数を算出するステップと
    を有する
    計算機負荷見積方法。
  12. 請求項11に記載の計算機負荷見積方法をコンピュータに実行させる
    計算機負荷見積プログラム。
JP2007059055A 2007-03-08 2007-03-08 計算機負荷見積システム、計算機負荷見積方法、計算機負荷見積プログラム Expired - Fee Related JP5088668B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007059055A JP5088668B2 (ja) 2007-03-08 2007-03-08 計算機負荷見積システム、計算機負荷見積方法、計算機負荷見積プログラム
US12/042,844 US7805410B2 (en) 2007-03-08 2008-03-05 Load estimating system and computer load estimating method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007059055A JP5088668B2 (ja) 2007-03-08 2007-03-08 計算機負荷見積システム、計算機負荷見積方法、計算機負荷見積プログラム

Publications (2)

Publication Number Publication Date
JP2008225575A true JP2008225575A (ja) 2008-09-25
JP5088668B2 JP5088668B2 (ja) 2012-12-05

Family

ID=39742651

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007059055A Expired - Fee Related JP5088668B2 (ja) 2007-03-08 2007-03-08 計算機負荷見積システム、計算機負荷見積方法、計算機負荷見積プログラム

Country Status (2)

Country Link
US (1) US7805410B2 (ja)
JP (1) JP5088668B2 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012017529A1 (ja) * 2010-08-04 2012-02-09 株式会社日立製作所 データベース管理方法、データベース管理装置及びデータベース管理プログラム
WO2012169102A1 (ja) * 2011-06-08 2012-12-13 日本電気株式会社 データベース性能予測装置及びデータベース予測方法
JP2015049891A (ja) * 2013-09-02 2015-03-16 タタ コンサルタンシー サービシズ リミテッドTATA Consultancy Services Limited アプリケーション開発段階でクエリにかかる経過応答時間を予測するシステム及び方法
US9594785B2 (en) 2010-12-16 2017-03-14 Nec Corporation Database management device and database management method

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7657540B1 (en) 2003-02-04 2010-02-02 Seisint, Inc. Method and system for linking and delinking data records
JP4716259B2 (ja) * 2006-03-29 2011-07-06 日本電気株式会社 サイジング支援システム、方法、及びプログラム
JP5282908B2 (ja) * 2007-10-03 2013-09-04 日本電気株式会社 階層型負荷推定システム、方法およびプログラム
US8266168B2 (en) * 2008-04-24 2012-09-11 Lexisnexis Risk & Information Analytics Group Inc. Database systems and methods for linking records and entity representations with sufficiently high confidence
US8219537B1 (en) * 2009-07-29 2012-07-10 Bank Of America Corporation Identifying skewed queries in an MMP system
TW201118558A (en) * 2009-11-18 2011-06-01 Inventec Corp Virtual hard disk drive
US9411859B2 (en) 2009-12-14 2016-08-09 Lexisnexis Risk Solutions Fl Inc External linking based on hierarchical level weightings
US9454548B1 (en) 2013-02-25 2016-09-27 Emc Corporation Pluggable storage system for distributed file systems
WO2015073003A1 (en) * 2013-11-14 2015-05-21 Hewlett-Packard Development Company, L.P. Estimating data
US10726013B2 (en) * 2015-05-07 2020-07-28 Nec Corporation Information processing device, information processing method, and recording medium
US20180107832A1 (en) * 2016-10-14 2018-04-19 Sap Se Table privilege management

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63220323A (ja) * 1987-03-10 1988-09-13 Fujitsu Ltd エンドユ−ザ言語内部処理論理出力処理方式
JPH03108036A (ja) * 1989-09-20 1991-05-08 Fujitsu Ltd データベース管理システムの性能見積もり方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0997200A (ja) 1995-09-29 1997-04-08 Hitachi Ltd クライアントサーバ型のデータベースシステム
JP3716753B2 (ja) * 2001-03-21 2005-11-16 日本電気株式会社 マルチプロセッサ構成の計算機間におけるトランザクション負荷分散方法及び方式並びにプログラム
US6925421B2 (en) * 2003-01-09 2005-08-02 International Business Machines Corporation Method, system, and computer program product for estimating the number of consumers that place a load on an individual resource in a pool of physically distributed resources

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63220323A (ja) * 1987-03-10 1988-09-13 Fujitsu Ltd エンドユ−ザ言語内部処理論理出力処理方式
JPH03108036A (ja) * 1989-09-20 1991-05-08 Fujitsu Ltd データベース管理システムの性能見積もり方法

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012017529A1 (ja) * 2010-08-04 2012-02-09 株式会社日立製作所 データベース管理方法、データベース管理装置及びデータベース管理プログラム
JP5304950B2 (ja) * 2010-08-04 2013-10-02 株式会社日立製作所 データベース管理方法、データベース管理装置及びデータベース管理プログラム
US9594785B2 (en) 2010-12-16 2017-03-14 Nec Corporation Database management device and database management method
WO2012169102A1 (ja) * 2011-06-08 2012-12-13 日本電気株式会社 データベース性能予測装置及びデータベース予測方法
JPWO2012169102A1 (ja) * 2011-06-08 2015-02-23 日本電気株式会社 データベース性能予測装置及びデータベース予測方法
US9336254B2 (en) 2011-06-08 2016-05-10 Nec Corporation Database performance estimation device and database estimation method
JP2015049891A (ja) * 2013-09-02 2015-03-16 タタ コンサルタンシー サービシズ リミテッドTATA Consultancy Services Limited アプリケーション開発段階でクエリにかかる経過応答時間を予測するシステム及び方法

Also Published As

Publication number Publication date
US20080222090A1 (en) 2008-09-11
US7805410B2 (en) 2010-09-28
JP5088668B2 (ja) 2012-12-05

Similar Documents

Publication Publication Date Title
JP5088668B2 (ja) 計算機負荷見積システム、計算機負荷見積方法、計算機負荷見積プログラム
US10664497B2 (en) Hybrid database table stored as both row and column store
US10387411B2 (en) Determining a density of a key value referenced in a database query over a range of rows
US9063982B2 (en) Dynamically associating different query execution strategies with selective portions of a database table
US9805077B2 (en) Method and system for optimizing data access in a database using multi-class objects
EP3014488B1 (en) Incremental maintenance of range-partitioned statistics for query optimization
US8918436B2 (en) Hybrid database table stored as both row and column store
US20170083573A1 (en) Multi-query optimization
US8732163B2 (en) Query optimization with memory I/O awareness
US20150142829A1 (en) System, apparatus, program and method for data aggregatione
US20140244628A1 (en) Hybrid Database Table Stored as Both Row and Column Store
US20130117255A1 (en) Accessing a dimensional data model when processing a query
US20120179698A1 (en) Multiple Sparse Index Intelligent Table Organization
US20070250517A1 (en) Method and Apparatus for Autonomically Maintaining Latent Auxiliary Database Structures for Use in Executing Database Queries
CN111708895B (zh) 一种知识图谱系统的构建方法及装置
JP5790755B2 (ja) データベース管理装置及びデータベース管理方法
US10503508B2 (en) Predictive query execution in analytical databases
US20060085464A1 (en) Method and system for providing referential integrity constraints
CN115495462A (zh) 批量数据更新方法、装置、电子设备和可读存储介质
CN114416741A (zh) 基于多级索引的kv数据写入读取方法、装置及存储介质
US8140520B2 (en) Embedding densities in a data structure
JP2013127750A (ja) パーティション分割装置及び方法及びプログラム
JP2018081603A (ja) Kvデータ構造変換装置、kvデータ構造変換方法、および、kvデータ構造変換プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100218

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120420

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120427

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120606

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120820

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150921

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120902

LAPS Cancellation because of no payment of annual fees