JP6639420B2 - フラッシュ最適化データ・レイアウトのための方法、フラッシュ最適化記憶のための装置、およびコンピュータ・プログラム - Google Patents

Description

本発明は、クエリ処理の間に使用されるフラッシュ最適化データ（flash-optimizeddata）・レイアウトおよびデータ・アクセス・アルゴリズムに関する。

用語「ビッグ・データ」は、手持ちのデータベース管理ツールまたは従来のデータ処理アプリケーションを使用して処理するのが困難になる、非常に大きく、かつ複合的なデータセットの任意の集合に対する広い用語として作られ、すぐに受け入れられてきた。課題は、取得、整理、記憶、検索、共有、転送、分析および視覚化を含む。より大きなデータセットに向かう傾向は、データの全体量が同一である別個のより小さなセットと比較して、単一の大きな関連データセットを分析することで追加の情報が導出可能なことに起因しており、相関関係を発見して、ビジネスの動向をつかみ、調査の品質を判定し、病気を防ぎ、法的引用をリンクし、犯罪に対処し、道路の交通状況をリアルタイムで判定することを可能にする。

２０１２年に、合理的な時間量で処理可能なデータセット・サイズの限界は、おおよそエクサバイトのデータ、すなわち、数百万テラバイトであった。科学者は、気象学、ゲノミクス、コネクトミクス、複雑な物理特性シミュレーション、ならびに生物学的および環境的調査を含む多くの分野において、大きなデータセットに起因する限界に時折直面する。こうした限界は、インターネット検索、財務、およびビジネス情報学にも影響を及ぼす。データセットは、サイズが増大している。これは、部分的には、ユビキタス情報検知モバイル・デバイス、エアリアル・センサ技術（リモート検知）、ソフトウェア・ログ、カメラ、マイクロフォン、無線周波数識別（ＲＦＩＤ）リーダ、および無線センサ・ネットワークによって、データセットがさらに収集され続けているためである。世界の技術的な一人当たり情報記憶容量は、１９８０年代以降おおよそ４０か月ごとに２倍になっている。２０１２年の時点では、毎日２．５エクサバイト（２．５×１０^１８）のデータが作成されていた。

ビッグ・データは、ほとんどの関係データベース管理システムならびにデスクトップ統計および視覚化パッケージと連動させるのが難しく、代わりに、何十、何百、またはさらには何千ものサーバで動作する大規模な並列ソフトウェアを必要とする。何が「ビッグ・データ」と考えられるかは、データセットを管理する組織の能力、ならびにその領域でデータセットを処理および分析するのに従来使用されているアプリケーションの能力に応じて変わる。一部の組織では、数百ギガバイトものデータに初めて直面することで、データ管理オプションを再検討する必要性が生じ得る。別の組織では、データ・サイズが重大な検討事項になる前に、数十または数百テラバイトを取り扱うことができる。ビッグ・データは通常、許容可能な経過時間内にデータを管理および処理するための一般的に使用されるソフトウェア・ツールの能力を超えたサイズを有するデータセットを含む。

ビッグ・データ・クエリ・エンジンのためのフラッシュ最適化列指向データ・レイアウト方法、装置、およびコンピュータ・プログラム（データ・アクセス・アルゴリズム）を提供することである。

一実施形態に従って、クエリに対するデータセットのフラッシュ最適化データ・レイアウトのための方法が提供される。方法は、プロセッサによって、選択最適化レイアウト（selection optimized layout）に従って、選択列をフラッシュ・メモリに記憶するステップを含み、選択最適化レイアウトは、述語マッチング（predicate matching）およびデータ・スキッピング（data skipping）を最適化するように構成される。選択最適化レイアウトは、選択列ごとに、一意なデータ値で満たされた選択列辞書を所与の選択列に記憶することによって形成され、一意なデータ値は、ソート順序で選択列辞書に記憶される。選択最適化レイアウトは、所与の選択列に２回以上現れる一意なデータ値のいずれも重複して記憶することなく、一意なデータ値が所与の選択列内に存在する各々の行位置に対応する行位置指定を記憶することによって形成される。

一実施形態に従って、クエリに対するデータセットのフラッシュ最適化記憶（flash-optimizedstorage）のための装置が提供される。装置は、プロセッサおよびコンピュータ実行可能命令を含むメモリを含み、コンピュータ実行可能命令は、プロセッサによって実行されるときに、プロセッサに動作を実行させる。動作は、プロセッサによって、選択最適化レイアウトに従って選択列をフラッシュ・メモリに記憶するステップを含み、選択最適化レイアウトは、述語マッチングおよびデータ・スキッピングを最適化するように構成される。選択最適化レイアウトは、選択列ごとに、一意なデータ値で満たされた選択列辞書を所与の選択列に記憶することによって形成され、一意なデータ値は、ソート順序で選択列辞書に記憶される。選択最適化レイアウトは、所与の選択列に２回以上現れる一意なデータ値のいずれも重複して記憶することなく、一意なデータ値が所与の選択列内に存在する各々の行位置に対応する行位置指定を記憶することによって形成される。

一実施形態に従って、クエリに対するデータセットのフラッシュ最適化記憶のためのコンピュータ・プログラム製品が提供される。コンピュータ・プログラム製品は、プログラム命令が具現化されたコンピュータ可読記憶媒体を含み、処理回路によって実行可能なプログラム命令は、処理回路に方法を実行させる。方法は、プロセッサによって、選択最適化レイアウトに従って選択列をフラッシュ・メモリに記憶するステップを含み、選択最適化レイアウトは、述語マッチングおよびデータ・スキッピングを最適化するように構成される。選択最適化レイアウトは、選択列ごとに、一意なデータ値で満たされた選択列辞書を所与の選択列に記憶することによって形成され、一意なデータ値は、ソート順序で選択列辞書に記憶される。選択最適化レイアウトは、所与の選択列に２回以上現れる一意なデータ値のいずれも重複して記憶することなく、一意なデータ値が所与の選択列内に存在する各々の行位置に対応する行位置指定を記憶することによって形成される。

追加の特徴および利点は、本発明の技術を通じて実現される。本発明の他の実施形態および態様は、本明細書で詳細に説明され、特許請求される発明の一部と考えられる。利点および特徴とともに本発明のさらなる良好な理解のために、詳細な説明および図面を参照する。

発明と見なされる主題は特に、本明細書の最後において特許請求の範囲で指摘され、明確に特許請求される。本発明の以下の特徴および他の特徴、ならびに利点が添付図面と併用される以下の詳細な説明から明らかである。

実施形態に従ったクラウド・コンピューティング・ノード／クラスタにおけるコンピュータ・システム／サーバの概略を示す図である。 実施形態に従った１つまたは複数のクラウド・コンピューティング・ノード／クラスタを有するクラウド・コンピューティング環境５０を示す図である。 実施形態に従ったコンピュータ・システム／サーバにおける特徴のさらなる詳細を示す図である。 ＴＰＣＨクエリでの個々の選択列の選択性を示すグラフである。 ＴＰＣＨクエリ６からの個々の選択列の選択性を示すグラフである。 実施形態に従って、テーブルが、ノード／クラスタでのコンピュータ・システム／サーバにわたる分散ファイル・システム（ＤＦＳ）ブロックにおける単一のＦｌａｓｈＱｕｅｒｙＦｉｌｅファイル／レイアウトとしてどのように論理的に表されるかを示す図である。 テーブルでデータ値を有する列および行の元の関係を示す図である。 実施形態に従った選択列に対する選択最適化レイアウトを示す図である。 実施形態に従った射影（projection）列に対する射影最適化レイアウトを示す図である。 実施形態に従った選択最適化レイアウトを利用する例を示す図である。 実施形態に従った低／中濃度列（cardinality columns）に対する射影最適化レイアウトの実装形態を示す図である。 実施形態に従った高濃度列に対する射影最適化レイアウトの実装形態を示す図である。 実施形態に従った射影もしくは選択列、またはその両方として使用することができる列に対するハイブリッド射影および選択レイアウトを示す図である。 実施形態に従った射影もしくは選択列、またはその両方として使用することができる最適化され、かつ空間効率のよい射影および選択レイアウトを示す図である。 実施形態に従った選択および射影列の両方としてポピュラ（popular）であり、選択最適化データ・レイアウトに記憶された列の例を示す図である。 実施形態に従った行グループにグループ化された行および列を示すテーブルである。 実施形態に従った正規化されたデータの読み取りの比較を示す図である。 実施形態に従った例示的なクエリの高速化を示す図である。 実施形態に従った処理の間のデータの読み取りの削減を示すグラフである。 実施形態に従ったデータセット・クエリのフラッシュ最適化データ・レイアウトのための方法を示すフローチャートである。

ペタバイトのデータに関するアドホックな対話式分析が急速に勢いを増しており、ビッグ・データのウェアハウスがますますポピュラになっている。アドホックなビッグ・データのクエリ処理の性能は、記憶性能に大きく左右される。特殊列指向（columnar）および行−列指向データ・レイアウトならびに関連するアルゴリズムは、クエリで指定された列にのみデータの読み取りを制限することによって、クエリ処理を高速化するために発展してきた。それにもかかわらず、それらのレイアウトは、クエリとは無関係な相当量のデータを結局は読み取ることになる。クエリごとのデータの読み取りの量を最小化し、追加の記憶層としてフラッシュなどのより高速なランダムにアクセス可能な記憶媒体および拡張キャッシュを利用することが、クエリ性能およびスループットをさらに改善するために重要である。フラッシュは、ハードディスク（ハードディスク・ドライブ（ＨＤＤ）とも称される）とは大きく異なる性能特性を有し、ハードディスクに対して最適化されたデータ・レイアウトおよびアクセス・アルゴリズムでは、フラッシュに関する性能は、最適なものを下回る。ＨＤＤ最適化レイアウトおよびアルゴリズムは、ＨＤＤに特有の高シーク時間を考えるとできるだけランダムなＩ／Ｏを回避するように設計され、順次アクセスが、ＨＤＤへのランダム・アクセスより何十倍も高速であるので強調される。一方で、ランダム・アクセスは、フラッシュではシーク・ペナルティがないので、フラッシュに関して高速である（ＨＤＤよりも４０倍〜１０００倍高速である）。フラッシュの異なる性能特性は、レイアウトおよびアルゴリズムの根本的な再設計を必要とする。

実施形態は、いわゆるＦｌａｓｈＱｕｅｒｙＦｉｌｅにおける新たなフラッシュ最適化データ・レイアウト、ＦｌａｓｈＱｕｅｒｙＦｉｌｅに対する関連するシリアライザ／デシリアライザ、ならびにＦｌａｓｈＱｕｅｒｙＦｉｌｅ（におけるテーブル）のアドホックなクエリ処理を高速化するための選択アルゴリズムおよび射影アルゴリズムを提示する。データ・レイアウトはデータがフラッシュに記憶されるテーブル／列構造であることに留意されたい。ＦｌａｓｈＱｕｅｒｙＦｉｌｅは、不要なデータを積極的にスキップすることによって、クエリごとのデータの読み取りを著しく削減する。ハードディスクに対して設計された最新のレイアウトとは異なり、ＦｌａｓｈＱｕｅｒｙＦｉｌｅは、高いランダム・アクセス性能ならびにフラッシュで可能な高い内部ＩＯ（入力および出力）の並列性を十分に利用することによって、フラッシュからの最大性能を利用するように設計される。ＦｌａｓｈＱｕｅｒｙＦｉｌｅは、フラッシュに関するＨＤＤ最適化行−列指向性データ・レイアウトおよびその関連するアルゴリズムと比較して、４倍〜１００倍のＴＰＣ−Ｈクエリの高速化、および１％未満〜９８％の範囲のクエリ選択性での２９％〜９９．０８％のデータの削減をもたらす。ＴＰＣＨは、トランザクション処理性能評議会（ＴＰＣ）によるアドホックな意思決定支援ベンチマークであることに留意されたい。

Ｈｉｖｅ、ＢｉｇＱｕｅｒｙ、ＢｉｇＳＱＬ、Ｉｍｐａｌａ、Ｐｒｅｓｔｏ、およびＨＡＷＱなどのビッグ・データのウェアハウスがますます当たり前となっている。ペタバイトのデータに対してアドホックな分析（ＯＬＡＰ）ＳＱＬクエリを対話形式で実行させる能力は、ビジネスでは極度に重要となっている。事前計算されたキューブなど、分析クエリを高速化するための従来のＯＬＡＰ技術は、ビッグ・データのケースでは機能しない。これは、ビッグ・データ・セットの規模が何倍もあり、全ての次元にわたってキューブを維持することが非常に高額だからである。クエリのアドホックな性質を考えると、インデックス付けまたはキャッシングなどの技術はいずれの支援にもならない。クエリが到達するときにデータがキャッシュに存在しないことがあり、または分析クエリは一般的に履歴データとともに直近のデータにアクセスするので、データが大きすぎてキャッシュに保持することができないことがある。結果として、記憶装置からキャッシュされていないデータに高速にアクセスする能力は、アドホックなクエリの対話形式処理において重要な役割を果たす。記憶性能は、全体的なアドホックな分析クエリ処理時間を削減し、スループットを改善するために重要である。

