JP2016529586A - マルチストアシステムをチューニングし、ビッグデータクエリワークロードを高速化するためのシステムおよび方法 - Google Patents

Abstract

マルチストアシステム内のクエリ処理の副産物を受け取り、副産物が、ビューまたは中間データの具体化されたものを含むことと、ビューまたは具体化されたものを、将来のクエリワークロードを示すものとして最近観察されたクエリに基づいて、ストア間にまたがって配置することと、予測された、クエリの将来のワークロードに基づいて、各ビューについて利益スコアを決定し、各ストアにはビュー記憶バジェットが割り振られ、ストア間でビューを転送するためにビュー転送バジェットがあることと、マルチストアシステムの物理設計をチューニングすることによってマルチストアシステムを動作させるためのシステムおよび方法が開示される。

Description

本願は、共に２０１３年９月１３日に出願された米国特許仮出願第６１８７７４２３号および第６１８７７４３０号に対する優先権を主張し、それらの内容を参照により組み込む。

マルチストアシステムは、ビッグデータ解析学にとって自然な進化を象徴するものであり、クエリ処理は、２つのストアにまたがり、データおよび計算を移転することができる。マルチストア処理に対する１つの手法は、ビッグデータのすべてをＲＤＢＭＳに転送およびロードし（すなわち、アップフロントデータローディング）、ビッグデータストアに対してその優れたクエリ処理性能を利用することである。しかし、ビッグデータの大きなサイズとＥＴＬ（Ｅｘｔｒａｃｔ−Ｔｒａｎｓｆｏｒｍ−Ｌｏａｄ）プロセスの高コストにより、この手法は非現実的なものになり得る。別の手法は、クエリがデータをまとめて転送する（すなわち、オンデマンドデータローディング）ことによって、クエリ処理中に両ストアを使用することである。しかし、これは、ビッグデータワークロードがクエリ間にまたがって何らかの重なりを有する場合、同じデータがストア間で繰り返し転送され得るので、作業が冗長になる。

マルチストア処理のためのより効果的な方策は、アップフロントデータローディングとオンデマンドデータローディングとの間での兼ね合いをはかることである。これは、探索クエリが本質的にその場限りのものであり、関連するデータが時間の経過につれて変化しているので厄介である。マルチストアシステムに関するきわめて重大な問題は、どのデータを、いつ、どのストア内で具体化するかを決定することである。本発明者らは、この問題を、マルチストアシステムの物理設計をチューニングすることと称する。また、マルチストアシステムでは、クエリが２つのストアのデータにアクセスすること、および、計算を可能とし、クエリ処理のために、ＨａｄｏｏｐのＨＤＦＳおよびＲＤＢＭＳなど、複数の別個のデータストアを使用する。マルチストアクエリ処理に対する現行の手法は、ストア間でのデータ移動、および、ローディングについてのコスト高により、両システムを使用することの潜在的な利益を完全に得ることができない。マルチストア物理設計をチューニングすること、すなわち、どのストアにどのデータがあるかを判断することにより、クエリ処理中のデータ移動の量を削減することができ、これは良好なマルチストア性能とするためにはきわめて重要である。これらのストアは、非常に非対称的な性能特性を有するので、データ配置問題は簡単でない。おおざっぱに言えば、ストア１は、より小さく、より速いストア２に比べて、大きく、遅い。具体的には、２つの課題がある。すなわち、ストア１は、クエリ処理性能がより劣るが、はるかに良好なデータローディング時間をもたらし、ストア２は、より良好なクエリ処理性能を有するが、データロード時間が非常にかかるという欠点がある。どのデータをどのストア内に配置するかを考えるときには、これらの課題の兼ね合いを理解することが必要となる。

第１の態様では、ＭＩＳＯ（ＭｕｌｔＩＳｔｏｒｅ−Ｏｎｌｉｎｅ−ｔｕｎｉｎｇ）と呼ばれる１つの手法により、各ストアで具体化されたビューの最良のセットを選択することによってビッグデータクエリ処理を高速化する。ＭＩＳＯは、ビッグデータクエリを処理するためにその予備の能力の一部を使用して、既存のＲＤＢＭＳリソースの利用を最大限にする。具体的には、マルチストアシステムの物理設計は、具体化するデータ（すなわち、どのビューか）、および、データを具体化するところ（すなわち、どのストアか）の２つを判断する構成要素を有する。さらに、これらの判断のどちらも、分離することができない。

上記の態様の利点は、以下の１つまたは複数を含むことができる。本発明者らの手法は、以下の特徴の独特の組合せで、適応的かつ軽量である。

１）本発明者らの解決策はオンラインで機能する。想定されるワークロードは、アナリストがクエリを提出し改訂し続けるので、その場限りのものである。マルチストア設計は、ワークロードの動的な変化に自動的に適応する。

２）具体化されたビューを物理設計の基本要素として使用する。具体化された
ビューを使用することの利益は、ビューが前の計算をカプセル化し、ストア間にまたがってビューを配置することにより、コストのかかる、クエリ処理中にまとめてデータを移動させる必要を取り除くことができる。正しいときに正しいストア内に正しいビューを有することにより、ストアのための有益な物理設計が生み出される。

３）本発明者らの手法は、クエリ処理の副産物だけに依拠する。ＨＤＦＳ（たとえば、Ｈａｄｏｏｐジョブ）を使用するクエリ処理は、フォールトトレランスのために中間結果を具体化する。同様に、マルチストアシステム内でのクエリ処理は、ストア間で中間結果を移動する。どちらの場合も、本発明者らは、これらの中間結果を日和見的具体化ビューとして処理し、それらは、クエリが完了した後、破棄されるのではなく、保持される。これらのビューは、ワークロードによって決定される関連データの現在のセットを表すので、物理設計をチューニングするのに有益である。ここで詳述される方法は、ビューが、ここで述べられているようにクエリ実行の副産物として無料で作成されず、将来のクエリを高速化する明らかな目的のために作成されるときでも適用可能であることに留意されたい。

４）本発明者らの方法は、適応的かつ軽量であり、クエリ処理の副産物だけを使用してオンライン式で機能する。本発明者らの方法は、チューニングのないマルチストアクエリ処理に比べて３：１ｘまでマルチストアシステムに対するビッグデータ解析処理を改善する。

第２の態様の方法では、マルチストアシステム内のクエリ処理の副産物を使用し、マルチストアシステムの物理設計をチューニングする。これらの副産物は、中間データが具体化されたものであり、その後、これらは、この方法によってストア間にまたがって配置される。これらの副産物は、ベースデータの上の「ビュー」と呼ばれる。クエリ処理にとって有益となるように、ビューをストア間にまたがって配置することが予測されるクエリワークロードが必要となる。この方法では、最近観察されたクエリを、将来のクエリワークロードを示すものとみなす。

次に、この予測されたクエリの将来のワークロードに基づいて、各ビューについて利益スコアを計算する。各ストアには、ビュー記憶バジェットが割り振られ、ストア間でビューを転送するためにビュー転送バジェットがある。各バジェットは、一意の値を有してもよい。このセットアップは、図２に示されている。

