JP2021519460A - データクエリ方法、装置、およびデバイス - Google Patents

Abstract

データクエリ方法、装置、およびデバイスが提供される。本方法は、受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得することと、リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整することと、計算ノードを使用することによって、クエリ要求に対応するデータをクエリすることと、を含む。本出願の技術的解決策を使用することによって、リソースプール内の計算ノードを動的に調整することができ、その結果、リソースプール内の計算ノードがすべての受信されたクエリ要求を処理することができ、したがって、計算ノードの処理効率およびリソース利用率をより効果的に向上させることができ、その結果、計算ノードが多数のクエリ要求に対する並列処理をより効率的に実施することができ、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅リソースの利用率を増加させ、したがって、全体的な計算リソースおよびユーザクエリ負荷の観点からより良い効果を達成し、ユーザの使用経験を向上させる。

Description

本出願は、２０１８年３月２９日に出願され、「Ｄａｔａ Ｑｕｅｒｙ Ｍｅｔｈｏｄ，Ａｐｐａｒａｔｕｓ ａｎｄ Ｄｅｖｉｃｅ」と題された中国特許出願第２０１８／１０２６８９６８．０号の優先権を主張し、その全体が参照により本明細書に組み込まれる。

本出願は、インターネットの技術分野に関し、より具体的には、データクエリ方法、装置、およびデバイスに関する。

オープンアナリティクスは、ユーザにサーバレスのクエリ分析サービスを提供し、あらゆる次元の大量のデータ分析およびクエリを実施し、高い同時実行性、低いレイテンシ（ミリ秒の応答）、リアルタイムのオンライン分析、大量のデータクエリ、および他の機能をサポートする。オープンアナリティクスシステムは、データソースおよび計算ノードを含んでもよく、データソースは、大量のデータを記憶し、クエリ要求を受信した後、計算ノードは、データソースから、クエリ要求に対応するデータにクエリする。

しかしながら、いくつかの適用シナリオ（マップデータクエリシナリオおよび画像データクエリシナリオなど）では、計算ノードは、短期間内に多数のクエリ要求を受信することがあり（すなわち同時実行性が非常に高い）、短期間内に多数のクエリ要求を処理する必要がある。この状況は、ＣＰＵ（中央処理装置）リソース、メモリリソース、および／またはネットワーク帯域幅の異常を引き起こし、クエリのタイムアウトまたはクエリの不具合につながる。

本出願は、データクエリ方法であって、
受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得することと、
リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整することと、
計算ノードを使用することによってクエリ要求に対応するデータをクエリすることと、を含む、方法を提供する。

本出願は、データクエリ方法であって、
受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配することであって、異なる割り当てグループが、異なるリソースサブプールに対応している、分配することと、
割り当てグループ内のクエリ要求の特徴情報に従って、割り当てグループのリソースオーバーヘッドを取得することと、
割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードを動的に調整することと、
リソースサブプール内の計算ノードを使用することによって、割り当てグループ内でクエリ要求に対応するデータをクエリすることと、を含む、データクエリ方法を提供する。

本出願は、データクエリ装置であって、
受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得する取得モジュールと、
リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整する処理モジュールと、
計算ノードを使用することによってクエリ要求に対応するデータをクエリするクエリモジュールと、を備える、データクエリ装置を提供する。

本出願は、データクエリ装置であって、
受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配する分配モジュールであって、異なる割り当てグループが、異なるリソースサブプールに対応している、分配モジュールと、
割り当てグループ内のクエリ要求の特徴情報に従って、割り当てグループのリソースオーバーヘッドを取得する、取得モジュールと、
割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードを動的に調整する、処理モジュールと、
リソースサブプール内の計算ノードを使用することによって割り当てグループ内のクエリ要求に対応するデータをクエリするクエリモジュールと、を備える、データクエリ装置を提供する。

本出願は、データクエリデバイスであって、受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得し、リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整し、計算ノードを使用することによって、クエリ要求に対応するデータをクエリするプロセッサ、を備える、データクエリデバイスを提供する。

本出願は、データクエリデバイスであって、受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配することであって、異なる割り当てグループが、異なるリソースサブプールに対応している、分配することと、割り当てグループ内のクエリ要求の特徴情報に従って、割り当てグループのリソースオーバーヘッドを取得することと、割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードを動的に調整することと、リソースサブプール内の計算ノードを使用することによって、割り当てグループ内のクエリ要求に対応するデータをクエリすることと、を行うプロセッサを備える、データクエリデバイスを提供する。

前述の技術的解決策に基づいて、本出願の一実施形態では、リソースオーバーヘッドは、受信されたクエリ要求の特徴情報に従って取得されてもよく、リソースプール内の計算ノードは、リソースオーバーヘッドおよび計算ノードリソースに従って動的に調整される。したがって、リソースプール内の計算ノードが受信されたすべてのクエリ要求を処理することができ、計算ノードの処理効率およびリソース利用率がより効果的に改善され、その結果、計算ノードが多数のクエリ要求に対する並列処理をより効率的に実施することができ、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅リソースの利用率を増加させ、したがって、全体的な計算リソースおよびユーザクエリ負荷の観点からより良い効果を達成し、ユーザの使用経験を向上させる。さらに、リソースプール内の計算ノードを動的に調整することを使用することによって、各計算ノードは、ユーザに対してサーバレスクエリ分析サービスを提供することができ、その結果、ユーザは、サーバまたはサービスインスタンスを知覚する必要がなく、クラウドサービスによって提供されるサービス自体を知覚する必要があるだけである。クラウドサービスに基づいて、ユーザは、計算ノードがデータソース内でデータクエリおよび分析を実施できるように、ＳＱＬクエリ要求を入力する必要があるだけであり、商業分析ツールおよびアプリケーション（ＡＰＰ）を、シームレスに統合することができる。リソースをインテリジェントに分析し、自動的に調整することができ、クラウドデータベースおよびクラウドデータ分析サービスクラスタのリソース利用率および価格／性能比がより効果的に上昇する。

本出願の実施形態または従来技術における技術的解決策をより明確に説明するために、本出願の実施形態および従来技術の説明で使用される添付図面を簡単に紹介する。明らかに、以下の説明における添付の図面は、本出願に説明されるいくつかの実施形態にすぎず、当業者は、本出願の実施形態のこれらの添付の図面に従って、他の図面を取得することができる。

本出願の実装様式におけるシステム構造の概略図である。 本出願の実装様式におけるデータクエリ方法のフロー図である。 本出願の別の実装様式におけるシステム構造の概略図である。 本出願の別の実装様式におけるデータクエリ方法のフロー図である。 本出願の実装様式におけるデータクエリ装置の構造図である。 本出願の別の実装様式におけるデータクエリ装置の構造図である。

本出願で使用される用語は、特定の実施形態を説明することのみを目的としており、本出願を限定することを意図するものではない。本出願および添付の特許請求の範囲で使用される単数形「１つの（ｏｎｅ）」、「その（ｔｈｅ）」、および「この（ｔｈｉｓ）」は、それらの意味が文脈で明確に表現されない限り、複数形をカバーすることも意図している。本明細書で使用される「および／または」という用語は、列挙された項目の任意の１つまたは複数を含む任意の可能な組み合わせを指すことも理解されたい。

本出願は、様々な種類の情報を説明するために第１、第２、および第３などの用語を使用することがあるが、情報はこれらの用語に限定されるべきではないことを理解されたい。これらの用語は、同じ種類の情報を区別することを意図しているにすぎない。例えば、本出願の範囲から逸脱することなく、第１の情報は、第２の情報とも呼ばれ得、同様に、第２の情報は、第１の情報とも呼ばれ得る。文脈に応じて、本明細書で使用される「場合（ｉｆ）」という用語は、「…の時点に（ａｔ ｔｈｅ ｔｉｍｅ ｏｆ…）」または「…のとき（ｗｈｅｎ…．）」、または「決定に応答して（ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｒｍｉｎａｔｉｏｎ）」として解釈され得る。”

本出願の一実施形態は、クライアント、ロードバランサ、フロントノード（「フロントエンドサーバ」とも呼ばれ得る）、計算ノード（「コンピュータサーバ」とも呼ばれ得る）、およびオープンアナリティクスを達成するためのシステムなどのデータソースを含むシステムに適用され得るデータクエリ方法を提供する。もちろん、リソーススケジューリングサーバなどの他のサーバもさらに含まれてもよく、これに限定は設けられない。

図１は、本出願の一実施形態の適用シナリオの概略図を示す。フロントノードリソースプールでは、１つまたは複数のフロントノードがあり、図１は、３つのフロントノードを例にとっている。計算ノードリソースプールでは、１つまたは複数の計算ノードがあり、図１は、５つの計算ノードを例にとっている。実用的な適用において、フロントノードを増加（フロントノードの数を増加させる）または減少（フロントノードの数を減少させる）させることができ、計算ノードも増加（計算ノードの数を増加させる）または減少させる（計算ノードの数を減少させる）ことができる。この実施形態は、計算ノードを増加または減少させるための解決策である。

