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

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

Info

Publication number
JP6639420B2
JP6639420B2 JP2016571407A JP2016571407A JP6639420B2 JP 6639420 B2 JP6639420 B2 JP 6639420B2 JP 2016571407 A JP2016571407 A JP 2016571407A JP 2016571407 A JP2016571407 A JP 2016571407A JP 6639420 B2 JP6639420 B2 JP 6639420B2
Authority
JP
Japan
Prior art keywords
data
row
column
projection
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.)
Active
Application number
JP2016571407A
Other languages
English (en)
Other versions
JP2017518584A (ja
Inventor
カウシィク、リニ
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.)
International Business Machines Corp
Original Assignee
International Business Machines 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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2017518584A publication Critical patent/JP2017518584A/ja
Application granted granted Critical
Publication of JP6639420B2 publication Critical patent/JP6639420B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0238Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • 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/22Indexing; Data structures therefor; Storage structures
    • G06F16/221Column-oriented storage; Management thereof
    • 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/24Querying
    • G06F16/245Query processing
    • G06F16/24569Query processing with adaptation to specific hardware, e.g. adapted for using GPUs or SSDs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/22Arrangements for sorting or merging computer data on continuous record carriers, e.g. tape, drum, disc
    • G06F7/24Sorting, i.e. extracting data from one or more carriers, rearranging the data in numerical or other ordered sequence, and rerecording the sorted data on the original carrier or on a different carrier or set of carriers sorting methods in general
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10Providing a specific technical effect
    • G06F2212/1041Resource optimization
    • G06F2212/1044Space efficiency improvement
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72Details relating to flash memory management
    • G06F2212/7208Multiple device management, e.g. distributing data over multiple flash devices

Landscapes

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

Description