ビッグ・データのウェアハウスは、ストレージそのものを管理せず、それらに対してデータを記憶するための内在する分散ファイル・システムに依存する。Ｆ１／ＢｉｇＱｕｅｒｙは、Ｈｉｖｅ、ＩｍｐａｌａなどのＨａｄｏｏｐシステム上でＣｏｌｏｓｓｕｓファイル・システムおよびＳＱＬを使用し、Ｈａｄｏｏｐ分散ファイル・システム（ＨＤＦＳ）を使用する。ビッグ・データのクエリ処理に対して特に設計されたレイアウトおよびアルゴリズムを有するシリアライザ／デシリアライザ（ｓｅｒｄｅとも称される）は、ファイル・システム（例えば、レコード−列指向（ＲＣＦｉｌｅ）、最適化レコード−列指向（ＯＲＣＦｉｌｅ）、およびＰａｒｑｕｅｔ）からテーブル・データを読み取り、このファイル・システムにテーブル・データを書き込むために使用される。各ｓｅｒｄｅ（すなわち、シリアライザ／デシリアライザ）は、その自身のファイル／データ・レイアウト、メタデータ、メモリ内データ構造、テーブル読み取り、スキャン、および挿入（ingest）オペレータを定義する。それらのｓｅｒｄｅは、それらがテーブルでの全ての列を読み取る代わりにクエリに現れる列にのみデータの読み取りを制限するので、クエリごとのデータの読み取りの量を削減する。しかしながら、それらのシリアライザ／デシリアライザは、クエリで全ての列に対して列指向テーブル・データ全体を順次スキャンし、結局は、列のデータが全てクエリに関係するわけではない場合に、多くの無関係なデータも読み取ることになる。ＯＲＣＦｉｌｅは、述語に基づいて非常に粒度を低くしていくつかのデータをスキップするためにＯＲＣＦｉｌｅが利用する最大および最小値などの列に関するサマリ情報を維持することによってテーブル・スキャン操作のオーバヘッドを削減することを試みる。この技術は、選択句での列の列データがソートされ、高濃度（多数の異なる値）を有しているときにデータをスキップするのに効果的である。しかしながら、列の大多数は、本質的にソートされず、低濃度を有する。クエリごとに読み取られる必要があるデータをさらに削減するために粒度が高い、行内グループ・データ・スキッピングを可能にするｉｏ効率がよいレイアウトおよび技術を開発する必要性がある。

この開示は、クラウド・コンピューティングに関する説明を含むが、本明細書に記載される教示の実装形態は、クラウド・コンピューティング環境に限定されないことが事前に理解される。むしろ、本発明の実施形態は、現在知られている、または後に開発されるいずれかの他のタイプのコンピューティング環境とともに実装されることが可能である。クラウド・コンピューティングは、最小限の管理努力またはサービスのプロバイダとの対話で即時にプロビジョニングおよび解放することができる構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシン、およびサービス）の、共有プールへの便利なオンデマンドのネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、少なくとも５つの特性、少なくとも３つのサービス・モデル、および少なくとも４つの配置モデルを含んでもよい。

ここで図１を参照して、クラウド・コンピューティング・ノード／クラスタの例の概略が実施形態に従って示される。クラウド・コンピューティング・ノード／クラスタ１０は、ビッグ・データを記憶／処理する際に利用することができる適切なクラウド・コンピューティング・ノード／クラスタの１つの例にすぎず、本明細書で説明される実施形態の使用または機能の範囲についてのいかなる限定も示唆しないことが意図される。いずれにせよ、クラウド・コンピューティング・ノード／クラスタ１０は、本明細書で示される機能のいずれかを実装し、もしくはいずれかを実行し、またはその両方を行うことが可能である。

クラウド・コンピューティング・ノード／クラスタ１０では、多数の他の汎用または専用コンピューティング・システム環境または構成で動作する複数のコンピュータ・システム／サーバ１２が存在する。複数のコンピュータ・システム／サーバ１２は、接続８２（ファイバ光学など）を通じて接続される。１つのコンピュータ・システム／サーバ１２の特定の詳細が図１に示されるが、詳細は、コンピュータ・ノード／クラスタ１０における他のコンピュータ・システム／サーバ１２に適用される。コンピュータ・システム／サーバ１２での使用に適切であってもよい公知のコンピューティング・システム、環境、もしくは構成、またはそれらの組合せの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドもしくはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記システムもしくはデバイスのいずれかを含む分散クラウド・コンピューティング環境などを含むが、それらに限定されない。

コンピュータ・システム／サーバ１２は、コンピュータ・システムによって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な状況で説明されてもよい。概して、プログラム・モジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、およびデータ構造などを含んでもよい。コンピュータ・システム／サーバ１２は、通信ネットワークを通じてリンクされるリモート処理デバイスによってタスクが実行される分散クラウド・コンピューティング環境で実施されてもよい。分散クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ記憶装置を含むローカルおよびリモートのコンピュータ・システム記憶媒体の両方に位置してもよい。

図１に示されるように、クラウド・コンピューティング・ノード／クラスタ１０におけるコンピュータ・システム／サーバ１２は、汎用コンピューティング・デバイスの形式で示される。コンピュータ・システム／サーバ１２のコンポーネントは、１つまたは複数のプロセッサ１６と、システム・メモリ２８と、システム・メモリ２８を含む種々のシステム・コンポーネントをプロセッサ１６に結合するバス１８とを含んでもよいが、それらに限定されない。プロセッサ１６は、当業者によって理解されるように、コンピュータ実行可能命令を読み取り、処理し、実行するための処理回路（プロセッサ回路）を含む。

バス１８は、様々なバス・アーキテクチャのうちのいずれかを使用したメモリ・バスまたはメモリ・コントローラ、周辺機器用バス、アクセラレイテッド・グラフィックス・ポート、およびプロセッサまたはローカル・バスを含むいくつかのタイプのバス構造のいずれかのうちの１つまたは複数を表す。例として、かつ非限定的に、そのようなアーキテクチャは、インダストリ・スタンダード・アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ）ローカル・バス、およびペリフェラル・コンポーネント・インタコネクト（ＰＣＩ）バスを含む。

コンピュータ・システム／サーバ１２は一般的に、様々なコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム／サーバ１２によってアクセス可能ないずれかの利用可能な媒体であってもよく、それは、揮発性および不揮発性媒体、着脱可能および着脱不能媒体の両方を含む。システム・メモリ２８は、ランダム・アクセス・メモリ（ＲＡＭ）３０もしくはキャッシュ・メモリ３２、またはその両方などの揮発性メモリの形式であるコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ１２はさらに、他の着脱可能／着脱不能、揮発性／不揮発性コンピュータ・システム記憶媒体を含んでもよい。単に例として、記憶システム３４は、着脱不能、不揮発性磁気媒体（図示せず、一般的に「ハード・ドライブ」、「ハードディスク」、もしくは「ハードディスク・ドライブ」、またはそれらの組合せと称される）から読み取り、それらに書き込むために設けられてもよい。図示しないが、着脱可能、不揮発性磁気ディスク（例えば、「フロッピー（Ｒ）・ディスク」）から読み取り、それらに書き込むための磁気ディスク・ドライブ、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭもしくは他の光学媒体などの着脱可能、不揮発性光ディスクから読み取り、それらに書き込むための光ディスク・ドライブが設けられてもよい。そのような例では、各々が１つまたは複数のデータ媒体インタフェースによってバス１８に接続されてもよい。以下でさらに示され、かつ説明されるように、メモリ２８は、本発明の実施形態の機能を実行するように構成されるプログラム・モジュールのセット（例えば、少なくとも１つの）を有する少なくとも１つのプログラム製品を含んでもよい。

メモリ２８は例として、かつ非限定的に、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データを含んでもよい。オペレーティング・システム、１つもしくは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データ（または、それらのいくつかの組合せ）は、ネットワーク環境の実装形態を含んでもよい。

加えて、コンピュータ・システム／サーバ１２は、フラッシュ・メモリ７５（フラッシュとも称される）を含む。フラッシュ・メモリ７５は、実施形態に従って本明細書で論じられるハードディスク・ドライブ３４とともにビッグ・データを記憶する。フラッシュ・メモリ７５は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０を含む。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、メモリ２８の他の部分に記憶されてもよい。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、本明細書で説明される実施形態の機能もしくは方法、またはその両方を実行するプログラム・モジュール４２（１つまたは複数のソフトウェア・アプリケーションであってもよい）を有する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、本明細書でさらに論じられるアルゴリズムを実装してもよい。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の特徴が単一のコンピュータ・システム／サーバ１２で強調されるが、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０（およびその機能）は、コンピューティング・ノード／クラスタ１０における他のコンピュータ・システム／サーバ１２にわたって分散されてもよい。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、本明細書で論じられる実施形態を実装するのに必要な全てのソフトウェア要素で構成される。

コンピュータ・システム／サーバ１２はまた、キーボード、ポインティング・デバイス、ディスプレイ２４などの１つもしくは複数の外部デバイス１４、ユーザがコンピュータ・システム／サーバ１２と対話することを可能にする１つもしくは複数のデバイス、またはコンピュータ・システム／サーバ１２が１つもしくは複数の他のコンピューティング・デバイスと通信することを可能にするいずれかのデバイス（例えば、ネットワーク・カード、モデムなど）、あるいはそれらの組合せと通信してもよい。そのような通信は、入力／出力（Ｉ／Ｏ）インタフェース２２を介して行うことができる。さらにまた、コンピュータ・システム／サーバ１２は、ネットワーク・アダプタ２０を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、汎用ワイド・エリア・ネットワーク（ＷＡＮ）、もしくはパブリック・ネットワーク（例えば、インターネット）、またはそれらの組合せと通信することができる。示されるように、ネットワーク・アダプタ２０は、バス１８を介して、コンピュータ・システム／サーバ１２の他のコンポーネントと通信する。図示されないが、他のハードウェアもしくはソフトウェア・コンポーネント、またはその両方がコンピュータ・システム／サーバ１２とともに使用されてもよいことが理解されるべきである。例は、マイクロコード、デバイス・ドライバ、冗長プロセッサ、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライバ、およびデータ・アーカイブ・ストレージ・システムなどを含むが、それらに限定されない。

ここで図２を参照して、ビッグ・データのウェアハウスとして見なされることがある例示的なクラウド・コンピューティング環境５０が示される。図示されるように、クラウド・コンピューティング環境５０は、例えば、携帯情報端末（ＰＤＡ）もしくは携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎ、あるいはそれらの組合せなどのクラウド・コンシューマによって使用されるローカル・コンピューティング・デバイスが通信することのできる１つまたは複数のクラウド・コンピューティング・ノード１０を含む。クラウド・コンピューティング環境５０は、実施形態に従ってコンピューティング・デバイス５４Ａ〜Ｎからのデータの記憶、処理、およびクエリを行う多数のノード／クラスタ１０を含んでもよい。ノード／クラスタ１０は、接続８４（ファイバ光学接続など）を介して相互に通信してもよい。それらは、上記で説明されたプライベート（Ｐｒｉｖａｔｅ）、コミュニティ（Ｃｏｍｍｕｎｉｔｙ）、パブリック（Ｐｕｂｌｉｃ）、もしはハイブリッド（Ｈｙｂｒｉｄ）のクラウド、またはそれらの組合せなどの１つまたは複数のネットワークで物理的に、または仮想的にグループ化されてもよい（図示せず）。これによって、クラウド・コンピューティング環境５０が、インフラストラクチャ、プラットフォームもしくはソフトウェア、またはそれらの組合せを、ローカル・コンピューティング・デバイス上でリソースを維持することをクラウド・コンシューマが必要としないサービスとして供給することが可能になる。図２に示されるコンピューティング・デバイス５４Ａ〜Ｎのタイプは例示のみであることが意図され、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０はネットワークもしくはネットワーク・アドレス指定可能接続（例えば、ウェブ・ブラウザを使用した）、またはその両方のいずれかのタイプを介していずれかのタイプのコンピュータ化デバイスと通信することができることが理解される。図３は、図面を不明確にしないようにいくつかの特徴を省略しつつ、実施形態に従ったコンピュータ・システム／サーバにおける特徴のさらなる詳細を示す。