ここで、クライアントを使用して、例えば、端末デバイス（ＰＣ（パーソナルコンピュータ）、ノートブック、またはモバイル端末など）が含むＡＰＰ（アプリケーション）であり得るか、または端末デバイスが含むブラウザであり得る、データソースからのデータをクエリする。クライアントの種類に限定は設けられない。

ここで、ロードバランサを使用して、例えば、非常に多くのクエリ要求が受信された後に、クエリ要求の負荷分散を実施し、これらのクエリ要求は、フロントノードにロード負荷分散され得る。このプロセスに限定は設けられない。

ここで、データソースを使用して、様々な種類のデータを記憶し、データソースに記憶されたデータをクライアントに提供してもよい。本出願の実施形態は、データソースに記憶されるデータの種類に限定はなく、例えば、データは、ユーザデータ、商品データ、地図データ、ビデオデータ、画像データ、または音声データであり得る。

ここで、リソースプール内の複数のフロントノードを使用して、同じ機能を提供する。具体的には、フロントノードを使用して、クライアントによって送信されたクエリ要求を受信し、クエリ要求のＳＱＬ（構造化クエリ言語）解析を実施し、ＳＱＬ解析結果を使用することによってクエリ要求を生成し、クエリ要求を計算ノードに送信し、クエリ要求を使用して、クエリ要求に対応するデータを要求する。次に、フロントノードをさらに使用して、計算ノードによって返されたデータを受信し、そのデータをクライアントに送信する。

ここで、リソースプール内の複数の計算ノードを使用して、同じ機能を提供する。具体的には、計算ノードを使用して、フロントノードによって送信されたクエリ要求を受信し、クエリ要求を使用して、データソースからクエリ要求に対応するデータを読み取り（この読み取りプロセスに限定されない）、データをフロントノードに送信する。

一例において、計算ノードが短時間で非常に多くのクエリ要求を受信する場合（すなわち同時実行性が非常に高い）、計算ノードは短時間で非常に多くのクエリ要求を処理する必要があり、ＣＰＵリソース、メモリリソース、および／またはネットワーク帯域幅の異常を引き起こし、クエリタイムアウトまたはクエリ失敗をもたらす。前述の方法とは異なり、本出願の一実施形態では、リソースプール内の計算ノードを動的に調整することができ、すなわち非常に多くのクエリ要求があるとき、リソースプール内の計算ノードの数を増加させて、計算ノード当たりのクエリ要求の数を減少させることができ、その結果、特定の計算ノードによって非常に多くのクエリ要求を短時間で処理することを回避することができ、計算ノードの処理効率およびリソース利用率をより効果的に向上させることができ、ＣＰＵリソース、メモリリソースおよびネットワーク帯域幅の占有を減少させることができ、したがって、処理性能が向上し、クライアントのクエリのタイムアウトまたは故障が回避され、ユーザの使用経験が向上する。

前述の適用シナリオにおいて、図２は、本出願の一実施形態で提供されるデータクエリ方法のフローの概略図を示す。この方法は、データクエリデバイスに適用され得る。データクエリデバイスは、図１のロードバランサ、フロントノード、またはリソーススケジューリングサーバであり得る。これに限定は設けられない。この実施形態では、フロントノードにおける適用を例にとると、この方法は、下記のステップを含み得る：

ステップ２０１：受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得すること。例えば、リソースオーバーヘッドは、予め設定された時間枠で受信されたクエリ要求の特徴情報に従って取得され得る。

ステップ２０２：リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整すること。

ステップ２０３：リソースプール内の計算ノードを使用することによって、クエリ要求に対応するデータをクエリすること。

前述の実装順序は、説明の便宜のために与えられた例にすぎない。実際の適用では、ステップ間の実装順序は変更されてもよく、限定されない。さらに、他の実施形態では、本明細書で示され、説明される順序に従って、対応する方法のステップを実装する必要はなく、方法は、本明細書で説明されるステップよりも多いまたは少ないステップを含んでもよい。さらに、本明細書で説明される単一のステップは、他の実施形態で説明される多数のステップに分割されてもよく、本明細書で説明される多数のステップは、他の実施形態で説明される単一のステップに組み合わせられてもよい。

ここで、クライアントがデータソース内のデータを要求する必要があるとき、クライアントはクエリ要求を送信してもよい。ロードバランサがこのクエリ要求を受信した後、ロードバランサは、クエリ要求をフロントノードに送信してもよい。フロントノードがクエリ要求を受信した後、フロントエンドは、クエリ要求をクエリキューに記憶してもよい。

ここで、フロントノードは予め設定された時間枠を設定してもよく、予め設定された時間枠の時間は、経験に従って、例えば、３秒に構成されてもよい。これに基づいて、フロントノードは、予め設定された時間枠内のクエリキューに記憶されたすべてのクエリ要求を、予め設定された時間枠内で受信されたクエリ要求、例えば、１００個のクエリ要求として、決定してもよい。

ステップ２０１の実装の前に、予め設定された時間枠で受信されたすべてのクエリ要求について、クエリ要求の各々の特徴情報も最初に取得してもよい。特徴情報は、限定されないが、下記の選択肢、すなわち同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース利用のうちの１つまたは任意のこれらの組み合わせを含んでもよい。

Ｉ．同時実行性、すなわち１００などの予め設定された時間枠で受信されるクエリ要求の数。

ＩＩ．クエリ複雑度、すなわちクエリ応答時間、ＣＰＵリソース占有率、メモリリソース占有率、ネットワーク帯域幅占有率などを表現し得るクエリ要求の実装のための複雑度。ここで、クエリ複雑度は通常、クエリ応答時間、ＣＰＵリソース占有率、メモリリソース占有率、およびネットワーク帯域幅占有率を正規化することによって取得され得る値である。例えば、大量のＣＰＵリソース、メモリリソース、およびネットワーク帯域幅が占有される必要があり、クエリ要求１が実装されるときクエリ応答時間が長い場合、クエリ要求１のクエリ複雑度は高い。少量のＣＰＵリソース、メモリリソース、およびネットワーク帯域幅が占有される必要があり、クエリ要求２が実装されるときクエリ応答時間が短い場合、クエリ要求２のクエリ複雑度は低い。

同じクエリキーワードを有するクエリ要求について、それらは、同じまたは同様のクエリ複雑度値を有する。したがって、クエリキーワードと複雑度値との間の対応関係を取得し、第１のマッピングテーブルに記録してもよい。例えば、クエリ要求１およびクエリ要求２が、両方ともクエリキーワードＡを有しているクエリ要求であると仮定すると、クエリ要求１およびクエリ要求２のクエリ複雑度値は同じである。クエリキーワードＡと複雑度値Ａとの間の対応関係が第１のマッピングテーブルに記録されると仮定すると、クエリ要求１およびクエリ要求２について、クエリ要求１のクエリ複雑度およびクエリ要求２のクエリ複雑度が、両方とも複雑度値Ａである。

ここで、クエリキーワードと複雑度値との間の対応関係を取得することは、限定されないが、経験に従ってクエリキーワードと複雑度値との間の対応関係を構成すること、あるいは、ニューラルネットワークを使用することによってクエリキーワードと複雑度値と間の対応関係を訓練すること（この訓練プロセスに限定は設けられない）、あるいは、クエリ要求が実装されるとき、クエリ要求のクエリキーワードおよびクエリキーワードの複雑度値を取得することを含んでもよい。クエリ要求が実装されるとき、１コアのＣＰＵリソースおよび１００Ｍのメモリリソースが消費される場合、複雑度値は、１コアＣＰＵリソースおよび１００Ｍのメモリリソースが対応する複雑度値である。これに限定は設けられない。

一例では、クエリ要求は、限定されないが、ＳＱＬクエリ要求を含んでもよく、クエリキーワードは、限定されないが、下記の選択肢、すなわち結合のキーワード（すなわちｊｏｉｎ。例えば、ＳＱＬクエリ要求は、キーワード「ｊｏｉｎ」を含む）、結果セットをグループ化するためのキーワード（すなわちｇｒｏｕｐｂｙ。例えば、ＳＱＬクエリ要求は、キーワード「ｇｒｏｕｐｂｙ」を含む）、結果セットを順序付けするためのキーワード（すなわちｏｒｄｅｒｂｙ。例えば、ＳＱＬクエリ要求は、キーワード「ｏｒｄｅｒｂｙ」を含む）、差異のためのキーワード設定（すなわちｄｉｓｔｉｎｃｔ。例えば、ＳＱＬクエリ要求は、キーワード「ｄｉｓｔｉｎｃｔ」を含む）、行番号の計算のためのキーワード（すなわちｃｏｕｎｔ。例えば、ＳＱＬクエリ要求は、キーワード「ｃｏｕｎｔ」を含む）、および枠関数のためのキーワード（すなわちｗｉｎｄｏｗ。例えば、ＳＱＬクエリ要求は、キーワード「ｗｉｎｄｏｗ」を含む）のうちの１つまたはこれらの組み合わせを含んでもよい。