次に、この方法では、最後のビュー配置がすべてのバジェット内に入り、将来のワークロードのコストを最小限に抑えるように、ストア間でビューを転送することを考慮する。解を計算するとき、この方法は、各ストア内にあるビューすべての集合であるビューの和集合を考慮する。解を計算したとき、それらの解は、各ストア内に配置されることになるこれらのビューのサブセットを含む。まず、最初に高性能ストアである、ストア２のためのビュー配置を解決することによって開始する。将来のワークロードにとって最も有益となると計算されたビューを、ストア２に転送する（またはその中で保持させる）ことが考えられる。ストア２について解が計算され、その解は、ストア２内に配置するためのビューのセットである。ストア２のための解は、ストア２のためのビュー記憶バジェットを超えてはならず、ビュー転送バジェットを超えてはならない。次いで、同様にストア１のための解を計算する。ストア１のための解は、ストア１のためのビュー記憶バジェットを超えてはならず、ストア２のための解によって消費されなかった残りのビュー転送バジェットを超えてはならない。

好ましい実施形態の利点は、以下の１つまたは複数を含むことができる。この方法は、マルチストアシステム内のデータ配置問題を解決する。このシステムでは、マルチストアシステムのためのクエリ処理時間がより速くなる。このシステムは、多数の組織ですでに配置済みである２つのストアを単純に使用する。このシステムは、クエリ実行時間を削減するようにそれらのストアを共に結合する。すでに存在するリソース（無関係なデータ処理タスクを実施する２つのストア）を使用することによって、このシステムは、企業リソースをよりよく利用する。これには、コスト上の利益がある。

（ａ）は２つの独立のストア、（ｂ）は両ストアを使用するマルチストアシステムの一例を示す図である。 ＭＩＳＯチューナ、クエリオプティマイザ、実行レイヤ、および２つのストアＨＶ、ＤＷを含む例示的なシステムアーキテクチャを示す図である。 マルチストアシステムを再構成するための例示的なプロセスを示す図である。 マルチストアシステムを再構成するための別の例示的なプロセスを示す図である。 ビューをマルチストアの要素として扱うための例示的なプロセスを示す図である。 マルチストア設計を作成するための例示的なプロセスを示す図である。 マルチストア設計を作成するための別の例示的なプロセスをより詳細に示す図である。 マルチストア設計を作成するための別の例示的なプロセスをより詳細に示す図である。 データベース管理のためのシステム内で使用される方法を示す図である。

図１は、（ａ）２つの独立のストア、および、（ｂ）両ストアを使用するマルチストアシステムの一例を示す図である。並列なリレーショナルデータベース管理システム（ＲＤＢＭＳ）は、長い間、データウェアハウスアプリケーションのためのストレージおよびクエリ処理エンジンの「主力商品」であった。最近、大規模なデータ記憶および解析のために「ビッグデータ」システムに向かう実質的な動きがあり、Ｈｉｖｅを用いるＨＤＦＳが、おそらくそのようなシステムの最も一般的な例である。本システムは、性能のために、または両ストアにまたがるデータセットの解析のために、並列ＲＤＢＭＳとビッグデータストアを「マルチストア」システムに組み込む。

ここで定義されるマルチストアは、必ずしもビッグデータストアとＲＤＢＭＳストアの組合せを示さないことに留意することが重要である。マルチストアは２つ以上のストアを含むことができ、またストアの異なる組合せを含むことができるという意味で、このセットアップにはいくらか変動性があり得る。換言すれば、マルチストアは、ＲＤＢＭＳとＨｉｖｅの組合せに制限されない。たとえば、マルチストアは、ビッグデータストア、カラムストア、および、ＲＤＢＭＳストアで構成され得る。本発明者らが詳述する技法をこれらの代替のセットアップに拡張することができることは自明である。マルチストアの概念について言及したので、説明を簡単にするために、本発明者らは、ＨｉｖｅおよびＲＤＢＭＳからなるマルチストアを、多種多様なマルチストアを代表するものとして述べる。

このシステムは、ＭＩＳＯ、すなわち、マルチストアオンラインチューニングアルゴリズムを実行し、各ストア内に具体化されたビューのセットをチューニングすることによってビッグデータクエリ処理を「スピードアップする」。ＭＩＳＯは、ビッグデータクエリを処理するためにその予備の能力の一部を使用して、既存のＲＤＢＭＳリソースの利用を最大限にする。ＲＤＢＭＳは、組織にとって非常に重要な事業データを保持することを考えると、ＤＢＡは、当然ながらＲＤＢＭＳリソースを守るものである。この問題に敏感であるならば、本発明者らの手法がＲＤＢＭＳレポーティングクエリに対してほとんど影響を及ぼすことなしに高速化を達成することは重要である。ＭＩＳＯは、マルチストアシステム内のデータ配置をチューニングするための適応的かつ軽量な方法であり、以下の特徴の独特の組合せを有する。

・オンラインで機能する。想定されるワークロードは、アナリストがクエリを提出し、改訂し続けるので、その場限りのものとなる。マルチストア設計は、ワークロードの動的な変化に自動的に適応する。

・具体化されたビューを物理設計の基本要素として使用する。具体化されたビューを使用することの利益は、ビューが前の計算をカプセル化し、ストア間にまたがるようにビューを配置することにより、コストのかかるクエリ処理中でのデータ移動をまとめて行う必要がなくなることである。正しいときに、正しいストア内に、正しいビューを有することにより、ストアのための有益な物理設計が生み出される。

・クエリ処理の副産物だけに依拠する。ＨＤＦＳ（たとえば、Ｈａｄｏｏｐジョブ）を使用するクエリ処理は、フォールトトレランスのために中間結果を具体化する。以前に言及したように、ビューがクエリ実行の副産物として生成されたものであることは望ましいことではあるが、それだけに制限される必要はない。また、この方法は、将来の、クエリを高速化するために明示的に具体化されるビューをも包含する。そのような場合、これらのビューを具体化する際のコストがあり、このコストは、それらの利益に照らして調整するべきである。同様に、マルチストアシステム内でのクエリ処理は、中間結果をストア間で移動させる。どちらの場合も、本発明者らは、これらの中間結果を日和見的具体化ビューとして処理し、それらを基礎となるストア内に戦略的に配置し、後続のクエリの評価を最適化することができる。これらのビューは、関連する現在のデータを表し、具体化されたビューを構築するための別々にコストがかかる要求を発行する必要なしに、ほぼ無料で物理設計をチューニングするための方法を提供する。

図１は、マルチストアシステムアーキテクチャの一例を示す。マルチストアでは、２つのデータストア、すなわち、ビッグデータストアとＲＤＢＭＳストアがある。図１に示されている本発明者らのシステムでは、ビッグデータストアはＨｉｖｅ（ＨＶ）であり、ＲＤＢＭＳは、商用並列データウェアハウス（ＤＷ）である。ＨＶは、ビッグデータログファイルを含み、ＤＷは、解析事業データを含む。一部のマルチストアシステムは、単一のクエリが、両ストアにまたがるデータにアクセスすることを可能にするが、ＭＩＳＯは、ＤＷ内の何らかの限られた予備の能力を使用し、クエリのワークロードのためにストアの物理設計をチューニングすることによって、ＨＶ内でのビッグデータ探索クエリを加速する。このようにして、ＭＩＳＯは、ビッグデータクエリのために既存のリソースを利用する。この手法を用いて、ＤＷは、ＨＶ内でのクエリの性能を改善するためのアクセラレータとして働く。本発明者らは、追って、ＭＩＳＯがこの高速化をＤＷに対してほとんど影響を及ぼすことなしに達成することを示す。