ビッグ・データについて、３つの方法、１）ＩＯ効率のよいｓｅｒｄｅおよび列指向レイアウトを使用することによってクエリごとにスキャンされる必要があるデータを削減すること、２）より高いＩＯスループットのために並列度の増加に依存すること、または３）データに高速アクセスするためにメモリもしくはフラッシュなどのより高速な媒体を利用すること、あるいはそれらの組合せでクエリ処理のために記憶性能を高めることができる。この開示は、実施形態に従って方法１）〜３）を使用して記憶性能を高めることに焦点を当てている。本開示は、行内グループ・レベルで列指向データの粒度の高いスキップによって、クエリごとのデータの読み取りを削減して、クエリ処理の性能を高めることが可能になる新たなメカニズムを提供する。

最新のｓｅｒｄｅは、パラメータとともにアーキテクチャの決定、データ構造、射影アルゴリズム、選択アルゴリズム、および結合アルゴリズムがＨＤＤの基本的な性能特性に基づいているハードディスク（ＨＤＤ）に対して設計される。ＨＤＤに特有な高シーク時間を考えると、ランダムなＩ／Ｏができるだけ回避され、順次アクセスがＨＤＤに対するランダム・アクセスより何十倍も高速なので、それらが強調される。記憶階層においてフラッシュなどのより高速かつランダムにアクセス可能な記憶媒体を利用する一般的な方法は、リアクティブ層（reactive tiering）を介したものとなっている。リアクティブ層では、記憶モジュールは、データへのアクセス・パターンを監視し、高性能フラッシュ層（すなわち、フラッシュ・メモリ）に頻繁にアクセスされているデータを移動させる。そのような移動は、いかなるアプリケーションでも認識することなく透過的に行われる。結果として、アプリケーションは、ハードディスクに対して本質的に設計された同一のアルゴリズム、プレフェッチ・メカニズム、ＡＰＩ（アプリケーション・プログラム・インタフェース）でフラッシュに存在しているデータにアクセスすることを継続する。結果として、達成される性能は、実施形態で開示されるフラッシュ最適化アルゴリズムおよびコードで達成可能な性能の一部にしかならない。最新技術で使用されるように、既存のＳＱＬ（Structured English Query Language）ファイルうちの１つの単純なデータ配置は、フラッシュの形式に合わせ、ＨＤＤ最適化アルゴリズムおよび前提条件を使用しても性能向上および粒度の高いデータ・スキッピングをほとんど利用することが可能でないが、これらは、そうでない場合、そのようなランダムにアクセス可能な媒体で達成可能である。１ドルごとの最適な性能を絞り出してより高価なフラッシュを正当化するために、順次にアクセスされるＨＤＤからフラッシュなどのランダムにアクセス可能な記憶媒体への移行は、基本的な設計の決定、データ・レイアウト、ｓｅｒｄｅの選択および射影オペレータの最調査を必須とする。

しかしながら、実施形態は、コンピュータ・ノード／クラスタ１０に記憶されたビッグ・データに対するＳＱＬに対し、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０と称される新規なフラッシュ最適化シリアライザ／デシリアライザを提供する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅの選択アルゴリズム、射影アルゴリズム、挿入アルゴリズム、データ・レイアウト、およびメタデータが１ドルごとの最適な性能を得るためにフラッシュ（フラッシュ・メモリ７５）などのランダムにアクセス可能な記憶装置に対して最適化される。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、アプリケーションが認識する方式でフラッシュ層（フラッシュ・メモリ７５）においてフラッシュに適切な、ポピュラな列のサブセットの予測的な配置を認識した記憶層であり、それに対するメカニズムを提供する。これによって、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０がアドホックな分析クエリに対して重要な性能保証をもたらすことが可能になる。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、根本的にデータ構造およびメタデータを粒度の高いデータ・スキッピングを可能とするように再設計し、述語プッシュダウン（predicate pushdown）およびレイト・マテリアライゼーション（latematerialization）を利用することによって、選択および射影の間にクエリに絶対に必要なデータのみを読み取ることによってクエリ処理の待ち時間を低減させる。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０はまた、フラッシュによって可能となる内部ＩＯの並列度によって行われることが可能となるその選択アルゴリズムにおけるデータ・アクセスの並列度を利用する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅは、スキャン・アルゴリズムにおける順次およびランダム・アクセスのバランスをとる際にフラッシュ７５の特性を注意深く考慮し、それは、各ランダム・アクセスがそれと関連付けられたＡＰＩのオーバヘッドをも有するので非常に重要である。１つの大きな順次アクセスの代わりに単純に多数の小さなランダム・アクセスを行うことは、ＡＰＩコールのオーバヘッドが主なものとなる場合に実際に性能を悪化させることがある。最後に、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、フラッシュの性能の利点を得ることが可能になる高性能ＩＯ ＡＰＩ、オブジェクト・シリアリゼーションおよびデシリアリゼーション、ならびにデータ構造を使用する重要性を示す。積極的にバッファおよびプリフェッチするＡＰＩなどの本質的にハードディスクに対して設計されるＡＰＩを使用することは実際に、フラッシュ７５の性能の利点を無効にする可能性がある。

最新の動向として既存の研究は主に、更新が多いオンライン・トランザクション処理（ＯＬＴＰ）の作業負荷にフラッシュを組み込むことに目を向けていた。分析処理（ＯＬＡＰ）の作業負荷においてフラッシュを利用するための研究に限定されており、ビッグ・データのＳＱＬに対してフラッシュを利用する研究が存在しない。ＯＬＡＰの作業負荷が、それらがほとんど本質的に順次的であり、テーブル全体をスキャンする必要もあるのでフラッシュを利用することができないという一般的な誤認識がある。しかしながら、本開示における拡張的な実験、ＯＬＡＰの作業負荷およびデータセットの分析、ならびに結果は、この誤認識を覆す。したがって、実施形態は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０を介したビッグ・データの分析クエリ処理のためのフラッシュ最適化シリアライザ／デシリアライザ（ｓｅｒｄｅ）を提供する。

理解を助けるために説明の目的で、以下で表題および副表題が設けられることに留意されたい。しかしながら、表題および副表題は限定を意味するものではない。

Ｉ．ビッグ・データ・エコシステムにおいてフラッシュを使用するサポート／根拠

フラッシュは、ビッグ・データの記憶階層でますます一般的となっている。フラッシュは、ディスクと比較してランダム・アクセスでは４０〜１０００倍の改善をもたらし、順次帯域幅では２〜７倍の改善をもたらす。フラッシュは、不揮発性であり、よって、データの複製を有する必要性をなくす。フラッシュは、データに対する主要な、かつ唯一の層としての機能を果たすことができる。一方で、ＲＡＭの揮発性は、不揮発性媒体におけるデータの追加の持続的な複製を必須とし、ビッグ・データのシステムにおいて大きな問題である重要なデータの複製をもたらす。フラッシュ・デバイスが、複数のチャネルを通じてフラッシュ・メモリ・コントローラに接続されるフラッシュ・メモリ・パッケージのアレイ上に構築されるので、フラッシュによって、ディスクよりもさらに高いレベルの、同時ＩＯのためのＩＯの並列度が可能になる。論理ブロックは、独立した同時データ・アクセスを可能にする複数のフラッシュ・メモリ・パッケージにわたって縞状に配置される（striped）。フラッシュの内部ＩＯの並列度は、さらに高い性能に対してさらに利用されてもよい。

フラッシュは、容量制約ＲＡＭよりも高価でなく、追加のＲＡＭを追加するよりも二次キャッシュとしてより良好に利用されもする。クエリおよび反復計算に対してよりＨａｄｏｏｐをより高速にすることに関する大多数の最近の研究は、非常に大きなＲＡＭのサイズに大きく依存する。フラッシュは、それがさらに低いコストでＲＡＭよりもさらに高い容量を可能にするのでＲＡＭよりもさらに高い１ドル当たりの性能を達成することができる。フラッシュはまた、ハードディスクよりも大幅にエネルギー効率が高く、エネルギーが比例し、さらに、エネルギー・コストの削減が所有することの全コストに関して重要な影響を及ぼす、ビッグ・データ・クラスタへの記憶のための魅力的な選択肢とさせる。さらに、フラッシュは、Ｍａｐ削減ジョブのマップ出力を記憶するために非常に望ましく、著しい量の中間的データをもたらす性質および他のベンチマークの３倍に性能を増加させる。

全体的に、高性能、省スペース、低消費電力、コスト削減、およびフラッシュの不揮発性は、実施形態に従って、ビッグ・データのクラスタにおける記憶層／キャッシュとして大いに望ましいものとさせる。

ＩＩ．粒度の高いデータ・スキッピングの機会

図４は、ＴＰＣＨクエリにおける個々の選択列の選択性を示すグラフ２００である。グラフ２００は、種々のＴＰＣＨクエリにおける各選択列のクエリ述語に一致する行を示す。列の選択性は、クエリ（Ｑ）の述語に一致するその列内の行の数である。例えば、所与の列が１００％の選択性を有する場合、これは、列における全ての行が述語に一致することを意味する。所与の列が２５％の選択性を有する場合、これは、列における行の４分の１がクエリの述語に一致することを意味する。

当業者は、ＳＱＬクエリにおける述語を理解している。例えば、述語は、ＷＨＥＲＥ句およびＨＡＶＩＮＧ句の検索条件、ＦＲＯＭ句の結合条件、および（ブール）値が要求される他の構成で使用される。ＳＱＬにおけるＷＨＥＲＥ句は、ＳＱＬデータ操作言語（ＤＭＬ）ステートメントが、指定された基準を満たす行にのみ作用するべきであることを指定する。基準は、述語の形式で表現される。ＷＨＥＲＥ句は、ＳＱＬ ＤＭＬステートメントによって作用し、またはクエリによって返される行の数を制限するために使用されてもよい。要するに、ＳＱＬのＷＨＥＲＥ句は、ＳＥＬＥＣＴ、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、またはＤＥＬＥＴＥステートメントなどのＳＱＬステートメントから生じるもののみを抽出するために使用される。

グラフ２００では、ｘ軸はＴＰＣＨクエリを示し、ｙ軸は各列における選択性の割合（％）を示す。ＴＰＣＨクエリ６（Ｑ６）が６億行以上を有する７９ＧＢ（ギガバイト）のＴＰＣＨ項目テーブルを対象とすることを前提とする。最新技術では、現在の列指向および行−列指向ｓｅｒｄｅは、射影（例えば、Ｌ＿ＥＸＴＥＮＤＥＤＰＲＩＣＥ、Ｌ＿ＤＩＳＣＯＵＮＴ）および選択列（例えば、図５でグラフ２１０を参照して、Ｌ＿ＳＨＩＰＤＡＴＥ、Ｌ＿ＤＩＳＣＯＵＮＴ、Ｌ＿ＱＵＡＮＴＩＴＹが図４におけるＴＰＣＨクエリ６からの例示的な選択列である）において全てのデータ（すなわち、全ての行位置）を読み取る。しかしながら、図５に表されるように、選択列Ｌ＿ＳＨＩＰＤＡＴＥにおける行の１５％、Ｌ＿ＤＩＳＣＯＵＮＴにおける１８％、およびＬ＿ＱＵＡＮＴＩＴＹにおける４６％のみが個々の列のクエリ述語に一致する。行の１％のみが、射影列Ｌ＿ＥＸＴＥＮＤＥＤＰＲＩＣＥおよびＬ＿ＤＩＳＣＯＵＮＴにおける１％のデータのみをクエリに関連するものとさせる３つの選択列にわたって全ての述語に一致する。全体的に、５つの列にわたって１６％のデータのみがクエリに関連する。既存のｓｅｒｄｅは、１％の関連するデータをまさに射影するようにそれらの射影列からの追加のデータの９９％程度を読み取り、選択性が５０％に満たないときに選択列からの追加のデータの５０％程度を読み取る。同様の傾向が他のクエリに存在し、選択列の選択性がＴＰＣＨクエリの大部分に対して１％〜６３％の範囲に及ぶ。よって、選択および射影段階の両方でのクエリに関連する列指向データのみを読み取ることができる行内グループの粒度の高いデータ・スキッピング技術は、分析クエリ（本明細書で開示される）ごとに、読み取られる必要があるデータを著しく削減することができる。

ＩＩＩ．ＦｌａｓｈＱｕｅｒｙＦｉｌｅ

この章では、本開示は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０のフラッシュ最適化データ・レイアウト、挿入アルゴリズム、選択アルゴリズム、および射影アルゴリズムを説明する。

Ａ．データ・レイアウト