表１は、クエリキーワードと複雑度値との間の対応関係を記録している第１のマッピングテーブルの一例を示す。ここでの複雑度値は、クエリ要求の複雑度を反映している。例えば、複雑度値５は、１コアのＣＰＵリソースおよび１００Ｍのメモリリソースが消費されることを意味し、複雑度値１０は、２コアのＣＰＵリソースおよび２００Ｍのメモリリソースが消費されることを意味し、残りは同じ様式で行われてもよい。もちろん、表１は一例にすぎず、クエリキーワードに対応する複雑度値は実際の条件に関連しているため、不要な詳細は繰り返さない。

さらに、予め設定された時間枠で受信されたすべてのクエリ要求について、クエリ要求のクエリ複雑度を取得するために、下記の方法を使用してもよい：方法１：クエリ要求からクエリキーワードを取得し、クエリキーワードを使用することによって第１のマッピングテーブルをクエリして、クエリキーワードに対応する複雑度値を取得し、複雑度値をクエリ要求が対応するクエリ複雑度として決定すること。方法２：クエリ要求の複数のサブクエリからクエリキーワードを取得し、各取得されたクエリキーワードを使用することによって第１のマッピングテーブルをクエリして、各クエリキーワードに対応する複雑度値を取得すること。次いで、取得された複雑度値の合計（すなわちすべての複雑度値の合計）を、クエリ要求が対応するクエリ複雑度として決定してもよい。

例えば、方法１では、クエリ要求がＳＱＬのｊｏｉｎステートメントである、すなわちクエリ要求がクエリキーワード「ｊｏｉｎ」を含むと仮定すると、表１に示される第１のマッピングテーブルは、クエリキーワード「ｊｏｉｎ」を使用することによってクエリされて、複雑度値５を取得してもよく、次いで、クエリ要求が対応するクエリ複雑度が複雑度値５であることが決定されてもよい。

方法２では、クエリ要求がサブクエリ１、サブクエリ２、およびサブクエリ３を含み、サブクエリ１がＳＱＬのｊｏｉｎステートメントであり、サブクエリ２がＳＱＬのｇｒｏｕｐｂｙステートメントであり、サブクエリ３がＳＱＬのｄｉｓｔｉｎｃｔステートメントであると仮定する。サブクエリ１は、クエリキーワード「ｊｏｉｎ」を含み、表１に示される第１のマッピングテーブルは、クエリキーワード「ｊｏｉｎ」を使用することによってクエリされて、複雑度値５を取得する。サブクエリ２は、クエリキーワード「ｇｒｏｕｐｂｙ」を含み、表１に示される第１のマッピングテーブルは、クエリキーワード「グループビー」を使用することによってクエリされて、複雑度値１０を取得する。サブクエリ２は、クエリキーワード「ｄｉｓｔｉｎｃｔ」を含み、表１に示される第１のマッピングテーブルは、クエリキーワード「ｄｉｓｔｉｎｃｔ」を使用することによってクエリされて、複雑度値１２を取得する。次いで、クエリ要求が対応するクエリ複雑度は、複雑度値５、複雑度値１０、および複雑度値１２の合計である、すなわちクエリ複雑度は、複雑度値２７であると決定されてもよい。

ＩＩＩ．走査されたクエリデータ、すなわちクエリ要求の実装中に返されたデータサイズ。例えば、クエリ要求１がデータＡを要求するために使用され、データＡのサイズが１０Ｍであると仮定すると、走査されたクエリデータは１０Ｍであり得、換言すれば、クライアントに返されたデータは１０Ｍであり得る。

一例では、履歴データを収集してもよく、履歴データに従って、データＩＤと走査されたクエリデータとの間の対応関係を取得し、次いで、第２のマッピングテーブルにおいて、データＩＤと走査されたクエリデータとの間の対応関係を記録している。例えば、クエリ要求が実装されるとき、クエリ要求がデータＡを要求するために使用され、データＡのサイズが１０Ｍである場合、フロントノードは、前述の情報（すなわち履歴データ）を収集し、データＡと走査されたクエリデータ１００との間の対応関係を取得し、その対応関係を第２のマッピングテーブルに記録してもよい。第２のマッピングテーブルの例を示す表２を参照されたい。第２のマッピングテーブルの内容に限定は設けられない。

さらに、予め設定された時間枠で受信されたすべてのクエリ要求について、クエリ要求の走査されたクエリデータを取得するために、下記の方法が使用されてもよい：クエリ要求のデータＩＤを使用することによって第２のマッピングテーブルをクエリして、データＩＤに対応する走査されたクエリデータを取得すること。例えば、クエリ要求によって運ばれるデータＩＤがデータＡである場合、データＡに対応する走査されたクエリデータ１０Ｍが決定される。クエリ要求によって運ばれるデータＩＤがデータＣである場合、第２のマッピングテーブルは、データＣが対応する走査されたクエリデータ１０Ｍを記録しないので、データＣが対応する走査されたクエリデータが、デフォルト値として設定されてもよい（例えば、走査されたクエリデータは、５Ｍに従って構成されてもよい）。

ＩＶ．クエリ応答時間、すなわちクエリ要求の実装に費やされる時間（クエリ要求の処理の開始からクエリ要求の処理の終了までに費やされる時間）。例えば、クエリ要求１が実装されるときに３秒が費やされると仮定すると、クエリ応答時間は３秒である。

ここで、履歴データを収集してもよく、履歴データに従って、データＩＤとクエリ応答時間との間の対応関係を取得し、データＩＤとクエリ応答時間との間の対応関係を第２のマッピングテーブルに記録する。予め設定された時間枠で受信されたすべてのクエリ要求について、クエリ要求のクエリ応答時間を取得するために、下記の方法が使用されてもよい：クエリ要求のデータＩＤを使用することによって第２のマッピングテーブルをクエリして、データＩＤに対応するクエリ応答時間を取得すること。

Ｖ．リソース利用、すなわちメモリ利用、ＣＰＵ利用、およびネットワーク帯域幅利用などの、クエリ要求が実装されるとき消費されるリソース。クエリ要求１が実装されるとき１コアのＣＰＵリソース、１００Ｍのメモリリソース、および１００Ｍのネットワーク帯域幅が消費されると仮定すると、リソース利用は１コアのＣＰＵリソース、１００Ｍのメモリリソース、および１００Ｍのネットワーク帯域幅である。

ここで、履歴データを収集し、履歴データに従って、データＩＤとリソース利用との間の対応関係を取得してもよい。次いで、データＩＤとリソース利用との間の対応関係も、第２のマッピングテーブルに記録してもよい。さらに、予め設定された時間枠で受信されたすべてのクエリ要求について、クエリ要求のリソース利用を取得するために、下記の方法も使用されてもよい：クエリ要求のデータＩＤを使用することによって第２のマッピングテーブルをクエリし、データＩＤに対応するリソース利用を取得できるようにすること。

一例では、フロントノードはまた、表３に示される第２のマッピングテーブルも維持してもよい。第２のマッピングテーブルは、データＩＤ、走査されたクエリデータ、クエリ応答時間、およびリソース利用の対応関係を記録している。これに基づいて、予め設定された時間枠で受信されたすべてのクエリ要求について、表３に示される第２のマッピングテーブルは、クエリ要求のデータＩＤを使用することによってクエリされ、それによってデータＩＤに対応する特徴情報を取得してもよい。特徴情報は、１つまたは複数の走査されたクエリデータ、クエリ応答時間、およびリソース利用を含んでもよい。

要約すると、前述のクエリ要求によって運ばれるデータＩＤがデータＡである場合、データＡに対応する走査されたクエリデータ１０Ｍ、クエリ応答時間３秒、およびリソース利用「ＣＰＵリソース：１コア；メモリリソース：１００Ｍ；ネットワーク帯域幅：１００Ｍ」が決定される。さらに、クエリ要求によって運ばれるデータＩＤがデータＣである場合、第２のマッピングテーブルはデータＣが対応する内容を記録しないので、走査されたクエリデータがデフォルト値として設定されてもよく、クエリ応答時間がデフォルト値として設定されてもよく、リソース利用がデフォルト値として設定されてもよい。これに限定は設けられない。

前述のプロセスを通じて、予め設定された時間枠で受信されたすべてのクエリ要求の特徴情報を取得することができ、例えば、同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース利用である特徴情報をとる。

ステップ２０１では、受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得することは、予め設定された時間枠で受信されたすべてのクエリ要求について、クエリ要求の特徴情報に従ってクエリ要求の予測リソース量を取得し、すべてのクエリ要求の予測リソース量に従ってリソースオーバーヘッドを決定することを含んでもよい。例えば、リソースオーバーヘッドは、すべてのクエリ要求の予測リソース量の合計であってもよい。