本発明は、クエリ処理の間に使用されるフラッシュ最適化データ(flash-optimizeddata)・レイアウトおよびデータ・アクセス・アルゴリズムに関する。
用語「ビッグ・データ」は、手持ちのデータベース管理ツールまたは従来のデータ処理アプリケーションを使用して処理するのが困難になる、非常に大きく、かつ複合的なデータセットの任意の集合に対する広い用語として作られ、すぐに受け入れられてきた。課題は、取得、整理、記憶、検索、共有、転送、分析および視覚化を含む。より大きなデータセットに向かう傾向は、データの全体量が同一である別個のより小さなセットと比較して、単一の大きな関連データセットを分析することで追加の情報が導出可能なことに起因しており、相関関係を発見して、ビジネスの動向をつかみ、調査の品質を判定し、病気を防ぎ、法的引用をリンクし、犯罪に対処し、道路の交通状況をリアルタイムで判定することを可能にする。
2012年に、合理的な時間量で処理可能なデータセット・サイズの限界は、おおよそエクサバイトのデータ、すなわち、数百万テラバイトであった。科学者は、気象学、ゲノミクス、コネクトミクス、複雑な物理特性シミュレーション、ならびに生物学的および環境的調査を含む多くの分野において、大きなデータセットに起因する限界に時折直面する。こうした限界は、インターネット検索、財務、およびビジネス情報学にも影響を及ぼす。データセットは、サイズが増大している。これは、部分的には、ユビキタス情報検知モバイル・デバイス、エアリアル・センサ技術(リモート検知)、ソフトウェア・ログ、カメラ、マイクロフォン、無線周波数識別(RFID)リーダ、および無線センサ・ネットワークによって、データセットがさらに収集され続けているためである。世界の技術的な一人当たり情報記憶容量は、1980年代以降おおよそ40か月ごとに2倍になっている。2012年の時点では、毎日2.5エクサバイト(2.5×1018)のデータが作成されていた。
ビッグ・データは、ほとんどの関係データベース管理システムならびにデスクトップ統計および視覚化パッケージと連動させるのが難しく、代わりに、何十、何百、またはさらには何千ものサーバで動作する大規模な並列ソフトウェアを必要とする。何が「ビッグ・データ」と考えられるかは、データセットを管理する組織の能力、ならびにその領域でデータセットを処理および分析するのに従来使用されているアプリケーションの能力に応じて変わる。一部の組織では、数百ギガバイトものデータに初めて直面することで、データ管理オプションを再検討する必要性が生じ得る。別の組織では、データ・サイズが重大な検討事項になる前に、数十または数百テラバイトを取り扱うことができる。ビッグ・データは通常、許容可能な経過時間内にデータを管理および処理するための一般的に使用されるソフトウェア・ツールの能力を超えたサイズを有するデータセットを含む。
ビッグ・データ・クエリ・エンジンのためのフラッシュ最適化列指向データ・レイアウト方法、装置、およびコンピュータ・プログラム(データ・アクセス・アルゴリズム)を提供することである。
一実施形態に従って、クエリに対するデータセットのフラッシュ最適化データ・レイアウトのための方法が提供される。方法は、プロセッサによって、選択最適化レイアウト(selection optimized layout)に従って、選択列をフラッシュ・メモリに記憶するステップを含み、選択最適化レイアウトは、述語マッチング(predicate matching)およびデータ・スキッピング(data skipping)を最適化するように構成される。選択最適化レイアウトは、選択列ごとに、一意なデータ値で満たされた選択列辞書を所与の選択列に記憶することによって形成され、一意なデータ値は、ソート順序で選択列辞書に記憶される。選択最適化レイアウトは、所与の選択列に2回以上現れる一意なデータ値のいずれも重複して記憶することなく、一意なデータ値が所与の選択列内に存在する各々の行位置に対応する行位置指定を記憶することによって形成される。
一実施形態に従って、クエリに対するデータセットのフラッシュ最適化記憶(flash-optimizedstorage)のための装置が提供される。装置は、プロセッサおよびコンピュータ実行可能命令を含むメモリを含み、コンピュータ実行可能命令は、プロセッサによって実行されるときに、プロセッサに動作を実行させる。動作は、プロセッサによって、選択最適化レイアウトに従って選択列をフラッシュ・メモリに記憶するステップを含み、選択最適化レイアウトは、述語マッチングおよびデータ・スキッピングを最適化するように構成される。選択最適化レイアウトは、選択列ごとに、一意なデータ値で満たされた選択列辞書を所与の選択列に記憶することによって形成され、一意なデータ値は、ソート順序で選択列辞書に記憶される。選択最適化レイアウトは、所与の選択列に2回以上現れる一意なデータ値のいずれも重複して記憶することなく、一意なデータ値が所与の選択列内に存在する各々の行位置に対応する行位置指定を記憶することによって形成される。
一実施形態に従って、クエリに対するデータセットのフラッシュ最適化記憶のためのコンピュータ・プログラム製品が提供される。コンピュータ・プログラム製品は、プログラム命令が具現化されたコンピュータ可読記憶媒体を含み、処理回路によって実行可能なプログラム命令は、処理回路に方法を実行させる。方法は、プロセッサによって、選択最適化レイアウトに従って選択列をフラッシュ・メモリに記憶するステップを含み、選択最適化レイアウトは、述語マッチングおよびデータ・スキッピングを最適化するように構成される。選択最適化レイアウトは、選択列ごとに、一意なデータ値で満たされた選択列辞書を所与の選択列に記憶することによって形成され、一意なデータ値は、ソート順序で選択列辞書に記憶される。選択最適化レイアウトは、所与の選択列に2回以上現れる一意なデータ値のいずれも重複して記憶することなく、一意なデータ値が所与の選択列内に存在する各々の行位置に対応する行位置指定を記憶することによって形成される。
追加の特徴および利点は、本発明の技術を通じて実現される。本発明の他の実施形態および態様は、本明細書で詳細に説明され、特許請求される発明の一部と考えられる。利点および特徴とともに本発明のさらなる良好な理解のために、詳細な説明および図面を参照する。
発明と見なされる主題は特に、本明細書の最後において特許請求の範囲で指摘され、明確に特許請求される。本発明の以下の特徴および他の特徴、ならびに利点が添付図面と併用される以下の詳細な説明から明らかである。
実施形態に従ったクラウド・コンピューティング・ノード/クラスタにおけるコンピュータ・システム/サーバの概略を示す図である。 実施形態に従った1つまたは複数のクラウド・コンピューティング・ノード/クラスタを有するクラウド・コンピューティング環境50を示す図である。 実施形態に従ったコンピュータ・システム/サーバにおける特徴のさらなる詳細を示す図である。 TPCHクエリでの個々の選択列の選択性を示すグラフである。 TPCHクエリ6からの個々の選択列の選択性を示すグラフである。 実施形態に従って、テーブルが、ノード/クラスタでのコンピュータ・システム/サーバにわたる分散ファイル・システム(DFS)ブロックにおける単一のFlashQueryFileファイル/レイアウトとしてどのように論理的に表されるかを示す図である。 テーブルでデータ値を有する列および行の元の関係を示す図である。 実施形態に従った選択列に対する選択最適化レイアウトを示す図である。 実施形態に従った射影(projection)列に対する射影最適化レイアウトを示す図である。 実施形態に従った選択最適化レイアウトを利用する例を示す図である。 実施形態に従った低/中濃度列(cardinality columns)に対する射影最適化レイアウトの実装形態を示す図である。 実施形態に従った高濃度列に対する射影最適化レイアウトの実装形態を示す図である。 実施形態に従った射影もしくは選択列、またはその両方として使用することができる列に対するハイブリッド射影および選択レイアウトを示す図である。 実施形態に従った射影もしくは選択列、またはその両方として使用することができる最適化され、かつ空間効率のよい射影および選択レイアウトを示す図である。 実施形態に従った選択および射影列の両方としてポピュラ(popular)であり、選択最適化データ・レイアウトに記憶された列の例を示す図である。 実施形態に従った行グループにグループ化された行および列を示すテーブルである。 実施形態に従った正規化されたデータの読み取りの比較を示す図である。 実施形態に従った例示的なクエリの高速化を示す図である。 実施形態に従った処理の間のデータの読み取りの削減を示すグラフである。 実施形態に従ったデータセット・クエリのフラッシュ最適化データ・レイアウトのための方法を示すフローチャートである。
ペタバイトのデータに関するアドホックな対話式分析が急速に勢いを増しており、ビッグ・データのウェアハウスがますますポピュラになっている。アドホックなビッグ・データのクエリ処理の性能は、記憶性能に大きく左右される。特殊列指向(columnar)および行−列指向データ・レイアウトならびに関連するアルゴリズムは、クエリで指定された列にのみデータの読み取りを制限することによって、クエリ処理を高速化するために発展してきた。それにもかかわらず、それらのレイアウトは、クエリとは無関係な相当量のデータを結局は読み取ることになる。クエリごとのデータの読み取りの量を最小化し、追加の記憶層としてフラッシュなどのより高速なランダムにアクセス可能な記憶媒体および拡張キャッシュを利用することが、クエリ性能およびスループットをさらに改善するために重要である。フラッシュは、ハードディスク(ハードディスク・ドライブ(HDD)とも称される)とは大きく異なる性能特性を有し、ハードディスクに対して最適化されたデータ・レイアウトおよびアクセス・アルゴリズムでは、フラッシュに関する性能は、最適なものを下回る。HDD最適化レイアウトおよびアルゴリズムは、HDDに特有の高シーク時間を考えるとできるだけランダムなI/Oを回避するように設計され、順次アクセスが、HDDへのランダム・アクセスより何十倍も高速であるので強調される。一方で、ランダム・アクセスは、フラッシュではシーク・ペナルティがないので、フラッシュに関して高速である(HDDよりも40倍〜1000倍高速である)。フラッシュの異なる性能特性は、レイアウトおよびアルゴリズムの根本的な再設計を必要とする。
実施形態は、いわゆるFlashQueryFileにおける新たなフラッシュ最適化データ・レイアウト、FlashQueryFileに対する関連するシリアライザ/デシリアライザ、ならびにFlashQueryFile(におけるテーブル)のアドホックなクエリ処理を高速化するための選択アルゴリズムおよび射影アルゴリズムを提示する。データ・レイアウトはデータがフラッシュに記憶されるテーブル/列構造であることに留意されたい。FlashQueryFileは、不要なデータを積極的にスキップすることによって、クエリごとのデータの読み取りを著しく削減する。ハードディスクに対して設計された最新のレイアウトとは異なり、FlashQueryFileは、高いランダム・アクセス性能ならびにフラッシュで可能な高い内部IO(入力および出力)の並列性を十分に利用することによって、フラッシュからの最大性能を利用するように設計される。FlashQueryFileは、フラッシュに関するHDD最適化行−列指向性データ・レイアウトおよびその関連するアルゴリズムと比較して、4倍〜100倍のTPC−Hクエリの高速化、および1%未満〜98%の範囲のクエリ選択性での29%〜99.08%のデータの削減をもたらす。TPCHは、トランザクション処理性能評議会(TPC)によるアドホックな意思決定支援ベンチマークであることに留意されたい。
Hive、BigQuery、BigSQL、Impala、Presto、およびHAWQなどのビッグ・データのウェアハウスがますます当たり前となっている。ペタバイトのデータに対してアドホックな分析(OLAP)SQLクエリを対話形式で実行させる能力は、ビジネスでは極度に重要となっている。事前計算されたキューブなど、分析クエリを高速化するための従来のOLAP技術は、ビッグ・データのケースでは機能しない。これは、ビッグ・データ・セットの規模が何倍もあり、全ての次元にわたってキューブを維持することが非常に高額だからである。クエリのアドホックな性質を考えると、インデックス付けまたはキャッシングなどの技術はいずれの支援にもならない。クエリが到達するときにデータがキャッシュに存在しないことがあり、または分析クエリは一般的に履歴データとともに直近のデータにアクセスするので、データが大きすぎてキャッシュに保持することができないことがある。結果として、記憶装置からキャッシュされていないデータに高速にアクセスする能力は、アドホックなクエリの対話形式処理において重要な役割を果たす。記憶性能は、全体的なアドホックな分析クエリ処理時間を削減し、スループットを改善するために重要である。
ビッグ・データのウェアハウスは、ストレージそのものを管理せず、それらに対してデータを記憶するための内在する分散ファイル・システムに依存する。F1/BigQueryは、Hive、ImpalaなどのHadoopシステム上でColossusファイル・システムおよびSQLを使用し、Hadoop分散ファイル・システム(HDFS)を使用する。ビッグ・データのクエリ処理に対して特に設計されたレイアウトおよびアルゴリズムを有するシリアライザ/デシリアライザ(serdeとも称される)は、ファイル・システム(例えば、レコード−列指向(RCFile)、最適化レコード−列指向(ORCFile)、およびParquet)からテーブル・データを読み取り、このファイル・システムにテーブル・データを書き込むために使用される。各serde(すなわち、シリアライザ/デシリアライザ)は、その自身のファイル/データ・レイアウト、メタデータ、メモリ内データ構造、テーブル読み取り、スキャン、および挿入(ingest)オペレータを定義する。それらのserdeは、それらがテーブルでの全ての列を読み取る代わりにクエリに現れる列にのみデータの読み取りを制限するので、クエリごとのデータの読み取りの量を削減する。しかしながら、それらのシリアライザ/デシリアライザは、クエリで全ての列に対して列指向テーブル・データ全体を順次スキャンし、結局は、列のデータが全てクエリに関係するわけではない場合に、多くの無関係なデータも読み取ることになる。ORCFileは、述語に基づいて非常に粒度を低くしていくつかのデータをスキップするためにORCFileが利用する最大および最小値などの列に関するサマリ情報を維持することによってテーブル・スキャン操作のオーバヘッドを削減することを試みる。この技術は、選択句での列の列データがソートされ、高濃度(多数の異なる値)を有しているときにデータをスキップするのに効果的である。しかしながら、列の大多数は、本質的にソートされず、低濃度を有する。クエリごとに読み取られる必要があるデータをさらに削減するために粒度が高い、行内グループ・データ・スキッピングを可能にするio効率がよいレイアウトおよび技術を開発する必要性がある。
この開示は、クラウド・コンピューティングに関する説明を含むが、本明細書に記載される教示の実装形態は、クラウド・コンピューティング環境に限定されないことが事前に理解される。むしろ、本発明の実施形態は、現在知られている、または後に開発されるいずれかの他のタイプのコンピューティング環境とともに実装されることが可能である。クラウド・コンピューティングは、最小限の管理努力またはサービスのプロバイダとの対話で即時にプロビジョニングおよび解放することができる構成可能なコンピューティング・リソース(例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシン、およびサービス)の、共有プールへの便利なオンデマンドのネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、少なくとも5つの特性、少なくとも3つのサービス・モデル、および少なくとも4つの配置モデルを含んでもよい。
ここで図1を参照して、クラウド・コンピューティング・ノード/クラスタの例の概略が実施形態に従って示される。クラウド・コンピューティング・ノード/クラスタ10は、ビッグ・データを記憶/処理する際に利用することができる適切なクラウド・コンピューティング・ノード/クラスタの1つの例にすぎず、本明細書で説明される実施形態の使用または機能の範囲についてのいかなる限定も示唆しないことが意図される。いずれにせよ、クラウド・コンピューティング・ノード/クラスタ10は、本明細書で示される機能のいずれかを実装し、もしくはいずれかを実行し、またはその両方を行うことが可能である。
クラウド・コンピューティング・ノード/クラスタ10では、多数の他の汎用または専用コンピューティング・システム環境または構成で動作する複数のコンピュータ・システム/サーバ12が存在する。複数のコンピュータ・システム/サーバ12は、接続82(ファイバ光学など)を通じて接続される。1つのコンピュータ・システム/サーバ12の特定の詳細が図1に示されるが、詳細は、コンピュータ・ノード/クラスタ10における他のコンピュータ・システム/サーバ12に適用される。コンピュータ・システム/サーバ12での使用に適切であってもよい公知のコンピューティング・システム、環境、もしくは構成、またはそれらの組合せの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドもしくはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラム可能家庭用電化製品、ネットワークPC、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記システムもしくはデバイスのいずれかを含む分散クラウド・コンピューティング環境などを含むが、それらに限定されない。
コンピュータ・システム/サーバ12は、コンピュータ・システムによって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な状況で説明されてもよい。概して、プログラム・モジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、およびデータ構造などを含んでもよい。コンピュータ・システム/サーバ12は、通信ネットワークを通じてリンクされるリモート処理デバイスによってタスクが実行される分散クラウド・コンピューティング環境で実施されてもよい。分散クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ記憶装置を含むローカルおよびリモートのコンピュータ・システム記憶媒体の両方に位置してもよい。
図1に示されるように、クラウド・コンピューティング・ノード/クラスタ10におけるコンピュータ・システム/サーバ12は、汎用コンピューティング・デバイスの形式で示される。コンピュータ・システム/サーバ12のコンポーネントは、1つまたは複数のプロセッサ16と、システム・メモリ28と、システム・メモリ28を含む種々のシステム・コンポーネントをプロセッサ16に結合するバス18とを含んでもよいが、それらに限定されない。プロセッサ16は、当業者によって理解されるように、コンピュータ実行可能命令を読み取り、処理し、実行するための処理回路(プロセッサ回路)を含む。
バス18は、様々なバス・アーキテクチャのうちのいずれかを使用したメモリ・バスまたはメモリ・コントローラ、周辺機器用バス、アクセラレイテッド・グラフィックス・ポート、およびプロセッサまたはローカル・バスを含むいくつかのタイプのバス構造のいずれかのうちの1つまたは複数を表す。例として、かつ非限定的に、そのようなアーキテクチャは、インダストリ・スタンダード・アーキテクチャ(ISA)バス、マイクロ・チャネル・アーキテクチャ(MCA)バス、拡張ISA(EISA)バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション(VESA)ローカル・バス、およびペリフェラル・コンポーネント・インタコネクト(PCI)バスを含む。
コンピュータ・システム/サーバ12は一般的に、様々なコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム/サーバ12によってアクセス可能ないずれかの利用可能な媒体であってもよく、それは、揮発性および不揮発性媒体、着脱可能および着脱不能媒体の両方を含む。システム・メモリ28は、ランダム・アクセス・メモリ(RAM)30もしくはキャッシュ・メモリ32、またはその両方などの揮発性メモリの形式であるコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム/サーバ12はさらに、他の着脱可能/着脱不能、揮発性/不揮発性コンピュータ・システム記憶媒体を含んでもよい。単に例として、記憶システム34は、着脱不能、不揮発性磁気媒体(図示せず、一般的に「ハード・ドライブ」、「ハードディスク」、もしくは「ハードディスク・ドライブ」、またはそれらの組合せと称される)から読み取り、それらに書き込むために設けられてもよい。図示しないが、着脱可能、不揮発性磁気ディスク(例えば、「フロッピー(R)・ディスク」)から読み取り、それらに書き込むための磁気ディスク・ドライブ、およびCD−ROM、DVD−ROMもしくは他の光学媒体などの着脱可能、不揮発性光ディスクから読み取り、それらに書き込むための光ディスク・ドライブが設けられてもよい。そのような例では、各々が1つまたは複数のデータ媒体インタフェースによってバス18に接続されてもよい。以下でさらに示され、かつ説明されるように、メモリ28は、本発明の実施形態の機能を実行するように構成されるプログラム・モジュールのセット(例えば、少なくとも1つの)を有する少なくとも1つのプログラム製品を含んでもよい。
メモリ28は例として、かつ非限定的に、オペレーティング・システム、1つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データを含んでもよい。オペレーティング・システム、1つもしくは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データ(または、それらのいくつかの組合せ)は、ネットワーク環境の実装形態を含んでもよい。
加えて、コンピュータ・システム/サーバ12は、フラッシュ・メモリ75(フラッシュとも称される)を含む。フラッシュ・メモリ75は、実施形態に従って本明細書で論じられるハードディスク・ドライブ34とともにビッグ・データを記憶する。フラッシュ・メモリ75は、FlashQueryFile80を含む。FlashQueryFile80は、メモリ28の他の部分に記憶されてもよい。FlashQueryFile80は、本明細書で説明される実施形態の機能もしくは方法、またはその両方を実行するプログラム・モジュール42(1つまたは複数のソフトウェア・アプリケーションであってもよい)を有する。FlashQueryFile80は、本明細書でさらに論じられるアルゴリズムを実装してもよい。FlashQueryFile80の特徴が単一のコンピュータ・システム/サーバ12で強調されるが、FlashQueryFile80(およびその機能)は、コンピューティング・ノード/クラスタ10における他のコンピュータ・システム/サーバ12にわたって分散されてもよい。FlashQueryFile80は、本明細書で論じられる実施形態を実装するのに必要な全てのソフトウェア要素で構成される。
コンピュータ・システム/サーバ12はまた、キーボード、ポインティング・デバイス、ディスプレイ24などの1つもしくは複数の外部デバイス14、ユーザがコンピュータ・システム/サーバ12と対話することを可能にする1つもしくは複数のデバイス、またはコンピュータ・システム/サーバ12が1つもしくは複数の他のコンピューティング・デバイスと通信することを可能にするいずれかのデバイス(例えば、ネットワーク・カード、モデムなど)、あるいはそれらの組合せと通信してもよい。そのような通信は、入力/出力(I/O)インタフェース22を介して行うことができる。さらにまた、コンピュータ・システム/サーバ12は、ネットワーク・アダプタ20を介して、ローカル・エリア・ネットワーク(LAN)、汎用ワイド・エリア・ネットワーク(WAN)、もしくはパブリック・ネットワーク(例えば、インターネット)、またはそれらの組合せと通信することができる。示されるように、ネットワーク・アダプタ20は、バス18を介して、コンピュータ・システム/サーバ12の他のコンポーネントと通信する。図示されないが、他のハードウェアもしくはソフトウェア・コンポーネント、またはその両方がコンピュータ・システム/サーバ12とともに使用されてもよいことが理解されるべきである。例は、マイクロコード、デバイス・ドライバ、冗長プロセッサ、外部ディスク・ドライブ・アレイ、RAIDシステム、テープ・ドライバ、およびデータ・アーカイブ・ストレージ・システムなどを含むが、それらに限定されない。
ここで図2を参照して、ビッグ・データのウェアハウスとして見なされることがある例示的なクラウド・コンピューティング環境50が示される。図示されるように、クラウド・コンピューティング環境50は、例えば、携帯情報端末(PDA)もしくは携帯電話54A、デスクトップ・コンピュータ54B、ラップトップ・コンピュータ54C、または自動車コンピュータ・システム54N、あるいはそれらの組合せなどのクラウド・コンシューマによって使用されるローカル・コンピューティング・デバイスが通信することのできる1つまたは複数のクラウド・コンピューティング・ノード10を含む。クラウド・コンピューティング環境50は、実施形態に従ってコンピューティング・デバイス54A〜Nからのデータの記憶、処理、およびクエリを行う多数のノード/クラスタ10を含んでもよい。ノード/クラスタ10は、接続84(ファイバ光学接続など)を介して相互に通信してもよい。それらは、上記で説明されたプライベート(Private)、コミュニティ(Community)、パブリック(Public)、もしはハイブリッド(Hybrid)のクラウド、またはそれらの組合せなどの1つまたは複数のネットワークで物理的に、または仮想的にグループ化されてもよい(図示せず)。これによって、クラウド・コンピューティング環境50が、インフラストラクチャ、プラットフォームもしくはソフトウェア、またはそれらの組合せを、ローカル・コンピューティング・デバイス上でリソースを維持することをクラウド・コンシューマが必要としないサービスとして供給することが可能になる。図2に示されるコンピューティング・デバイス54A〜Nのタイプは例示のみであることが意図され、コンピューティング・ノード10およびクラウド・コンピューティング環境50はネットワークもしくはネットワーク・アドレス指定可能接続(例えば、ウェブ・ブラウザを使用した)、またはその両方のいずれかのタイプを介していずれかのタイプのコンピュータ化デバイスと通信することができることが理解される。図3は、図面を不明確にしないようにいくつかの特徴を省略しつつ、実施形態に従ったコンピュータ・システム/サーバにおける特徴のさらなる詳細を示す。
ビッグ・データについて、3つの方法、1)IO効率のよいserdeおよび列指向レイアウトを使用することによってクエリごとにスキャンされる必要があるデータを削減すること、2)より高いIOスループットのために並列度の増加に依存すること、または3)データに高速アクセスするためにメモリもしくはフラッシュなどのより高速な媒体を利用すること、あるいはそれらの組合せでクエリ処理のために記憶性能を高めることができる。この開示は、実施形態に従って方法1)〜3)を使用して記憶性能を高めることに焦点を当てている。本開示は、行内グループ・レベルで列指向データの粒度の高いスキップによって、クエリごとのデータの読み取りを削減して、クエリ処理の性能を高めることが可能になる新たなメカニズムを提供する。
最新のserdeは、パラメータとともにアーキテクチャの決定、データ構造、射影アルゴリズム、選択アルゴリズム、および結合アルゴリズムがHDDの基本的な性能特性に基づいているハードディスク(HDD)に対して設計される。HDDに特有な高シーク時間を考えると、ランダムなI/Oができるだけ回避され、順次アクセスがHDDに対するランダム・アクセスより何十倍も高速なので、それらが強調される。記憶階層においてフラッシュなどのより高速かつランダムにアクセス可能な記憶媒体を利用する一般的な方法は、リアクティブ層(reactive tiering)を介したものとなっている。リアクティブ層では、記憶モジュールは、データへのアクセス・パターンを監視し、高性能フラッシュ層(すなわち、フラッシュ・メモリ)に頻繁にアクセスされているデータを移動させる。そのような移動は、いかなるアプリケーションでも認識することなく透過的に行われる。結果として、アプリケーションは、ハードディスクに対して本質的に設計された同一のアルゴリズム、プレフェッチ・メカニズム、API(アプリケーション・プログラム・インタフェース)でフラッシュに存在しているデータにアクセスすることを継続する。結果として、達成される性能は、実施形態で開示されるフラッシュ最適化アルゴリズムおよびコードで達成可能な性能の一部にしかならない。最新技術で使用されるように、既存のSQL(Structured English Query Language)ファイルうちの1つの単純なデータ配置は、フラッシュの形式に合わせ、HDD最適化アルゴリズムおよび前提条件を使用しても性能向上および粒度の高いデータ・スキッピングをほとんど利用することが可能でないが、これらは、そうでない場合、そのようなランダムにアクセス可能な媒体で達成可能である。1ドルごとの最適な性能を絞り出してより高価なフラッシュを正当化するために、順次にアクセスされるHDDからフラッシュなどのランダムにアクセス可能な記憶媒体への移行は、基本的な設計の決定、データ・レイアウト、serdeの選択および射影オペレータの最調査を必須とする。
しかしながら、実施形態は、コンピュータ・ノード/クラスタ10に記憶されたビッグ・データに対するSQLに対し、FlashQueryFile80と称される新規なフラッシュ最適化シリアライザ/デシリアライザを提供する。FlashQueryFileの選択アルゴリズム、射影アルゴリズム、挿入アルゴリズム、データ・レイアウト、およびメタデータが1ドルごとの最適な性能を得るためにフラッシュ(フラッシュ・メモリ75)などのランダムにアクセス可能な記憶装置に対して最適化される。FlashQueryFile80は、アプリケーションが認識する方式でフラッシュ層(フラッシュ・メモリ75)においてフラッシュに適切な、ポピュラな列のサブセットの予測的な配置を認識した記憶層であり、それに対するメカニズムを提供する。これによって、FlashQueryFile80がアドホックな分析クエリに対して重要な性能保証をもたらすことが可能になる。FlashQueryFile80は、根本的にデータ構造およびメタデータを粒度の高いデータ・スキッピングを可能とするように再設計し、述語プッシュダウン(predicate pushdown)およびレイト・マテリアライゼーション(latematerialization)を利用することによって、選択および射影の間にクエリに絶対に必要なデータのみを読み取ることによってクエリ処理の待ち時間を低減させる。FlashQueryFile80はまた、フラッシュによって可能となる内部IOの並列度によって行われることが可能となるその選択アルゴリズムにおけるデータ・アクセスの並列度を利用する。FlashQueryFileは、スキャン・アルゴリズムにおける順次およびランダム・アクセスのバランスをとる際にフラッシュ75の特性を注意深く考慮し、それは、各ランダム・アクセスがそれと関連付けられたAPIのオーバヘッドをも有するので非常に重要である。1つの大きな順次アクセスの代わりに単純に多数の小さなランダム・アクセスを行うことは、APIコールのオーバヘッドが主なものとなる場合に実際に性能を悪化させることがある。最後に、FlashQueryFile80は、フラッシュの性能の利点を得ることが可能になる高性能IO API、オブジェクト・シリアリゼーションおよびデシリアリゼーション、ならびにデータ構造を使用する重要性を示す。積極的にバッファおよびプリフェッチするAPIなどの本質的にハードディスクに対して設計されるAPIを使用することは実際に、フラッシュ75の性能の利点を無効にする可能性がある。
最新の動向として既存の研究は主に、更新が多いオンライン・トランザクション処理(OLTP)の作業負荷にフラッシュを組み込むことに目を向けていた。分析処理(OLAP)の作業負荷においてフラッシュを利用するための研究に限定されており、ビッグ・データのSQLに対してフラッシュを利用する研究が存在しない。OLAPの作業負荷が、それらがほとんど本質的に順次的であり、テーブル全体をスキャンする必要もあるのでフラッシュを利用することができないという一般的な誤認識がある。しかしながら、本開示における拡張的な実験、OLAPの作業負荷およびデータセットの分析、ならびに結果は、この誤認識を覆す。したがって、実施形態は、FlashQueryFile80を介したビッグ・データの分析クエリ処理のためのフラッシュ最適化シリアライザ/デシリアライザ(serde)を提供する。
理解を助けるために説明の目的で、以下で表題および副表題が設けられることに留意されたい。しかしながら、表題および副表題は限定を意味するものではない。
I.ビッグ・データ・エコシステムにおいてフラッシュを使用するサポート/根拠
フラッシュは、ビッグ・データの記憶階層でますます一般的となっている。フラッシュは、ディスクと比較してランダム・アクセスでは40〜1000倍の改善をもたらし、順次帯域幅では2〜7倍の改善をもたらす。フラッシュは、不揮発性であり、よって、データの複製を有する必要性をなくす。フラッシュは、データに対する主要な、かつ唯一の層としての機能を果たすことができる。一方で、RAMの揮発性は、不揮発性媒体におけるデータの追加の持続的な複製を必須とし、ビッグ・データのシステムにおいて大きな問題である重要なデータの複製をもたらす。フラッシュ・デバイスが、複数のチャネルを通じてフラッシュ・メモリ・コントローラに接続されるフラッシュ・メモリ・パッケージのアレイ上に構築されるので、フラッシュによって、ディスクよりもさらに高いレベルの、同時IOのためのIOの並列度が可能になる。論理ブロックは、独立した同時データ・アクセスを可能にする複数のフラッシュ・メモリ・パッケージにわたって縞状に配置される(striped)。フラッシュの内部IOの並列度は、さらに高い性能に対してさらに利用されてもよい。
フラッシュは、容量制約RAMよりも高価でなく、追加のRAMを追加するよりも二次キャッシュとしてより良好に利用されもする。クエリおよび反復計算に対してよりHadoopをより高速にすることに関する大多数の最近の研究は、非常に大きなRAMのサイズに大きく依存する。フラッシュは、それがさらに低いコストでRAMよりもさらに高い容量を可能にするのでRAMよりもさらに高い1ドル当たりの性能を達成することができる。フラッシュはまた、ハードディスクよりも大幅にエネルギー効率が高く、エネルギーが比例し、さらに、エネルギー・コストの削減が所有することの全コストに関して重要な影響を及ぼす、ビッグ・データ・クラスタへの記憶のための魅力的な選択肢とさせる。さらに、フラッシュは、Map削減ジョブのマップ出力を記憶するために非常に望ましく、著しい量の中間的データをもたらす性質および他のベンチマークの3倍に性能を増加させる。
全体的に、高性能、省スペース、低消費電力、コスト削減、およびフラッシュの不揮発性は、実施形態に従って、ビッグ・データのクラスタにおける記憶層/キャッシュとして大いに望ましいものとさせる。
II.粒度の高いデータ・スキッピングの機会
図4は、TPCHクエリにおける個々の選択列の選択性を示すグラフ200である。グラフ200は、種々のTPCHクエリにおける各選択列のクエリ述語に一致する行を示す。列の選択性は、クエリ(Q)の述語に一致するその列内の行の数である。例えば、所与の列が100%の選択性を有する場合、これは、列における全ての行が述語に一致することを意味する。所与の列が25%の選択性を有する場合、これは、列における行の4分の1がクエリの述語に一致することを意味する。
当業者は、SQLクエリにおける述語を理解している。例えば、述語は、WHERE句およびHAVING句の検索条件、FROM句の結合条件、および(ブール)値が要求される他の構成で使用される。SQLにおけるWHERE句は、SQLデータ操作言語(DML)ステートメントが、指定された基準を満たす行にのみ作用するべきであることを指定する。基準は、述語の形式で表現される。WHERE句は、SQL DMLステートメントによって作用し、またはクエリによって返される行の数を制限するために使用されてもよい。要するに、SQLのWHERE句は、SELECT、INSERT、UPDATE、またはDELETEステートメントなどのSQLステートメントから生じるもののみを抽出するために使用される。
グラフ200では、x軸はTPCHクエリを示し、y軸は各列における選択性の割合(%)を示す。TPCHクエリ6(Q6)が6億行以上を有する79GB(ギガバイト)のTPCH項目テーブルを対象とすることを前提とする。最新技術では、現在の列指向および行−列指向serdeは、射影(例えば、L_EXTENDEDPRICE、L_DISCOUNT)および選択列(例えば、図5でグラフ210を参照して、L_SHIPDATE、L_DISCOUNT、L_QUANTITYが図4におけるTPCHクエリ6からの例示的な選択列である)において全てのデータ(すなわち、全ての行位置)を読み取る。しかしながら、図5に表されるように、選択列L_SHIPDATEにおける行の15%、L_DISCOUNTにおける18%、およびL_QUANTITYにおける46%のみが個々の列のクエリ述語に一致する。行の1%のみが、射影列L_EXTENDEDPRICEおよびL_DISCOUNTにおける1%のデータのみをクエリに関連するものとさせる3つの選択列にわたって全ての述語に一致する。全体的に、5つの列にわたって16%のデータのみがクエリに関連する。既存のserdeは、1%の関連するデータをまさに射影するようにそれらの射影列からの追加のデータの99%程度を読み取り、選択性が50%に満たないときに選択列からの追加のデータの50%程度を読み取る。同様の傾向が他のクエリに存在し、選択列の選択性がTPCHクエリの大部分に対して1%〜63%の範囲に及ぶ。よって、選択および射影段階の両方でのクエリに関連する列指向データのみを読み取ることができる行内グループの粒度の高いデータ・スキッピング技術は、分析クエリ(本明細書で開示される)ごとに、読み取られる必要があるデータを著しく削減することができる。
III.FlashQueryFile
この章では、本開示は、FlashQueryFile80のフラッシュ最適化データ・レイアウト、挿入アルゴリズム、選択アルゴリズム、および射影アルゴリズムを説明する。
A.データ・レイアウト
図6は、実施形態に従って、ノード/クラスタ10におけるコンピュータ・システム/サーバ12にわたって分散される(FlashQueryFile80によって)複数の分散ファイル・システム(DFS)ブロックに分割される(記憶される)単一のFlashQueryFileファイル/レイアウト304としてテーブルが論理的にどのように表されるかを示す。図6は、メモリ28に記憶されたファイル・ブロック301を示すが、ファイル・ブロック301は、ノード/クラスタ10における複数のコンピュータ・システム/サーバ12にわたって分散される多数のファイル・ブロック301を表す。図6はまた、以下で論じられるようにフラッシュ・メモリ75に記憶されたメタデータ・ヘッダを強調する。
したがって、FlashQueryFileファイル/レイアウト304における列は、各々が構成可能な数の行を含む複数の行グループに水平に区分化される。ファイル・ブロック301は、複数の行グループを含む。FlashQueryFile80は、3つの異なるレベル、1)RCHeaderと称されるブロック・レベル・ヘッダ、2)RGHeaderと称される行−グループレベル・ヘッダ、および3)ColHeaderと称される列レベル・ヘッダでメタデータ・ヘッダを維持する。ヘッダ(すなわち、RCHeader310、RGHeader315、およびColHeader320)は、必要なデータへの高速なランダム・アクセスを促進するためのデータ構造を維持し、粒度の高いデータ・スキッピングを可能にする。メタデータ・ヘッダRCHeader310、RGHeader315、およびColHeader320の各々は、クエリを実行している間(例えば、クエリの選択段階/部)、ファイル・ブロック全体をいつスキップするか(次いで、次のファイル・ブロックにいつ移動するか)、行グループをいつスキップするか(次いで、次の行グループにいつ移動するか)、もしくは列をいつスキップするか(次いで、次の列にいつ移動するか)、またはそれらの組合せについて判定するためにFlashQueryFile80によって読み取ることができるメタデータを含む。例として、選択列325、低濃度の射影列330、および超高濃度の射影列335が示される。
(ファイル・ブロック)RCHeader310は、ファイル・ブロックにおける行グループの番号(n_rgs)およびバージョン番号を含み、バージョン番号は、展開の期間の間に種々のバージョンのファイル・ブロック構造にわたって後方および前方互換を維持する際にFlashQueryFile80ソフトウェアを支援する。
RGHeader315ヘッダは、ファイル・ブロックにおける行グループの開始のオフセット(rg_offset)およびファイル・ブロックにおける行グループのサイズ(rg_size)を含む。RGHeader315はまた、行グループに存在する行および列の数を含む。例えば、行グループのサイズがファイル・ブロックに対して1千万行になるように構成される場合、rg_rowsフィールドは、値として1千万を含む。
ColHeader320は、ファイル・ブロックにおける種々の考えられる列指向レイアウトに対するファイル・オフセット・ポインタを維持する。列の辞書のファイル・オフセットおよびサイズは、u_offsetおよびu_sizeでそれぞれ維持される。u_offsetおよびu_sizeフィールドは、高速射影および選択のために辞書(例えば、選択辞書もしくは射影辞書、またはその両方)を利用するFlashQueryFileレイアウトに対して満たされる。l_offsetおよびl_sizeフィールドは、射影−最適化レイアウトで使用されるルックアップ構造のファイル・オフセットを含む。フィールドd_offsetおよびd_sizeは、そのままで記憶される(例えば、濃度=1を有する列がいずれの辞書もなしにそのままで記憶される)列のデータのファイル・オフセットを含む。FlashQueryFile80によって実行されるように、矢印341、342、343、344、345、346、347、348、349、350、351、352、353、354は、メタデータ・ヘッダの関係および使用を示す。矢印341〜354は、ファイル・ブロック301において並べられたオフセットが示しているオフセット・フィールドとデータ構造との間の関係を示す。
全ての構造におけるデータ型は、空間効率を維持する観点で注意深く選択されている。FlashQueryFile80は、FlashQueryFileファイル304(挿入アルゴリズム102によって決定される)で2つのデータ・レイアウト、一方は、クエリの選択段階/部に対して最適化され、他方は、クエリの射影段階/部に対して最適化される。実験の見解から、述語値、ならびに列の順序および数がアドホックなクエリにわたって変化する間、一部の列は、射影または選択列のいずれかとしてポピュラとなる傾向がある。例えば、TPCHデータセットでは、2つの列、L_EXTENDEDPRICE(図示せず)およびL_DISCOUNTが最もポピュラな射影列である。それらのポピュラリティは、TPCHが金銭的なベンチマークとしてモデル化されるので、直感的に理解でき、それらの数字列は金銭の問題となり(deal with money)、数値に関して集約を行うことができる。L_SHIPDATE(図5における)などの日付型を有する列は、日付が一般的に分析クエリにおける重要な次元であるので選択列として非常にポピュラである。同様に、主キーおよび外部キーは、ポピュラな選択列である。BlinkDBの論文は、Facebookから実世界のクエリの分析に基づいている選択列に関する同様の見解を有し、列の20%のサブセットが80%のアドホックなクエリの選択句で行われている。この見解に基づいて、FlashQueryFile80は、列指向データに対する3つのデータフォーマット、すなわち、ポピュラな選択列に対する高速選択のために最適化された第1のフォーマット、ポピュラな射影列に対する高速射影のために最適化された第2のフォーマット、射影もしくは選択列、またはその両方(クエリにおける異なる回数)として使用されている列に対して使用されるハイブリッド・レイアウトである第3のフォーマット、を供給する。デフォルトのレイアウトは、ハイブリッド・フォーマットであり、そこでは、アドミニストレータもしくはプレディクタ・モジュール、またはその両方(FlashQueryFile80における)は、ハイブリッド・レイアウトよりもさらに空間効率をよくするための選択専用または射影専用レイアウトを選択することができる。産業的追跡の前の分析はまた、選択列のセットがアドホックな分析クエリでさえ非常に予測可能なままであることを発見してきた。そのような見解によって案内されるように、FlashQueryFile80(挿入アルゴリズム102を介した)によって、ユーザもしくはクエリ・エンジン、またはその両方が、テーブルにおける一部の列を、射影された列のみ、選択された列のみ、もしくは射影された列および選択された列の組合せ、またはそれらの組合せである列としてマーク付けすることが任意選択で可能になる。したがって、FlashQueryFile80(挿入アルゴリズム102を介した)は、空間効率のために(FlashQueryFileファイル304における)そのデータ・レイアウトの決定において、この情報(すなわち、射影のみされた列、選択のみされた列、もしくは組合せ、またはそれらの組合せである列としてテーブルにあるマーク付けされた列)の係数を利用する。挿入アルゴリズム102が以下のテーブル表1で説明される。主キーは行を一意に識別する列また列のグループである。テーブルごとに主キーを有するべきであり、テーブルは2つ以上の主キーを有することはできない。主キーの特性は、テーブルの第1の列にあるように列の定義の一部として指定されてもよく、またはそれは、CREATE TABLEステートメントの別個の句として指定されてもよい。外部キーは、その値が別の(または同一の)テーブルの主キーにおける値と一致するべきである1つのテーブルにおける列または列のセットである。外部キーは、その主キーの参照と言われる。外部キーは、データの整合性を維持するためのメカニズムである。
表1:フラッシュ最適化挿入アルゴリズム
Figure 0006639420
Figure 0006639420
Figure 0006639420
1)選択最適化データ・レイアウト
図7は、テーブルにおいてデータ値を有する列および行の元の関係401を示す。テーブルは、実施形態に従って、FlashQueryFile80によってコンピュータ・システム/サーバ10に挿入されて、フラッシュ・メモリに対して最適化される。実施形態は、元の関係にテーブルを記憶しない。実施形態に従って、図8は、(基本)選択最適化レイアウトを示し、図9は、可変サイズのポピュラな射影列に対する(基本)射影最適化レイアウトを示す。実施形態に従って、図8〜15は、例示的なレイアウトであり、図6におけるファイル・ブロック301のさらなる詳細および特定の例を示す。実施形態に従って、図7におけるテーブルの元の関係401から、高速述語マッチ(predicate match)を促進し、選択句/部(例えば、述語を含むwhere句)の間のデータの読み取りを削減するために、図8に示される選択最適化データ・レイアウト402が設計されている(記憶のためにFlashQueryFile80によって)。潜在的な選択列ごとに、FlashQueryFile80は、列の各行グループで発生する一意な値を抽出し、一意な値を選択辞書403に隣接して記憶する。列ヘッダは、一意な値の開始に対するオフセット(off)を維持する。次に、値ごとに、FlashQueryFile80は、各々の一意な値が列で発生する(図8に図示されないが、図6に示される)行位置のセットのオフセット450(省略してoffもしくは0、またはその両方)および長さ(すなわち、サイズ)を記憶する。最後に、FlashQueryFile80は、一意な値ごとに行位置のセットを行位置指定405に記憶する。オフセット450は、個々の一意な値に対する行位置の各々の集合/グループ化の位置に対応する。メタデータ・ヘッダでは、FlashQueryFile80はまた、行グループごとに列におけるエントリの最大値、最小値、中間値、平均値および総数を記録(記憶)する。最大値は、列の行グループごとに発生する最大値を意味し、最小値は、列の行グループごとに発生する最小値を意味し、中間値は、列の行グループごとに発生する中間値を意味し、平均値は、列の行グループごとに発生する平均値を意味する。総数は、列の行グループにおける行の数を意味する。
図7における元の関係テーブル401と比較して、選択最適化データ・レイアウト402は、同一のデータ値の記憶を繰り返すことなく列C1を記憶する新たな方法である。図8は、選択辞書403(列ヘッダにおける)が列C1に対する一意なデータ値を記憶し、一意なデータ値が121、130、140、150である例を示す。行位置指定405(列ヘッダにおける)は、元の関係401において一意な値を含んだ列C1における行位置ごとに行位置(すなわち、名前)を記憶する。例えば、一意なデータ値121は、行位置指定405における行位置r2、r3、およびr6(元の関係に対し)であるが、一意な値121は、1回のみ記憶され、3つの異なる行位置に対して複製されない。一意なデータ値130は、行位置指定405における行位置r1およびr4(行位置ブロブにおける)であるものとして表される。一意なデータ値140は、行位置指定405における行位置r7(行位置ブロブにおける)であるものとして表される。一意なデータ値150は、行位置指定405における行位置r5(行位置ブロブにおける)であるものとして表される。各々の行位置ブロブは、同一の一意な値を有するものとして表される1つまたは複数の行位置の集合である。オフセット450のうちの各々の1つは、特定の行位置ブロブの開始に対するものである。
この例では、FlashQueryFile80が列C1を選択最適化レイアウト402のための1つの選択列として選択することを前提とする。FlashQueryFile80は、一意な値121、130、140、150となる、列C1における各々の行グループで発生する一意な値を判定し、それらの一意な値をメモリ28に隣接して記憶する。一意とは、FlashQueryFile80が、列C1における同一の値の記憶を繰り返す必要なく、選択された列C1における各々の一意な値の単一のエントリのみを必要とすることを意味する。FlashQueryFile80は、最初の一意な値121の開始など、一意な値の開始にオフセット(off)を記憶するように列ヘッダを構成する。FlashQueryFile80が、各々の値が列で発生する行位置のセットのオフセット450および長さ(すなわち、サイズ)を記憶するので、FlashQueryFile80は、一意な値121、130、140、150(メモリ28に並んで記憶される)ごとのデータの正確な位置を判定することができる。
2)射影最適化データ・レイアウト
元の関係テーブル401から取得(挿入)されるように、図9は、射影に対してのみ使用される、すなわち、select句に現れる可変長列に対して使用される射影最適化データ・レイアウト404(メモリ28に記憶された)を示す。列が可変長である場合、FlashQueryFile80は、列において各々の行位置のオフセットおよびサイズを含むルックアップ構造406を維持する。次いで、列データは、列の濃度が低い場合に、辞書408に配置される。そうでない場合、データは単純にファイル・システム・ブロック上に順次配置される。列ヘッダは、ルックアップ構造406およびデータ(値)のオフセットを維持する。(特定の)列が固定長である場合、ルックアップ構造が使用されず、データが単純にファイル・システム・ブロックに順次配置される。FlashQueryFile80は、後のルックアップを支援するために列ヘッダにおけるフィールド長を記録する。
図7における元の関係テーブル401と比較して、射影最適化データ・レイアウト404は、同一のデータ値の記憶を繰り返す必要なくことなく列C3を記憶する新たな方法である。例えば、射影辞書408は、一意なデータ値600、602、603、670、680(すなわち、データ値を繰り返すことなく)(のみ)を記憶する。ルックアップ構造406は、各々のデータ値のメモリにおける各々のデータ値のオフセット(off)およびサイズ(例えば、バイト、キロバイトなど)を記憶する。データ値600が列C3に1回のみ現れるので(すなわち、行1にのみ)、データ値600は、ルックアップ構造406においてoffr1(オフセット)およびsizer2を有する。しかしながら、データ値670は、行4および行6の両方で、列3で2回現れ、したがって、ルックアップ構造406は、offr4およびsizer4を記憶することによって行4を表し、offr6およびsizer6を記憶することによって行6を表す。データ値670は、2つの別個の行4および6に対応するように射影辞書408に1回のみ記憶され、よって、空間を節約し、データ値670の一致があるか(および、列3において単一のデータ値ごとに実際にスキャンする必要なく、ルックアップ構造406(すなわち、メタデータ)をスキャンすることによっていくつの行が列C3において一致するか)を判定することをさらに容易にする。
3)さらなる例示的な選択および射影最適化データ・レイアウト
図10は、実施形態に従った選択最適化レイアウト402(FlashQueryFile80の)を利用する例を示す。図10は、選択最適化レイアウト402に対して各々の行位置(r1〜r14)におけるデータ値(元の関係401からの列C1の追加のデータ値を有する)を示す典型的な列指向データ・レイアウトを示す。図10は、クエリ:Select sum(c2) where c1=130 and c1=150を前提とする。FlashQueryFile80の選択アルゴリズムは、選択最適化レイアウト402から辞書403およびオフセット450を読み取る。FlashQueryFile80の選択アルゴリズムは、C1=130およびC1=150の述語マッチを実行する。最後に、FlashQueryFile80の選択アルゴリズム(のみ)は、行位置リスト405における一致する行位置を読み取り(読み取ろうとし)、行位置リスト405における一致しない行位置をスキップする。判定された行位置は、FlashQueryFile80の射影アルゴリズムに渡される。
図11は、実施形態に従った低/中濃度列(FlashQueryFile80の)に対する射影最適化レイアウト404の実装形態を示す。低および中濃度列は、高濃度列よりも低い濃度を有する。低濃度列は、中濃度列よりも低い濃度を有する。辞書408は、列指向データで発生する全ての一意な値(列C3およびC4に対して)を記憶するように作成される。次に、各々の行位置の列値を辞書値にマッピングするルックアップ構造406がインデックスとともに作成される。図11では、インデックスは、図9に示されるオフセットおよびサイズを使用することなく、辞書408における各エントリにマッピングするためにルックアップ構造406において利用される。ルックアップ構造406内で、indexr1およびindexr2の両方が、辞書408における一意な値Rosa Parksにマッピングする。列ヘッダにおけるl_offsetおよびl_sizeフィールドは、ファイル・ブロック301における直列化されたルックアップ構造のファイル・オフセットを示すように設定される。u_offsetおよびu_sizeフィールドは、ファイル・ブロック301における直列化された辞書を示すように設定される。
図11では、FlashQueryFile80の射影アルゴリズムは、全ての述語に一致する行のリストの入力を受け取る(選択アルゴリズムから)ように構成され、行位置のリストは、r1、r5、およびr7である。FlashQueryFile80は、辞書408(一意な値の)を読み取るように構成される。FlashQueryFile80は、所望の行位置(r1、r5、およびr7など)ごとにルックアップ・テーブル構造406に記憶されたインデックスにおいて辞書をルックアップ(および取り出す)ように構成される。
別の実施形態に従って、図12は、高濃度列に対する別の射影最適化レイアウト404を示す。空間効率および性能の理由のためにこのケースでは辞書が使用されない。列指向データは、ファイル・ブロック301について直列化され、ルックアップ構造406は、可変長列を有する列(列C3について表される)に対する各々の行位置において列のオフセット(例えば、offr1、offr2など)を記憶する。列が高濃度および固定長を有するとき、列C4が例示的な表示である。列ヘッダにおけるl_offsetおよびl_sizeフィールドは、ファイル・ブロック301における直列化されたルックアップ構造を示すように設定される。d_offsetおよびd_sizeフィールドは、ファイル・ブロック301における直列化された列指向データを示すように設定される。
図12では、FlashQueryFile80の射影アルゴリズムは、全ての述語に一致する行のリストの入力を受け取る(選択アルゴリズムから)ように構成され、行位置のリストは、r1、r5、およびr7である。列が可変長を有する場合、FlashQueryFile80は、個々のルックアップ要素(ルックアップ構造406における)を1つのオプションとして読み取り、または行位置をクラスタ化し、ルックアップ構造406のチャンク(要素のグループ)を読み取るように構成される。FlashQueryFile80は、d_offsetを(列ヘッダからの)をルックアップ構造406に記憶されたoff(オフセット)に追加することによって、行位置の値のファイル・オフセットを判定する。列が可変長を有する場合、FlashQueryFile80は、行位置オフセットをd_offset+行位置×フィールド長として計算する。FlashQueryFile80は、グレイにマーク付けされた(すなわち、強調表示された)エントリをフラッシュから直接読み取り、データの残りの読み取りをスキップするように構成される。
実施形態に従って、図13は、クエリに応じて射影もしくは選択列、またはその両方として使用することができる列に対するハイブリッド射影および選択レイアウト480を示す。図13は、選択および射影最適化レイアウト(402および404)と組み合わせたレイアウトを示す。
実施形態に従って、図14は、クエリに応じて射影もしくは選択列、またはその両方として使用することができる列に対する最適化され、かつ空間効率のよい射影および選択レイアウト490を示す。この組み合わされたレイアウト490は、列がソートされる場合のみ使用されてもよい。ルックアップ・テーブルにおける行位置ごとにルックアップ・エントリを維持する代わりに、開始および終了の行位置のみがルックアップ・テーブル491において追跡される。ルックアップ・テーブル491は、各々の一意な値に対応するルックアップ・エントリに逆ポインタを適用することによって、辞書403、408における各々の一意な値に対する行位置ブロブとしての機能を果たす。
図15は、実施形態に従った選択最適化レイアウト402(FlashQueryFile80の)を利用する異なる例を示す。実施形態に従って、図15は、クエリが同一のクエリにおける射影列として選択最適化レイアウト402に配置された列として使用されることであった場合でさえ、射影段階(クエリの)を最適化するメカニズムを示す。例えば、図15は、選択および射影列の両方(ハイブリッドと称されてもよい)としてポピュラな列を示し、FlashQueryFile80は、実施形態に従って、このハイブリッド列(選択および射影列の両方として使用される)を選択最適化データ・レイアウト402に記憶する。FlashQueryFile80において射影処理の前に選択処理が行われる根拠となる。射影アルゴリズムによって必要とされるルックアップ構造(460)は、クエリ処理の実行時間の間に動的に作成される。選択アルゴリズムは、述語に一致する列値および関連する行位置を得る。逆ルックアップ構造460は、行位置を値にマッピングする抽出された情報から作成される。次いで、ルックアップ構造460は、本明細書で射影最適化データ・レイアウトにおいてさらに議論される、対象の行位置に関する値を射影するために射影段階の間に使用される。
図15では、ハイブリッド(FlashQueryFile80の)に対する射影アルゴリズムは、述語列c1=130および列C1=150である全ての述語に一致する行のリストの入力(選択アルゴリズムからの)を受け取るように構成される。FlashQueryFile80は、述語に一致するリストまたは行の入力を受け取り、メモリ内ルックアップ(例えば、辞書403)から直接エントリ(グレイにマーク付けされ/強調表示された)を読み取り、データの残りの読み取りをスキップする。
B.フラッシュ最適化選択アルゴリズム
FlashQueryFileフラッシュ最適化選択アルゴリズム104(スキャン・アルゴリズムとも称される)は、上記で説明されたように、フラッシュに対して最適化され、性能のためにフラッシュで可能になるランダム・アクセスおよび内部並列度を利用する。FlashQueryFile80は、可能な最小データをできるだけ速く読み取ることを目的として設計される。フラッシュ(例えば、フラッシュ・メモリ75)によって、ハードディスク・ドライブよりも同時IO処理でさらなる内部並列度が可能になり、FlashQueryFile80は、フラッシュ最適化選択アルゴリズム104(スキャン・アルゴリズム)を使用することによってフラッシュで可能な並列度を利用する。最新のRCFileおよびORCFileは、各行グループを順次読み取り、FlashQueryFile80は、各行グループを並列に読み取る(すなわち、同時に)。加えて、述語に一致する列値の行位置ブロブも並列に読み取る。次いで、全ての述語に一致する行位置の最後の積結合が、射影アルゴリズム106に渡される。
ここで、選択アルゴリズム104を示すために、演算は、クエリ、select avg(a)、 sum(b) from the table where c=5 and d>10を考える。テーブルに列a、b、c、およびdが存在することに留意されたい。この例示的なクエリでは、射影部/段階は、select avg(a)、sum(b) from the tableであり、選択部/段階は、where c=5 and d>10である。このクエリでは、述語は、列cに対してc=5(すなわち、5)であり、述語は、列dに対してd>10(すなわち、>10)である。
FlashQueryFileの選択演算子は、ブロック・ヘッダ(RCHeader)を最初に読み取る。RCHeaderは、行グループごとに全ての列の最大値および最小値に関する統計を含む。列dの最大値が10未満、であるとともに、列cの最大値が5未満、または最小値が5を超える全ての行グループがスキップされる。次いで、列cおよびdがそれらの濃度に基づいてランク付けされる。より低い濃度を有する列が最初に評価される。順序付けのための基本的な根拠は、データの読み取りを最少化することである。ここで、以下の論述で理解されるように、cは低濃度を有する列であると仮定される。残りの行グループごとに、FlashQueryFile80は、列cの一意な値を含むデータ構造で逆直列化され、読み取られるスレッドを並列に発生させる。述語マッチ(処理/演算)は、列cの一意な値に対して実行され、述語(すなわち、column c=5)が1つまたは複数の一意な値と一致する場合、一致する一意な値に関する行位置ブロブが並列に読み取られる。行位置ブロブの残りがスキップされ、クエリの選択性が検討中の選択列に対して低い場合にデータの読み取りにおいて著しい削減をもたらす。述語が一致しない場合(例えば、column c=5に対し)、述語マッチ演算が行グループに対する列dに対して(特に一致しない)スキップされ、データの読み取りにおける著しい削減をもたらし(列cの全ての行位置ブロブの読み取り、列dに対する辞書の読み取りおよび列dに対する行位置ブロブの読み取りが読み取りからスキップされる)。cおよびdの述語の両方に一致する行位置の積結合は注釈され、記憶される。対照的に、最新のファイル・フォーマットは、列cおよびdのデータ全体を読み取る(本明細書で論じられたようにスキップすることなく)。
当該シナリオを続けると、column c=5の述語が一致した/識別された行グループにおける一意な値と一致するとき、述語マッチ演算は、列dの一意な値に対して実行され、述語(すなわち、column d>10)が1つまたは複数の一意な値と一致する場合、一致する一意な値に関する行位置が並列に読み取られる。
実施形態におけるアプローチは、いくつかのシナリオでの選択段階読み取り要件でデータが読み取られる必要性を著しく削減する。
1)述語は、一意な値の一部に一致しない。このケースでは、選択アルゴリズムは、述語に一致しない一意な値に対して行位置を読み取ることをスキップするように構成され、
2)列は、ソートされ、高濃度を有する。このシナリオでは、多数の行グループがスキップされてもよく、
3)選択列の濃度が低く、選択性も低い。このシナリオは、選択の間の最少量のデータの読み込みをもたらす。一意な値の辞書は、低濃度を理由に実際の列データよりもさらに小さい。述語に一致する値がほとんどない場合、行位置ブロブの大多数が読み取られるようになり、著しいデータの削減をもたらす。行位置ブロブは、一意な値に関する行位置の可変長のセットを意味する。セット(または列)の濃度は、セット(または列)の別個のまたは一意な要素の数の測定であることに留意されたい。
表2は、フラッシュ最適化選択アルゴリズム104の例を示す。
表2:フラッシュ最適化選択アルゴリズム
Figure 0006639420
C.フラッシュ最適化射影アルゴリズム
フラッシュ最適化射影アルゴリズム106は、FlashQueryFile80における適切なレイト・マテリアライゼーションの選択アルゴリズム104のカーテシ(courtesy)の後に呼び出される。レイト・マテリアライゼーションは、選択段階(where c=5 and d>10)を最初に実行することによって、関連する行位置のみに対する射影段階(例えば、select avg(a)、sum(b) from the table)の間に読み取られる必要があるデータを制限するためにFlashQueryFile80で使用される。射影アルゴリズム106は、選択段階の前の演算で判定されたように述語(例えば、rows where c=5 and d>10)に一致する行位置の最後のセットを受け取る。選択性(すなわち、述語に一致する所与の列内の行の数)が構成可能な閾値よりも低い場合、FlashQueryFile80は、射影列における所望の行位置のファイル・オフセットを計算/判定し、オフセットにおいて値のポイント読み取りを行う。次いで、FlashQueryFile80は、クエリに対する回答を返す。選択性閾値は構成可能であり、作業に基づいて変更することができる。1つの例として、デフォルトの選択性閾値は1.5%であってもよい。この1.5%のデフォルトの選択性閾値は、全ての述語に一致する行位置の数が1.5%未満である場合、データを読み取るためにポイント読み込み(FlashQueryFile80による)が使用されることを意味する。1.5%よりも高いクエリの選択性について、クラスタ化されたアプローチが使用される。例では、射影アルゴリズムは、選択アルゴリズムによって(前に)判定された列aの値の平均および行位置のセットで発生した列bの値の合計を返すように構成される。選択性が構成可能な閾値以上である場合、FlashQueryFile80は、行位置をクラスタ化(すなわち、集約)し、1つのファイルのシステム・コールで構成可能な数の行位置の値を読み取る。次いで、FlashQueryFile80は、クエリに対する回答を返す。この技術は、クエリの選択性が低い、すなわち、述語に一致する行位置がほとんどない場合にデータの読み取りを著しく削減する。対照的に、最新のファイル・フォーマットのスキャン・オペレータは、列a、bのデータ全体を前もって読み取る(FlashQueryFile80ではない)。選択性が0.01%である場合、例として、最新のアプローチは、0.99%の列のデータの読み取りを不要にさせる。フラッシュなどのランダムにアクセス可能な記憶媒体は、性能に影響することなくそのような目標とされるランダムな読み取りを可能にすることを実現する鍵である。
表3は、フラッシュ最適化射影アルゴリズム106の例を示す。
表3:フラッシュ最適化射影アルゴリズム
Figure 0006639420
D.行グループサイズの判定
最新のファイルフォーマットとは異なり、FlashQueryFile80は、ソート順序、濃度などの列特性を考慮して、より詳しく行グループのサイズを判定し、より良好な性能を得るように構成される。例えば、開示された実験ごとに、列が高濃度を有し、ソートされない場合、より大きな行グループのサイズを有することによって、実施形態では、選択アルゴリズム104(スキャン・アルゴリズム)がより高速になる。したがって、FlashQueryFile80は、そのようなケースに対してより大きな行グループのサイズを有するようFlashQueryFileファイル304を構成する。
一方で、列がソートされ、高濃度を有する場合、小さな行グループのサイズが多くの行グループのスキップをもたらすので、小さな行グループのサイズはより良好に作用する。したがって、FlashQueryFile80は、そのようなケースで小さな行グループのサイズを有するようFlashQueryFileファイル304を構成する。例えば、大きな行グループのサイズは、何百万もの行(例えば、1千万)を含んでもよく、小さな行グループのサイズは、何千もの行(例えば、50,000)のみを含んでもよい。
E.高性能符号化
現在、Hadoopなどのビッグ・データのエコシステムに対する選択肢の言語であるJava(R)は、高性能の計算に対して本質的に最適化されていない。実験者は、フラッシュからの最大限の性能を利用するために著しく本質的なオーバヘッドを有しないAPIに複数の変更を加え、これを注意深く選択する必要があった。大多数のAPI、特に、ファイル・システムAPIは、ハードディスクの周辺で設計される。例えば、BufferedInputStreamは、それが必要以上にjava(R)のバッファにデータを不必要に読み込む(バッファする)ので小さな4バイトまたは4KB(キロバイト)でさえ読み取るための最適な選択肢ではない。また、IOが異なるブロックでランダムに行われる場合、多くのロック・チェックを実行し、スレッド安全性に対して設計されたファイル・システムAPIを使用することは必要でない。呼び出しで指定されたオフセットを有する単純なファイル・チャネルを使用することが最も作用していた。直接IOを可能にするAPIは、間接IOよりも良好に作用する。Java(R)のクラスの直列化および逆直列化は、非常に時間を要し、実際のクラスのサイズよりもストレージ上の多くの空間を消費する。実験者は、辞書、ルックアップ、行位置ブロブなどの必要なデータ構造の高速かつ空間効率のよい表現、ならびに下層の記憶に対するデータ構造の読み取りおよび書き込みメカニズムを符号化している。Cなどの言語は、データ構造の効率的な表現をサポートし、直列化/逆直列化が高価でない。よって、データ構造は、Cのバージョンのコードにおける構造体として表されてもよい。
F.ハイブリッドおよび層構造レイアウト
フラッシュはハードディスク・ドライブよりも高価であり、解決策のために最良の1ドル当たりの性能値を得る方式で賢明に使用される必要がある能力に制限がある。フラッシュはディスクよりも40〜1000倍高いランダムなIOP(IOプロセッサ)性能を得るが、順次帯域幅はディスクよりも2〜7倍高いにすぎない。フラッシュを使用するための純粋な方法は、ポピュラな列の全てをフラッシュに配置することである。しかしながら、ポピュラな列の全てがフラッシュに適切な特性を有しているわけではない。例えば、性別を記録する列のケース(すなわち、男性または女性、よって、2の濃度(男性および女性)のケース)などの、列が非常に低濃度を有するケースを考える。そのような列に対する対象のデータが莫大な量(すなわち、高いポピュラリティ)であるので、データをランダムに読み取るために複数の呼び出しを送出する代わりに1つの呼び出しでデータを単純に順次スキャンすることがよりよい。よって、そのポピュラリティにもかかわらず、そのような列は、FlashQueryFile80に組み込まれ、FlashQueryFile80によって判定されるような、フラッシュに対する最良の1ドル当たりの性能値を得られない。一方で、高濃度を有する列は、比較的値ごとに読み取られる必要があるデータが少ないので、フラッシュにより適している。FlashQueryFile80は、フラッシュに配置されることになるデータに関して非常に選択的であり、特定のデータベース列に対して正確な層(すなわち、フラッシュ・メモリ75またはハードディスク・ドライブ28のいずれか)を決定するために列の特性(本開示の範囲を超えた)に基づいた最適化アルゴリズムを使用する。層構造の設定で、選択列の一意な値を含む辞書は、フラッシュに配置され、レイアウトの残りは、ハードディスク・ドライブに配置される。射影列のケースでは、ルックアップ構造も同様にフラッシュに配置される。
FlashQueryFile80によって実行されるように、図16は、FlashQueryFileファイル・ブロックのレイアウトを示し、同一の(単一の)データ・ノード/クラスタ10上でファイル・システム・ブロックにわたる列の分割を示す。図16は、実施形態に従って判定されるように行および列が行グループにグループ化され(行グループ(RG)ないし行グループ(RG)など)、フラッシュ・メモリ75もしくはハードディスク・ドライブ34、またはその両方での記憶のためにFlashQueryFile80によって挿入されるような行および列の元の関係を示すテーブル502である。行グループは、本明細書で論じられるように利用される。
IV.評価
実験者は、40の倍率を選択することによって、40GBのTPCHデータセットを生成した。項目テーブルは、可変長の2億4千万行以上および16列、ならびに特性を有していた。実験者は、FlashQueryFile80のserdeの性能をORCFileのserdeと比較した。データは、HDD最適化ORCFileフォーマットをフラッシュに配置することと比較して、FlashQueryFile80の新たなフラッシュ最適化ファイル・フォーマット、データ・レイアウト、選択アルゴリズム、および射影アルゴリズムの有効性を強調し、HDD最適化ORCFile選択および射影オペレータを使用してHDD最適化ORCFileフォーマットにアクセスするための両方のシナリオでフラッシュに配置された。このシナリオは、データがポピュラと見なされ、アプリケーションがストレージへのクエリを実行していることを通知することなく、より低速なHDD層からより高速な記憶層に移動するケースで非常に一般的である。結果として、データの新たな位置を認識していないアプリケーションは、HDD最適化コードを使用してデータになおもアクセスする。6つのクワッド・コアIntel Xeon CPU E5645@2.40GHzおよび96GB RAMを有するサーバに関して評価が行われた。示される結果(図18に示される)は、TPCHクエリ1でのものであり、ある範囲のクエリ選択性を可能にするために複数の述語値が使用された。
A.性能およびデータ分析
図17は、他のアルゴリズムと比較してFlashQueryFile80に対する正規化されたデータの読み取りを示すグラフ600を示す。
グラフ700では、図18は、実施形態に従ったFlashQueryFile80でのクエリ1の高速化の1つの例を示す。 図18は、ORCFileに対するFlashQueryFile80でのTPCHクエリ1の高速化を示す。図18は、FlashQueryFile80でのクエリ1の高速化を示す。クエリは、1つの選択列l_shipdateおよび6つの射影列を有する。結果の感度を示すために、クエリ1の選択性を、選択列l_shipdateに対して述語値を変更することによって、1%未満から98%まで変えた。FlashQueryFile80は、そのio効率のよいアルゴリズムおよびレイアウトのデータ・カーテシの読み取りが少なく、フラッシュの高い内部io並列度および高速ランダム・アクセスを利用するので、FlashQueryFile80はORCFileよりも高速にクエリを処理する。
図19は、FlashQueryFile80でのTPCHクエリ1の選択および射影段階のデータの削減を示す。ORCFileは単に、最小および最大サマリ情報に基づいて行グループをフィルタリングするために適切な粒度が低いメカニズムを有する。FlashQueryFileは、FlashQueryFileのフォーマットおよびアクセス方法がフラッシュに対して最適化され、ORCFileがHDDに対して設計されるようにORCFileがフラッシュ・メモリにも配置されるシナリオでさえ、FlashQueryFileは、最大で23倍の高速化を達成することが可能である。x軸は選択性を示し、y軸はFlashQueryFileに対するORCFileよりも数倍高速な高速化の規模を示す。高速化は、ORCFileのクエリ処理時間をFlashQueryFileのクエリ処理時間で除算することによって計算される。FlashQueryFile80のフラッシュ最適化ファイル・フォーマット(本明細書で開示される)は、フラッシュ(例えば、フラッシュ75)からの真の1ドル当たりの性能値を得るために重要である。RCFileに対するFlashQueryFileのケースでは、新たなフォーマットおよびアルゴリズムのデータの読み取りカーテシの量を削減し、フラッシュの高性能なランダム・アクセスおよびより高いレベルのIO並列度を利用するので、高い高速化が可能となる。HDDに対して最適化されるORCFileなどのserdeは、フラッシュまたはRAMなどの単純により高速な、ランダムにアクセス可能な媒体に配置されるときに性能向上をあまり得られない。
さらに図19に関して、FlashQueryFile80は、その粒度の高いデータ・スキッピングのデータ・カーテシの著しい削減を達成することが可能である。ORCFileは、クエリ1に対して選択列におけるデータ全体を結局は読み取ることになる。選択列l_shipdateの濃度は低く、選択性が低いときのシナリオでは、大多数の行位置データをスキップすることができ、よって、読み取られない。射影アルゴリズムは、射影段階の間にデータの読み取りをさらに削減させる。さらに、選択最適化辞書に基づくレイアウトは、さらに空間効率のよいデータ符号化をもたらし、選択性が98%程度であるシナリオでさえ、データの削減を支援する理由となる。
ORCFileは単に、最小および最大サマリ情報に基づいて行グループをフィルタリングするために適切な粒度が低いメカニズムを有する。ORCFileのメカニズムは、スキップする行グループを発見することができず、クエリ1に対して選択列におけるデータ全体を結局は読み込むことになる。一方で、FlashQueryFile80は、行内グループ・データ・スキッピングを実行し、選択列l_shipdateにおいてデータの81%をスキップすることが可能である。l_shipdateの濃度は低い。辞書サイズは小さく、各々の行位置ブロブは大きい。述語に一致しない行位置ブロブは、FlashQueryFile80によってスキップされ、データの19%のみのデータの読み取りとなる。さらに、辞書に基づくレイアウトは、さらに空間効率のよいデータ符号化をもたらし、図18において選択性が98%程度であるシナリオでさえ、データの削減を支援する理由となる。データの削減は、射影段階の間に行われ、FlashQueryFileは、全ての述語に一致する行位置の最後のセットのみからデータを読み取る。データの削減は、サイズが小さいほどデータがより削減される射影のバッファ・サイズに左右される。しかしながら、性能は、選択性が1%未満でない限り/なるまで、非常に小さな射影バッファ・サイズの影響を受ける。射影アルゴリズムのデータの削減は、射影性(すなわち、射影される列の数)が増加するにつれて増加する。
図20は、実施形態に従った、データセット・クエリのフラッシュ最適化データ・レイアウトのための方法(そのサブ・コンポーネントを含むFlashQueryFile80によって実行される)を示す。図1〜19を参照することができる。種々のアルゴリズム、ならびに選択および射影レイアウトが、フラッシュ・メモリおよびHDDメモリの両方に対して使用されてもよいが、フラッシュ・メモリの最大の速度改善を行うことができることに留意されたい。
ブロック905では、FlashQueryFile80は、選択最適化レイアウト402に従って選択列をフラッシュ・メモリ75に記憶する(1つまたは複数のプロセッサ16を介して)ように構成され、選択最適化レイアウト402は、選択列に対するランダム・アクセス(もしくは述語マッチングおよびデータ・スキッピング、またはそれらの組合せ)を最適化するように構成される。
ブロック910では、選択列ごとの選択最適化レイアウト402は、一意なデータ値のみで満たされた選択列辞書403を所与の選択列に記憶することによって(例えば、列C1のみが一意なデータ値121、130、140、150を選択列辞書403に記憶するが、データ値の一部は元の関係401において繰り返されていてもよい)形成され、一意なデータ値は、ソート順序で選択列辞書403に記憶される。
ブロック915では、選択列ごとの選択最適化レイアウト402は、所与の選択列に2回以上現れる一意なデータ値を重複して記憶することなく、一意なデータ値が所与の選択列内に存在する各々の行位置に対応する行位置指定405を記憶することによって形成される。例えば、データ値121は、行位置r2、r3、r6で3回発生するが(元の関係401において)、データ値121は、図8における辞書403に1回のみ一意に記憶される。
所与の選択列に対する選択最適化レイアウトは、単一のオフセットを行位置指定において同一の一意なデータ値を有する個々の行位置に記憶することによって形成される。例えば、図10はオフセット構造450(例えば、フラッシュ・メモリ75における記憶位置)を有し、オフセット構造450は、全てが同一の一意なデータ値121を有する個々の行位置r2、r3、r6、r9、r10、r11、r13(行位置指定/リスト405)に対応するオフセットOを記憶する。図10における列C1について、一意なデータ値121が辞書403に1回のみ記憶される。
同一の一意なデータ値を有する個々の行位置は、行位置指定405内の同一のメモリ位置に記憶される。例えば、個々の行位置r2、r3、r6、r9、r10、r11、r13は、図10での行位置指定/リスト405における単一/同一のメモリ位置に記憶される。
個々の行位置の各々は、所与の選択列における同一の一意なデータ値に対応し、それによって、同一の一意なデータ値への一致によって、同一の一意なデータ値を有しない他の個々の行位置を読み取る必要なく、個々の行位置の各々が同一のメモリから読み取られるようになる。図10では、演算2は、述語c1=130およびc1=150に対する一意なデータ値130および150にそれぞれ一致する。演算3は、一意なデータ値130に一致するための個々の行位置r1、r4、および、一意なデータ値150に一致するための個々の行位置r5、r12、r14を含むメモリ位置である対応する行位置ブロブを取り出す。
FlashQueryFile80は、射影最適化レイアウト404に従って、射影列をフラッシュ・メモリ75に記憶するように構成され、射影最適化レイアウト404は、射影列へのランダム・アクセスを最適化するように構成される。射影列ごとの射影最適化レイアウト404は、一意なデータ値のみで満たされた射影列辞書408を所与の射影列に記憶することによって形成され、一意なデータ値は、ソート順序で射影列辞書408に記憶される。例えば、射影列辞書408は、図9における一意なデータ値600、602、603、670、680を1回のみ記憶するが、図7における元の関係401は、それらのデータ値の一部を繰り返す。射影列ごとの射影最適化レイアウト404は、所与の射影列で2回以上現れる一意なデータを重複して記憶することなく、一意なデータ値の各々に対する行位置ごとのインデックス(別のケースでは、行位置ごとのオフセット)を含むルックアップ構造406を所与の射影列に記憶すること(一意なデータ値の各々に対する行位置ごとのサイズとともに)を含む。
所与の射影列ごとの射影最適化レイアウトは、所与の射影列において同一の一意なデータ値を有する個々の行位置に対するインデックス(別のケースでは、同一のサイズおよび同一のオフセット)をルックアップ構造に記憶することによって形成され、それによって、個々の行位置が所与の射影列における全ての行位置を読み取る必要なく読み取られるようになる。図9における行位置r4およびr6に対するルックアップ構造406では、オフセットoffr4およびoffr6は、それらの対応する一意なデータ値670に対して同一である。同様に、(図9における行位置r4およびr6に対するルックアップ構造406では)データ・サイズ(キロバイト)sizer4およびsizer6は、それらの対応する一意なデータ値670に対して同一である。
所与の射影列ごとの射影最適化レイアウトは、所与の射影において別の同一の一意なデータ値を有する他の個々の行位置に対する別の同一のサイズおよび別の同一のオフセットをルックアップ構造に記憶することによって形成される。例えば、図9における行位置r5およびr7に対するルックアップ構造406では、それらの行位置は、列c3におけるそれらの同一の対応する一意なデータ値680に対して同一のオフセット(値)offr5およびoffr7、ならびに同一のサイズsizer5およびsizerを有する。
FlashQueryFile80は、データセットに対して実行されることになるクエリを受け取るように構成され、クエリは、射影部および選択部を含む。FlashQueryFile80は、選択部を実行し、その後クエリの射影部を実行するように構成される(本明細書ではレイト・マテリアライゼーションとも称される)。選択部は、選択部におけるルールに従って一致することになる述語を含む。射影部は、一意なデータをデータセットから取り出す要件を含む。
選択部を実行することは(FlashQueryFile80によって)、述語に対する範囲外にある統計を有する行グループをスキップするために所与の選択列に対する行グループの統計(すなわち、図6におけるメタデータ・ヘッダ)を読み取ることを含み、所与の選択列の行グループに対する統計を読み取ることは、読み取り時に行グループ自体における実際の一意なデータ値を読み取る必要なく実行される。行グループは、ともにグループ化されている所与の選択列における行である(図16に示されるように)。スキップされていない所与の選択列の残りの行グループについて、FlashQueryFile80は、所与の選択列の残りの行グループ(スキップされていない行グループ)に対する選択列辞書403における一意なデータ値を、各スレッドが個々の行グループを処理するマルチスレッド方式で取り出すように構成される。スレッドは、プロセッサによって実行される一連のプログラム命令である。FlashQueryFile80は、一致する一意な値を発見するために残りの行グループに対して選択列辞書403における一意なデータ値に対して述語の述語マッチングを実行するように構成される。FlashQueryFile80は、スキップされた行グループ位置を取り出す(または読み取る)ことなく、所与の選択列における一致する一意な値に対する行位置のみを取り出す。
クエリの射影部を実行することは、一致する一意な値を取り出すために、一致する一意な値に対する行位置の各々に対してオフセット(例えば、ルックアップ構造406における)を取り出すことを含む。クエリに対する回答を返すために、行位置の一致する一意な値に関してクエリの射影部における要件を実行する(単純に一致する一意な値を取り出すことであってもよい)。射影部は、データ値をデータセットから取り出す要件を含んでもよい。クエリの射影部/段階は、FlashQueryFile80に、一致する一意な値で何が行われるかを指示する。
さらにフラッシュ・メモリに関して、フラッシュ・メモリは、当業者によって理解されるように、電気的に消去および再プログラムすることができる電子不揮発性コンピュータ記憶媒体である。NANDおよびNOR論理ゲートにちなんで命名される2つの主なタイプのフラッシュ・メモリが存在する。個々のフラッシュ・メモリ・セルの内部特性は、対応するゲートと同様の特性を示す。NANDタイプフラッシュ・メモリは、ブロックで(またはページで)書き込みおよび読み取りをすることができ、概して、デバイス全体よりもはるかに小さい。NORタイプのフラッシュによって、単一の機械語(バイト)が書き込まれ(消去された位置に)または読み取られることが独立して可能になる。フラッシュ・メモリは、フローティング・ゲート・トランジスタから構成されたメモリ・セルのアレイに情報を記憶する。従来のシングルレベル・セル(SLC)素子では、各セルが1ビットの情報のみを記憶する。トリプルレベル・セル(TLC)素子を含むマルチレベル・セル(MLC)素子として知られる一部のより新しいフラッシュ・メモリは、そのセルのフローティング・ゲートに印加する電荷の複数のレベルの間で選択することによって、セルごとに2ビット以上を記憶することができる。
さらにハードディスク・ドライブに関して、ハードディスク・ドライブ(HDD)は、磁気素材で被膜された高速回転ディスク(プラッタ)を使用してデジタル情報を記憶および取り出すために使用されるデータ記憶デバイスである。HDDは、電源が停止されたときでさえそのデータを保持する。HDDは、データを表面から読み取り、表面に書き込むための移動するアクチュエータ・アーム上に配置された磁気ヘッドを有する1つまたは複数の剛体(「ハード」)高速回転ディスク(プラッタ)から構成される。
本発明の種々の実施形態の説明は、例示を目的に提示されているが、包括的であることを意図しているわけでなく、開示された実施形態を限定することも意図していない。説明された実施形態の範囲および主旨から逸脱することなく、多くの変更および変形が当業者にとって明らかとなる。本明細書で使用される用語は、実施形態の原理、実際の適用もしくは市場で発見される技術への技術的改善を最良に説明し、または他の当業者が本明細書で開示された実施形態を理解することを可能にするために選択された。
本発明は、システム、方法、もしくはコンピュータ・プログラム製品、またはそれらの組合せであってもよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体を含んでもよい。
コンピュータ可読記憶媒体は、命令実行デバイスによる使用のために命令を保持および記憶することができる有形デバイスとすることができる。コンピュータ可読記憶媒体は例えば、電子記憶装置、磁気記憶装置、光学式記憶装置、電磁気記憶装置、半導体記憶装置子、または上記のいずれかの適切な組合せであってもよいが、それらに限定されない。コンピュータ可読記憶媒体のさらなる特定の例の非包括的なリストは、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ(RAM)、リードオンリ・メモリ(ROM)、消去可能なプログラマブル・リードオンリ・メモリ(EPROMまたはフラッシュ・メモリ)、スタティック・ランダム・アクセス・メモリ(SRAM)、ポータブル・コンパクト・ディスク・リードオンリ・メモリ(CD−ROM)、デジタル多用途ディスク(DVD)、メモリ・スティック、フロッピー(R)・ディスク、パンチカードまたは命令が記録された溝内の凸構造などの機械的符号化装置、および上記のいずれかの適切な組合せを含む。本明細書で使用されるコンピュータ可読記憶媒体は、無線波、他の自由に伝播する電磁波、導波路および他の伝送媒体を通じて伝播する電磁波(例えば、ファイバ光学ケーブルを通る光パルス)、または有線を通じて伝送される電気信号などの一時的信号自体であると解釈されない。
本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング/プロセシング・デバイスに、あるいはネットワーク、例えば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワークもしくは無線ネットワーク、またはそれらの組合せを介して外部コンピュータもしくは外部記憶装置にダウンロードされてもよい。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータもしくはエッジ・サーバ、またはそれらの組合せを含んでもよい。各コンピューティング/プロセシング・デバイスにおけるネットワーク・アダプタ・カードまたはネットワーク・インタフェースは、コンピュータ可読プログラム命令をネットワークから受け取り、それぞれのコンピューティング/プロセシング・デバイスのコンピュータ可読記憶媒体に記憶するためにコンピュータ可読プログラム命令を転送する。
本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ(ISA)命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、初期設定データ、あるいはSmalltalk(R)もしくはC++などのオブジェクト指向プログラミング言語、または「C」プログラミング言語もしくは同様のプログラミング言語などの従来の手続き型プログラミング言語を含む1つもしくは複数のプログラミング言語のいずれかの組合せで記述されたソース・コードもしくはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に、ユーザのコンピュータ上で部分的に、スタンドアロン・ソフトウェア・パッケージとして、ユーザのコンピュータ上で部分的にかつリモート・コンピュータで部分的に、またはリモート・コンピュータもしくはサーバ上で全体的に実行してもよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク(LAN)もしくはワイド・エリア・ネットワーク(WAN)を含む、いずれかのタイプのネットワークを通じてユーザのコンピュータに接続されてもよく、または接続は、外部コンピュータに対してなされてもよい(例えば、インターネット・サービス・プロバイダを使用してインターネットを通じて)。一部の実施形態では、例えば、プログラム可能論理回路、フィールド・プログラマブル・ゲート・アレイ(FPGA)、またはプログラム可能論理アレイ(PLA)を含む電子回路は、本発明の態様を実行するために、電子回路を個別化するようにコンピュータ可読プログラム命令の状態情報を利用することによってコンピュータ可読プログラム命令を実行してもよい。
本発明の態様は、本発明の実施形態に従った方法、装置(システム)、およびコンピュータ・プログラム製品のフローチャートの例示もしくはブロック図、またはその両方を参照して本明細書で説明される。フローチャートの例示もしくはブロック図、またはその両方の各ブロック、フローチャートの例示もしくはブロック図、またはその両方におけるブロックの組合せは、コンピュータ可読プログラム命令によって実装されてもよい。
それらのコンピュータ可読プログラム命令は、コンピュータのプロセッサまたは他のプログラム可能データ処理装置を介して実行する命令が、フローチャートもしくはブロック図、またはその両方の1つまたは複数のブロックで指定された機能/行為を実装する手段を生成するように、汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供されて、マシンを作り出すものであってよい。それらのコンピュータ可読プログラム命令はまた、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートもしくはブロック図、またはその両方の1つまたは複数のブロックで指定された機能/行為の態様を実装する命令を含む製品を含むように、コンピュータ可読記憶媒体に記憶され、コンピュータ、プログラム可能データ処理装置もしくは他のデバイス、またはそれらの組合せに特定の方式で機能するように指示するものであってもよい。
コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラム可能装置、または他のデバイス上で実行する命令が、フローチャートもしくはブロック図、またはその両方の1つまたは複数のブロックで指定された機能/行為を実行するように、コンピュータ実行プロセスを生成するべく、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードされ、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップを実行させるものであってもよい。
図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に従ったシステム、方法、およびコンピュータ・プログラム製品の考えられる実装形態のアーキテクチャ、機能、および動作を例示している。この点について、フローチャートまたはブロック図における各ブロックは、指定された論理機能を実装するための1つまたは複数の実行可能命令を含む、命令のモジュール、セグメント、または部分を表してもよい。一部の代替的な実装形態では、ブロックで述べられた機能は、図面で述べられた順序と異なって行われてもよい。例えば、含まれる機能に応じて、連続して示される2つのブロックは実際には、実質的に同時に実行されてもよく、または時には、ブロックは、逆順序で実行されてもよい。ブロック図もしくはフローチャートの例示、またはその両方のブロック、およびブロック図もしくはフローチャートの例示、またはその両方のブロックの組合せは、指定された機能もしくは動作を実行し、または専用ハードウェアおよびコンピュータ命令の組合せを実行する専用ハードウェアベース・システムによって実装されてもよい。