図６は、実施形態に従って、ノード／クラスタ１０におけるコンピュータ・システム／サーバ１２にわたって分散される（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって）複数の分散ファイル・システム（ＤＦＳ）ブロックに分割される（記憶される）単一のＦｌａｓｈＱｕｅｒｙＦｉｌｅファイル／レイアウト３０４としてテーブルが論理的にどのように表されるかを示す。図６は、メモリ２８に記憶されたファイル・ブロック３０１を示すが、ファイル・ブロック３０１は、ノード／クラスタ１０における複数のコンピュータ・システム／サーバ１２にわたって分散される多数のファイル・ブロック３０１を表す。図６はまた、以下で論じられるようにフラッシュ・メモリ７５に記憶されたメタデータ・ヘッダを強調する。

したがって、ＦｌａｓｈＱｕｅｒｙＦｉｌｅファイル／レイアウト３０４における列は、各々が構成可能な数の行を含む複数の行グループに水平に区分化される。ファイル・ブロック３０１は、複数の行グループを含む。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、３つの異なるレベル、１）ＲＣＨｅａｄｅｒと称されるブロック・レベル・ヘッダ、２）ＲＧＨｅａｄｅｒと称される行−グループレベル・ヘッダ、および３）ＣｏｌＨｅａｄｅｒと称される列レベル・ヘッダでメタデータ・ヘッダを維持する。ヘッダ（すなわち、ＲＣＨｅａｄｅｒ３１０、ＲＧＨｅａｄｅｒ３１５、およびＣｏｌＨｅａｄｅｒ３２０）は、必要なデータへの高速なランダム・アクセスを促進するためのデータ構造を維持し、粒度の高いデータ・スキッピングを可能にする。メタデータ・ヘッダＲＣＨｅａｄｅｒ３１０、ＲＧＨｅａｄｅｒ３１５、およびＣｏｌＨｅａｄｅｒ３２０の各々は、クエリを実行している間（例えば、クエリの選択段階／部）、ファイル・ブロック全体をいつスキップするか（次いで、次のファイル・ブロックにいつ移動するか）、行グループをいつスキップするか（次いで、次の行グループにいつ移動するか）、もしくは列をいつスキップするか（次いで、次の列にいつ移動するか）、またはそれらの組合せについて判定するためにＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって読み取ることができるメタデータを含む。例として、選択列３２５、低濃度の射影列３３０、および超高濃度の射影列３３５が示される。

（ファイル・ブロック）ＲＣＨｅａｄｅｒ３１０は、ファイル・ブロックにおける行グループの番号（ｎ＿ｒｇｓ）およびバージョン番号を含み、バージョン番号は、展開の期間の間に種々のバージョンのファイル・ブロック構造にわたって後方および前方互換を維持する際にＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０ソフトウェアを支援する。

ＲＧＨｅａｄｅｒ３１５ヘッダは、ファイル・ブロックにおける行グループの開始のオフセット（ｒｇ＿ｏｆｆｓｅｔ）およびファイル・ブロックにおける行グループのサイズ（ｒｇ＿ｓｉｚｅ）を含む。ＲＧＨｅａｄｅｒ３１５はまた、行グループに存在する行および列の数を含む。例えば、行グループのサイズがファイル・ブロックに対して１千万行になるように構成される場合、ｒｇ＿ｒｏｗｓフィールドは、値として１千万を含む。

ＣｏｌＨｅａｄｅｒ３２０は、ファイル・ブロックにおける種々の考えられる列指向レイアウトに対するファイル・オフセット・ポインタを維持する。列の辞書のファイル・オフセットおよびサイズは、ｕ＿ｏｆｆｓｅｔおよびｕ＿ｓｉｚｅでそれぞれ維持される。ｕ＿ｏｆｆｓｅｔおよびｕ＿ｓｉｚｅフィールドは、高速射影および選択のために辞書（例えば、選択辞書もしくは射影辞書、またはその両方）を利用するＦｌａｓｈＱｕｅｒｙＦｉｌｅレイアウトに対して満たされる。ｌ＿ｏｆｆｓｅｔおよびｌ＿ｓｉｚｅフィールドは、射影−最適化レイアウトで使用されるルックアップ構造のファイル・オフセットを含む。フィールドｄ＿ｏｆｆｓｅｔおよびｄ＿ｓｉｚｅは、そのままで記憶される（例えば、濃度＝１を有する列がいずれの辞書もなしにそのままで記憶される）列のデータのファイル・オフセットを含む。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって実行されるように、矢印３４１、３４２、３４３、３４４、３４５、３４６、３４７、３４８、３４９、３５０、３５１、３５２、３５３、３５４は、メタデータ・ヘッダの関係および使用を示す。矢印３４１〜３５４は、ファイル・ブロック３０１において並べられたオフセットが示しているオフセット・フィールドとデータ構造との間の関係を示す。

全ての構造におけるデータ型は、空間効率を維持する観点で注意深く選択されている。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅファイル３０４（挿入アルゴリズム１０２によって決定される）で２つのデータ・レイアウト、一方は、クエリの選択段階／部に対して最適化され、他方は、クエリの射影段階／部に対して最適化される。実験の見解から、述語値、ならびに列の順序および数がアドホックなクエリにわたって変化する間、一部の列は、射影または選択列のいずれかとしてポピュラとなる傾向がある。例えば、ＴＰＣＨデータセットでは、２つの列、Ｌ＿ＥＸＴＥＮＤＥＤＰＲＩＣＥ（図示せず）およびＬ＿ＤＩＳＣＯＵＮＴが最もポピュラな射影列である。それらのポピュラリティは、ＴＰＣＨが金銭的なベンチマークとしてモデル化されるので、直感的に理解でき、それらの数字列は金銭の問題となり（deal with money）、数値に関して集約を行うことができる。Ｌ＿ＳＨＩＰＤＡＴＥ（図５における）などの日付型を有する列は、日付が一般的に分析クエリにおける重要な次元であるので選択列として非常にポピュラである。同様に、主キーおよび外部キーは、ポピュラな選択列である。ＢｌｉｎｋＤＢの論文は、Ｆａｃｅｂｏｏｋから実世界のクエリの分析に基づいている選択列に関する同様の見解を有し、列の２０％のサブセットが８０％のアドホックなクエリの選択句で行われている。この見解に基づいて、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、列指向データに対する３つのデータフォーマット、すなわち、ポピュラな選択列に対する高速選択のために最適化された第１のフォーマット、ポピュラな射影列に対する高速射影のために最適化された第２のフォーマット、射影もしくは選択列、またはその両方（クエリにおける異なる回数）として使用されている列に対して使用されるハイブリッド・レイアウトである第３のフォーマット、を供給する。デフォルトのレイアウトは、ハイブリッド・フォーマットであり、そこでは、アドミニストレータもしくはプレディクタ・モジュール、またはその両方（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０における）は、ハイブリッド・レイアウトよりもさらに空間効率をよくするための選択専用または射影専用レイアウトを選択することができる。産業的追跡の前の分析はまた、選択列のセットがアドホックな分析クエリでさえ非常に予測可能なままであることを発見してきた。そのような見解によって案内されるように、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０（挿入アルゴリズム１０２を介した）によって、ユーザもしくはクエリ・エンジン、またはその両方が、テーブルにおける一部の列を、射影された列のみ、選択された列のみ、もしくは射影された列および選択された列の組合せ、またはそれらの組合せである列としてマーク付けすることが任意選択で可能になる。したがって、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０（挿入アルゴリズム１０２を介した）は、空間効率のために（ＦｌａｓｈＱｕｅｒｙＦｉｌｅファイル３０４における）そのデータ・レイアウトの決定において、この情報（すなわち、射影のみされた列、選択のみされた列、もしくは組合せ、またはそれらの組合せである列としてテーブルにあるマーク付けされた列）の係数を利用する。挿入アルゴリズム１０２が以下のテーブル表１で説明される。主キーは行を一意に識別する列また列のグループである。テーブルごとに主キーを有するべきであり、テーブルは２つ以上の主キーを有することはできない。主キーの特性は、テーブルの第１の列にあるように列の定義の一部として指定されてもよく、またはそれは、ＣＲＥＡＴＥ ＴＡＢＬＥステートメントの別個の句として指定されてもよい。外部キーは、その値が別の（または同一の）テーブルの主キーにおける値と一致するべきである１つのテーブルにおける列または列のセットである。外部キーは、その主キーの参照と言われる。外部キーは、データの整合性を維持するためのメカニズムである。

表１：フラッシュ最適化挿入アルゴリズム

１）選択最適化データ・レイアウト

図７は、テーブルにおいてデータ値を有する列および行の元の関係４０１を示す。テーブルは、実施形態に従って、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によってコンピュータ・システム／サーバ１０に挿入されて、フラッシュ・メモリに対して最適化される。実施形態は、元の関係にテーブルを記憶しない。実施形態に従って、図８は、（基本）選択最適化レイアウトを示し、図９は、可変サイズのポピュラな射影列に対する（基本）射影最適化レイアウトを示す。実施形態に従って、図８〜１５は、例示的なレイアウトであり、図６におけるファイル・ブロック３０１のさらなる詳細および特定の例を示す。実施形態に従って、図７におけるテーブルの元の関係４０１から、高速述語マッチ（predicate match）を促進し、選択句／部（例えば、述語を含むｗｈｅｒｅ句）の間のデータの読み取りを削減するために、図８に示される選択最適化データ・レイアウト４０２が設計されている（記憶のためにＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって）。潜在的な選択列ごとに、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、列の各行グループで発生する一意な値を抽出し、一意な値を選択辞書４０３に隣接して記憶する。列ヘッダは、一意な値の開始に対するオフセット（ｏｆｆ）を維持する。次に、値ごとに、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、各々の一意な値が列で発生する（図８に図示されないが、図６に示される）行位置のセットのオフセット４５０（省略してｏｆｆもしくは０、またはその両方）および長さ（すなわち、サイズ）を記憶する。最後に、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、一意な値ごとに行位置のセットを行位置指定４０５に記憶する。オフセット４５０は、個々の一意な値に対する行位置の各々の集合／グループ化の位置に対応する。メタデータ・ヘッダでは、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０はまた、行グループごとに列におけるエントリの最大値、最小値、中間値、平均値および総数を記録（記憶）する。最大値は、列の行グループごとに発生する最大値を意味し、最小値は、列の行グループごとに発生する最小値を意味し、中間値は、列の行グループごとに発生する中間値を意味し、平均値は、列の行グループごとに発生する平均値を意味する。総数は、列の行グループにおける行の数を意味する。

図７における元の関係テーブル４０１と比較して、選択最適化データ・レイアウト４０２は、同一のデータ値の記憶を繰り返すことなく列Ｃ１を記憶する新たな方法である。図８は、選択辞書４０３（列ヘッダにおける）が列Ｃ１に対する一意なデータ値を記憶し、一意なデータ値が１２１、１３０、１４０、１５０である例を示す。行位置指定４０５（列ヘッダにおける）は、元の関係４０１において一意な値を含んだ列Ｃ１における行位置ごとに行位置（すなわち、名前）を記憶する。例えば、一意なデータ値１２１は、行位置指定４０５における行位置ｒ２、ｒ３、およびｒ６（元の関係に対し）であるが、一意な値１２１は、１回のみ記憶され、３つの異なる行位置に対して複製されない。一意なデータ値１３０は、行位置指定４０５における行位置ｒ１およびｒ４（行位置ブロブにおける）であるものとして表される。一意なデータ値１４０は、行位置指定４０５における行位置ｒ７（行位置ブロブにおける）であるものとして表される。一意なデータ値１５０は、行位置指定４０５における行位置ｒ５（行位置ブロブにおける）であるものとして表される。各々の行位置ブロブは、同一の一意な値を有するものとして表される１つまたは複数の行位置の集合である。オフセット４５０のうちの各々の１つは、特定の行位置ブロブの開始に対するものである。

この例では、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０が列Ｃ１を選択最適化レイアウト４０２のための１つの選択列として選択することを前提とする。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、一意な値１２１、１３０、１４０、１５０となる、列Ｃ１における各々の行グループで発生する一意な値を判定し、それらの一意な値をメモリ２８に隣接して記憶する。一意とは、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０が、列Ｃ１における同一の値の記憶を繰り返す必要なく、選択された列Ｃ１における各々の一意な値の単一のエントリのみを必要とすることを意味する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、最初の一意な値１２１の開始など、一意な値の開始にオフセット（ｏｆｆ）を記憶するように列ヘッダを構成する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０が、各々の値が列で発生する行位置のセットのオフセット４５０および長さ（すなわち、サイズ）を記憶するので、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、一意な値１２１、１３０、１４０、１５０（メモリ２８に並んで記憶される）ごとのデータの正確な位置を判定することができる。