ここで、クエリ要求の予測リソース量をクエリ要求の特徴情報に従って取得するとき、特徴情報がクエリ複雑度であると仮定すると、クエリ複雑度の複雑度値が大きいほど、予測リソース量は大きくなり、クエリ複雑度の複雑度値が小さいほど、予測リソース量が小さくなる。前述の法則に準拠している限り、この決定プロセスに限定は設けられない。特徴情報が走査されたクエリデータであると仮定すると、走査されたクエリデータが大きいほど、予測リソース量は大きくなり、走査されたクエリデータが小さいほど、予測リソース量は小さくなる。前述の法則に準拠している限り、この決定プロセスに限定は設けられない。特徴情報がクエリ応答時間であると仮定すると、クエリ応答時間が大きいほど、予測リソース量は大きくなり、クエリ応答時間が小さいほど、予測リソース量は小さくなる。前述の法則に準拠している限り、この決定プロセスに限定は設けられない。特徴情報がリソース利用であると仮定すると、リソース利用が大きいほど、予測リソース量は大きくなり、リソース利用が小さいほど、予測リソース量は小さくなる。前述の法則に準拠している限り、この決定プロセスに限定は設けられない。もちろん、前述の方法は、少なくとも１つの例を有する。これに限定はない。

例えば、特徴情報が複数の同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース使用であるとき、例えば、５つの特徴の包含をとると、同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース使用は、正規化されてもよく、換言すれば、同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース利用は、同じ数量レベルに正規化されてもよい。この正規化の方法に限定は設けられない。正規化された同時実行性Ａ、クエリ複雑度Ｂ、走査されたクエリデータＣ、クエリ応答時間Ｄ、およびリソース利用Ｅを取得すると仮定すると、同時実行性Ａ、クエリ複雑度Ｂ、走査されたクエリデータＣ、クエリ応答時間Ｄ、およびリソース利用Ｅを合計してもよい。合計結果が大きいほど、予測リソース量は大きくなり、合計結果が小さいほど、予測リソース量は小さくなる。前述の法則に準拠している限り、これに限定は設けられない。

別の例では、重み１＊同時実行性Ａ、重み２＊クエリ複雑度Ｂ、重み３＊走査されたクエリデータＣ、重み４＊クエリ応答時間Ｄ、および重み５＊リソース利用Ｅを合計することもできる。合計結果が大きいほど、予測リソース量は大きくなり、合計結果が小さいほど、予測リソース量は小さくなる。前述の法則に準拠している限り、これに限定は設けられない。ここで、重み１、重み２、重み３、重み４、および重み５は、すべて経験に従って構成されることができ、これに限定は設けられない。例えば、重み１、重み２、重み３、重み４、および重み５の合計は、１であってもよく、もちろん、２または３などの他の値であってもよい。

一例では、クエリ要求の特徴情報に従ってクエリ要求の予測リソース量を取得することは、予測モデルを使用することによってクエリ要求の特徴情報を分析して、クエリ要求の予測リソース量を取得することを含み得る。予測モデルは、限定されないが、Ｈｏｌｔ−Ｗｉｎｔｅｒ（立方体指数平滑法）季節モデル、ＡＲＭＡ（自動回帰移動平均）モデル、線形回帰モデル、ニューラルネットワークモデルを含み得る。

予測モデルがニューラルネットワークモデルであると仮定すると、ニューラルネットワークは、履歴データを使用して、特徴情報と予測リソース量との間の対応関係を訓練してもよい。例えば、特徴情報がクエリ複雑度であるとき、クエリ複雑度と予測リソース量との間の対応関係を訓練してもよい。例えば、クエリ要求が実装されるとき、クエリ要求のクエリ複雑度が複雑度値５であり、実際に消費されるリソース量がリソース量Ａであると仮定すると、複雑度値５と予測リソース量Ａとの間の対応関係を取得してもよい。もちろん、ニュートラルネットワークは、大量の履歴データを使用することによって、クエリ複雑度と予測リソース量との間の対応関係を訓練し、この訓練プロセスに限定は設けられない。訓練結果において、クエリ複雑度の複雑度値が大きいほど、予測リソース量は大きくなり、クエリ複雑度の複雑度値が小さいほど、予測リソース量は小さくなる。同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、リソース利用、および他の特徴情報については、それらの訓練プロセスは同様であるので、不要な詳細は繰り返さない。特徴情報が、複数の同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース利用である場合、その訓練プロセスは同様であるので、不要な詳細は繰り返さない。

さらに、ニュートラルネットワークが特徴情報と予測リソース量との間の対応関係を訓練した後、予め設定された時間枠で受信されたすべてのクエリ要求について、ニュートラルネットワークは、クエリ要求の特徴情報に従って対応関係をクエリして、クエリ要求の予測リソース量を取得してもよい。このプロセスに限定は設けられない。

もちろん、前述の方法は、ニューラルネットワークモデルを使用して予測リソース量を取得する例にすぎず、これに限定は設けられない。予測モデルが、Ｈｏｌｔ−Ｗｉｎｔｅｒ季節モデル、ＡＲＭＡモデル、または線形回帰モデルである場合、その実装方法はニューラルネットワークモデルの実装方法同様であるので、決定プロセスが下記の法則に準拠する限り、不要な詳細は繰り返さない：クエリ複雑度の複雑度値が大きいほど、予測リソース量は大きくなる；走査されたクエリデータが大きいほど、予測リソース量は大きくなる；クエリ応答時間が大きいほど、予測リソース量は大きくなる；リソース利用が大きいほど、予測リソース量は大きくなる；同時実行性が大きいほど、予測リソース量は大きくなる。

ステップ２０２において、リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整することは、限定されないが、リソースオーバーヘッドおよび計算ノードリソースに従って、計算ノードの数を取得することを含んでもよく、次いで、計算ノードの数と一致する計算ノードがリソースプール内に分配されてもよい。

ここで、リソースオーバーヘッドおよび計算ノードリソースに従って、計算ノードの数を取得することは、限定されないが、下記の方法を含み得る：計算ノードの数は、リソースオーバーヘッド／計算ノードリソースを整数に切り上げることによって取得され得る。もちろん、計算ノードの数がリソースオーバーヘッド／計算ノードリソースを整数に切り上げた結果以上である限り、計算ノードの数を取得するために他の方法も使用されてもよく、これに限定は設けられない。

例えば、予め設定された時間枠で受信されたすべてのクエリ要求の予測リソース量の合計が１００ＣＰＵコアである、すなわちリソースオーバーヘッドが１００ＣＰＵコアであるとき、コンピュートノードリソースが８ＣＰＵコアである（すなわちリソースプール内の各計算ノードには、８ＣＰＵコアの計算ノードリソースが提供される）と仮定すると、計算ノードの数は１３個であり得る。明らかに、計算ノードの数が１３個であるとき、１３個の計算ノードが１０４のＣＰＵコアを提供することができるので、１３個の計算ノードは、１００のＣＰＵコアのリソースオーバーヘッドを満足することができ、すなわち１３個の計算ノードは、予め設定された時間枠で受信されたすべてのクエリ要求を処理することができる。

別の例では、リソースオーバーヘッドが２０Ｇメモリであるとき、計算ノードリソースが２Ｇメモリであると仮定すると、計算ノードの数は１０個であり得る。明らかに、計算ノードの数が１０個であるとき、１０個の計算ノードが２０Ｇのメモリを提供することができるので、１０個の計算ノードは、２０Ｇのメモリのリソースオーバーヘッドを満足することができ、すなわち１０個の計算ノードは、予め設定された時間枠で受信されたすべてのクエリ要求を処理することができる。

別の例では、リソースオーバーヘッドが１００ＣＰＵコアおよび２０Ｇメモリであり、計算ノードリソースが８ＣＰＵコアおよび２Ｇメモリであるとき、ＣＰＵコアリソースは１３個の計算ノードを使用する必要があり、メモリリソースは１０個の計算ノードを使用する必要があり、そのため最大数１３の計算ノードが計算ノードの数として決定され得る。

ここで、リソースプール内の計算ノードの数と一致する計算ノードを分配することは、リソースプール内に既に存在する計算ノードの数が計算ノードの数よりも少ない場合、計算ノードをリソースプール内で増加させて、減少後の計算ノードの数が計算ノードの数以上になるようにすることを含んでもよい。リソースプール内に既に存在する計算ノードの数が計算ノードの数よりも多い場合、計算ノードをリソースプール内で減少させて、減少後の計算ノードの数が計算ノードの数以上になるようにしてもよい。

例えば、リソースプールに８個の計算ノードがあるが、前述の計算ノードの数は１３個であると仮定すると、５個の計算ノードをリソースプール内で増加させてもよく、その結果、リソースプールに合計１３個の計算ノードがあり、これら１３個の計算ノードは、予め設定された時間枠で受信されたすべてのクエリ要求を処理するために使用される。

別の例では、リソースプール内に２０個の計算ノードがあるが、前述の計算ノードの数は１３個であると仮定すると、７個の計算ノードをリソースプール内で減少させてもよく、その結果、リソースプール内に合計１３個の計算ノードがあり、これら１３個の計算ノードは、予め設定された時間枠で受信されたすべてのクエリ要求を処理するために使用される。