図２は、本発明者らのシステムアーキテクチャを示し、ＭＩＳＯチューナ、クエリオプティマイザ、実行レイヤ、および、２つのストアＨＶ、ＤＷを含む。本発明者らのシステムでは、各ストアは、独立のクラスタにある。ＨＶはログデータを含み、一方、ＤＷは解析データを含むが、この研究では、本発明者らの重点は、ログデータにだけ提出されたビッグデータクエリを加速することにある。図に示されているように、各ストアは、ＨＶ内に記憶された、具体化されたベースデータ（すなわち、ログ）のビューのセットを有し、それと共に、これらのビューは、マルチストア物理設計を構成する。

フォールトトレランスのために、Ｈａｄｏｏｐベースのシステム（たとえば、ＨＶ）は、クエリ実行中に中間結果を具体化し、本発明者らは、これらの副産物を日和見的具体化ビューとして保持する。一方、ＤＷによる生産物は、一般にそれらの具体化された中間結果へのアクセスを提供しない。しかし、これらの結果が使用可能になった場合には、それらもまたチューニングのために使用することができる。本発明者らのシステムでは、物理設計をチューニングするときに日和見的具体化ビューのクラスを考慮する。ワークロード性能を改善するためにストアにまたがるこれらのビューの配置を決定することは、ＭＩＳＯチューナの仕事である。これらのビューを配置するとき、各ストアは、図示されているようにビュー記憶バジェットを有し、また、ストア間にまたがってビューを移動するときの転送バジェットがある。これらのバジェットは、記憶および転送することができるビューの総サイズを制限する。

本発明者らのシステムにおける主なデータソースは、大きなログファイルである。ここで、本発明者らは、Ｔｗｉｔｔｅｒ、Ｆｏｕｒｓｑｕａｒｅ、Ｉｎｓｔａｇｒａｍ、Ｙｅｌｐなどのサイトから引き出されたソーシャルメディアデータを予想する。このタイプのデータは、主として、ほとんど構造をもたないテキストベースのものである。ログは、ｊｓｏｎ、ｘｍｌ、ＣＳＶなどテキストベースのフォーマット、または、ＬＯＧ４Ｊファイルなど完全な非構造化フォーマットで、フラットなＨＤＦＳファイルとしてＨＶ内に記憶される。

システムへの入力は、クエリのストリームである。クエリ原語はＨｉｖｅＱＬであり、これは、Ｈｉｖｅ（ＨＶ）によって実装されるＳＱＬのサブセットを表す。クエリは宣言型であり、関心のあるログスキーマがクエリ自体の中で指定され、クエリ実行中に抽出されるように、ログデータに対して直接提出される。ＨＶでは、フラットデータをテキストファイルから抽出することは、特定のフラットファイルフォーマット（たとえば、ｊｓｏｎ）からデータフィールドをどのように抽出するか理解しているＳｅｒＤｅ（シリアライズ／デシリアライズ）関数によって行われる。クエリは、リレーショナル演算と、ユーザ定義の関数（ＵＤＦ）を示す任意のコードとを含むことができる。ＵＤＦは、いくつかの言語（たとえば、Ｐｅｒｌ、Ｐｙｔｈｏｎ）で提供され得る任意のユーザコードであり、ＵＤＦは、ＨＶ内でＨａｄｏｏｐジョブとして実行される。クエリは、ログを直接参照し、ＨｉｖｅＱＬで書かれ、システムは、クエリ部分式をＤＷ内で実行するとき、クエリ部分式をＤＷ準拠のクエリに自動的に変換する。処理ロケーション（ＤＷまたはＨＶ）は、エンドユーザから隠され、エンドユーザは、単一のストアに照会している印象を有する。

実行レイヤ構成要素は、クエリオプティマイザによって生成される実行プランの各構成要素を適切なストアに転送する責任を担う。マルチストア実行プランでは、データおよび計算が、一方のストアから他方のストアに移行されるプラングラフ内のカットを示す「分割点」を含むとすることができる。ＤＷがＨＶクエリのためのアクセラレータとして使用されるので、プラン内の分割により、データおよび計算は、一方向、すなわち、ＨＶからＤＷに移動する。マルチストアクエリオプティマイザのジョブ（次に述べる）が、プランについて分割点を選択する。一例として、並んでいる図は、３つのパネルを有し、実行プラン（ＤＡＧとして表されている）、次いでカットによって示されている２つの可能な分割点を示す。各分割点にて、実行レイヤは、中間データ（すなわち、カットの上方でオペレータの出力に対応するワーキングセット）を移行し、新しいストア上でプランの実行を再開する。第２のパネルでは、１つの中間データセットが実行レイヤによって移行される必要があり、一方、第３のパネルでは、２つの中間データセットが実行レイヤによって移行される必要があることに留意されたい。中間データセットは、クエリ実行中に移行されるとき、一時的なＤＷテーブル空間に記憶され（すなわち、分類されない）、クエリの終了時に破棄される。実行レイヤは、チューナによって物理設計に対する変更が要求されたときに、ビューの移動を編成する責任をも担う。ビューは、チューニング中に移行されるとき、恒久的なＤＷテーブル空間に記憶され、次のチューニング段階まで物理設計の一部となる。

マルチストアクエリオプティマイザ構成要素は、クエリを入力としてとり、クエリのためにマルチストア実行プランを計算する。プランは、複数のストアにまたがり、必要に応じてデータを移動させて計算することができ、各ストアの物理設計を使用する。複数のストアにまたがるオプティマイザの設計は、ストア間の共通のコスト単位（予想実行時間）に基づかなければならず、したがって各特定のストアについて何らかの単位標準化が必要とされる。本発明者らのマルチストアコスト関数は、３つの構成要素、すなわち、ＨＶ内のコスト、ストア間にまたがってワーキングセットを転送するためのコスト、およびＤＷ内のコストを、標準化された単位で表して考慮する。本発明者らは、各システムのコスト単位をクエリ実行時間に対して較正するための実験を実施した。結局の所、必要なデータがＤＷ内に存在する場合には、ＤＷ内で実行することが、常に非常に広いマージンで、より速かった。これらのストアは、非常に非対称的な性能を有するので、ＨＶ単位がＤＷ単位より完全に優位を占め、単位の粗い較正／標準化でも本発明者らの目的に十分なものになる。