２）射影最適化データ・レイアウト

元の関係テーブル４０１から取得（挿入）されるように、図９は、射影に対してのみ使用される、すなわち、ｓｅｌｅｃｔ句に現れる可変長列に対して使用される射影最適化データ・レイアウト４０４（メモリ２８に記憶された）を示す。列が可変長である場合、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、列において各々の行位置のオフセットおよびサイズを含むルックアップ構造４０６を維持する。次いで、列データは、列の濃度が低い場合に、辞書４０８に配置される。そうでない場合、データは単純にファイル・システム・ブロック上に順次配置される。列ヘッダは、ルックアップ構造４０６およびデータ（値）のオフセットを維持する。（特定の）列が固定長である場合、ルックアップ構造が使用されず、データが単純にファイル・システム・ブロックに順次配置される。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、後のルックアップを支援するために列ヘッダにおけるフィールド長を記録する。

図７における元の関係テーブル４０１と比較して、射影最適化データ・レイアウト４０４は、同一のデータ値の記憶を繰り返す必要なくことなく列Ｃ３を記憶する新たな方法である。例えば、射影辞書４０８は、一意なデータ値６００、６０２、６０３、６７０、６８０（すなわち、データ値を繰り返すことなく）（のみ）を記憶する。ルックアップ構造４０６は、各々のデータ値のメモリにおける各々のデータ値のオフセット（ｏｆｆ）およびサイズ（例えば、バイト、キロバイトなど）を記憶する。データ値６００が列Ｃ３に１回のみ現れるので（すなわち、行１にのみ）、データ値６００は、ルックアップ構造４０６においてｏｆｆ_ｒ１（オフセット）およびｓｉｚｅ_ｒ２を有する。しかしながら、データ値６７０は、行４および行６の両方で、列３で２回現れ、したがって、ルックアップ構造４０６は、ｏｆｆ_ｒ４およびｓｉｚｅ_ｒ４を記憶することによって行４を表し、ｏｆｆ_ｒ６およびｓｉｚｅ_ｒ６を記憶することによって行６を表す。データ値６７０は、２つの別個の行４および６に対応するように射影辞書４０８に１回のみ記憶され、よって、空間を節約し、データ値６７０の一致があるか（および、列３において単一のデータ値ごとに実際にスキャンする必要なく、ルックアップ構造４０６（すなわち、メタデータ）をスキャンすることによっていくつの行が列Ｃ３において一致するか）を判定することをさらに容易にする。

３）さらなる例示的な選択および射影最適化データ・レイアウト

図１０は、実施形態に従った選択最適化レイアウト４０２（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の）を利用する例を示す。図１０は、選択最適化レイアウト４０２に対して各々の行位置（ｒ１〜ｒ１４）におけるデータ値（元の関係４０１からの列Ｃ１の追加のデータ値を有する）を示す典型的な列指向データ・レイアウトを示す。図１０は、クエリ：Ｓｅｌｅｃｔ ｓｕｍ（ｃ２） ｗｈｅｒｅ ｃ１＝１３０ ａｎｄ ｃ１＝１５０を前提とする。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の選択アルゴリズムは、選択最適化レイアウト４０２から辞書４０３およびオフセット４５０を読み取る。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の選択アルゴリズムは、Ｃ１＝１３０およびＣ１＝１５０の述語マッチを実行する。最後に、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の選択アルゴリズム（のみ）は、行位置リスト４０５における一致する行位置を読み取り（読み取ろうとし）、行位置リスト４０５における一致しない行位置をスキップする。判定された行位置は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の射影アルゴリズムに渡される。

図１１は、実施形態に従った低／中濃度列（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の）に対する射影最適化レイアウト４０４の実装形態を示す。低および中濃度列は、高濃度列よりも低い濃度を有する。低濃度列は、中濃度列よりも低い濃度を有する。辞書４０８は、列指向データで発生する全ての一意な値（列Ｃ３およびＣ４に対して）を記憶するように作成される。次に、各々の行位置の列値を辞書値にマッピングするルックアップ構造４０６がインデックスとともに作成される。図１１では、インデックスは、図９に示されるオフセットおよびサイズを使用することなく、辞書４０８における各エントリにマッピングするためにルックアップ構造４０６において利用される。ルックアップ構造４０６内で、ｉｎｄｅｘ_ｒ１およびｉｎｄｅｘ_ｒ２の両方が、辞書４０８における一意な値Ｒｏｓａ Ｐａｒｋｓにマッピングする。列ヘッダにおけるｌ＿ｏｆｆｓｅｔおよびｌ＿ｓｉｚｅフィールドは、ファイル・ブロック３０１における直列化されたルックアップ構造のファイル・オフセットを示すように設定される。ｕ＿ｏｆｆｓｅｔおよびｕ＿ｓｉｚｅフィールドは、ファイル・ブロック３０１における直列化された辞書を示すように設定される。

図１１では、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の射影アルゴリズムは、全ての述語に一致する行のリストの入力を受け取る（選択アルゴリズムから）ように構成され、行位置のリストは、ｒ１、ｒ５、およびｒ７である。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、辞書４０８（一意な値の）を読み取るように構成される。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、所望の行位置（ｒ１、ｒ５、およびｒ７など）ごとにルックアップ・テーブル構造４０６に記憶されたインデックスにおいて辞書をルックアップ（および取り出す）ように構成される。

別の実施形態に従って、図１２は、高濃度列に対する別の射影最適化レイアウト４０４を示す。空間効率および性能の理由のためにこのケースでは辞書が使用されない。列指向データは、ファイル・ブロック３０１について直列化され、ルックアップ構造４０６は、可変長列を有する列（列Ｃ３について表される）に対する各々の行位置において列のオフセット（例えば、ｏｆｆ_ｒ１、ｏｆｆ_ｒ２など）を記憶する。列が高濃度および固定長を有するとき、列Ｃ４が例示的な表示である。列ヘッダにおけるｌ＿ｏｆｆｓｅｔおよびｌ＿ｓｉｚｅフィールドは、ファイル・ブロック３０１における直列化されたルックアップ構造を示すように設定される。ｄ＿ｏｆｆｓｅｔおよびｄ＿ｓｉｚｅフィールドは、ファイル・ブロック３０１における直列化された列指向データを示すように設定される。

図１２では、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の射影アルゴリズムは、全ての述語に一致する行のリストの入力を受け取る（選択アルゴリズムから）ように構成され、行位置のリストは、ｒ１、ｒ５、およびｒ７である。列が可変長を有する場合、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、個々のルックアップ要素（ルックアップ構造４０６における）を１つのオプションとして読み取り、または行位置をクラスタ化し、ルックアップ構造４０６のチャンク（要素のグループ）を読み取るように構成される。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、ｄ＿ｏｆｆｓｅｔを（列ヘッダからの）をルックアップ構造４０６に記憶されたｏｆｆ（オフセット）に追加することによって、行位置の値のファイル・オフセットを判定する。列が可変長を有する場合、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、行位置オフセットをｄ＿ｏｆｆｓｅｔ＋行位置×フィールド長として計算する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、グレイにマーク付けされた（すなわち、強調表示された）エントリをフラッシュから直接読み取り、データの残りの読み取りをスキップするように構成される。

実施形態に従って、図１３は、クエリに応じて射影もしくは選択列、またはその両方として使用することができる列に対するハイブリッド射影および選択レイアウト４８０を示す。図１３は、選択および射影最適化レイアウト（４０２および４０４）と組み合わせたレイアウトを示す。

実施形態に従って、図１４は、クエリに応じて射影もしくは選択列、またはその両方として使用することができる列に対する最適化され、かつ空間効率のよい射影および選択レイアウト４９０を示す。この組み合わされたレイアウト４９０は、列がソートされる場合のみ使用されてもよい。ルックアップ・テーブルにおける行位置ごとにルックアップ・エントリを維持する代わりに、開始および終了の行位置のみがルックアップ・テーブル４９１において追跡される。ルックアップ・テーブル４９１は、各々の一意な値に対応するルックアップ・エントリに逆ポインタを適用することによって、辞書４０３、４０８における各々の一意な値に対する行位置ブロブとしての機能を果たす。

図１５は、実施形態に従った選択最適化レイアウト４０２（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の）を利用する異なる例を示す。実施形態に従って、図１５は、クエリが同一のクエリにおける射影列として選択最適化レイアウト４０２に配置された列として使用されることであった場合でさえ、射影段階（クエリの）を最適化するメカニズムを示す。例えば、図１５は、選択および射影列の両方（ハイブリッドと称されてもよい）としてポピュラな列を示し、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、実施形態に従って、このハイブリッド列（選択および射影列の両方として使用される）を選択最適化データ・レイアウト４０２に記憶する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０において射影処理の前に選択処理が行われる根拠となる。射影アルゴリズムによって必要とされるルックアップ構造（４６０）は、クエリ処理の実行時間の間に動的に作成される。選択アルゴリズムは、述語に一致する列値および関連する行位置を得る。逆ルックアップ構造４６０は、行位置を値にマッピングする抽出された情報から作成される。次いで、ルックアップ構造４６０は、本明細書で射影最適化データ・レイアウトにおいてさらに議論される、対象の行位置に関する値を射影するために射影段階の間に使用される。

図１５では、ハイブリッド（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の）に対する射影アルゴリズムは、述語列ｃ１＝１３０および列Ｃ１＝１５０である全ての述語に一致する行のリストの入力（選択アルゴリズムからの）を受け取るように構成される。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、述語に一致するリストまたは行の入力を受け取り、メモリ内ルックアップ（例えば、辞書４０３）から直接エントリ（グレイにマーク付けされ／強調表示された）を読み取り、データの残りの読み取りをスキップする。

Ｂ．フラッシュ最適化選択アルゴリズム

ＦｌａｓｈＱｕｅｒｙＦｉｌｅフラッシュ最適化選択アルゴリズム１０４（スキャン・アルゴリズムとも称される）は、上記で説明されたように、フラッシュに対して最適化され、性能のためにフラッシュで可能になるランダム・アクセスおよび内部並列度を利用する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、可能な最小データをできるだけ速く読み取ることを目的として設計される。フラッシュ（例えば、フラッシュ・メモリ７５）によって、ハードディスク・ドライブよりも同時ＩＯ処理でさらなる内部並列度が可能になり、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、フラッシュ最適化選択アルゴリズム１０４（スキャン・アルゴリズム）を使用することによってフラッシュで可能な並列度を利用する。最新のＲＣＦｉｌｅおよびＯＲＣＦｉｌｅは、各行グループを順次読み取り、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、各行グループを並列に読み取る（すなわち、同時に）。加えて、述語に一致する列値の行位置ブロブも並列に読み取る。次いで、全ての述語に一致する行位置の最後の積結合が、射影アルゴリズム１０６に渡される。

ここで、選択アルゴリズム１０４を示すために、演算は、クエリ、ｓｅｌｅｃｔ ａｖｇ（ａ）、 ｓｕｍ（ｂ） ｆｒｏｍ ｔｈｅ ｔａｂｌｅ ｗｈｅｒｅ ｃ＝５ ａｎｄ ｄ＞１０を考える。テーブルに列ａ、ｂ、ｃ、およびｄが存在することに留意されたい。この例示的なクエリでは、射影部／段階は、ｓｅｌｅｃｔ ａｖｇ（ａ）、ｓｕｍ（ｂ） ｆｒｏｍ ｔｈｅ ｔａｂｌｅであり、選択部／段階は、ｗｈｅｒｅ ｃ＝５ ａｎｄ ｄ＞１０である。このクエリでは、述語は、列ｃに対してｃ＝５（すなわち、５）であり、述語は、列ｄに対してｄ＞１０（すなわち、＞１０）である。