一例では、フロントノードが数１３個の計算ノードを取得した後、フロントノードは、数１３の計算ノードを運ぶリソース増加または減少命令をリソーススケジューリングサーバに送信してもよい。リソーススケジューリングサーバがリソースの増加または減少命令を受信した後、リソーススケジューリングサーバは、リソースプール内の計算ノードの数１３と一致する計算ノードを分配してもよい。

例えば、１つのフロントノードがある場合、リソーススケジューリングサーバは、数１３の計算ノードを運ぶリソースの増加または減少命令のみを受信し、そのため計算ノードがリソースプール内で増加または減少され、その結果、リソースプール内に１３個の計算ノードがあるようになる。別の例では、２つのフロントノードがある場合、リソーススケジューリングサーバが、１３個の計算ノードを運ぶリソースの増加または減少命令、および８個の計算ノードを運ぶリソースの増加または減少命令を受信すると仮定すると、計算ノードがリソースプール内で増加または減少され、その結果、リソースプール内に２１個の計算ノードがあるようになる。

ここで、リソーススケジューリングサーバがリソースプール内の計算ノードを増加／減少させるとき、性能は、第２のスケール（それは、１００ミリ秒スケールまで最適化され得る）であってもよく、換言すれば、わずか数秒（それは、１００ミリ秒スケールまで最適化され得る）であってもよく、計算ノードは、リソースプール内で増加または減少されてもよい。

ステップ２０３において、リソースプール内の計算ノードを使用することによって、前述のクエリ要求に対応するデータをクエリすることは、予め設定された時間枠で受信されたすべてのクエリ要求について、フロントノードは、クエリ要求のＳＱＬ解析を実施し、ＳＱＬ解析結果を使用することによってクエリ要求を生成し、クエリ要求を計算ノードに送信してもよく、計算ノードがクエリ要求を受信した後、計算ノードは、データソースからクエリ要求に対応するデータを読み取り、計算を実行し、フロントノードにデータを返してもよく、フロントノードは、受信されたデータをクライアントに返す。例えば、フロントノードは、クエリ要求を６つのクエリサブ要求に分割し（このプロセスに限定は設けられない）、６つのクエリサブ要求を６つの計算ノードに負荷分散する。すべての計算ノードについて、クエリ要求を受信した後、計算ノードは、データソースからクエリサブ要求に対応するデータを読み取り、データをフロントノードに返す。フロントノードが６個のクエリサブ要求に対応するデータを受信した後、データを組み合わせてデータセットを取得する。組み合わされたデータセットは、前述のクエリ要求が対応するデータである。次いで、データセットをクライアントに送信し、最終的にはデータクエリ動作を完了する。

前述の技術的解決策に基づいて、本出願の一実施形態では、リソースオーバーヘッドは、受信されたクエリ要求の特徴情報に従って取得されてもよく、計算ノードの数は、リソースオーバーヘッドおよび計算ノードリソースに従って取得され、計算ノードの数と一致する計算ノードは、リソースプールに分配される。このようにして、リソースプール内の計算ノードを動的に調整することができ、その結果、リソースプール内の計算ノードが受信されたすべてのクエリ要求を処理することができ、したがって、計算ノードの処理効率およびリソース利用率をより効果的に向上させることができ、その結果、計算ノードが多数のクエリ要求に対する並列処理をより効率的に実施することができ、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅リソースの利用率を増加させ、したがって、全体的な計算リソースおよびユーザクエリ負荷の観点からより良い効果を達成し、ユーザの使用経験を向上させる。クエリ要求の特徴を分析および予測することによって、計算ノードのリソースをインテリジェントに分析し、自動的に調整することができ、クラウドデータベースおよびクラウドデータ分析サービスクラスタのリソース利用率および価格／性能比がより効果的に上昇する。さらに、リソースプール内の計算ノードを動的に調整することを使用することによって、各計算ノードは、ユーザに対してサーバレスクエリ分析サービスを提供することができ、その結果、ユーザは、サーバまたはサービスインスタンスを知覚する必要がなく、クラウドサービスによって提供されるサービス自体を知覚する必要があるだけであり、クラウドサービスに基づいて、ユーザは、計算ノードがデータソース内でデータクエリおよび分析を実施できるように、ＳＱＬクエリ要求を入力する必要があるだけであり、商業分析ツールおよびアプリケーション（ＡＰＰ）を、シームレスに統合することができる。

本出願の一実施形態の別の適用シナリオの概略図である図３を参照されたい。以下に図３の図１との違いを説明する。図１では、すべての計算ノードは同じリソースプール内にあり、図３では、計算ノードのリソースプールは、例えば、リソースサブプール１、リソースサブプール２、およびリソースサブプール３をとる複数のリソースサブプールに分割されてもよく、一方で、計算ノードはリソースサブプールに位置付けられている。例えば、リソースサブプール１は、２つの計算ノードを含み、リソースサブプール２は、２つの計算ノードを含み、リソースサブプール３は、４つの計算ノードを含む。この実施形態では、リソースプール以外のリソースサブプール内の計算ノードは、増加または減少される。

同じリソースサブプールについて、すべての計算ノードの計算ノードリソースは同じであり、異なるリソースサブプールについて、計算ノードの計算ノードリソースは同じであっても異なっていてもよい。例えば、リソースサブプール１内の計算ノードリソースは４ＣＰＵコアであり、リソースサブプール２内の計算ノードリソースは８ＣＰＵコアであり、リソースサブプール３内の計算ノードリソースは１６ＣＰＵコアである。

ここで、異なるユーザの要件に従って、異なるレベルのリソースサブプールは、異なるユーザに対して分割されてもよい。例えば、ユーザのＳＬＡ（サービスレベル契約、すなわちサービスタイプ、サービス品質、顧客支払い、および他の条件を定義する、ネットワークサービスサプライヤとユーザとの間の契約）情報に基づいて、異なるレベルのリソースサブプールは、異なるユーザに対して分割されてもよく、それによって異なるユーザの要件を満たす。

前述の適用シナリオにおいて、図４は、本出願の一実施形態で提供されるデータクエリ方法のフローの概略図を示す。フロントノードにおけるこの方法の適用を例にとると、この方法は、下記のステップを含み得る：

ステップ４０１：受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配することであって、異なる割り当てグループが、異なるリソースサブプールに対応している、分割すること。例えば、予め設定された時間枠で受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配する。

ステップ４０２：割り当てグループ内のクエリ要求の特徴情報に従って、割り当てグループのリソースオーバーヘッドを取得すること。

ステップ４０３：割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードを動的に調整すること。

ステップ４０４：リソースサブプール内の計算ノードを使用することによって、割り当てグループ内のクエリ要求に対応するデータをクエリすること、すなわち異なるクエリ要求が、異なるリソースサブプール内の計算ノードと共に分配され得ること。

一例では、前述の実装順序は、説明の便宜のために与えられた例にすぎない。実際の適用では、ステップ間の実装順序は変更されてもよく、限定されない。さらに、他の実施形態では、本明細書で示され、説明される順序に従って、対応する方法のステップを実装する必要はなく、本方法は、本明細書で説明されるステップよりも多いまたは少ないステップを含んでもよい。さらに、本明細書で説明される単一のステップは、他の実施形態で説明される多数のステップに分割されてもよく、本明細書で説明される多数のステップは、他の実施形態で説明される単一のステップに組み合わせられてもよい。

ステップ４０１の実装の前に、すべての受信されたクエリ要求について、クエリ要求の各々の特徴情報も最初に取得されてもよい。特徴情報は、限定されないが、下記の選択肢、すなわち同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース利用率のうちの１つまたは任意のこれらの組み合わせを含んでもよい。ここで、特徴情報を取得するための方法は、図２に示されるフローを参照できるため、不要な詳細は繰り返さない。

ステップ４０１において、受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配することは、限定されないが、すべての受信されたクエリ要求に対して、クエリ要求の予測されたリソース量は、クエリ要求の特徴情報に従って取得されてもよく、予測リソース量が属するリソース区間が決定され、クエリ要求が、リソース区間が対応する割り当てグループに分配されてもよく、異なる割り当てグループが、異なるリソース区間に対応し得ることを含み得る。

ここで、ステップ２０１において、クエリ要求の予測リソース量を取得するプロセスを参照できるので、不要な詳細は繰り返さない。