分割点の選択は、クエリ実行時間に影響を及ぼすので、正しい分割点を選択することが重要である。マルチストアクエリオプティマイザは、論理的な実行プランに基づいて分割点を選択し、次いで得られたサブプランをストア特有のオプティマイザに委任する。クエリ部分式が実行されるストアは、各ストア内に存在する具体化されたビューに応じて決まる。さらに、分割点を決定するとき、オプティマイザは、ＨＶ内でのみ実行することができるＵＤＦなど、各ストアについて有効な演算をも考慮しなければならない。クエリ部分式をあるストアから別のストアに移動することは、データをあるストアから別のストアに転送およびロードするためのコストに、部分式を他方のストア内で実行するコストを加えたものが、現在のストア内で実行を続けるより少ないときだけ、直ちに有益である。さらに、ストア間の非対称的な性能により、本発明者らは、部分式によって必要とされるデータ（ビュー）がＤＷ内にすでに存在するとき、部分式の実行コストはＤＷ内の方が常に低いことに気付いた。マルチストアクエリオプティマイザにとっての主な挑戦課題は、クエリのワーキングセットのデータサイズが、ＨＶ内で実行を続けるのではなく、ＤＷに転送およびロードするのに「十分小さい」ものになる実行プラン内の点を決定することである。

本発明者らの実装では、オプティマイザに、各ストアについて仮想物理設計を考えて、マルチストアプランのコストを評価する「ｗｈａｔ−ｉｆ」モードを追加することができる。オプティマイザは、ＭＩＳＯチューナによって考慮される仮想物理設計を評価するために、［１４］からの書換えアルゴリズムを使用する。

ＭＩＳＯチューナ構成要素は、定期的に起動され、ワークロードの「最新の特質」に基づいて各ストア内の具体化されたビューを再編成する。チューナは、いくつかの候補の設計を調べ、ｗｈａｔ−ｉｆオプティマイザを使用して、最近のクエリ（図２における履歴）のスライディングウィンドウ上でのそれらの利益を解析する。次いで、選択された設計が実行レイヤに転送され、次いで実行レイヤは、新たに計算された設計に従ってビューをＨＶからＤＷへ、またＤＷからＨＶへ移動する（図２に示す）。本発明者らが再編成段階と呼ぶＭＩＳＯチューナの起動は、時間ベース（たとえば、１時間ごと）、クエリベース（たとえば、クエリごと）、活動ベース（たとえば、システムがアイドルであるとき）、または上記の組合せとすることができる。本発明者らのシステムでは、再編成はクエリベースである。

ビュー転送バジェットは、ストア間の矢印によって示されている。これは、再編成段階中にストア間でＧＢ転送されるビューの合計のサイズを表し、チューナに対する制約として提供される。ＨＶビュー記憶バジェットおよびＤＷビュー記憶バジェットもまた図に示されており、同様にチューナに対する制約として提供される。これらは、各ストア内のビュー群についてＧＢで割り振られた記憶総量を表す。ＤＷは、厳しく管理されるストアを表すが、ＨＶ展開は、一般にそれほど厳しく管理されず、ＤＷより多くの予備の能力を有することがある。これらの理由のために、再構成間にＨＶ内で作成される新しい日和見的ビューは、次にＭＩＳＯチューナが起動されるときまで保持され、一方、ＤＷ内のビューのセットは、再編成段階中を除いて変更されない。Ｈａｄｏｏｐ構成では、通常動作中にこれらの具体化物を保持するための一時記憶空間が十分にあるはずであり、本発明者らは、少しだけ長く−次の再編成段階までそれらをとっておくことを提案するにすぎない。ＨＶビュー記憶バジェットはチューニング時に施行されるだけなので、システムが限定的な一時空間を有する場合、いくつかの単純なポリシを考慮することができる。すなわち、再編成をより頻繁に行うことができ、または単純なＬＲＵポリシを一時空間に適用することができ、またはＨＶビュー記憶バジェットの少量を追加の一時空間として予約しておくことができる。

本発明者らの設計の要素は、具体化されたビューであり、ビューの母集団は、Ｖとして示される。各ストアの物理設計は、ＨＶについてＶ_h、ＤＷについてＶ_dとして示される。ここで、Ｖ_h，Ｖ_d⊆Ｖである。値Ｂ_h、Ｂ_dは、それぞれＨＶ、ＤＷについてのビュー記憶バジェットの制約を示し、再編成段階のためのビュー転送バジェットは、Ｂ_tとして示される。前述のように、再編成段階は定期的に発生し（たとえば、ｊ個のクエリがシステムによって観察された後）、その時点で、ビューがストア間で転送されてもよい。制約Ｂ_h、Ｂ_d、およびＢ_tは、ＧＢで指定される。

Ｍ＝＜Ｖ_h，Ｖ_d＞をマルチストア設計とする。Ｍは、第１の構成要素がＨＶ内のビュー群を表し、第２の構成要素がＤＷ内のビュー群を表す対である。本発明では、本発明者らは、２つのストアだけを含むように定義を制限するが、この定義は、より一般的な場合において追加ストアを含むように拡張されてもよい。

本発明者らは、入力ストリームの直近のｎ個のクエリをワークロードＷとして示す。クエリｑ_iは、Ｗ内のｉ番目のクエリを表す。マルチストア設計Ｍを考えてのクエリｑのコストは、ｃｏｓｔ（ｑ，Ｍ）で示され、仮想設計Ｍ下でのＨＶ内のコスト、ｑのワーキングセットをＤＷに転送するためのコスト、およびＤＷ内のコストの和である。本発明者らがマルチストア設計Ｍについて使用する評価メトリックは、下式のように定義される総ワークロードコストである。

直感的に、このメトリックは、ワークロード内のクエリすべてを処理するための総時間の和を表す。これは理にかなったメトリックであるが、他のものも可能である。このメトリックは、再編成制約Ｂ_tを含まないことに留意されたい。なぜなら、再編成制約Ｂ_tはこの問題への入力として提供されるからである。ｑクエリについてのビューｖ∈Ｖの利益（ｂｅｎｅｆｉｔ）は、ビューｖがマルチストア設計内にある状態およびない状態で評価されるｑのコストの変化としておおまかに定義される。形式的には、ｂｅｎｅｆｉｔ（ｑ，ｖ）＝ｃｏｓｔ（ｑ，Ｍ∪v）−ｃｏｓｔ（ｑ，Ｍ）であり、Ｍ∪vは、ｖがＭ内の両ストアに追加されることを意味する。

クエリｑについて、１対のビュー（ａ，ｂ）が、ｑについてのそれらの利益に関して互いに相互作用し得る。この相互作用は、ｂが存在するとき、ｑについてのａの利益が変化すると発生する。本発明者らは、利益変化の大きさの尺度である［１９］に定義されている相互作用度（ｄｅｇｒｅｅ ｏｆ ｉｎｔｅｒａｃｔｉｏｎ：ｄｏｉ）を使用する。さらに、ｂに対するビューａについての相互作用のタイプは、正でも負でもよい。正の相互作用は、ｂが存在するときａの利益が増大すると発生する。具体的には、ａおよびｂは、両方を使用することの利益がそれらの個々の利益の和より高いとき正方向に相互作用すると言われる。この場合には、ａおよびｂを共にナップサックに詰めたいと望む。負の相互作用は、ｂが存在するときａの利益が減少すると発生する。例として、ａまたはｂを使用し、ｑに回答すると仮定してみる。したがって、どちらも個々にｑにとって有益であるが、ａがわずかに大きな利益をもたらすと仮定してみる。両ビューが存在するとき、オプティマイザは、常にａを好むことになり、したがってｂを決して使用せず、その場合、ｂの利益はゼロになる。この場合、ａおよびｂを共にナップサックに詰めると、ビュー記憶バジェットを非効率的に使用することになる。本発明者らは、後記の解決策を定式化するとき、ｄｏｉとビュー間の相互作用のタイプとを共に使用する。