ＦｌａｓｈＱｕｅｒｙＦｉｌｅの選択演算子は、ブロック・ヘッダ（ＲＣＨｅａｄｅｒ）を最初に読み取る。ＲＣＨｅａｄｅｒは、行グループごとに全ての列の最大値および最小値に関する統計を含む。列ｄの最大値が１０未満、であるとともに、列ｃの最大値が５未満、または最小値が５を超える全ての行グループがスキップされる。次いで、列ｃおよびｄがそれらの濃度に基づいてランク付けされる。より低い濃度を有する列が最初に評価される。順序付けのための基本的な根拠は、データの読み取りを最少化することである。ここで、以下の論述で理解されるように、ｃは低濃度を有する列であると仮定される。残りの行グループごとに、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、列ｃの一意な値を含むデータ構造で逆直列化され、読み取られるスレッドを並列に発生させる。述語マッチ（処理／演算）は、列ｃの一意な値に対して実行され、述語（すなわち、ｃｏｌｕｍｎ ｃ＝５）が１つまたは複数の一意な値と一致する場合、一致する一意な値に関する行位置ブロブが並列に読み取られる。行位置ブロブの残りがスキップされ、クエリの選択性が検討中の選択列に対して低い場合にデータの読み取りにおいて著しい削減をもたらす。述語が一致しない場合（例えば、ｃｏｌｕｍｎ ｃ＝５に対し）、述語マッチ演算が行グループに対する列ｄに対して（特に一致しない）スキップされ、データの読み取りにおける著しい削減をもたらし（列ｃの全ての行位置ブロブの読み取り、列ｄに対する辞書の読み取りおよび列ｄに対する行位置ブロブの読み取りが読み取りからスキップされる）。ｃおよびｄの述語の両方に一致する行位置の積結合は注釈され、記憶される。対照的に、最新のファイル・フォーマットは、列ｃおよびｄのデータ全体を読み取る（本明細書で論じられたようにスキップすることなく）。

当該シナリオを続けると、ｃｏｌｕｍｎ ｃ＝５の述語が一致した／識別された行グループにおける一意な値と一致するとき、述語マッチ演算は、列ｄの一意な値に対して実行され、述語（すなわち、ｃｏｌｕｍｎ ｄ＞１０）が１つまたは複数の一意な値と一致する場合、一致する一意な値に関する行位置が並列に読み取られる。

実施形態におけるアプローチは、いくつかのシナリオでの選択段階読み取り要件でデータが読み取られる必要性を著しく削減する。

１）述語は、一意な値の一部に一致しない。このケースでは、選択アルゴリズムは、述語に一致しない一意な値に対して行位置を読み取ることをスキップするように構成され、

２）列は、ソートされ、高濃度を有する。このシナリオでは、多数の行グループがスキップされてもよく、

３）選択列の濃度が低く、選択性も低い。このシナリオは、選択の間の最少量のデータの読み込みをもたらす。一意な値の辞書は、低濃度を理由に実際の列データよりもさらに小さい。述語に一致する値がほとんどない場合、行位置ブロブの大多数が読み取られるようになり、著しいデータの削減をもたらす。行位置ブロブは、一意な値に関する行位置の可変長のセットを意味する。セット（または列）の濃度は、セット（または列）の別個のまたは一意な要素の数の測定であることに留意されたい。

表２は、フラッシュ最適化選択アルゴリズム１０４の例を示す。

表２：フラッシュ最適化選択アルゴリズム

Ｃ．フラッシュ最適化射影アルゴリズム

フラッシュ最適化射影アルゴリズム１０６は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０における適切なレイト・マテリアライゼーションの選択アルゴリズム１０４のカーテシ（courtesy）の後に呼び出される。レイト・マテリアライゼーションは、選択段階（ｗｈｅｒｅ ｃ＝５ ａｎｄ ｄ＞１０）を最初に実行することによって、関連する行位置のみに対する射影段階（例えば、ｓｅｌｅｃｔ ａｖｇ（ａ）、ｓｕｍ（ｂ） ｆｒｏｍ ｔｈｅ ｔａｂｌｅ）の間に読み取られる必要があるデータを制限するためにＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０で使用される。射影アルゴリズム１０６は、選択段階の前の演算で判定されたように述語（例えば、ｒｏｗｓ ｗｈｅｒｅ ｃ＝５ ａｎｄ ｄ＞１０）に一致する行位置の最後のセットを受け取る。選択性（すなわち、述語に一致する所与の列内の行の数）が構成可能な閾値よりも低い場合、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、射影列における所望の行位置のファイル・オフセットを計算／判定し、オフセットにおいて値のポイント読み取りを行う。次いで、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、クエリに対する回答を返す。選択性閾値は構成可能であり、作業に基づいて変更することができる。１つの例として、デフォルトの選択性閾値は１．５％であってもよい。この１．５％のデフォルトの選択性閾値は、全ての述語に一致する行位置の数が１．５％未満である場合、データを読み取るためにポイント読み込み（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０による）が使用されることを意味する。１．５％よりも高いクエリの選択性について、クラスタ化されたアプローチが使用される。例では、射影アルゴリズムは、選択アルゴリズムによって（前に）判定された列ａの値の平均および行位置のセットで発生した列ｂの値の合計を返すように構成される。選択性が構成可能な閾値以上である場合、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、行位置をクラスタ化（すなわち、集約）し、１つのファイルのシステム・コールで構成可能な数の行位置の値を読み取る。次いで、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、クエリに対する回答を返す。この技術は、クエリの選択性が低い、すなわち、述語に一致する行位置がほとんどない場合にデータの読み取りを著しく削減する。対照的に、最新のファイル・フォーマットのスキャン・オペレータは、列ａ、ｂのデータ全体を前もって読み取る（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０ではない）。選択性が０．０１％である場合、例として、最新のアプローチは、０．９９％の列のデータの読み取りを不要にさせる。フラッシュなどのランダムにアクセス可能な記憶媒体は、性能に影響することなくそのような目標とされるランダムな読み取りを可能にすることを実現する鍵である。

表３は、フラッシュ最適化射影アルゴリズム１０６の例を示す。

表３：フラッシュ最適化射影アルゴリズム

Ｄ．行グループサイズの判定

最新のファイルフォーマットとは異なり、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、ソート順序、濃度などの列特性を考慮して、より詳しく行グループのサイズを判定し、より良好な性能を得るように構成される。例えば、開示された実験ごとに、列が高濃度を有し、ソートされない場合、より大きな行グループのサイズを有することによって、実施形態では、選択アルゴリズム１０４（スキャン・アルゴリズム）がより高速になる。したがって、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、そのようなケースに対してより大きな行グループのサイズを有するようＦｌａｓｈＱｕｅｒｙＦｉｌｅファイル３０４を構成する。

一方で、列がソートされ、高濃度を有する場合、小さな行グループのサイズが多くの行グループのスキップをもたらすので、小さな行グループのサイズはより良好に作用する。したがって、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、そのようなケースで小さな行グループのサイズを有するようＦｌａｓｈＱｕｅｒｙＦｉｌｅファイル３０４を構成する。例えば、大きな行グループのサイズは、何百万もの行（例えば、１千万）を含んでもよく、小さな行グループのサイズは、何千もの行（例えば、５０，０００）のみを含んでもよい。

Ｅ．高性能符号化

現在、Ｈａｄｏｏｐなどのビッグ・データのエコシステムに対する選択肢の言語であるＪａｖａ（Ｒ）は、高性能の計算に対して本質的に最適化されていない。実験者は、フラッシュからの最大限の性能を利用するために著しく本質的なオーバヘッドを有しないＡＰＩに複数の変更を加え、これを注意深く選択する必要があった。大多数のＡＰＩ、特に、ファイル・システムＡＰＩは、ハードディスクの周辺で設計される。例えば、ＢｕｆｆｅｒｅｄＩｎｐｕｔＳｔｒｅａｍは、それが必要以上にｊａｖａ（Ｒ）のバッファにデータを不必要に読み込む（バッファする）ので小さな４バイトまたは４ＫＢ（キロバイト）でさえ読み取るための最適な選択肢ではない。また、ＩＯが異なるブロックでランダムに行われる場合、多くのロック・チェックを実行し、スレッド安全性に対して設計されたファイル・システムＡＰＩを使用することは必要でない。呼び出しで指定されたオフセットを有する単純なファイル・チャネルを使用することが最も作用していた。直接ＩＯを可能にするＡＰＩは、間接ＩＯよりも良好に作用する。Ｊａｖａ（Ｒ）のクラスの直列化および逆直列化は、非常に時間を要し、実際のクラスのサイズよりもストレージ上の多くの空間を消費する。実験者は、辞書、ルックアップ、行位置ブロブなどの必要なデータ構造の高速かつ空間効率のよい表現、ならびに下層の記憶に対するデータ構造の読み取りおよび書き込みメカニズムを符号化している。Ｃなどの言語は、データ構造の効率的な表現をサポートし、直列化／逆直列化が高価でない。よって、データ構造は、Ｃのバージョンのコードにおける構造体として表されてもよい。

Ｆ．ハイブリッドおよび層構造レイアウト

フラッシュはハードディスク・ドライブよりも高価であり、解決策のために最良の１ドル当たりの性能値を得る方式で賢明に使用される必要がある能力に制限がある。フラッシュはディスクよりも４０〜１０００倍高いランダムなＩＯＰ（ＩＯプロセッサ）性能を得るが、順次帯域幅はディスクよりも２〜７倍高いにすぎない。フラッシュを使用するための純粋な方法は、ポピュラな列の全てをフラッシュに配置することである。しかしながら、ポピュラな列の全てがフラッシュに適切な特性を有しているわけではない。例えば、性別を記録する列のケース（すなわち、男性または女性、よって、２の濃度（男性および女性）のケース）などの、列が非常に低濃度を有するケースを考える。そのような列に対する対象のデータが莫大な量（すなわち、高いポピュラリティ）であるので、データをランダムに読み取るために複数の呼び出しを送出する代わりに１つの呼び出しでデータを単純に順次スキャンすることがよりよい。よって、そのポピュラリティにもかかわらず、そのような列は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０に組み込まれ、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって判定されるような、フラッシュに対する最良の１ドル当たりの性能値を得られない。一方で、高濃度を有する列は、比較的値ごとに読み取られる必要があるデータが少ないので、フラッシュにより適している。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、フラッシュに配置されることになるデータに関して非常に選択的であり、特定のデータベース列に対して正確な層（すなわち、フラッシュ・メモリ７５またはハードディスク・ドライブ２８のいずれか）を決定するために列の特性（本開示の範囲を超えた）に基づいた最適化アルゴリズムを使用する。層構造の設定で、選択列の一意な値を含む辞書は、フラッシュに配置され、レイアウトの残りは、ハードディスク・ドライブに配置される。射影列のケースでは、ルックアップ構造も同様にフラッシュに配置される。

ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって実行されるように、図１６は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅファイル・ブロックのレイアウトを示し、同一の（単一の）データ・ノード／クラスタ１０上でファイル・システム・ブロックにわたる列の分割を示す。図１６は、実施形態に従って判定されるように行および列が行グループにグループ化され（行グループ（ＲＧ_１）ないし行グループ（ＲＧ_Ｎ）など）、フラッシュ・メモリ７５もしくはハードディスク・ドライブ３４、またはその両方での記憶のためにＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって挿入されるような行および列の元の関係を示すテーブル５０２である。行グループは、本明細書で論じられるように利用される。

ＩＶ．評価

実験者は、４０の倍率を選択することによって、４０ＧＢのＴＰＣＨデータセットを生成した。項目テーブルは、可変長の２億４千万行以上および１６列、ならびに特性を有していた。実験者は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０のｓｅｒｄｅの性能をＯＲＣＦｉｌｅのｓｅｒｄｅと比較した。データは、ＨＤＤ最適化ＯＲＣＦｉｌｅフォーマットをフラッシュに配置することと比較して、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０の新たなフラッシュ最適化ファイル・フォーマット、データ・レイアウト、選択アルゴリズム、および射影アルゴリズムの有効性を強調し、ＨＤＤ最適化ＯＲＣＦｉｌｅ選択および射影オペレータを使用してＨＤＤ最適化ＯＲＣＦｉｌｅフォーマットにアクセスするための両方のシナリオでフラッシュに配置された。このシナリオは、データがポピュラと見なされ、アプリケーションがストレージへのクエリを実行していることを通知することなく、より低速なＨＤＤ層からより高速な記憶層に移動するケースで非常に一般的である。結果として、データの新たな位置を認識していないアプリケーションは、ＨＤＤ最適化コードを使用してデータになおもアクセスする。６つのクワッド・コアＩｎｔｅｌ Ｘｅｏｎ ＣＰＵ Ｅ５６４５＠２．４０ＧＨｚおよび９６ＧＢ ＲＡＭを有するサーバに関して評価が行われた。示される結果（図１８に示される）は、ＴＰＣＨクエリ１でのものであり、ある範囲のクエリ選択性を可能にするために複数の述語値が使用された。

Ａ．性能およびデータ分析

図１７は、他のアルゴリズムと比較してＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０に対する正規化されたデータの読み取りを示すグラフ６００を示す。