ここで、予測リソース量が属するリソース区間が決定され、クエリ要求は、リソース区間が対応する割り当てグループに分配されることは、限定されないが、事前にすべてのリソースサブプールについてリソース区間を構成することを含み得る。割り当て方法に限定は設けられない。例えば、リソースサブプールの計算ノードリソースがより大きいとき、リソースサブプールのリソース区間はより大きくてもよく、リソースサブプールの計算ノードリソースがより小さいとき、リソースサブプールのリソース区間がより小さくてもよい。例えば、リソースサブプール１の計算ノードリソースが４ＣＰＵコアであり、リソースサブプール２の計算ノードリソースが８ＣＰＵコアであり、リソースサブプール３の計算ノードリソースが１６ＣＰＵコアである場合、リソースサブプール１のリソース区間が［０−１）ＣＰＵコアであり、リソースサブプール２のリソース区間が［１−２）ＣＰＵコアであり、リソースサブプール３のリソース区間が［２−無限）ＣＰＵコアである。さらに、割り当てグループは、各リソース区間に対してさらに構成されてもよい。例えば、割り当てグループ１は、リソースサブプール１のリソース区間に対して構成され、割り当てグループ２は、リソースサブプール２のリソース区間に対して構成され、割り当てグループ３は、リソースサブプール３のリソース区間に対して構成される。明らかに、割り当てグループ１はリソースサブプール１に対応し、割り当てグループ２はリソースサブプール２に対応し、割り当てグループ３はリソースサブプール３に対応する。
さらに、クエリ要求の予測リソース量が１ＣＰＵコアであると仮定すると、予測リソース量が属するリソース区間がリソースサブプール２のリソース区間であると決定されてもよく、クエリ要求は割り当てグループ２に分配されてもよい。明らかに、前述の処理が、予め設定された時間枠で受信されたすべてのクエリ要求に対して実施された後、これらのクエリ要求は、すべての割り当てグループに分配されてもよい。例えば、クエリ要求１〜１０は割り当てグループ１に分配され、クエリ要求１１〜５０は割り当てグループ２に分配され、クエリ要求５１〜１００は割り当てグループ３に分配される。

ステップ４０２において、割り当てグループにおけるクエリ要求の特徴情報に従って、割り当てグループのリソースオーバーヘッドを取得することは、割り当てグループ内のすべてのクエリ要求について、クエリ要求の特徴情報に従ってクエリ要求の予測リソース量を取得し、予測リソース量に従って、割り当てグループのリソースオーバーヘッドを取得することを含み得る。

ここで、ステップ４０２の実装プロセスは、ステップ２０１を参照することができる。違いは、ステップ２０１において、処理は、すべての受信されたクエリ要求に対してであり、ステップ４０２において、処理は、割り当てグループ内のすべてのクエリ要求に対してであることである。他のプロセスも同様であるため、不要な詳細は繰り返さない。

ステップ４０３において、割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードを動的に調整することは、割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードの数を取得することと、リソースサブプール内の計算ノードの数と一致する計算ノードを分配することと、を含み得る。

さらに、リソースサブプール内の計算ノードの数と一致する計算ノードを分配することは、リソースサブプール内の既存の計算ノードの数が計算ノードの数よりも少ない場合、計算ノードをリソースサブプール内で増加させ、増加後の計算ノードの数が計算ノードの数以上になるようにし、リソースサブプール内の既存の計算ノードの数が計算ノードの数よりも大きい場合、計算ノードをリソースサブプール内で減少させ、減少後の計算ノードの数が計算ノードの数以上になるようにできることを含み得る。

ここで、ステップ４０３の実施プロセスは、ステップ２０２を参照することができる。違いは、ステップ２０２において、すべての受信されたクエリ要求のリソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードが動的に調整され、ステップ４０３において、割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードが動的に調整されることである。

例えば、ステップ４０３において、リソースサブプール１内の計算ノードの数１０を、割り当てグループ１のリソースオーバーヘッドおよびリソースサブプール１の計算ノードリソースに従って取得することができ、１０個の計算ノードを、リソースサブプール１内に分配する。さらに、リソースサブプール２内の計算ノードの数８を、割り当てグループ２のリソースオーバーヘッドおよびリソースサブプール２の計算ノードリソースに従って取得することができ、８個の計算ノードをリソースサブプール１内に分配する。さらに、リソースサブプール３内の計算ノードの数１３を、割り当てグループ３のリソースオーバーヘッドおよびリソースサブプール３の計算ノードリソースに従って取得することができ、１３個の計算ノードをリソースサブプール３内に分配する。

ここで、ステップ４０４の実装プロセスは、ステップ２０３を参照することができる。違いは、ステップ２０３において、クエリ要求が対応するクエリ要求がリソースプールの計算ノードに送信され、一方、ステップ４０４において、割り当てグループ１のクエリ要求が対応するクエリ要求がリソースサブプール１の計算ノードに送信され、割り当てグループ２のクエリ要求が対応するクエリ要求が、リソースサブプール２の計算ノードに送信され、割り当てグループ３のクエリ要求が対応するクエリ要求が、リソースサブプール３の計算ノードに送信されることであり、このため不要な詳細は繰り返さない。

前述の方法と同じ適用概念に基づいて、本出願の一実施形態は、データクエリ装置をさらに提供する。図５は、装置の構造図である。本装置は、

受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得するための取得モジュール５０１と、リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整するための処理モジュール５０２と、計算ノードを使用することによって、クエリ要求に対応するデータをクエリするためのクエリモジュール５０３と、を備える。

一例では、取得モジュール５０１はさらに、特徴情報がクエリ複雑度を含む場合、クエリ要求からクエリキーワードを取得することと、クエリキーワードを使用することによって第１のマッピングテーブルをクエリして、クエリキーワードに対応する複雑度値を取得し、複雑度値をクエリ要求が対応するクエリ複雑度として決定することと、またはクエリ要求の複数のサブクエリからクエリキーワードを取得することと、取得されたクエリキーワードを使用することによって第１のマッピングテーブルをクエリして、クエリキーワードに対応する複雑度値を取得すること、取得された複雑度値の合計をクエリ要求が対応するクエリ複雑度値として決定することと、を目的とし、第１のマッピングテーブルは、クエリキーワードと複雑度値との間の対応関係を記録している。

前述の方法と同じ適用概念に基づいて、本出願の一実施形態は、受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得することと、リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整することと、計算ノードを使用することによって、クエリ要求に対応するデータをクエリすることと、のためのプロセッサを備える、データクエリデバイスを提供する。

前述の方法と同じ適用概念に基づいて、本出願の一実施形態は、データクエリデバイス上に適用され得る機械可読メモリ媒体をさらに提供する。多数のコンピュータ命令がマシン可読メモリ媒体に記憶され、コンピュータ命令が実行されると、下記の処理が実施される：受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得することと、リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整することと、計算ノードを使用することによって、クエリ要求に対応するデータをクエリすること。

前述の方法と同じ適用概念に基づいて、本出願の一実施形態は、データクエリ装置をさらに提供する。図６は、装置の構造図である。本装置は、

受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配するための分配モジュール６０１であって、異なる割り当てグループが異なるリソースサブプールに対応する、分配モジュール６０１と、割り当てグループ内のクエリ要求の特徴情報に従って、割り当てグループのリソースオーバーヘッドを取得するための取得モジュール６０２と、割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールのコンピュートノードリソースに従って、リソースサブプール内のコンピュートノードを動的に調整するための処理モジュール６０３と、リソースサブプール内の計算ノードを使用することによって、割り当てグループ内のクエリ要求に対応するデータをクエリするためのクエリモジュール６０４と、を備える。

一例では、具体的に、分配モジュール６０３を使用して、受信されたクエリ要求について、クエリ要求の特徴情報に従ってクエリ要求の予測リソース量を取得し、予測リソース量が属するリソース区間を決定し、リソース区間が対応する割り当てグループにクエリ要求を分配し、異なる割り当てグループは、異なるリソース区間に対応する。

前述の方法と同じ適用概念に基づいて、本出願の一実施形態は、受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配し、異なる割り当てグループが、異なるリソースサブプールに対応している、分配することと、割り当てグループ内のクエリ要求の特徴情報に従って、割り当てグループのリソースオーバーヘッドを取得することと、割り当てグループのリソースオーバーヘッドおよび割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードを動的に調整することと、リソースサブプール内の計算ノードを使用することによって、割り当てグループ内のクエリ要求に対応するデータをクエリすることと、のためのプロセッサ、を備える、データクエリデバイスを提供する。

前述の方法と同じ適用概念に基づいて、本出願の一実施形態は、データクエリデバイス上に適用され得る機械可読メモリ媒体をさらに提供する。多数のコンピュータ命令がマシン可読メモリ媒体に記憶され、コンピュータ命令が実行されると、下記の処理が実施される：受信されたクエリ要求の特徴情報に従って、受信されたクエリ要求を少なくとも１つの割り当てグループに分配することであって、異なる割り当てグループが異なるリソースサブプールに対応する、分配することと、割り当てグループ内のクエリ要求の特徴情報に従って、割り当てグループのリソースオーバーヘッドを取得することと、割り当てグループが対応するリソースサブプールのリソースオーバーヘッドおよびリソースサブプールの計算ノードリソースに従って、リソースサブプール内の計算ノードを動的に調整することと、リソースサブプール内の計算ノードを使用することによって、割り当てグループ内のクエリ要求に対応するデータをクエリすること。