マルチストア設計問題
観察されたクエリストリーム、マルチストア設計Ｍ＝＜Ｖ_h，Ｖ_d＞、および設計制約Ｂ_h、Ｂ_d、Ｂ_tのセットを考えて、これらの制約を満たし、将来のワークロードコストを最小限に抑える新しいマルチストア設計

を計算する。ただし

である。

一実施形態は、ビュー相互作用を扱い両ストアの物理設計を解決するようにヒューリスティックな手法を使用する。このセクションでは、本発明者らは、ヒューリスティクスに刺激を与え、それを展開し、次いで、この実験的なセクションの後の方で、同様のチューニング手法に比べて本発明者らの手法が著しい利益をもたらすことを示す。

本発明者らが対処するワークロードは、本質的にオンラインであり、したがって、最近のワークロードを反映するように設計をチューニングするために、再編成は定期的に行われる。本発明者らの手法は、ワークロードが与えられる静的な最適化問題を定期的に解くことによって、良好なマルチストア設計を得ることである。各再編成段階中に、チューナは、本発明者らのコストメトリックＴｏｔａｌＣｏｓｔ（Ｗ，Ｍ^new）によって計算される総ワークロードコストを最小限に抑える新しいマルチストア設計

を計算する。ここで総ワークロードコストを最小限に抑えることは、代表的なワークロードＷについてＭ^newの利益を最大限にすることに等しい。ＭＩＳＯチューナアルゴリズムは次の通りである。

最初の２ステップは、ビュー間の相互作用を、新しい設計を計算する前の前処理ステップとして扱う。チューナアルゴリズムは、現在の設計Ｖ_hおよびＶ_d内のビューすべてを相互作用セットにグループ化することによって始まる。このステップの目標は、Ｖ内の他のビューと強い正または負の相互作用を有するビューを識別することである。このステップの終わりにはビューの複数のセットがあり、セット内のビューは互いに強く相互作用し、異なるセットに属するビュー同士は強く相互作用しない。本発明者らは、ビューのいくつかを保持し、他のビューを破棄することによって各セットを疎らにする。セットを疎らにするために、本発明者らは、セット内の相互作用するビュー同士の性質が正か、それとも負かを考える。相互作用するビュー同士の性質が強く正である場合には、ヒューリスティックとして、それらのビューは、それらがすべて存在するとき追加の利益を提供するので、常に一緒に考慮するべきである。それらのビューのうち、本発明者らは、それらすべてを単一の候補として扱う。相互作用するビュー同士の性質が強く負である場合には、それらのビューは、それらのすべてが存在するとき追加の利益がほとんどないため、Ｍ^newのために一緒に考慮するべきでない。それらのビューのうち、本発明者らは、代表的なビューを候補として選択し、残りを破棄する。前処理ステップが完了した後で、得られた候補ビューＶ_candsのセットは、２つの多次元ナップサック問題を順次解くことによって行われる、新しいマルチストア設計を計算するとき独立して考慮することができるビューを含む。各ナップサックの次元は、記憶バジェット制約および転送バジェット制約である。ビュー記憶バジェットＢ_dおよびビュー転送バジェットＢ_tを使用して、ＤＷについてナップサックのインスタンスを解く。このステップの出力は、新しいＤＷ設計

である。次いで、ビュー記憶バジェットＢ_hと、ＤＷ設計を解決した後に残っているビュー転送バジェット

とを使用して、ＨＶについてナップサックのインスタンスを解く。このステップの出力は、新しいＨＶ設計

である。ＤＷ設計を最初に解決する理由は、正しいビューが存在するとき、優れた実効性能を提供することができるからである。良好なＤＷ設計の場合、クエリ処理は、より早くＤＷに移行し、したがってそのクエリ処理パワーを利用することができる。この理由のために、ＤＷ設計を主な目標として注目し、これを第１の段階で解決する。ＤＷ設計が選択された後、第２の段階でＨＶ設計が解決される。この２段階手法で、ＨＶおよびＤＷの設計は、補足的なものと見ることができるが、ヒューリスティックとして、ＨＶより大きな重要性をＤＷに与えるように定式化することができる。

次に、ビュー相互作用を考慮するための本発明者らのヒューリスティック解決策について述べる。なぜなら、それらはナップサックの詰込みに影響を及ぼす可能性があるからである。たとえば、ｖ_aがすでに詰められており、ｖ_bが追加される場合には、ｖ_aとｖ_bの間に相互作用がある場合、ｖ_aの利益は、ｖ_bが追加されたとき変化することになる。本発明者らのヒューリスティック手法は、Ｖ内のビューの中での最も強い相互作用だけを考慮して候補ビューのセットを生成し、それにより、ナップサック問題を解くとき、各ビューの利益を独立したものとして扱うことができる。これは、動的なプログラミングでの定式化では、ナップサック内にすでにあるアイテムの利益が、新しいアイテムが追加されたときに変化しないことが必要とされるからである。本発明者らは、下記で述べるように、２ステップ手法を使用し、ナップサックの詰め込み中に使用されることになる候補ビューＶ_candsを生成する。

相互作用セットを計算する前に、最初に、予想される将来の利益関数を使用することによって、各ビューの予想利益を計算する。この利益関数は、それぞれがＷの全長の一部分である一連の重なり合わないエポックにＷを分割する。これは、最近のクエリ履歴を表す。この方法では、各ビューの予想される将来の利益を、エポックごと、各ｑ∈Ｗについてのビュー、の利益に対して減衰させることによって計算され、クエリｑについてのビューｖの利益は、ｑがずっと過去に現れたので、より軽く扱われる。計算の成果は、過去の複数のウィンドウにわたるｖの利益の滑らかな平均化である。このようにして、利益計算は、より長いワークロード履歴を取り込むが、将来のワークロードについての中間的な利益をより代表するものとして、最近の履歴を好む。

相互作用セットを見つけ出すために、本発明者らは、部分Ｐ_i内のビューが別の部分Ｐ_j内のビューと相互作用しないことを意味する候補ビューＶの安定な区画Ｐ≡｛Ｐ₁，Ｐ₂，．．．，Ｐ_m｝を生成する。この方法では、各部分Ｐ_i内のビュー間の相互作用の大きさ（すなわち、利益の変化）は、ｄｏｉによって取り込まれる。ｄｏｉを計算するとき、本発明者らは、相互作用が正であるか、それとも負であるかを示す利益変化の符号を保持するように計算をわずかに修正する。正の相互作用と負の相互作用を共に有する１対のビューについては、大きさは相互作用同士の和であり、和の符号は、正味の正であるか負であるかを示す。区分する手順は、最も有意なビュー相互作用、すなわち、何らかの選択された閾値を超える大きさを有するものだけを保存する。この閾値は、弱い相互作用を無視する効果を有する。閾値の値は、システムおよびワークロードに依存するが、少数（たとえば、本発明者らの場合４つ）のビューを有する、したがって最も強い相互作用のビューだけを保持する部分群をもたらすように、十分大きなものとすべきである。