Claims (13)

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

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/305,179 US9846567B2 (en) 2014-06-16 2014-06-16 Flash optimized columnar data layout and data access algorithms for big data query engines
US14/305,179 2014-06-16
PCT/IB2015/054387 WO2015193771A1 (en) 2014-06-16 2015-06-10 Flash optimized columnar data layout and data access algorithms for big data query engines

Publications (2)

Publication Number Publication Date
JP2017518584A JP2017518584A (ja) 2017-07-06
JP6639420B2 true JP6639420B2 (ja) 2020-02-05

Family

ID=54836185

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016571407A Active JP6639420B2 (ja) 2014-06-16 2015-06-10 フラッシュ最適化データ・レイアウトのための方法、フラッシュ最適化記憶のための装置、およびコンピュータ・プログラム

Country Status (5)

Country Link
US (3) US9846567B2 (ja)
JP (1) JP6639420B2 (ja)
KR (1) KR101938953B1 (ja)
GB (1) GB2544206B (ja)
WO (1) WO2015193771A1 (ja)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9501550B2 (en) * 2012-04-18 2016-11-22 Renmin University Of China OLAP query processing method oriented to database and HADOOP hybrid platform
US9442954B2 (en) * 2012-11-12 2016-09-13 Datawise Systems Method and apparatus for achieving optimal resource allocation dynamically in a distributed computing environment
US9846567B2 (en) 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
US10127260B2 (en) * 2014-11-25 2018-11-13 Sap Se In-memory database system providing lockless read and write operations for OLAP and OLTP transactions
US10409835B2 (en) * 2014-11-28 2019-09-10 Microsoft Technology Licensing, Llc Efficient data manipulation support
US9952808B2 (en) 2015-03-26 2018-04-24 International Business Machines Corporation File system block-level tiering and co-allocation
JP6893209B2 (ja) * 2015-10-30 2021-06-23 アクシオム コーポレーション 構造化されたマルチフィールドファイルのレイアウトの自動解釈
KR101780652B1 (ko) * 2016-03-11 2017-09-21 주식회사 이디엄 열-지향 레이아웃 파일 생성 방법
CN107360103A (zh) * 2016-05-09 2017-11-17 中国移动通信集团四川有限公司 一种操作维护系统和资源调度方法
EP3465431A4 (en) 2016-05-23 2020-03-25 JPMorgan Chase Bank, N.A. SECURITY DESIGN AND ARCHITECTURE FOR A MULTI-TENANT HADOOP CLUSTER
US10437780B2 (en) * 2016-07-14 2019-10-08 Snowflake Inc. Data pruning based on metadata
US10762071B2 (en) * 2016-11-29 2020-09-01 Sap Se Value-ID-based sorting in column-store databases
US10956469B2 (en) * 2017-01-06 2021-03-23 International Business Machines Corporation System and method for metadata correlation using natural language processing
US10409814B2 (en) * 2017-01-26 2019-09-10 International Business Machines Corporation Network common data form data management
US10585913B2 (en) * 2017-03-20 2020-03-10 Datameer, Inc. Apparatus and method for distributed query processing utilizing dynamically generated in-memory term maps
CN107644070B (zh) * 2017-09-13 2020-09-15 北京柠檬微趣科技股份有限公司 数据索引方法、数据查询方法及电子设备
US10621167B2 (en) 2017-10-26 2020-04-14 Sap Se Data separation and write redirection in multi-tenancy database systems
US10733168B2 (en) * 2017-10-26 2020-08-04 Sap Se Deploying changes to key patterns in multi-tenancy database systems
US10657276B2 (en) 2017-10-26 2020-05-19 Sap Se System sharing types in multi-tenancy database systems
US10740315B2 (en) 2017-10-26 2020-08-11 Sap Se Transitioning between system sharing types in multi-tenancy database systems
US10740318B2 (en) 2017-10-26 2020-08-11 Sap Se Key pattern management in multi-tenancy database systems
US10713277B2 (en) 2017-10-26 2020-07-14 Sap Se Patching content across shared and tenant containers in multi-tenancy database systems
CN110020227B (zh) * 2017-10-31 2021-10-15 北京国双科技有限公司 一种数据排序方法和装置
CN110019218B (zh) 2017-12-08 2023-08-25 阿里巴巴集团控股有限公司 数据存储与查询方法及设备
TWI664527B (zh) * 2018-03-20 2019-07-01 慧榮科技股份有限公司 用來於一記憶裝置中進行初始化之方法、記憶裝置及其控制器以及電子裝置
EP3547166B1 (en) * 2018-03-26 2020-12-02 Hasso-Plattner-Institut für Digital Engineering gGmbH Data placement in hybrid data layouts for tiered htap databases
US10915551B2 (en) 2018-06-04 2021-02-09 Sap Se Change management for shared objects in multi-tenancy systems
US11379450B2 (en) * 2018-10-09 2022-07-05 Oracle International Corporation Relational method for transforming unsorted sparse dictionary encodings into unsorted-dense or sorted-dense dictionary encodings
CN109637278A (zh) * 2019-01-03 2019-04-16 青岛萨纳斯智能科技股份有限公司 大数据教学实验实训平台
US11106674B2 (en) * 2019-03-31 2021-08-31 International Business Machines Corporation Extensible data skipping
US11176133B2 (en) * 2019-04-04 2021-11-16 Sap Se Filter evaluation for table fragments
US11163766B2 (en) * 2019-04-04 2021-11-02 Sap Se Unique key lookup with additional filter
US11327995B2 (en) 2019-09-11 2022-05-10 Micro Focus Llc Complex data type encoding within columnar database
CN110795407B (zh) * 2019-10-14 2022-06-10 华东计算技术研究所(中国电子科技集团公司第三十二研究所) 适用于分布式文件系统的文件随机写方法及系统
US11914589B2 (en) * 2020-02-28 2024-02-27 Sap Se Efficient computation of order by, order by with limit, min, and max in column-oriented databases
US11366796B2 (en) * 2020-04-30 2022-06-21 Oracle International Corporation Systems and methods for compressing keys in hierarchical data structures
US11762559B2 (en) 2020-05-15 2023-09-19 International Business Machines Corporation Write sort management in a multiple storage controller data storage system
US11580022B2 (en) 2020-05-15 2023-02-14 International Business Machines Corporation Write sort management in a multiple storage controller data storage system
KR102175183B1 (ko) 2020-06-09 2020-11-05 이창근 기업 데이터 통합 관리 방법, 장치, 및 시스템
US11954134B2 (en) * 2021-12-08 2024-04-09 Sap Se Visualization of complex hierarchy data with interactive adjustments
US11886409B1 (en) * 2022-08-11 2024-01-30 Sap Se Searchable catalog of columnar numerical data
US12117980B1 (en) * 2023-09-11 2024-10-15 Oracle International Corporation Auto recognition of big data computation engine for optimized query runs on cloud platforms

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5918225A (en) * 1993-04-16 1999-06-29 Sybase, Inc. SQL-based database system with improved indexing methodology
US5848406A (en) 1996-09-03 1998-12-08 Matsushita Electric Industrial Co., Ltd. Method for presenting information on display devices of varying sizes
US6330555B1 (en) 1999-02-19 2001-12-11 Nortel Networks Limited Method and apparatus for enabling a view of data across a database
US6487641B1 (en) 1999-04-19 2002-11-26 Oracle Corporation Dynamic caches with miss tables
US7024414B2 (en) 2001-08-06 2006-04-04 Sensage, Inc. Storage of row-column data
US7499907B2 (en) * 2001-10-12 2009-03-03 Teradata Us, Inc. Index selection in a database system
US7117222B2 (en) 2003-03-13 2006-10-03 International Business Machines Corporation Pre-formatted column-level caching to improve client performance
ATE515746T1 (de) 2003-09-15 2011-07-15 Ab Initio Technology Llc Datenprofilierung
KR100684942B1 (ko) 2005-02-07 2007-02-20 삼성전자주식회사 복수의 사상 기법들을 채용한 적응형 플래시 메모리 제어장치 및 그것을 포함한 플래시 메모리 시스템
US8538969B2 (en) * 2005-06-03 2013-09-17 Adobe Systems Incorporated Data format for website traffic statistics
US7457910B2 (en) 2005-06-29 2008-11-25 Sandisk Corproation Method and system for managing partitions in a storage device
CN100471180C (zh) * 2006-02-09 2009-03-18 华为技术有限公司 一种消息传递的方法、装置和系统
US7761444B2 (en) 2006-10-05 2010-07-20 Hewlett-Packard Development Company, L.P. Identifying a sequence of blocks of data to retrieve based on a query
EP2097825B1 (en) 2006-12-26 2013-09-04 SanDisk Technologies Inc. Use of a direct data file system with a continuous logical address space interface
US8150850B2 (en) 2008-01-07 2012-04-03 Akiban Technologies, Inc. Multiple dimensioned database architecture
US9805077B2 (en) 2008-02-19 2017-10-31 International Business Machines Corporation Method and system for optimizing data access in a database using multi-class objects
US8121975B2 (en) 2008-02-20 2012-02-21 Panorama Software Inc. Creating pivot tables from tabular data
US8478775B2 (en) 2008-10-05 2013-07-02 Microsoft Corporation Efficient large-scale filtering and/or sorting for querying of column based data encoded structures
US8935223B2 (en) 2009-04-30 2015-01-13 Oracle International Corporation Structure of hierarchical compressed data structure for tabular data
WO2010141182A2 (en) * 2009-06-02 2010-12-09 Saffron Technology, Inc. Methods, systems and computer program products for providing a distributed associative memory base
US20110029319A1 (en) * 2009-07-29 2011-02-03 Google Inc. Impression forecasting and reservation analysis
WO2011142026A1 (ja) * 2010-05-14 2011-11-17 株式会社日立製作所 時系列データ管理装置、システム、方法、およびプログラム
US9218408B2 (en) 2010-05-27 2015-12-22 Oracle International Corporation Method for automatically creating a data mart by aggregated data extracted from a business intelligence server
US8284627B2 (en) 2010-10-22 2012-10-09 International Business Machines Corporation Reducing energy consumption and optimizing workload and performance in multi-tier storage systems using extent-level dynamic tiering
JP5178813B2 (ja) 2010-12-16 2013-04-10 ヤフー株式会社 検索システム及び方法
EP2671160A2 (en) 2011-02-01 2013-12-11 Drobo, Inc. System, apparatus, and method supporting asymmetrical block-level redundant storage
US10152482B2 (en) * 2011-10-07 2018-12-11 Synopsys, Inc. Method of speeding up access to design databases having large numbers of design units
US8914353B2 (en) 2011-12-20 2014-12-16 Sap Se Many-core algorithms for in-memory column store databases
US11347443B2 (en) 2012-04-13 2022-05-31 Veritas Technologies Llc Multi-tier storage using multiple file sets
US9658896B2 (en) 2012-05-16 2017-05-23 International Business Machines Corporation Apparatus and method to manage device performance in a storage system
US8868576B1 (en) 2012-06-28 2014-10-21 Emc Corporation Storing files in a parallel computing system based on user-specified parser function
US10909113B2 (en) 2013-07-31 2021-02-02 Sap Se Global dictionary for database management systems
US9292554B2 (en) * 2013-08-20 2016-03-22 Pivotal Software, Inc. Thin database indexing
CA2867589A1 (en) 2013-10-15 2015-04-15 Coho Data Inc. Systems, methods and devices for implementing data management in a distributed data storage system
US9450602B2 (en) * 2014-01-02 2016-09-20 Sap Se Efficiently query compressed time-series data in a database
US9633058B2 (en) 2014-06-16 2017-04-25 International Business Machines Corporation Predictive placement of columns during creation of a large database
US9846567B2 (en) * 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
US9952808B2 (en) 2015-03-26 2018-04-24 International Business Machines Corporation File system block-level tiering and co-allocation