前述の実施形態において具体的に説明されるシステム、装置、モジュール、またはユニットは、コンピュータチップまたは存在物によって、または特定の機能を処理する製品によって達成されてもよい。典型的な達成デバイスは、コンピュータである。コンピュータの具体的な形態は、パーソナルコンピュータ（ＰＣ）、ラップトップコンピュータ、携帯電話、カメラ付き携帯電話、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤー、ナビゲーションエイド、電子メールトランシーバ、ゲームコンソール、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスの任意のいくつかの組み合わせであってもよい。

説明の便宜上、前述の装置が説明されるとき、装置は機能によっていくつかのユニットに分割され、ユニットがそれぞれ説明される。もちろん、本出願が実装されるとき、ユニットの機能は、１つまたは複数のソフトウェアおよび／またはハードウェアにユニットを入れることによって達成されてもよい。

当業者は、本出願の実施形態が、方法、システム、またはコンピュータプログラム製品として提供されてもよく、したがって、本出願が、完全にソフトウェア、または完全にハードウェア、またはソフトウェアとハードウェアとの組み合わせの形態で実施形態を採用してもよいことを理解するべきである。さらに、本出願の実施形態は、コンピュータ使用可能プログラムコードを含む、１つまたは複数のコンピュータ使用可能記憶媒体（限定されないが、ディスク記憶装置、ＣＤ−ＲＯＭ、および光記憶装置を含む）上に実装されるコンピュータプログラム製品の形態を採用してもよい。

本出願は、本出願の実施形態による方法、デバイス（システム）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照することによって説明される。フローチャートおよび／またはブロック図におけるすべてのフローおよび／またはブロック、ならびにフローチャートおよび／またはブロック図におけるフローおよび／またはブロックの組み合わせは、コンピュータプログラム命令を通じて達成されてもよいことを理解されたい。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または任意の他のプログラム可能なデータ処理機器のプロセッサに提供されてもよく、機械を生成し、その結果、任意の他のプログラム可能なデータ処理機器のコンピュータまたはプロセッサによって実行される命令を通じて、フローチャートの１つもしくは複数のフローおよび／またはブロック図の１つもしくは複数のブロックにおいて指定された機能を達成するための装置が生成される。

さらに、これらのコンピュータプログラム命令は、コンピュータ可読メモリに記憶することもでき、コンピュータ可読メモリに記憶された命令が命令装置を含む製品を生成するように、コンピュータまたは他のプログラム可能なデータ処理機器を特定の方式で動作させるように誘導されてもよい。命令装置は、フローチャートの１つまたは複数のフローおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能を達成する。

これらのコンピュータプログラム命令はまた、一連の動作ステップがコンピュータまたは他のプログラム可能なデータ処理機器上で実行され、コンピュータによって達成される処理を生成するように、コンピュータまたは他のプログラム可能なデータ処理機器にロードされてもよく、したがって、コンピュータまたは他のプログラム可能なデータ処理機器上で実行される命令は、フローチャートにおけるフローの１つまたは複数のフローおよび／またはブロック図におけるブロックの１つまたは複数のブロックにおいて指定された機能を達成するためのステップを提供する。

前述の説明は、本出願の好ましい実施形態であり、本出願を限定することを意図するものではない。本出願の趣旨および原理から逸脱することなく行われたすべての修正、同一の置換および改良は、本願の範囲内に含まれるものとする。

Claims (29)

1. データクエリ方法であって、
   受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得することと、
   前記リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整することと、
   前記計算ノードを使用することによって前記クエリ要求に対応するデータをクエリすることと、を含む、方法。
2. 前記特徴情報が、下記、すなわち同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース利用のうちの１つまたはこれらの組み合わせを含む、請求項１に記載の方法。
3. 前記受信されたクエリ要求の前記特徴情報に従って前記リソースオーバーヘッドを前記取得する前に、前記方法は、
   前記特徴情報がクエリ複雑度を含む場合、前記クエリ要求からクエリキーワードを取得することと、
   前記クエリキーワードを使用することによって第１のマッピングテーブルをクエリして、前記クエリキーワードに対応する複雑度値を取得し、前記複雑度値を前記クエリ要求が対応するクエリ複雑度として決定することと、をさらに含み、
   前記第１のマッピングテーブルが、クエリキーワードと複雑度値との間の対応関係を記録する、請求項１に記載の方法。
4. 前記受信されたクエリ要求の前記特徴情報に従って前記リソースオーバーヘッドを前記取得する前に、前記方法は、
   前記特徴情報がクエリ複雑度を含む場合、前記クエリ要求の複数のサブクエリからクエリキーワードを取得することと、前記取得したクエリキーワードを使用することによって第１のマッピングテーブルをクエリして、前記クエリキーワードに対応する複雑度値を取得することと、取得した複雑度値の合計を前記クエリ要求が対応する前記クエリ複雑度として決定することと、をさらに含み、
   前記第１のマッピングテーブルが、クエリキーワードと複雑度値との間の対応関係を記録する、請求項１に記載の方法。
5. 前記クエリ要求が、ＳＱＬクエリ要求を含み、
   前記クエリキーワードが、下記、すなわちｊｏｉｎ、ｇｒｏｕｐｂｙ、ｏｒｄｅｒｂｙ、ｄｉｓｔｉｎｃｔ、ｃｏｕｎｔ、およびｗｉｎｄｏｗのうちの１つまたはこれらの組み合わせを含む、請求項３または４に記載の方法。
6. 前記受信されたクエリ要求の前記特徴情報に従って前記リソースオーバーヘッドを前記取得する前に、前記方法が、
   前記クエリ要求のデータＩＤを使用することによって第２のマッピングテーブルをクエリし、前記データＩＤに対応する特徴情報を取得することをさらに含み、
   前記第２のマッピングテーブルが、データＩＤおよび特徴情報の対応関係を記録し、
   前記特徴情報が、走査されたクエリデータ、クエリ応答時間、およびリソース利用のうちの１つまたは複数を含む、請求項１に記載の方法。
7. 前記クエリ要求の前記データＩＤを使用することによって前記第２のマッピングテーブルをクエリして、前記データＩＤに対応する特徴情報を前記取得する前に、前記方法が、
   履歴データを収集し、前記履歴データに従って、データＩＤと特徴情報との間の対応関係を取得することと、
   前記データＩＤと前記特徴情報との間の対応関係を前記第２のマッピングテーブルに記録することと、をさらに含む、請求項６に記載の方法。
8. 前記受信されたクエリ要求の前記特徴情報に従って前記リソースオーバーヘッドを前記取得することが、
   前記受信されたクエリ要求について、前記クエリ要求の前記特徴情報に従って、前記クエリ要求の予測リソース量を取得することと、
   前記クエリ要求の前記予測リソース量に従って、前記リソースオーバーヘッドを決定することと、を含む、請求項１に記載の方法。
9. 前記クエリ要求の前記特徴情報に従って、前記クエリ要求の前記予測リソース量を前記取得することが、
   予測モデルを使用することによって前記クエリ要求の前記特徴情報を分析して、前記クエリ要求の前記予測リソース量を取得することを含み、前記予測モデルが、Ｈｏｌｔ−Ｗｉｎｔｅｒ季節モデル、ＡＲＭＡモデル、線形回帰モデル、ニューラルネットワークモデルを含む、請求項８に記載の方法。
10. 前記リソースオーバーヘッドおよび前記計算ノードリソースに従って、リソースプール内の前記計算ノードを動的に調整することが、
    前記リソースオーバーヘッドおよび前記計算ノードリソースに従って、計算ノードの数を取得し、
    前記リソースプール内の前記計算ノードの数と一致する計算ノードを分配することと、を含む、請求項１に記載の方法。
11. 前記リソースプール内の前記計算ノードの数と一致する前記計算ノードを前記分配することは、
    前記リソースプール内に既に存在する前記計算ノードの数が前記計算ノードの数よりも少ない場合、前記リソースプール内の計算ノードを増加させて、前記増加後の前記計算ノードの数が前記計算ノードの数以上になるようにすることと、
    前記リソースプール内に既に存在する前記計算ノードの数が前記計算ノードの数よりも多い場合、前記リソースプール内の計算ノードを減少させて、前記減少後の前記計算ノードの数が前記計算ノードの数以上になるようにすることと、を含む、請求項１０に記載の方法。
12. データクエリ方法であって、
    受信されたクエリ要求の特徴情報に従って、前記受信されたクエリ要求を少なくとも１つの割り当てグループに分配することであって、異なる割り当てグループが、異なるリソースサブプールに対応している、分配することと、
    割り当てグループにおけるクエリ要求の特徴情報に従って、前記割り当てグループのリソースオーバーヘッドを取得することと、
    前記割り当てグループのリソースオーバーヘッドおよび前記割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、前記リソースサブプール内の計算ノードを動的に調整することと、
    前記リソースサブプール内の計算ノードを使用することによって、前記割り当てグループ内で前記クエリ要求に対応するデータをクエリすることと、を含む、データクエリ方法。