これらの部分は重なり合わない（すなわち、ビュー同士が部分間にまたがって相互作用しない）ので、各部分は、ｍナップサックに詰めるときに独立して考慮されてもよい。これは、Ｐ_i≠Ｐ_jである場合、部分Ｐ_i内のビューの利益が部分Ｐ_j内のどのビューの利益によっても影響を受けないからである。しかし、この時点で、いくつかの部分は１より大きなカーディナリティを有することがあり、このため、同じ部分内のビューの中で代表的なビューを選択するための方法について次に述べる。

これらの部分を指定するために、最初に、正方向に相互作用するビュー、次いで負方向に相互作用するビューを考慮に入れる。本発明者らは、ヒューリスティックを適用し、大きな正の相互作用を有するビューがナップサック内に共に詰められることを確実にすることによって、正の相互作用を利用する。各部分内では、正の相互作用を有するビュー対同士が単一のナップサックアイテムに「統合」される。なぜなら、これらのビュー対は、共に使用されたときに著しい追加の利益をもたらすからである。この新しいアイテムは、両ビューのサイズの和に等しい重みを有し、利益は、両ビューが共に使用されたときの総利益である。この統合手順は、各部分内の正方向に相互作用する対すべてに対して、エッジ重みの大きなものから再帰的に適用される。統合は、その部分内に正方向に相互作用するビューの対がそれ以上なくなるまで続行する。

統合手順を適用した後、１より大きなカーディナリティを有する部分はすべて、強く負の相互作用をするビューだけを含む。本発明者らの次のヒューリスティックは、これらのビューを一緒にナップサック内に詰めず、それらの１つを、その部分を代表するものとして選択することである。これは、これらのビューを一緒に詰めることが、ナップサック容量を非効率的に使用することであるからである。代表を選択するために、本発明者らは、重みの単位当たりの利益を低減することによって部分内のアイテムを順序付け、先頭のアイテムをその部分を代表するものとして保持するだけである。この欲張りなヒューリスティックは、物理設計に対するナップサック手法に一般的に使用されており、本発明者らはここでそれを使用し、ある部分内で強い負の相互作用を有するビューの中から選択する。この手順は、すべての部分が単一の代表的なビューを有するまで、各部分に適用される。これらのステップの後、得られる区画Ｐは、単集合の部分だけを含む。これらの部分はＶ_candsを形成し、ｍナップサックによって独立したものとして扱われる。

各再編成ウィンドウ中には、ＭＩＳＯチューナは、０−１多次元ナップサック問題（以下、ｍナップサック）の２つのインスタンス、すなわち、ＤＷのための第１のインスタンス、およびＨＶのための第２のインスタンスを解決する。各インスタンスは、動的なプログラミングの定式化を使用して解決される。各再編成ウィンドウの開始時には、Ｖ_hは、以前の再編成ウィンドウ中にＭＩＳＯチューナによってＨＶ設計に追加されたすべてのビュー、ならびに、最後の再編成以降作成されたＨＶ内の任意の新しい日和見的ビューを含むことに留意されたい。再編成中には、ＭＩＳＯチューナは、ＨＶおよびＤＷのためにそれぞれ新しい設計

および

を計算する。ＤＷはより良好なクエリ性能を有するので、最初のヒューリスティックとして、ＭＩＳＯは、ＤＷインスタンスを最初に解決し、最良のビュー群がＤＷ設計に追加されることになる。さらに、本発明者らは、ストア間にまたがってビューを複製することを防止するためにＶ_h∩Ｖ_d＝Φを確保する。これもまたヒューリスティックであるが、本発明者らの論理的根拠は、これが具体化されたビューのより「多様な」セットをもたらし、したがって未知の将来のワークロードについて準備する際に限られた記憶バジェットをよりよく利用することになる可能性があることである。望むなら、この特性は、ＨＶおよびＤＷを共に詰めるとき、Ｖ_cands内のビューすべてを含めることによって和らげることができる。

追加のヒューリスティックとして、本発明者らは、最初の段階でＤＷ設計を解決するとき消費することができるＢ_tの一部分を制限しない。次いで、任意の残りの転送バジェット

を使用し、ＤＷから立ち退かされたビューをＨＶに転送する。これは、転送バジェットのすべてが、ビューをＤＷに転送する最初の段階中に消費される可能性があることを意味する。あるいは、各方向で転送するためにＢ_ｔの一部分を予約することができるが、これもまたヒューリスティックになろう。

この段階では、目標の設計は

であり、ｍナップサック次元は、Ｂ_dおよびＢ_tである。ＤＷを詰めるときに考慮すべき２つの場合がある。ＨＶ（Ｖ_h）内のビューは転送バジェットＢ_tを消費することになる場合（場合１）、ＤＷ（Ｖ_d）内のビューは消費しない場合（場合２）である。候補ビューはＶ_cands＝Ｖ_h∪Ｖ_dである。変数ｋは、Ｖ_cands内のｋ番目の要素を示し（すなわち、ビューｖ_k）、要素の順序は無関係である。再帰関係Ｃは、以下の２つの場合によって与えられる。

場合１：ビューｖ_kがＨＶ内にあるときｖ_k∈Ｖ_hが当てはまる。

このとき、どちらかの要素ｋがＢ_tに収まらない（ｓｚ（ｖ_k）＞Ｂ_tであるため）場合、要素ｋをとばし、続行する。ｋがＢ_tおよびＢ_dに収まる（ｓｚ（ｖ_k）Ｂ_tおよびｓｚ（ｖ_k）Ｂ_dであるため）場合、（ａ）要素ｋをとばし、続行する、または、（ｂ）要素ｋをｍナップサックに追加し、そのサイズをＢ_tおよびＢ_dから減算し、その利益を累積し（ｂｎ（ｖ_k））、続行する、の最大値をとる。

場合２：ビューｖ_ｋがＨＶ内にないとき、

が当てはまる。

このとき、どちらかの要素ｋがＢ_ｄに収まらない（ｓｚ（ｖ_k）＞Ｂ_dであるため）場合、要素ｋをとばし、続行する。ｋがＢ_dに収まる（ｓｚ（ｖ_ｋ）Ｂ_dであるため）場合、（ａ）要素ｋをとばし、続行する、または（ｂ）要素ｋをｍナップサックに追加し、そのサイズをＢ_dから減算し、その利益を累積し（ｂｎ（ｖ_k））、続行する、の最大値をとる。この最初の段階の終了時に、ＤＷの設計

が完了する。

この段階では、目標の設計は

であり、ｍナップサック次元は、Ｂ_dおよび

であり、

は、いまＨＶに転送して戻すために使用可能である、ＤＷから立ち退かされたビューを表す。解は、修正された入力を有する、段階１に対して対称的なものである。値Ｂ_tは、