グラフ７００では、図１８は、実施形態に従ったＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０でのクエリ１の高速化の１つの例を示す。 図１８は、ＯＲＣＦｉｌｅに対するＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０でのＴＰＣＨクエリ１の高速化を示す。図１８は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０でのクエリ１の高速化を示す。クエリは、１つの選択列ｌ＿ｓｈｉｐｄａｔｅおよび６つの射影列を有する。結果の感度を示すために、クエリ１の選択性を、選択列ｌ＿ｓｈｉｐｄａｔｅに対して述語値を変更することによって、１％未満から９８％まで変えた。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、そのｉｏ効率のよいアルゴリズムおよびレイアウトのデータ・カーテシの読み取りが少なく、フラッシュの高い内部ｉｏ並列度および高速ランダム・アクセスを利用するので、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０はＯＲＣＦｉｌｅよりも高速にクエリを処理する。

図１９は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０でのＴＰＣＨクエリ１の選択および射影段階のデータの削減を示す。ＯＲＣＦｉｌｅは単に、最小および最大サマリ情報に基づいて行グループをフィルタリングするために適切な粒度が低いメカニズムを有する。ＦｌａｓｈＱｕｅｒｙＦｉｌｅは、ＦｌａｓｈＱｕｅｒｙＦｉｌｅのフォーマットおよびアクセス方法がフラッシュに対して最適化され、ＯＲＣＦｉｌｅがＨＤＤに対して設計されるようにＯＲＣＦｉｌｅがフラッシュ・メモリにも配置されるシナリオでさえ、ＦｌａｓｈＱｕｅｒｙＦｉｌｅは、最大で２３倍の高速化を達成することが可能である。ｘ軸は選択性を示し、ｙ軸はＦｌａｓｈＱｕｅｒｙＦｉｌｅに対するＯＲＣＦｉｌｅよりも数倍高速な高速化の規模を示す。高速化は、ＯＲＣＦｉｌｅのクエリ処理時間をＦｌａｓｈＱｕｅｒｙＦｉｌｅのクエリ処理時間で除算することによって計算される。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０のフラッシュ最適化ファイル・フォーマット（本明細書で開示される）は、フラッシュ（例えば、フラッシュ７５）からの真の１ドル当たりの性能値を得るために重要である。ＲＣＦｉｌｅに対するＦｌａｓｈＱｕｅｒｙＦｉｌｅのケースでは、新たなフォーマットおよびアルゴリズムのデータの読み取りカーテシの量を削減し、フラッシュの高性能なランダム・アクセスおよびより高いレベルのＩＯ並列度を利用するので、高い高速化が可能となる。ＨＤＤに対して最適化されるＯＲＣＦｉｌｅなどのｓｅｒｄｅは、フラッシュまたはＲＡＭなどの単純により高速な、ランダムにアクセス可能な媒体に配置されるときに性能向上をあまり得られない。

さらに図１９に関して、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、その粒度の高いデータ・スキッピングのデータ・カーテシの著しい削減を達成することが可能である。ＯＲＣＦｉｌｅは、クエリ１に対して選択列におけるデータ全体を結局は読み取ることになる。選択列ｌ＿ｓｈｉｐｄａｔｅの濃度は低く、選択性が低いときのシナリオでは、大多数の行位置データをスキップすることができ、よって、読み取られない。射影アルゴリズムは、射影段階の間にデータの読み取りをさらに削減させる。さらに、選択最適化辞書に基づくレイアウトは、さらに空間効率のよいデータ符号化をもたらし、選択性が９８％程度であるシナリオでさえ、データの削減を支援する理由となる。

ＯＲＣＦｉｌｅは単に、最小および最大サマリ情報に基づいて行グループをフィルタリングするために適切な粒度が低いメカニズムを有する。ＯＲＣＦｉｌｅのメカニズムは、スキップする行グループを発見することができず、クエリ１に対して選択列におけるデータ全体を結局は読み込むことになる。一方で、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、行内グループ・データ・スキッピングを実行し、選択列ｌ＿ｓｈｉｐｄａｔｅにおいてデータの８１％をスキップすることが可能である。ｌ＿ｓｈｉｐｄａｔｅの濃度は低い。辞書サイズは小さく、各々の行位置ブロブは大きい。述語に一致しない行位置ブロブは、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によってスキップされ、データの１９％のみのデータの読み取りとなる。さらに、辞書に基づくレイアウトは、さらに空間効率のよいデータ符号化をもたらし、図１８において選択性が９８％程度であるシナリオでさえ、データの削減を支援する理由となる。データの削減は、射影段階の間に行われ、ＦｌａｓｈＱｕｅｒｙＦｉｌｅは、全ての述語に一致する行位置の最後のセットのみからデータを読み取る。データの削減は、サイズが小さいほどデータがより削減される射影のバッファ・サイズに左右される。しかしながら、性能は、選択性が１％未満でない限り／なるまで、非常に小さな射影バッファ・サイズの影響を受ける。射影アルゴリズムのデータの削減は、射影性（すなわち、射影される列の数）が増加するにつれて増加する。

図２０は、実施形態に従った、データセット・クエリのフラッシュ最適化データ・レイアウトのための方法（そのサブ・コンポーネントを含むＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって実行される）を示す。図１〜１９を参照することができる。種々のアルゴリズム、ならびに選択および射影レイアウトが、フラッシュ・メモリおよびＨＤＤメモリの両方に対して使用されてもよいが、フラッシュ・メモリの最大の速度改善を行うことができることに留意されたい。

ブロック９０５では、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、選択最適化レイアウト４０２に従って選択列をフラッシュ・メモリ７５に記憶する（１つまたは複数のプロセッサ１６を介して）ように構成され、選択最適化レイアウト４０２は、選択列に対するランダム・アクセス（もしくは述語マッチングおよびデータ・スキッピング、またはそれらの組合せ）を最適化するように構成される。

ブロック９１０では、選択列ごとの選択最適化レイアウト４０２は、一意なデータ値のみで満たされた選択列辞書４０３を所与の選択列に記憶することによって（例えば、列Ｃ１のみが一意なデータ値１２１、１３０、１４０、１５０を選択列辞書４０３に記憶するが、データ値の一部は元の関係４０１において繰り返されていてもよい）形成され、一意なデータ値は、ソート順序で選択列辞書４０３に記憶される。

ブロック９１５では、選択列ごとの選択最適化レイアウト４０２は、所与の選択列に２回以上現れる一意なデータ値を重複して記憶することなく、一意なデータ値が所与の選択列内に存在する各々の行位置に対応する行位置指定４０５を記憶することによって形成される。例えば、データ値１２１は、行位置ｒ２、ｒ３、ｒ６で３回発生するが（元の関係４０１において）、データ値１２１は、図８における辞書４０３に１回のみ一意に記憶される。

所与の選択列に対する選択最適化レイアウトは、単一のオフセットを行位置指定において同一の一意なデータ値を有する個々の行位置に記憶することによって形成される。例えば、図１０はオフセット構造４５０（例えば、フラッシュ・メモリ７５における記憶位置）を有し、オフセット構造４５０は、全てが同一の一意なデータ値１２１を有する個々の行位置ｒ２、ｒ３、ｒ６、ｒ９、ｒ１０、ｒ１１、ｒ１３（行位置指定／リスト４０５）に対応するオフセットＯ_１を記憶する。図１０における列Ｃ１について、一意なデータ値１２１が辞書４０３に１回のみ記憶される。

同一の一意なデータ値を有する個々の行位置は、行位置指定４０５内の同一のメモリ位置に記憶される。例えば、個々の行位置ｒ２、ｒ３、ｒ６、ｒ９、ｒ１０、ｒ１１、ｒ１３は、図１０での行位置指定／リスト４０５における単一／同一のメモリ位置に記憶される。

個々の行位置の各々は、所与の選択列における同一の一意なデータ値に対応し、それによって、同一の一意なデータ値への一致によって、同一の一意なデータ値を有しない他の個々の行位置を読み取る必要なく、個々の行位置の各々が同一のメモリから読み取られるようになる。図１０では、演算２は、述語ｃ１＝１３０およびｃ１＝１５０に対する一意なデータ値１３０および１５０にそれぞれ一致する。演算３は、一意なデータ値１３０に一致するための個々の行位置ｒ１、ｒ４、および、一意なデータ値１５０に一致するための個々の行位置ｒ５、ｒ１２、ｒ１４を含むメモリ位置である対応する行位置ブロブを取り出す。

ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、射影最適化レイアウト４０４に従って、射影列をフラッシュ・メモリ７５に記憶するように構成され、射影最適化レイアウト４０４は、射影列へのランダム・アクセスを最適化するように構成される。射影列ごとの射影最適化レイアウト４０４は、一意なデータ値のみで満たされた射影列辞書４０８を所与の射影列に記憶することによって形成され、一意なデータ値は、ソート順序で射影列辞書４０８に記憶される。例えば、射影列辞書４０８は、図９における一意なデータ値６００、６０２、６０３、６７０、６８０を１回のみ記憶するが、図７における元の関係４０１は、それらのデータ値の一部を繰り返す。射影列ごとの射影最適化レイアウト４０４は、所与の射影列で２回以上現れる一意なデータを重複して記憶することなく、一意なデータ値の各々に対する行位置ごとのインデックス（別のケースでは、行位置ごとのオフセット）を含むルックアップ構造４０６を所与の射影列に記憶すること（一意なデータ値の各々に対する行位置ごとのサイズとともに）を含む。

所与の射影列ごとの射影最適化レイアウトは、所与の射影列において同一の一意なデータ値を有する個々の行位置に対するインデックス（別のケースでは、同一のサイズおよび同一のオフセット）をルックアップ構造に記憶することによって形成され、それによって、個々の行位置が所与の射影列における全ての行位置を読み取る必要なく読み取られるようになる。図９における行位置ｒ４およびｒ６に対するルックアップ構造４０６では、オフセットｏｆｆ_ｒ４およびｏｆｆ_ｒ６は、それらの対応する一意なデータ値６７０に対して同一である。同様に、（図９における行位置ｒ４およびｒ６に対するルックアップ構造４０６では）データ・サイズ（キロバイト）ｓｉｚｅ_ｒ４およびｓｉｚｅ_ｒ６は、それらの対応する一意なデータ値６７０に対して同一である。

所与の射影列ごとの射影最適化レイアウトは、所与の射影において別の同一の一意なデータ値を有する他の個々の行位置に対する別の同一のサイズおよび別の同一のオフセットをルックアップ構造に記憶することによって形成される。例えば、図９における行位置ｒ５およびｒ７に対するルックアップ構造４０６では、それらの行位置は、列ｃ３におけるそれらの同一の対応する一意なデータ値６８０に対して同一のオフセット（値）ｏｆｆ_ｒ５およびｏｆｆ_ｒ７、ならびに同一のサイズｓｉｚｅ_ｒ５およびｓｉｚｅｒ_７を有する。

ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、データセットに対して実行されることになるクエリを受け取るように構成され、クエリは、射影部および選択部を含む。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、選択部を実行し、その後クエリの射影部を実行するように構成される（本明細書ではレイト・マテリアライゼーションとも称される）。選択部は、選択部におけるルールに従って一致することになる述語を含む。射影部は、一意なデータをデータセットから取り出す要件を含む。

選択部を実行することは（ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０によって）、述語に対する範囲外にある統計を有する行グループをスキップするために所与の選択列に対する行グループの統計（すなわち、図６におけるメタデータ・ヘッダ）を読み取ることを含み、所与の選択列の行グループに対する統計を読み取ることは、読み取り時に行グループ自体における実際の一意なデータ値を読み取る必要なく実行される。行グループは、ともにグループ化されている所与の選択列における行である（図１６に示されるように）。スキップされていない所与の選択列の残りの行グループについて、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、所与の選択列の残りの行グループ（スキップされていない行グループ）に対する選択列辞書４０３における一意なデータ値を、各スレッドが個々の行グループを処理するマルチスレッド方式で取り出すように構成される。スレッドは、プロセッサによって実行される一連のプログラム命令である。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、一致する一意な値を発見するために残りの行グループに対して選択列辞書４０３における一意なデータ値に対して述語の述語マッチングを実行するように構成される。ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０は、スキップされた行グループ位置を取り出す（または読み取る）ことなく、所与の選択列における一致する一意な値に対する行位置のみを取り出す。

クエリの射影部を実行することは、一致する一意な値を取り出すために、一致する一意な値に対する行位置の各々に対してオフセット（例えば、ルックアップ構造４０６における）を取り出すことを含む。クエリに対する回答を返すために、行位置の一致する一意な値に関してクエリの射影部における要件を実行する（単純に一致する一意な値を取り出すことであってもよい）。射影部は、データ値をデータセットから取り出す要件を含んでもよい。クエリの射影部／段階は、ＦｌａｓｈＱｕｅｒｙＦｉｌｅ８０に、一致する一意な値で何が行われるかを指示する。