13. 前記特徴情報が、下記、すなわち同時実行性、クエリ複雑度、走査されたクエリデータ、クエリ応答時間、およびリソース利用のうちの１つまたはこれらの組み合わせを含む、請求項１２に記載の方法。
14. 前記受信されたクエリ要求を少なくとも１つの割り当てグループに前記分配する前に、前記方法は、
    前記特徴情報がクエリ複雑度を含む場合、前記クエリ要求からクエリキーワードを取得することと、
    前記クエリキーワードを使用することによって第１のマッピングテーブルをクエリして、前記クエリキーワードに対応する複雑度値を取得し、前記複雑度値を前記クエリ要求が対応するクエリ複雑度として決定することと、をさらに含み、
    前記第１のマッピングテーブルが、クエリキーワードと複雑度値との間の対応関係を記録する、請求項１２に記載の方法。
15. 前記受信されたクエリ要求を少なくとも１つの割り当てグループに前記分配する前に、前記方法は、
    前記特徴情報がクエリ複雑度を含む場合、クエリ要求の複数のサブクエリからクエリキーワードを取得することと、
    前記取得したクエリキーワードを使用することによって第１のマッピングテーブルをクエリして、前記クエリキーワードに対応する複雑度値を取得することと、
    取得された複雑度値の合計を前記クエリ要求が対応するクエリ複雑度として決定することと、をさらに含み、
    前記第１のマッピングテーブルが、クエリキーワードと複雑度値との間の対応関係を記録する、請求項１２に記載の方法。
16. 前記クエリ要求が、ＳＱＬクエリ要求を含み、
    前記クエリキーワードが、下記、すなわちｊｏｉｎ、ｇｒｏｕｐｂｙ、ｏｒｄｅｒｂｙ、ｄｉｓｔｉｎｃｔ、ｃｏｕｎｔ、およびｗｉｎｄｏｗのうちの１つまたはこれらの組み合わせを含む、請求項１４または１５に記載の方法。
17. 前記受信されたクエリ要求を少なくとも１つの割り当てグループに前記分配する前に、前記方法は、
    クエリ要求のデータＩＤを使用することによって第２のマッピングテーブルをクエリし、前記データＩＤに対応する特徴情報を取得することをさらに含み、
    前記第２のマッピングテーブルが、データＩＤおよび特徴情報の対応関係を記録し、
    前記特徴情報が、走査されたクエリデータ、クエリ応答時間、およびリソース利用のうちの１つまたは複数を含む、請求項１２に記載の方法。
18. 前記クエリ要求の前記データＩＤを使用することによって第２のマッピングテーブルをクエリして、前記データＩＤに対応する特徴情報を前記取得する前に、前記方法が、
    履歴データを収集し、前記履歴データに従って、前記データＩＤと特徴情報との間の対応関係を取得することと、
    前記データＩＤと前記特徴情報との間の対応関係を前記第２のマッピングテーブルに記録することと、をさらに含む、請求項１７に記載の方法。
19. 前記受信されたクエリ要求の前記特徴情報に従って、前記受信されたクエリ要求を少なくとも１つの割り当てグループに前記分配することが、
    受信されたクエリ要求について、前記クエリ要求の特徴情報に従って前記クエリ要求の予測リソース量を取得し、前記予測リソース量が属するリソース区間を決定することと、
    前記リソース区間が対応する前記割り当てグループに前記クエリ要求を分配することと、を含む、請求項１２に記載の方法。
20. 割り当てグループ内のクエリ要求の特徴情報に従って、前記割り当てグループの前記リソースオーバーヘッドを取得することが、
    割り当てグループ内のクエリ要求について、前記クエリ要求の特徴情報に従って前記クエリ要求の予測リソース量を取得し、前記予測リソース量に従って前記割り当てグループのリソースオーバーヘッドを決定することを含む、請求項１２に記載の方法。
21. 前記クエリ要求の前記特徴情報に従って、前記クエリ要求の前記予測リソース量を前記取得することが、
    予測モデルを使用することによって前記クエリ要求の特徴情報を分析して、前記クエリ要求の予測リソース量を取得することを含み、
    前記予測モデルが、Ｈｏｌｔ−Ｗｉｎｔｅｒ季節モデル、ＡＲＭＡモデル、線形回帰モデル、ニューラルネットワークモデルを含む、請求項１９または２０に記載の方法。
22. 前記割り当てグループのリソースオーバーヘッドおよび前記割り当てグループが対応する前記リソースサブプールの前記計算ノードリソースに従って、前記リソースサブプール内の前記計算ノードを動的に調整することと、
    前記割り当てグループの前記リソースオーバーヘッドおよび前記割り当てグループが対応する前記リソースサブプールの前記計算ノードリソースに従って、前記リソースサブプール内の計算ノードの数を取得することと、
    前記リソースサブプール内の前記計算ノードの数と一致する計算ノードを分配することと、を含む、請求項１２に記載の方法。
23. 前記リソースサブプール内の前記計算ノードの数と一致する計算ノードを前記分配することは、
    前記リソースサブプール内に既に存在する前記計算ノードの数が前記計算ノードの数よりも少ない場合、前記リソースサブプール内の計算ノードを増加させて、前記増加後の前記計算ノードの数が前記計算ノードの数以上になるようにすることと、
    前記リソースサブプール内に既に存在する前記計算ノードの数が前記計算ノードの数よりも多い場合、前記リソースサブプール内の計算ノードを減少させて、前記減少後の前記計算ノードの数が前記計算ノードの数以上になるようにすることと、を含む、請求項２２に記載の方法。
24. データクエリ装置であって、
    受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得する取得モジュールと、
    前記リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整する処理モジュールと、
    前記計算ノードを使用することによって前記クエリ要求に対応するデータをクエリするクエリモジュールと、を備える、データクエリ装置。
25. 前記取得モジュールは、さらに
    前記特徴情報がクエリ複雑度を含む場合、
    クエリ要求からクエリキーワードを取得し、前記クエリキーワードを使用することによって第１のマッピングテーブルをクエリして、クエリキーワードに対応する複雑度値を取得し、前記複雑度値を前記クエリ要求が対応するクエリ複雑度として決定するか、または
    クエリ要求の複数のサブクエリから前記クエリキーワードを取得し、前記取得されたクエリキーワードを使用することによって第１のマッピングテーブルをクエリして、前記クエリキーワードに対応する前記複雑度値を取得し、前記取得された複雑度値の合計を前記クエリ要求が対応する前記クエリ複雑度として決定し、前記第１のマッピングテーブルが、クエリキーワードと複雑度値との間の対応関係を記録する、前記２４に記載の装置。
26. フロントノードに適用されるデータクエリ装置であって、前記装置が、
    受信されたクエリ要求の特徴情報に従って、前記受信されたクエリ要求を少なくとも１つの割り当てグループに分配する分配モジュールであって、異なる割り当てグループが、異なるリソースサブプールに対応する、分配モジュールと、
    割り当てグループ内のクエリ要求の特徴情報に従って、前記割り当てグループのリソースオーバーヘッドを取得する、取得モジュールと、
    前記割り当てグループのリソースオーバーヘッドおよび前記割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、前記リソースサブプール内の計算ノードを動的に調整する、処理モジュールと、
    前記リソースサブプール内の計算ノードを使用することによって前記割り当てグループ内のクエリ要求に対応するデータをクエリするクエリモジュールと、を備える、データクエリ装置。
27. 前記分配モジュールが、さらに
    受信されたクエリ要求について、前記クエリ要求の前記特徴情報に従って前記クエリ要求の予測リソース量を取得し、前記予測リソース量が属するリソース区間を決定し、
    前記リソース区間が対応する前記割り当てグループに前記クエリ要求を分配し、異なる割り当てグループが、異なるリソース間隔に対応する、請求項２６に記載の装置。
28. データクエリデバイスであって、
    受信されたクエリ要求の特徴情報に従ってリソースオーバーヘッドを取得し、前記リソースオーバーヘッドおよび計算ノードリソースに従って、リソースプール内の計算ノードを動的に調整し、前記計算ノードを使用することによって、前記クエリ要求に対応するデータをクエリするプロセッサ、を備える、データクエリデバイス。
29. データクエリデバイスであって、
    受信されたクエリ要求の特徴情報に従って、前記受信されたクエリ要求を少なくとも１つの割り当てグループに分配することであって、異なる割り当てグループが、異なるリソースサブプールに対応している、分配することと、割り当てグループ内のクエリ要求の特徴情報に従って、前記割り当てグループのリソースオーバーヘッドを取得することと、前記割り当てグループのリソースオーバーヘッドおよび前記割り当てグループが対応するリソースサブプールの計算ノードリソースに従って、前記リソースサブプール内の計算ノードを動的に調整することと、前記リソースサブプール内の計算ノードを使用することによって、前記割り当てグループ内のクエリ要求に対応するデータをクエリすることと、を行うプロセッサを備える、データクエリデバイス。

Images