に初期化される。候補ビューは、Ｖ_h内に残っているもの、およびＤＷから立ち退かされたものであり

、したがって

である。同様に、段階２で定義された、２つの場合がある。
場合１：ビューｖ_kがＤＷから立ち退かされたとき

が当てはまる。
場合２：ビューｖ_kがＤＷから立ち退かされなかったとき

が当てはまる。

前と同様に、これらの場合は、ビューを移動する必要があるか否かを示す。いま、段階１からの再帰関係をこれらの修正された場合と共に使用することができる。

本発明者らのナップサック手法の複雑さは、

であり、この式で、ｄは離散化係数（たとえば、１ＧＢ）を表す。記憶バジェットおよび転送バジェットを離散化することによって、この手法を、実用時に効率的なものにし、定期的に新しい設計を再計算することを必要とする本発明者らのシナリオに適したものにすることができる。

図３は、マルチストアシステムを再構成するための例示的なプロセスを示す。このプロセスは、最初にシステム上で新しいクエリＱを受け取る（１０２）。次いで、このプロセスは、２つのストアに対してクエリＱを実行する（１０４）。次に、このプロセスは、１０６で再構成が必要とされるかどうかチェックする。必要とされない場合には、このプロセスは１０２にループバックし、必要とされる場合には、このプロセスは、１０８で再構成を実施し、次いで１０６にループバックする。

図４は、マルチストアシステムを再構成するための例示的なプロセスを示す。このシステムでは、新しいクエリがシステム上で受け取られる（１２０）。次に１２０では、Ｖが既存のビューのセットであり、Ｑがそれらのビューを使用して書き換えられ、システムが、計算をリレーショナルデータベース管理システムにオフロードすることができるＱのプラン内の分割点のセットを見つけ出す。次いで、このプロセスは、それらの新しいビューに基づいてＶを更新する。このプロセスは、１２２から、再構成が必要とされるかどうかチェックする１２４に進む。必要とされない場合、このプロセスは、１２０にループバックする。必要とされる場合、このプロセスは、Ｂ＿ｈおよびＢ＿ｄが、両ストア内に現在存在するビューのセットであり、Ｂ＿ｔはこれらのストア間で移動するための転送バジェットである１２６に移動する。このプロセスは、１２６で、記憶バジェット制約および転送バジェット制約が満たされるように各ストアについてビューのサブセットを選択する。

図５は、ビューをマルチストアの要素として扱うための例示的なプロセスを示す。このプロセスは、既存のクエリ処理システムがビッグデータクエリ処理を高速化することを可能にする方法を含む（１４０）。また、このプロセスは、クエリ処理が高性能リレーショナルデータベース管理システムにオフロードされる方法をも含む（１４２）。また、このプロセスは、１４４で、日和見的ビューをマルチストアの物理設計の要素として使用する方法をも含む。また、このプロセスは、１４６で、どのビューを特定のストア内に所定の順序で配置するべきか決定するための方法をも含む。また、このプロセスは、１４８で、リレーショナルデータベース管理システムの既存のクエリが、ビューのための記憶バジェットおよび転送バジェットを制限することによって影響を受けない方法をも含む。また、このプロセスは、計算をリレーショナルデータベース管理システムに移動することができるクエリの分割点を判断する方法をも含む（１５０）。また、このプロセスは、１５２で、過去の最近のワークロードを見ることに基づいてビューを移動する方法をも含む。

図６は、マルチストア設計を作成するための例示的なプロセスを示す。この方法は、ストア間にまたがって既存のビューのセットＶを受け取る（２０２）。次に、ナップサックベースの方法を使用して、このプロセスは、２０４で、現在のストア内で保持するためのビューのサブセット、ストア間にまたがって転送するためのビューのサブセット、および、ドロップするためのビューのサブセット、を選択する。このプロセスは、２０６で、新しいマルチストア設計に到達する。

図７は、マルチストア設計を作成するための別の例示的なプロセスをより詳細に示す。このプロセスでは、既存のビューのセットＶがストア間にまたがって提供される（２１０）。このプロセスは、２１２で、強く相互作用するビューを、正および負共に解決する。次に、このプロセスは、２１４で、転送バジェット内でナップサックの詰込みを使用して、リレーショナルデータベース管理システムに最も有益なビューを詰める。次に、このプロセスは、２１６で、ビッグデータストアに残りのビューを残りの転送バジェットで詰める。次いで、このプロセスは、２１８で、どのナップサックにも詰められなかったビューを破棄する。次いで、このプロセスは、２２０で、新しいマルチストア設計を生成する。

図８は、マルチストア設計を作成するための別の例示的なプロセスをより詳細に示す。最初に、このプロセスは、２３０で、ストア間にまたがって既存のビューのセットＶを受け取る。次に、このプロセスは、２３２で、バジェットおよび履歴データ、たとえばビッグデータストアバジェット、ＲＤＢＭＳストアバジェット、転送バジェット、および最後のｈ個のクエリの履歴を更新する。また、このプロセスは、以下を実施する。
２３４で、互いに強く相互作用しているビューのサブセットの中で、
・ 負の相互作用について、これらのビューの中の１つをナップサックの詰込みのためのアイテムとして選択する。
・ 正の相互作用について、それらをナップサックの詰込みのための単一のアイテムになるように統合する。
２３６で、このプロセスは、以下を実施する。
・ 記憶バジェットＢ_dおよび転送バジェットＢ_tでＲＤＢＭＳのためのナップサックの詰込み
・ アイテムＶ_iの値はＣＯＳＴ（Ｖ_i，Ｑ）であり、記憶容量ＳＩＺＥ（Ｖ_i）を消費する。
・ 現在ビッグデータストア内に存在する場合、転送バジェットＳＩＺＥ（Ｖ_i）を消費する。
２３８では、このプロセスは、
・ 詰込みに使用可能な残りのアイテムを考慮し、
・ 記憶バジェットＢ_dおよび任意の残りの転送バジェットでＲＤＢＭＳのためのナップサックの詰込みを実施し、
・ アイテムＶ_iの値はＣＯＳＴ（Ｖ_i，Ｑ）であり、記憶容量ＳＩＺＥ（Ｖ_i）を消費する。

さらに、現在ＲＤＢＭＳ内に存在する場合、転送バジェットＳＩＺＥ（Ｖ_i）を消費する。次いで、このプロセスは、２４０で、どのナップサックにも詰められなかったビューを破棄する。このプロセスは、２５０で、新しいマルチストア設計を生成する。

図９は、データベース管理のためのシステム内で使用される方法を示す。このシステムは、２６２で、どのビューをどのストア内に配置するべきか、またどのビューを破棄するべきか判断する方法を含む。また、このプロセスは、２６４で、所与の記憶バジェットについて最も有益なビューのセットを判断する方法をも含む。また、このプロセスは、２６６で、ストア間にまたがって転送するために最も有益なビューのセットを判断する方法をも含む。また、このプロセスは、２６８で、ＲＤＢＭＳにとって最も有益なビューが最初に選択される方法をも含む。また、このプロセスは、２７０で、ビッグデータストアのためのビューが次に選択される方法をも含む。また、このプロセスは、２７２で、ビュー間の相互作用が扱われる方法をも含む。また、このプロセスは、２７４で、動的なプログラミング解決策を使用し、両ストアを詰める方法をも含む。