Also Published As

Publication number Publication date
US10048937B2 (en) 2018-08-14
US20150363167A1 (en) 2015-12-17
WO2015193771A1 (en) 2015-12-23
GB2544206A (en) 2017-05-10
US9846567B2 (en) 2017-12-19
KR101938953B1 (ko) 2019-01-15
US20180011690A1 (en) 2018-01-11
US10162598B2 (en) 2018-12-25
GB201621179D0 (en) 2017-01-25
US20180225090A1 (en) 2018-08-09
KR20160145785A (ko) 2016-12-20
GB2544206B (en) 2017-11-08
JP2017518584A (ja) 2017-07-06

Similar Documents

Publication Publication Date Title
JP6639420B2 (ja) フラッシュ最適化データ・レイアウトのための方法、フラッシュ最適化記憶のための装置、およびコンピュータ・プログラム
US11593037B2 (en) File system block-level tiering and co-allocation
US9594524B2 (en) System and method for distributed computing in non-volatile memory
Wang et al. SSD in-storage computing for list intersection
US10664497B2 (en) Hybrid database table stored as both row and column store
US10346383B2 (en) Hybrid database table stored as both row and column store
CN107851123B (zh) 在存储器中虚拟列单元内具体化表达式以加速分析查询
US20160203135A1 (en) In-memory latch-free index structure
WO2015084864A1 (en) Systems and methods of modeling object networks
US9104726B2 (en) Columnar databases
Dziedzic et al. DBMS data loading: An analysis on modern hardware
Kim et al. Optimally leveraging density and locality for exploratory browsing and sampling
Lim et al. An analysis of image storage systems for scalable training of deep neural networks
Patel et al. Workload aware cost-based partial loading of raw data for limited storage resources
US11520763B2 (en) Automated optimization for in-memory data structures of column store databases
Park et al. KV-CSD: A Hardware-Accelerated Key-Value Store for Data-Intensive Applications
Li et al. Optimizing nonindexed join processing in flash storage-based systems
Byun et al. A column-aware index management using flash memory for read-intensive databases
Ravindran et al. Data structures for big data stores
Sachdev et al. Khanan: Performance Comparison and Programming α-Miner Algorithm in Column-Oriented and Relational Database Query Languages
Rajadnye Is Datawarehouse Relevant in the Era of Big Data?
Shwetha et al. Efficient Query Processing and Data Integrity in Cloud using Column Oriented Database

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161227

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180307

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190319

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190607

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: 20191203

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191224

R150 Certificate of patent or registration of utility model

Ref document number: 6639420

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150