さらにフラッシュ・メモリに関して、フラッシュ・メモリは、当業者によって理解されるように、電気的に消去および再プログラムすることができる電子不揮発性コンピュータ記憶媒体である。ＮＡＮＤおよびＮＯＲ論理ゲートにちなんで命名される２つの主なタイプのフラッシュ・メモリが存在する。個々のフラッシュ・メモリ・セルの内部特性は、対応するゲートと同様の特性を示す。ＮＡＮＤタイプフラッシュ・メモリは、ブロックで（またはページで）書き込みおよび読み取りをすることができ、概して、デバイス全体よりもはるかに小さい。ＮＯＲタイプのフラッシュによって、単一の機械語（バイト）が書き込まれ（消去された位置に）または読み取られることが独立して可能になる。フラッシュ・メモリは、フローティング・ゲート・トランジスタから構成されたメモリ・セルのアレイに情報を記憶する。従来のシングルレベル・セル（ＳＬＣ）素子では、各セルが１ビットの情報のみを記憶する。トリプルレベル・セル（ＴＬＣ）素子を含むマルチレベル・セル（ＭＬＣ）素子として知られる一部のより新しいフラッシュ・メモリは、そのセルのフローティング・ゲートに印加する電荷の複数のレベルの間で選択することによって、セルごとに２ビット以上を記憶することができる。

さらにハードディスク・ドライブに関して、ハードディスク・ドライブ（ＨＤＤ）は、磁気素材で被膜された高速回転ディスク（プラッタ）を使用してデジタル情報を記憶および取り出すために使用されるデータ記憶デバイスである。ＨＤＤは、電源が停止されたときでさえそのデータを保持する。ＨＤＤは、データを表面から読み取り、表面に書き込むための移動するアクチュエータ・アーム上に配置された磁気ヘッドを有する１つまたは複数の剛体（「ハード」）高速回転ディスク（プラッタ）から構成される。

本発明の種々の実施形態の説明は、例示を目的に提示されているが、包括的であることを意図しているわけでなく、開示された実施形態を限定することも意図していない。説明された実施形態の範囲および主旨から逸脱することなく、多くの変更および変形が当業者にとって明らかとなる。本明細書で使用される用語は、実施形態の原理、実際の適用もしくは市場で発見される技術への技術的改善を最良に説明し、または他の当業者が本明細書で開示された実施形態を理解することを可能にするために選択された。

本発明は、システム、方法、もしくはコンピュータ・プログラム製品、またはそれらの組合せであってもよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体を含んでもよい。

コンピュータ可読記憶媒体は、命令実行デバイスによる使用のために命令を保持および記憶することができる有形デバイスとすることができる。コンピュータ可読記憶媒体は例えば、電子記憶装置、磁気記憶装置、光学式記憶装置、電磁気記憶装置、半導体記憶装置子、または上記のいずれかの適切な組合せであってもよいが、それらに限定されない。コンピュータ可読記憶媒体のさらなる特定の例の非包括的なリストは、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリ・メモリ（ＲＯＭ）、消去可能なプログラマブル・リードオンリ・メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク・リードオンリ・メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリ・スティック、フロッピー（Ｒ）・ディスク、パンチカードまたは命令が記録された溝内の凸構造などの機械的符号化装置、および上記のいずれかの適切な組合せを含む。本明細書で使用されるコンピュータ可読記憶媒体は、無線波、他の自由に伝播する電磁波、導波路および他の伝送媒体を通じて伝播する電磁波（例えば、ファイバ光学ケーブルを通る光パルス）、または有線を通じて伝送される電気信号などの一時的信号自体であると解釈されない。

本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／プロセシング・デバイスに、あるいはネットワーク、例えば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワークもしくは無線ネットワーク、またはそれらの組合せを介して外部コンピュータもしくは外部記憶装置にダウンロードされてもよい。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータもしくはエッジ・サーバ、またはそれらの組合せを含んでもよい。各コンピューティング／プロセシング・デバイスにおけるネットワーク・アダプタ・カードまたはネットワーク・インタフェースは、コンピュータ可読プログラム命令をネットワークから受け取り、それぞれのコンピューティング／プロセシング・デバイスのコンピュータ可読記憶媒体に記憶するためにコンピュータ可読プログラム命令を転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、初期設定データ、あるいはＳｍａｌｌｔａｌｋ（Ｒ）もしくはＣ＋＋などのオブジェクト指向プログラミング言語、または「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの従来の手続き型プログラミング言語を含む１つもしくは複数のプログラミング言語のいずれかの組合せで記述されたソース・コードもしくはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に、ユーザのコンピュータ上で部分的に、スタンドアロン・ソフトウェア・パッケージとして、ユーザのコンピュータ上で部分的にかつリモート・コンピュータで部分的に、またはリモート・コンピュータもしくはサーバ上で全体的に実行してもよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含む、いずれかのタイプのネットワークを通じてユーザのコンピュータに接続されてもよく、または接続は、外部コンピュータに対してなされてもよい（例えば、インターネット・サービス・プロバイダを使用してインターネットを通じて）。一部の実施形態では、例えば、プログラム可能論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラム可能論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行するために、電子回路を個別化するようにコンピュータ可読プログラム命令の状態情報を利用することによってコンピュータ可読プログラム命令を実行してもよい。

本発明の態様は、本発明の実施形態に従った方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャートの例示もしくはブロック図、またはその両方を参照して本明細書で説明される。フローチャートの例示もしくはブロック図、またはその両方の各ブロック、フローチャートの例示もしくはブロック図、またはその両方におけるブロックの組合せは、コンピュータ可読プログラム命令によって実装されてもよい。

それらのコンピュータ可読プログラム命令は、コンピュータのプロセッサまたは他のプログラム可能データ処理装置を介して実行する命令が、フローチャートもしくはブロック図、またはその両方の１つまたは複数のブロックで指定された機能／行為を実装する手段を生成するように、汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供されて、マシンを作り出すものであってよい。それらのコンピュータ可読プログラム命令はまた、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートもしくはブロック図、またはその両方の１つまたは複数のブロックで指定された機能／行為の態様を実装する命令を含む製品を含むように、コンピュータ可読記憶媒体に記憶され、コンピュータ、プログラム可能データ処理装置もしくは他のデバイス、またはそれらの組合せに特定の方式で機能するように指示するものであってもよい。

コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラム可能装置、または他のデバイス上で実行する命令が、フローチャートもしくはブロック図、またはその両方の１つまたは複数のブロックで指定された機能／行為を実行するように、コンピュータ実行プロセスを生成するべく、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードされ、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップを実行させるものであってもよい。

図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に従ったシステム、方法、およびコンピュータ・プログラム製品の考えられる実装形態のアーキテクチャ、機能、および動作を例示している。この点について、フローチャートまたはブロック図における各ブロックは、指定された論理機能を実装するための１つまたは複数の実行可能命令を含む、命令のモジュール、セグメント、または部分を表してもよい。一部の代替的な実装形態では、ブロックで述べられた機能は、図面で述べられた順序と異なって行われてもよい。例えば、含まれる機能に応じて、連続して示される２つのブロックは実際には、実質的に同時に実行されてもよく、または時には、ブロックは、逆順序で実行されてもよい。ブロック図もしくはフローチャートの例示、またはその両方のブロック、およびブロック図もしくはフローチャートの例示、またはその両方のブロックの組合せは、指定された機能もしくは動作を実行し、または専用ハードウェアおよびコンピュータ命令の組合せを実行する専用ハードウェアベース・システムによって実装されてもよい。

Claims (13)

1. クエリに対するデータセットのフラッシュ最適化データ・レイアウトのための方法であって、
   プロセッサによって、選択最適化レイアウトに従って、選択列をフラッシュ・メモリに記憶するステップを含み、
   前記選択最適化レイアウトは、述語マッチングおよびデータ・スキッピングを最適化するように構成され、
   前記選択最適化レイアウトは、選択列ごとに、
   一意なデータ値で満たされた選択列辞書を所与の選択列に記憶するステップであって、前記一意なデータ値は、ソート順序で前記選択列辞書に記憶される、前記記憶するステップと、
   前記所与の選択列に２回以上現れる前記一意なデータ値のいずれも重複して記憶することなく、前記一意なデータ値が前記所与の選択列内に存在する各々の行位置に対応する行位置指定を記憶するステップと
   によって形成される、方法。
2. 前記選択最適化レイアウトは、前記所与の選択列に対し、前記行位置指定において同一の一意なデータ値を有する個々の行位置に対する単一のオフセットを記憶することによって形成される、請求項１に記載の方法。
3. 前記同一の一意なデータ値を有する前記個々の行位置は、前記行位置指定内で同一のメモリ位置に記憶される、請求項２に記載の方法。
4. 前記同一の一意なデータ値に対する一致によって、前記同一の一意なデータ値を有しない他の個々の行位置を読み取る必要なく、前記個々の行位置の各々が前記同一のメモリ位置から読み取られるように、前記個々の行位置は各々、前記所与の選択列における前記同一の一意なデータ値に対応する、請求項３に記載の方法。
5. 射影最適化レイアウトに従って、射影列を前記フラッシュ・メモリに記憶するステップをさらに含み、前記射影最適化レイアウトは、前記射影列へのランダム・アクセスを最適化するように構成され、
   前記射影最適化レイアウトは、射影列ごとに、
   一意なデータ値で満たされた射影列辞書を所与の射影列に記憶することであって、前記一意なデータ値は、ソート順序で前記射影列辞書に記憶される、前記記憶することと、
   前記所与の射影列に２回以上現れる前記一意なデータ値のいずれも重複して記憶することなく、前記一意なデータ値の各々に対する行位置ごとのインデックスを含むルックアップ構造を前記所与の射影列に記憶することと
   によって形成される、請求項１に記載の方法。
6. 前記射影最適化レイアウトは、前記所与の射影列に対し、前記所与の射影列における全ての行位置を読み取る必要なく、個々の行位置が読み取られるように、前記所与の射影列において同一の一意なデータ値を有する前記個々の行位置に対するインデックスを前記ルックアップ構造に記憶することによって形成される、請求項５に記載の方法。
7. 前記射影最適化レイアウトは、前記所与の射影列に対し、前記所与の射影列において別の同一の一意なデータ値を有する他の個々の行位置に対する他のインデックスを前記ルックアップ構造に記憶することによって形成される、請求項６に記載の方法。
8. 前記データセットに対して実行されることになるクエリを受け取るステップであって、
   前記クエリは射影部および選択部を含む、前記受け取るステップと、
   前記選択部を実行するステップと、次いで前記クエリの前記射影部を実行するステップと
   をさらに含み、
   前記選択部は、前記選択部におけるルールに従って一致することになる述語を含み、
   前記射影部は、前記一意なデータ値を前記データセットから取り出すための要件を含む、請求項１に記載の方法。
9. 前記選択部を実行するステップは、前記述語の範囲外にある統計を有する行グループをスキップするために前記所与の選択列に対する行グループの統計を読み取るステップを含み、前記所与の選択列の前記行グループに対する前記統計を読み取るステップは、前記読み取り時に前記行グループにおける前記一意なデータ値を読み取る必要なく実行され、
   前記行グループは、ともにグループ化されている前記所与の選択列における行であり、
   前記選択部を実行するステップは、さらに、
   スキップされていない前記所与の選択列の残りの行グループに対し、前記所与の選択列の前記残りの行グループに対する前記選択列辞書における前記一意なデータ値を、各スレッドが個々の行グループを処理するマルチスレッド方式で取り出すステップと、
   一致する一意な値を発見するために前記残りの行グループに対する前記選択列辞書における前記一意なデータ値に対して前記述語の述語マッチングを実行するステップと、
   前記所与の選択列における前記一致する一意な値に対する行位置のみを取り出すステップと
   を含む、請求項８に記載の方法。
10. 前記クエリの前記射影部を実行するステップは、前記一致する一意な値を取り出すために前記一致する一意な値に対する前記行位置の各々に対するオフセットを取り出すステップと、
    前記クエリに対する回答を返すために前記行位置の前記一致する一意な値に関する前記クエリの前記射影部における要件を実行するステップと
    を含む、請求項９に記載の方法。
11. クエリに対するデータセットのフラッシュ最適化記憶のための装置であって、
    請求項１〜１０の何れか１項に記載の方法の各ステップを実行する、コンピュータ・ハードウェアによる手段を備える、装置。
12. 請求項１〜１０の何れか１項に記載の方法の各ステップをコンピュータに実行させる、
    コンピュータ・プログラム。
13. 請求項１２に記載の前記コンピュータ・プログラムをコンピュータ可読記憶媒体に記憶した、コンピュータ可読記憶媒体。
    

Images