本発明は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実装されてよい。本発明は、プロセッサと、データ記憶システムと、揮発性および不揮発性メモリおよび／または記憶要素と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを有するプログラム可能なコンピュータ上で実行されるコンピュータプログラムで実装されることが好ましい。

例として、システムをサポートするためのコンピュータのブロック図について次に論じる。コンピュータは、ＣＰＵバスによって結合されたプロセッサと、ランダムアクセスメモリ（ＲＡＭ）と、プログラムメモリ（好ましくは、フラッシュＲＯＭなど書込み可能な読出し専用メモリ（ＲＯＭ））と、入力／出力（Ｉ／Ｏ）コントローラとを含むことが好ましい。コンピュータは、任意選択で、ハードディスクおよびＣＰＵバスに結合されるハードドライブコントローラを含んでもよい。ハードディスクを使用し、本発明などアプリケーションプログラム、およびデータを記憶してもよい。あるいは、アプリケーションプログラムは、ＲＡＭまたはＲＯＭ内に記憶されてもよい。Ｉ／Ｏコントローラは、Ｉ／ＯバスによりＩ／Ｏインターフェースに結合される。Ｉ／Ｏインターフェースは、シリアルリンク、ローカルエリアネットワーク、ワイヤレスリンク、およびパラレルリンクなど通信リンクを介して、アナログまたはデジタル形態でデータを受信および送信する。任意選択で、ディスプレイ、キーボード、およびポインティングデバイス（マウス）もまたＩ／Ｏバスに接続されてよい。あるいは、別個の接続部（別個のバス）を、Ｉ／Ｏインターフェース、ディスプレイ、キーボード、およびポインティングデバイス用に使用してもよい。プログラム可能な処理システムは、事前にプログラムされていても、プログラムを別のソース（たとえば、フロッピディスク、ＣＤ−ＲＯＭ、または別のコンピュータ）からダウンロードすることによってプログラム（および再プログラム）されてもよい。

各コンピュータプログラムは、本明細書に記載の手順を実施するために記憶媒体またはデバイスがコンピュータによって読み取られたときコンピュータの動作を構成および制御するために汎用または専用のプログラム可能なコンピュータによって読取り可能な機械可読記憶媒体またはデバイス（たとえば、プログラムメモリまたは磁気ディスク）内に有形に記憶される。また、本発明のシステムは、コンピュータプログラムで構成されたコンピュータ可読記憶媒体内に含まれるものとみなされてよく、そのように構成された記憶媒体は、本明細書に記載の機能を実施するように特定の、事前に定義された形でコンピュータを動作させる。

当業者なら、いまや前述の説明から、本発明の広い教示を様々な形態で実施することができることを理解することができる。理解できるように、開示され特許請求されている方法のステップは、本発明の精神から逸脱することなしに本明細書で開示され特許請求されているものとは異なる順序で実施することができる。したがって、本発明について、その特定の例と共に述べたが、図面、明細書、および以下の特許請求の範囲を検討すれば、当業者には他の修正形態が明らかになるので、本発明の真の範囲は、そのように限定されるべきでない。

Claims (20)

1. マルチストアシステムを動作させるための方法であって、
   前記マルチストアシステム内のクエリ処理の副産物を受け取り、前記副産物が、ビューまたは中間データの具体化されたものを含むことと、
   前記ビューまたは具体化されたものを、将来のクエリワークロードを示すものとして最近観察されたクエリに基づいて、前記ストア間にまたがって配置することと、
   予測された、クエリの将来のワークロードに基づいて、各ビューについて利益スコアを決定し、各ストアにはビュー記憶バジェットが割り振られ、前記ストア間でビューを転送するためにビュー転送バジェットがあることと、
   前記マルチストアシステムの物理設計をチューニングすることを含む方法。
2. すべてのバジェット内で最終的なビュー配置に収まり、前記将来のクエリワークロードのコストを最小限に抑えるように、前記ストア間でビューを転送することを含む、請求項１に記載の方法。
3. 各バジェットが一意の値を含む、請求項１に記載の方法。
4. ビューの統一セットを、各ストア内にあるビューすべての和集合として考慮することを含む、請求項１に記載の方法。
5. 各ストア内に配置されるべきビューのサブセットを含む解を生成することを含む、請求項１に記載の方法。
6. 最初に高性能ストアのためのビュー配置を解決することを含む、請求項１に記載の方法。
7. 前記高性能ストアに転送する（またはその中で保持する）ために、将来のワークロードにとって最も有益となるビューを決定することを含む、請求項６に記載の方法。
8. 前記高性能ストアについて解が計算され、前記解が、前記高性能ストア内に配置するための前記ビューのセットである、請求項１に記載の方法。
9. 前記高性能ストアについての前記解が、前記高性能ストアのためのビュー記憶バジェット、およびビュー転送バジェットより小さい、請求項１に記載の方法。
10. 第２のストアについて解を決定することを含む、請求項１に記載の方法。
11. 前記高性能ストアのためのビュー記憶バジェットより小さく、前記高性能ストアのための前記解によって消費されなかった残りのビュー転送バジェットより小さいコストで、前記第２のストアについて解を決定することを含む、請求項１に記載の方法。
12. どのビューをどのストア内に配置するべきか、またどのビューを破棄するべきか判断することを含む、請求項１に記載の方法。
13. 所与の記憶バジェットについて最も有益なビューのセットを判断する、請求項１に記載の方法。
14. ストア間にまたがって転送するために最も有益なビューのセットを判断することを含む、請求項１に記載の方法。
15. ＲＤＢＭＳにとって最も有益なビューを選択することを含む、請求項１に記載の方法。
16. 前記ビッグデータストアのためのどのビューが次に選択されるか決定することを含む、請求項１に記載の方法。
17. ビュー間の相互作用を扱うことを含む、請求項１に記載の方法。
18. 動的なプログラミング解決策を使用し、両ストアを詰める、請求項１に記載の方法。
19. プロセッサと、
    コンピュータ可読コードとを備えており、前記コンピュータ可読コードが、
    前記マルチストアシステム内のクエリ処理の副産物を受け取り、前記副産物が、ビューまたは中間データの具体化されたものを含むこと、
    前記ビューまたは具体化されたものを、将来のクエリワークロードを示すものとして最近観察されたクエリに基づいて、前記ストア間にまたがって配置すること、
    予測された、クエリの将来のワークロードに基づいて、各ビューについて利益スコアを決定し、各ストアにはビュー記憶バジェットが割り振られ、前記ストア間でビューを転送するためにビュー転送バジェットがあること、および、
    前記マルチストアシステムの物理設計をチューニングすることのためのものである、マルチストアシステム。
20. すべてのバジェット内で最終的なビュー配置に収まり、前記将来のクエリワークロードのコストを最小限に抑えるように、前記ストア間でビューを転送することを含む、請求項１９に記載のシステム。

Images