特許 7583501 データクエリ方法、装置およびデバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-06

(45)【発行日】2024-11-14

(54)【発明の名称】データクエリ方法、装置およびデバイス

(51)【国際特許分類】

   G06F 16/13 20190101AFI20241107BHJP

   G06F 13/10 20060101ALI20241107BHJP

   G06F 13/14 20060101ALI20241107BHJP

   G06F 16/172 20190101ALI20241107BHJP

【ＦＩ】

G06F16/13 100

G06F13/10 340A

G06F13/14 330A

G06F16/172

【請求項の数】 8

(21)【出願番号】P 2020539715

(86)(22)【出願日】2019-01-11

(65)【公表番号】

(43)【公表日】2021-05-06

(86)【国際出願番号】 CN2019071357

(87)【国際公開番号】W WO2019141134

(87)【国際公開日】2019-07-25

【審査請求日】2022-01-06

【審判番号】

【審判請求日】2023-11-02

(31)【優先権主張番号】201810053977.8

(32)【優先日】2018-01-19

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡ ＧＲＯＵＰ ＨＯＬＤＩＮＧ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】ジンビン ドゥー

(72)【発明者】

【氏名】シアン ジョウ

(72)【発明者】

【氏名】ウェンボー マー

(72)【発明者】

【氏名】ジエンナン ジー

(72)【発明者】

【氏名】チャオチュン ジャン

【合議体】

【審判長】吉田 美彦

【審判官】林 毅

【審判官】大塚 俊範

(56)【参考文献】

【文献】米国特許出願公開第２００３／０１０１２３１（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０５３５４１９３（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

G06F16/13

G06F16/172

(57)【特許請求の範囲】

【請求項1】

フロントエンドサーバに適用されるデータクエリ方法であって、前記データクエリ方法は、
クライアントによって送信されたクエリ要求を受信することと、
前記クエリ要求内のデータ識別子を介して、前記データ識別子とリソース占有情報との間の対応関係を記録したマッピングテーブルにクエリを実行して、前記データ識別子に対応するデータセットの前記リソース占有情報を取得することにより、前記クエリ要求に対応する前記データセットの前記リソース占有情報を決定することであって、前記リソース占有情報は、メモリ使用量を少なくとも含む、ことと、
前記リソース占有情報に従って、前記クエリ要求をキャッシュすることを決定することに応答して、前記クエリ要求に対応する前記データセットを取得し、前記データセットを外部メモリに記憶することと、
前記外部メモリから前記データセットを読み取り、前記データセットを前記クライアントに送信することと、を含む、データクエリ方法。

【請求項2】

前記クエリ要求に対応する前記データセットの前記リソース占有情報を決定した後、前記データクエリ方法は、
前記リソース占有情報に従って前記クエリ要求をキャッシュしないことを決定することに応答して、前記クエリ要求に対応する前記データセットを取得し、前記データセットを前記クライアントに送信することをさらに含む、請求項１に記載のデータクエリ方法。

【請求項3】

前記クエリ要求に対応する前記データセットの前記リソース占有情報を決定した後、前記データクエリ方法は、
前記リソース占有情報と前記フロントエンドサーバの現在占有されているリソースの合計がリソース閾値以上の場合、前記クエリ要求をキャッシュすることを決定すること、または
前記リソース占有情報と前記フロントエンドサーバの現在占有されているリソースの前記合計が前記リソース閾値よりも小さい場合、前記クエリ要求をキャッシュしないことを決定することをさらに含む、請求項１または２に記載のデータクエリ方法。

【請求項4】

前記データセットを前記クライアントに送信した後、前記データクエリ方法は、
前記クエリ要求に対応する処理時間を取得することであって、前記処理時間は、前記クエリ要求が受信されてから前記データセットが前記クライアントに送信されるまでの時間である、ことと、
前記クエリ要求に対応する前記処理時間に従って前記リソース閾値を調整することと、をさらに含む、請求項３に記載のデータクエリ方法。

【請求項5】

前記クエリ要求に対応する前記処理時間に従って前記リソース閾値を前記調整することは、
前記クエリ要求に対応する前記処理時間が予め設定された第１の時間閾値よりも長い場合、前記リソース閾値の値を増加させることであって、前記増加されたリソース閾値は、前記リソース閾値の上限よりも大きくない、こと、または
前記クエリ要求に対応する前記処理時間が予め設定された第２の時間閾値よりも短い場合、前記リソース閾値の前記値を減少させることであって、前記減少されたリソース閾値は、前記リソース閾値の下限よりも小さくない、こと、
を含み、
第１の時間閾値は、第２の時間閾値よりも大きい、請求項４に記載のデータクエリ方法。

【請求項6】

前記リソース占有情報は、
メモリ占有率、
ＣＰＵ占有率、および
前記データセットのデータ量のうちの１つまたは任意の組み合わせをさらに含む、請求項１または２に記載のデータクエリ方法。

【請求項7】

フロントエンドサーバに適用されるデータクエリデバイスであって、前記データクエリデバイスは、
クライアントによって送信されたクエリ要求を受信する受信モジュールと、
前記クエリ要求内のデータ識別子を介して、前記データ識別子とリソース占有情報との間の対応関係を記録したマッピングテーブルにクエリを実行して、前記データ識別子に対応するデータセットの前記リソース占有情報を取得することにより、前記クエリ要求に対応する前記データセットの前記リソース占有情報を決定する決定モジュールであって、前記リソース占有情報は、メモリ使用量を少なくとも含む、決定モジュールと、
前記リソース占有情報に従って、前記クエリ要求をキャッシュすることを決定することに応答して、前記クエリ要求に対応する前記データセットを取得する取得モジュールと、
前記データセットを外部メモリに記憶する記憶モジュールと、
前記外部メモリから前記データセットを読み取り、前記クライアントに前記データセットを送信する送信モジュールと、を含む、データクエリデバイス。

【請求項8】

クライアントによって送信されたクエリ要求を受信する受信機と、
前記クエリ要求内のデータ識別子を介して、前記データ識別子とリソース占有情報との間の対応関係を記録したマッピングテーブルにクエリを実行して、前記データ識別子に対応するデータセットの前記リソース占有情報を取得することにより、前記クエリ要求に対応する前記データセットの前記リソース占有情報を決定し、前記リソース占有情報に従って前記クエリ要求をキャッシュすることを決定することに応答して、前記クエリ要求に対応する前記データセットを取得し、前記データセットを外部メモリに記憶し、前記外部メモリから前記データセットを読み取る、プロセッサと、
前記データセットを前記クライアントに送信する送信機と、を含み、
前記リソース占有情報は、メモリ使用量を少なくとも含む、フロントエンドサーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１８年１月１９日に出願され、「データクエリ方法、装置およびデバイス」と題された中国特許出願第２０１８１００５３９７７．８号の優先権を主張し、その全体が参照により本明細書に組み込まれる。

【0002】

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

【背景技術】

【0003】

分析データベースは、あらゆる次元の大量のデータの分析および統計タスクを実行できるリアルタイムコンピューティングエンジンであり、高い同時実行性、低いレイテンシ（ミリ秒の応答）、リアルタイムのオンライン分析、大量のデータクエリ、および多くの他の機能をサポートする。また、分析データベースは大量のデータを記憶できる。クライアントによって送信されたクエリ要求を受信した後、クエリ要求に対応するデータにクエリを実行し、クエリが実行されたデータをクライアントに返すことができる。

【0004】

しかしながら、特定のシナリオ（マップデータクエリ、データプロファイリングクエリなど）において、短期間内に多数のクエリ要求が受信されてもよく（すなわち、同時要求数が非常に多い）、各クエリ要求に対応するデータ量も非常に多くなる。このような場合においては、多数のクエリ要求が非常に短時間に処理される必要があり、各クエリ要求に対して大量のデータが返され、中央処理装置（ＣＰＵ）リソース、メモリリソース、ネットワーク帯域幅などに異常が発生する。このような状況は、クライアントクエリのタイムアウト、または場合によっては不具合をもたらし、これはユーザエクスペリエンスに影響する。

【発明の概要】

【0005】

本出願は、データクエリ方法を提供し、本方法はフロントエンドサーバに適用され、本方法は、
クライアントによって送信されたクエリ要求を受信することと、
クエリ要求に対応するデータセットのリソース占有情報を決定することと、
リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶することと、
外部メモリからデータセットを読み取り、データセットをクライアントに送信することと、を含む。

【0006】

本出願はさらに、データクエリデバイスを提供し、デバイスはフロントエンドサーバに適用され、デバイスは、
クライアントによって送信されたクエリ要求を受信するために使用される受信モジュールと、
クエリ要求に対応するデータセットのリソース占有情報を決定するために使用される決定モジュールと、
リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得するために使用される取得モジュールと、
データセットを外部メモリに記憶するために使用される記憶モジュールと、
外部メモリからデータセットを読み取り、クライアントにデータセットを送信するために使用される送信モジュールと、を含む。

【0007】

本出願はさらに、フロントエンドサーバを提供し、フロントエンドサーバは、
クライアントによって送信されたクエリ要求を受信するために使用される受信機と、
クエリ要求に対応するデータセットのリソース占有情報を決定し、リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶し、外部メモリからデータセットを読み取るために使用されるプロセッサと、
データセットをクライアントに送信するために使用される送信機と、を含む。

【0008】

上記で提供された技術的解決策に基づいて、本出願の例示的な実施形態では、クエリ要求が受信された後、データセットをクライアントに直接送信する代わりに、クエリ要求およびデータセットが最初に外部メモリに記憶される。このようにして、クエリ要求に対応するデータセットがローカルにキャッシュされることによって、短期間内に多数のクエリ要求を処理することを回避する。すなわち、短期間内に多数のデータセットをクライアントに返すことを回避することによって、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅の占有を削減し、クライアントクエリのタイムアウトまたは場合によっては不具合を回避し、ユーザエクスペリエンスを向上させる。

【図面の簡単な説明】

【0009】

本出願の例示的な実施形態または従来技術の技術的解決策をより明確に説明するために、本出願の例示的な実施形態または従来技術の図面を簡単に説明する。明らかに、以下の説明の図面は、本出願のいくつかの例示的な実施形態にすぎない。当業者に対して、本出願の例示的な実施形態のこれらの図面に基づいて、他の図面も取得され得る。

【図1】本出願の例示的な実施形態におけるシステム構造の概略図である。

【図2A】本出願の例示的な実施形態におけるクエリ要求処理の概略図である。

【図2B】本出願の別の例示的な実施形態におけるクエリ要求処理の概略図である。

【図3】本出願の例示的な実施形態におけるデータクエリ方法のフローチャートである。

【図4A】本出願の別の例示的な実施形態におけるデータクエリ方法のフローチャートである。

【図4B】本出願の別の例示的な実施形態におけるデータクエリ方法のフローチャートである。

【図4C】本出願のさらに別の例示的な実施形態におけるデータクエリ方法のフローチャートである。

【図5A】本出願の例示的な実施形態における効果の概略図である。

【図5B】本出願の別の例示的な実施形態における効果の概略図である。

【図5C】本出願の別の例示的な実施形態における効果の概略図である。

【図5D】は、本出願の別の例示的な実施形態における効果の概略図である。

【図5E】本出願のさらに別の例示的な実施形態における効果の概略図である。

【図6】本出願の例示的な実施形態におけるデータクエリデバイスの構造図である。

【発明を実施するための形態】

【0010】

本出願で使用される用語は、特定の例示的な実施形態を説明することのみを目的としており、本出願を限定するものではない。本出願および特許請求の範囲で使用される単数形「１つの」、「前記」、および「その」は、文脈がそうでないことを明確に示さない限り、複数形を含むことも意図される。本明細書で使用される「および／または」という用語は、列挙された項目の１つ以上を含む任意の、またはすべての可能な組み合わせを指すことも理解されたい。

【0011】

本明細書では、第１、第２、第３などの用語が本出願における様々な情報を説明するために使用され得るが、情報はこれらの用語に限定されるべきではないことを理解されたい。これらの用語は、同じ種類の情報を互いから区別するためにのみ使用される。例えば、本出願の範囲から逸脱することなく、第１の情報は、第２の情報とも呼ばれ得る。同様に、第２の情報は、文脈に応じて、第１の情報とも呼ばれ得る。また、「場合」という単語は、「とき」または「間」もしくは「決定に応答して」として解釈され得る。

【0012】

本出願の例示的な実施形態は、クライアント、フロントエンドサーバ（フロントノードとも呼ばれる）、コンピューティングサーバ（コンピューティングノードとも呼ばれる）、および分析データベース（ＡＤＳと呼ばれる分析ＤＢなど）を実装するために使用されるシステムなどのデータベースを含むシステムに適用されることができるデータクエリ方法を提案する。もちろん、本出願において限定されない、リソーススケジューリングサーバなどの他のサーバも含まれ得る。

【0013】

本出願の例示的な実施形態による適用シナリオの概略図である図１を参照すると、クライアント、フロントエンドサーバ、コンピューティングサーバ、およびデータベースの数は、１つ以上であり得る。図１において、３つのクライアント、１つのフロントエンドサーバ、３つのコンピューティングサーバ、および３つのデータベースが例において使用される。もちろん、クライアント、フロントエンドサーバ、コンピューティングサーバ、およびデータベースの数は他の値であり得、本出願において限定されない。

【0014】

その中でも、分析データベースはリアルタイムの計算エンジンであり、あらゆる次元の大量のデータを使用して分析および統計タスクを実行でき、高い同時実行性、低いレイテンシ、リアルタイムのオンライン分析、大量のデータクエリ、およびその他の機能をサポートできる。

【0015】

クライアントは、端末デバイス（ＰＣ（パーソナルコンピュータ）、ノートブックコンピュータ、モバイル端末など）上のＡＰＰ（アプリケーション）または端末デバイス上のブラウザなどのデータベースからのデータにクエリを実行するために使用される。クライアントの具体的な種類に限定はない。

【0016】

データベースは、様々な種類のデータを記憶するために使用され、データベースに記憶されたデータをクライアントに提供できる。データベースに記憶されるデータの具体的な種類に関しては、本出願の例示的な実施形態において限定はなく、ユーザデータ、データ、地図データ、ビデオデータ、画像データ、音声データなどであり得る。

【0017】

フロントエンドサーバは、クライアントによって送信されたクエリ要求を受信し、クエリ要求に対してＳＱＬ（構造化クエリ言語）解析を実行し、ＳＱＬ解析結果を使用してスケジューリング要求を生成し、次に、スケジューリング要求をコンピューティングサーバに送信するために使用される。スケジューリング要求は、クエリ要求に対応するデータを要求するために使用される。さらに、コンピューティングサーバによって返されたデータを受信し、次に、データをクライアントに送信する。

【0018】

コンピューティングサーバは、フロントエンドサーバによって送信されたスケジューリング要求を受信し、スケジューリング要求を使用して、データベースからスケジューリング要求に対応するデータを読み取り、次に、データをフロントエンドサーバに送信する。

【0019】

図２Ａに示されるように、フロントエンドサーバは多数のスレッドを開始でき、各スレッドはクエリ要求を処理するために使用される。例えば、クエリ要求１を受信した後、フロントエンドサーバはクエリ要求１に対するスレッド１を開始し、スレッド１はクエリ要求１を処理し、すなわち、スケジューリング要求をコンピューティングサーバに送信すること、およびコンピューティングサーバによってクライアントに返されたデータを送信することなどの動作を実行する。データをクライアントに送信した後、スレッド１は解放される。スレッド１が作動しているときに、フロントエンドサーバがクエリ要求２を受信した場合、クエリ要求２に対してスレッド２が開始され、スレッド２はクエリ要求２を処理する。スレッド１とスレッド２の両方が作動しているときに、フロントエンドサーバがクエリ要求３を受信した場合、クエリ要求３に対してスレッド３が開始され、したがって、スレッド３がクエリ要求３を処理し、同様に続く。

【0020】

要約すると、フロントエンドサーバが短期間内に多数のクエリ要求を受信すると（すなわち、同時実行数が多い）、フロントエンドサーバは多数のスレッドを開始してもよく、次に、多数のスレッドが多数のクエリ要求を処理する。この場合、各クエリ要求に対応するデータ量が多い場合、各クエリ要求に対して大量のデータが返される必要があり、ＣＰＵリソース、メモリリソース、ネットワーク帯域幅などに異常をもたらし、フロントエンドサーバの処理性能における低下をもたらし、およびクライアントクエリのタイムアウト、または場合によっては不具合の問題をさらに引き起こし、これはユーザエクスペリエンスに悪影響を与える。例えば、各クエリ要求に対して大量のデータが返される必要があるとき、これらのデータは大量のメモリリソースを占有する。その結果、メモリオーバーフローまたは頻繁なメモリリサイクルなどの問題になり得、クエリのタイムアウトまたは不具合をもたらす。

【0021】

前述の問題に対処するために、図２Ｂに示されるように、本出願の例示的な実施形態において、フロントエンドサーバは多数のクエリスレッドを開始してもよく、各クエリスレッドはクエリ要求を処理するために使用される。また、フロントエンドサーバは、外部メモリにおけるクエリ要求を順次処理するために使用されるスケジューリングスレッドを開始できる。例えば、クエリ要求１を受信した後、フロントエンドサーバはクエリ要求１に対してクエリスレッド１を開始し、クエリスレッド１はクエリ要求１を処理する。クエリスレッド１が作動しているときに、フロントエンドサーバがクエリ要求２を受信した場合、クエリ要求２に対してクエリスレッド２が開始され、したがって、クエリスレッド２はクエリ要求２を処理する。クエリスレッド１とクエリスレッド２の両方が作動しているときに、フロントエンドサーバがクエリ要求３、クエリ要求４、クエリ要求５などを受信した場合、これらのクエリ要求に対してクエリスレッドはさらに開始されないが、これらのクエリ要求は外部メモリに記憶される。

【0022】

フロントエンドサーバは、スケジューリングスレッドを開始できる。スケジューリングスレッドは、最初に外部メモリにおけるクエリ要求３を処理する。クエリ要求３の処理が完了すると、スケジューリングスレッドは外部メモリにおけるクエリ要求４を処理する。クエリ要求４の処理が完了した後、次に、スケジューリングスレッドは外部メモリにおけるクエリ要求５を処理し、同様に続く。

【0023】

要約すると、フロントエンドサーバが短期間内に多数のクエリ要求を受信する（すなわち、同時実行数が多い）場合、開始されるクエリスレッドの数が制御され、短期間内に多数のクエリ要求を処理することを回避できる。このようにして、本出願は、短期間内に大量のデータをクライアントに返すことを回避でき、これによって、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅の占有を削減し、処理性能を向上させ、クライアントクエリのタイムアウトまたは不具合を回避し、これによって、ユーザエクスペリエンスを向上させる。

【0024】

上記の適用シナリオにおいて、本出願の例示的な一実施形態において提案されるデータクエリ方法のフローチャートである図３を参照すると、この方法はフロントエンドサーバに適用されることができ、本方法は以下のステップを含むことができる。
ステップ３０１は、クライアントによって送信されたクエリ要求を受信することを含み、
ステップ３０２は、クエリ要求に対応するデータセットのリソース占有情報を決定することを含み、
ステップ３０３は、リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶することを含み、
ステップ３０４は、外部メモリからデータセットを読み取り、データセットをクライアントに送信することを含む。

【0025】

一例において、上記の実行順序は、説明の便宜のために与えられた例にすぎない。実際の適用では、ステップの実行順序も変更され得、本出願において実行順序に限定はない。さらに、他の例示的な実施形態では、対応する方法のステップは、本説明において示され、および説明される順序で必ずしも実行される必要はない。この方法は、本説明において説明されるよりも多いまたは少ないステップを含んでもよい。また、本説明において説明される個々のステップは、他の例示的な実施形態の説明において多数のステップに分割されてもよい。本説明において説明される多数のステップは、他の例示的な実施形態の説明において単一のステップに組み合わせられてもよい。

【0026】

ステップ３０１について、一例において、クライアントがデータを要求するとき、クエリ要求が送信されてもよく、フロントエンドサーバがクライアントによって送信されたクエリ要求を受信し、次に、データベースにおいてデータを要求するためにクエリ要求が使用される。

【0027】

ステップ３０２について、クエリ要求に対応するデータセットのリソース占有情報を決定した後、クエリ要求がリソース占有情報に従ってキャッシュされないことが決定された場合、クエリ要求に対応するデータセットが取得されることができ、次に、データセットが、データセットをキャッシュせずにクライアントに送信される。

【0028】

ステップ３０３について、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶するプロセスは、限定されないが、クエリ要求に対応するコンテキスト情報を外部メモリに記憶し、次に、外部メモリからコンテキスト情報を読み取り、コンテキスト情報を使用してクエリ要求に対応するデータセットを取得し、次に、データセットを外部メモリに記憶することを含んでもよい。

【0029】

ステップ３０３について、一例において、クエリ要求を受信した後、フロントエンドサーバは、クエリ要求に対応するコンテキスト情報を外部メモリに直接記憶してもよく、あるいは、フロントエンドサーバは、具体的な固有の条件が満たされた場合にのみ、クエリ要求に対応するコンテキスト情報を外部メモリに記憶してもよい。

【0030】

クエリ要求に対応するコンテキスト情報およびデータセットを記憶するための記憶媒体（説明の便宜のため、最終的にクライアントに返されるデータはデータセットと呼ばれ、データセットは、本出願の以下の区分においてさらに詳細に説明される）は、内部メモリのリソースを占有することを回避するために、内部メモリ（またはメモリ）ではなく、外部メモリと呼ばれる。外部メモリは、内部メモリおよびＣＰＵキャッシュ以外の記憶デバイスを指す。外部メモリは、限定されないが、ハードディスク、フロッピーディスク、光ディスク、Ｕディスクなどを含んでもよい。外部メモリの種類に対しては、内部メモリと異なる限り、制限はない。

【0031】

クエリ要求に対応するコンテキスト情報は、限定されないが、クエリ要求に対応するクエリ識別子、クエリ要求の受信時間、クエリ要求に対応するユーザ情報（クライアントのＩＰアドレスなど）、クエリ要求に対応する予測データ量、クエリ要求のうちの１つ、または任意の組み合わせを含んでもよい。クエリ要求に対応するコンテキスト情報の一例については、表１を参照されたく、本出願において限定されない。

【0032】

【表1】

【0033】

クエリ要求は、一意であり得るクエリ識別子に対応でき、すなわち、異なるクエリ要求は異なるクエリ識別子を有する。クエリ識別子（表１に示されるクエリ識別子１０１など）を介して、フロントエンドサーバは、受信時間、ユーザ情報、予測データ量、クエリ要求などのコンテンツを取得でき、同様に続く。

【0034】

受信時間は、フロントエンドサーバがクエリ要求を受信した時間を指し、すなわち、フロントエンドサーバがクエリ要求を受信したとき、２０１７．１１．６．１４．１６．１０などのクエリ要求の受信時間を記録してもよい。

【0035】

ユーザ情報は、限定されないが、クライアントのＩＰアドレス（クエリ要求のソースＩＰアドレス）、ユーザ識別情報（クエリ要求から取得されることができるユーザ名、パスワードなど）を含んでもよく、本出願において、これに対する制限はない。

【0036】

予測データ量は、クエリ要求に対応するデータセットの決定されたデータ量（すなわち、データセットのデータサイズ）を指す。例えば、クエリ要求１を受信した後、フロントエンドサーバは実際にはまだクエリ要求１に対応するデータセットを取得していないため、最初にクエリ要求１に対応するデータセットのデータ量に対して決定されることができる。本明細書におけるデータ量は予測データ量であり、決定プロセスについては後の区分において説明される。

【0037】

クエリ要求は、フロントエンドサーバによって受信されたクエリ要求であり、クエリ要求によって運ばれるすべてのコンテンツを含む。

【0038】

一例において、「特定の条件が満たされたときに、クエリ要求に対応するコンテキスト情報を外部メモリに記憶するフロントエンドサーバ」のプロセスは、限定されないが、以下の状況を含むことができ、
図４Ａに示されるようなケース１は、データクエリ方法の別のフローチャートである。本方法は次のステップを含む。
ステップ４１１は、クエリ要求に対応するデータセットのリソース占有情報を決定することを含む。

【0039】

ステップ４１２は、リソース占有情報に従ってクエリ要求をキャッシュするかどうかを決定することを含む。

【0040】

「はい」である場合、ステップ４１３が実行され、「いいえ」の場合、ステップ４１４が実行される。

【0041】

ステップ４１３は、クエリ要求に対応するコンテキスト情報を外部メモリに記憶することを含む。

【0042】

さらに、外部メモリからコンテキスト情報を読み取るステップが実行される。コンテキスト情報は、クエリ要求に対応するデータセットを取得するために使用され、次に、データセットは外部メモリに記憶される。

【0043】

ステップ４１４は、クエリ要求に対応するデータセットを取得し、データセットをクライアントに送信することを含む。

【0044】

ステップ３０２またはステップ４１１について、一例において、「クエリ要求に対応するデータセットのリソース占有情報を決定する」プロセスは、限定されないが、クエリ要求によって運ばれるデータ識別子を介してマッピングテーブルにクエリを実行し、データ識別子に対応するデータセットのリソース占有情報を取得することを含んでもよく、この場合、マッピングテーブルは、データ識別子とリソース占有情報との間の対応関係を記録するために使用される。さらに、マッピングテーブルを生成するために、クエリ要求に対応するデータセットを取得した後、フロントエンドサーバは、クエリ要求によって運ばれるデータ識別子とマッピングテーブルにおけるデータセットのリソース占有情報との間の対応関係を記録してもよい。

【0045】

例えば、データセットＡに対するクエリ要求を初めて受信した後、フロントエンドサーバは、クエリ要求によって運ばれるデータ識別子（データセットＡに対応するデータ識別子１など）を介してマッピングテーブルにクエリを実行する。データ識別子１に対応するリソース占有情報がマッピングテーブルに存在しないため、フロントエンドサーバは、リソース占有情報がデフォルトのリソース占有情報１であることを決定する（リソース占有情報１は、経験に基づいて事前に構成され、データ識別子に対応するリソース占有情報がマッピングテーブルに存在しないとき、リソース占有情報１が決定される）。

【0046】

さらに、フロントエンドサーバがクエリ要求に対応するデータセットを取得した後（後の区分において、クエリ要求に対応するデータセットを取得する方法について説明される）、データセットのリソース占有情報が取得されることができる。リソース占有情報がリソース占有情報Ａであるとすると、データ識別子１とリソース占有情報Ａとの間の対応関係がマッピングテーブルに記録されることができる。表２に示されるように、これはマッピングテーブルの一例である。

【0047】

【表2】

【0048】

フロントエンドサーバがデータセットＡを再度要求するためのクエリ要求を受信した後（２回目、３回目など）、クエリ要求によって運ばれたデータ識別子１を使用してマッピングテーブルにクエリを実行することによって、データ識別子１に対応するリソース占有情報Ａが取得されることができる。すなわち、決定結果はリソース占有情報Ａである。クエリ要求に対応するデータセットを取得した後、フロントエンドサーバは、データセットのリソース占有情報を集計することができる。現在の集計結果がリソース占有情報Ａと同じである場合、リソース占有情報Ａは変更されないままにされ、現在の集計結果がリソース占有情報Ａと異なる場合、リソース占有情報Ａが現在の集計結果に置き換えられる。

【0049】

一例において、上記のリソース占有情報は、限定されないが、メモリ占有率、ＣＰＵ占有率、データセットのデータ量（すなわち、データセットのサイズ）のうちの１つ、または任意の組み合わせを含んでもよい。

【0050】

「データセットのリソース占有情報を集計する」プロセスは、クエリ要求に対応するデータセットが取得された後、データセットに対応するメモリ占有率が集計されることができることを含んでもよく、すなわち、５％など、データセットによってどれだけメモリが占有されているかを集計することができ、これは、このデータセットがメモリの合計の５％を占めることを意味する。クエリ要求に対応するデータセットが取得された後、データセットに対応するＣＰＵ使用率も集計されることができ、すなわち、データセットはＣＰＵの合計の５％を占有することを示す、５％など、データセットによってＣＰＵがどれほど占有されているか、などが集計されることができる。クエリ要求に対応するデータセットが取得された後、データセットに対応するデータ量が集計されることができ、すなわち、データセットのサイズが集計されることができる。

【0051】

ステップ４１２について、一例において、「リソース占有情報に従ってクエリ要求をキャッシュするかどうかを決定する」プロセスは、限定されないが、リソース占有情報とフロントエンドサーバの現在占有されているリソースの合計がリソース閾値以上である場合、クエリ要求がキャッシュされると決定されることができ、または、リソース占有情報とフロントエンドサーバの現在占有されているリソースの合計がリソース閾値未満である場合、クエリ要求がキャッシュされないと決定されてもよいことを含んでもよい。

【0052】

リソース占有情報がメモリ占有率、ＣＰＵ占有率、およびデータセットのデータ量を含むとすると、リソース閾値はメモリ閾値（８５％など）、ＣＰＵ閾値（９０％など）、データ閾値の量（２００Ｍなど）を含んでもよい。フロントエンドサーバは、現在のメモリ使用量（６０％など、メモリの６０％が現在使用されていることを示す）、現在のＣＰＵ使用量（６０％など、ＣＰＵの６０％が現在使用されていることを示す）、および現在の帯域幅の使用量（１００Ｍなど、１００Ｍの帯域幅が現在占有されていることを示す）を集計できる。

【0053】

次に、メモリ占有率と現在のメモリ使用量の合計がメモリ閾値未満である、ＣＰＵ占有率と現在のＣＰＵ使用量の合計がＣＰＵ閾値未満である、および、データセットのデータ量と現在の帯域幅の使用量の合計がデータ量閾値未満である場合、クエリ要求をキャッシュしないと決定される。メモリ占有率と現在のメモリ使用量の合計がメモリ閾値以上である、ＣＰＵ占有率と現在のＣＰＵ使用量の合計がＣＰＵ閾値以上である、およびデータセットのデータ量と現在の帯域幅の使用量の合計がデータ量閾値以上である、の３つの条件のうちの１つ以上が満たされた場合、クエリ要求はキャッシュされると決定される。

【0054】

一例において、リソース閾値（メモリ閾値、ＣＰＵ閾値、データ量閾値など）は、経験に基づいて構成された固定値であってもよく、すなわち、リソース閾値は変化しない。別の例では、リソース閾値は動的に調整されることができ、すなわち、リソース閾値の初期値が経験に従って構成された後、次に、リソース閾値が動的に調整されることができる。リソース閾値の動的調整プロセスは、特定の具体的で例示的な実施形態に関連して以下で説明される。

【0055】

外部メモリにおけるクエリ要求について、クエリ要求のデータセットをクライアントに送信した後、リソース閾値は動的に調整されることができ、すなわち、外部メモリにおける各クエリ要求がリソース閾値の調整をトリガする。

【0056】

例えば、クエリ要求１を受信した後、クエリ要求１をキャッシュするかどうかを決定するためにリソース閾値１が使用され、キャッシュする場合、クエリ要求１に対応するコンテキスト情報が外部メモリに記憶され、クエリ要求１に対応するデータセットをクライアントに送信した後、リソース閾値１はリソース閾値２になるように調整される。クエリ要求２を受信した後、クエリ要求２をキャッシュするかどうかを決定するためにリソース閾値２が使用され、キャッシュされない場合、クエリ要求２に対応するコンテキスト情報は外部メモリに記憶されない。クエリ要求２に対応するデータセットをクライアントに送信した後、リソース閾値２を調整する必要はない。

【0057】

一例において、リソース閾値を動的に調整するプロセスは、クエリ要求に対応する処理時間を取得することを含んでもよく、処理時間は、クエリ要求を受信してからデータセットをクライアントに送信するまでの時間であり得る。次に、リソース閾値は、クエリ要求に対応する処理時間に従って調整されてもよい。さらに、「クエリ要求に対応する処理時間に従ってリソース閾値を調整する」プロセスは、限定されないが、クエリ要求に対応する処理時間が予め設定された第１の時間閾値より長い場合、リソース閾値の値は増加されることができ、この場合、増加したリソース閾値はリソース閾値の上限より大きくなく、クエリ要求に対応する処理時間が事前に設定された第２の時間閾値よりも短い場合、リソース閾値の値は減少されることができ、この場合、減少したリソース閾値は、リソース閾値の下限未満ではないことを含んでもよい。

【0058】

クエリ要求の受信時間はコンテキスト情報から取得されることができ、データセットがクライアントに送信される時間は、リソース閾値が調整される現在の時間である。要約すると、フロントエンドサーバは、現在の時間と受信時間との間の差を、クエリ要求に対応する処理時間として決定してもよい。

【0059】

上述の予め設定された第１の時間閾値と予め設定された第２の時間閾値の両方は、経験に従って構成されることができる。それらに制限はなく、事前に設定された第１の時間閾値は、事前に設定された第２の時間閾値よりも大きくなり得る。

【0060】

リソース閾値の上限は経験に従って構成されることができ、リソース閾値の上限に制限はない。リソース閾値の下限閾値は、経験に従って構成されることができ、リソース閾値の下限閾値に制限はない。もちろん、リソース閾値の上限およびリソース閾値の下限を構成するとき、リソース閾値の上限は、リソース閾値の下限より大きくなり得る。

【0061】

リソース閾値の値を増加させることは、現在のリソース閾値と第１のリソース調整値の合計を計算することを含んでもよく、２つの合計がリソース閾値の上限より大きくない場合、増加したリソース閾値は２つの合計になり、一方で、２つの合計がリソース閾値の上限より大きい場合、増加したリソース閾値はリソース閾値の上限である。

【0062】

リソース閾値の値を減少させることは、現在のリソース閾値と第２のリソース調整値との間の差を計算することを含んでもよく、２つの間の差がリソース閾値の下限閾値より小さくない場合、減少されたリソース閾値は２つの間の差であり、一方で、２つの間の差がリソース閾値のより小さな閾値未満である場合、減少されたリソース閾値はリソース閾値の、より小さな閾値である。

【0063】

第１のリソース調整値および第２のリソース調整値の両方は経験に基づいて構成されてもよく、第１のリソース調整値および第２のリソース調整値は同じであってもよく、または異なっていてもよい。

【0064】

上記の例示的な実施形態において、クエリ要求に対応する処理時間が予め設定された第１の時間閾値より長い場合、クエリ要求がキャッシュに記憶されるとき、クエリ要求の処理時間が比較的長いことを意味する。したがって、キャッシュされる必要があるクエリ要求の数は最小限にされるべきである。これに基づいて、リソース閾値の値が増加されることができ、その結果、リソース占有情報とフロントエンドサーバの現在占有されているリソースの合計はリソース閾値未満である。その結果、クエリ要求はキャッシュされる必要がなく、クエリ要求の処理時間が長すぎるという問題を回避する。

【0065】

上記の例示的な実施形態において、クエリ要求に対応する処理時間が予め設定された第２の時間閾値未満である場合、クエリ要求がキャッシュに記憶されるとき、クエリ要求の処理時間が短縮され得ることを意味する。したがって、キャッシュされる必要のあるクエリ要求の数が増加され得る。これに基づいて、リソース閾値の値が減少され得る。このようにして、リソース占有情報とフロントエンドサーバの現在占有されているリソースの合計は、リソース閾値以上であるべきである。その結果、クエリ要求がキャッシュされ得、フロントエンドサーバの処理リソースが節約され得る。

【0066】

ケース２：図４Ｂを参照すると、データクエリ方法の別のフローチャートが示される。本方法は以下を含む。
ステップ４２１は、クエリ要求によって運ばれるパラメータ情報を解析することを含む。
ステップ４２２は、パラメータ情報がパラメータテーブルに存在するかどうかを決定することを含み、パラメータテーブルは、キャッシュ用のパラメータ情報を記録するために使用され、パラメータ情報が存在する場合、ステップ４２３を実行し、パラメータ情報が存在しない場合、ステップ４２４を実行する。

【0067】

ステップ４２３は、クエリ要求に対応するコンテキスト情報を外部メモリに記憶することを含む。

【0068】

さらに、外部メモリからコンテキスト情報を読み取ることと、コンテキスト情報を使用してクエリ要求に対応するデータセットを取得することと、データセットを外部メモリに記憶することと、を含むステップが次に実行される。

【0069】

ステップ４２４は、クエリ要求に対応するデータセットを取得することと、データセットをクライアントに送信することと、を含む。

【0070】

一例において、フロントエンドサーバは、パラメータ情報をパラメータテーブルにキャッシュする、および記憶するためのパラメータ情報を取得することができる。これに基づいて、クエリ要求を受信した後、クエリ要求によって運ばれたパラメータ情報が解析され、次に、パラメータ情報がパラメータテーブルに存在するかどうかが決定される。答えが「はい」の場合、クエリ要求はキャッシュされる必要があり、一方で、答えが「いいえ」の場合、クエリ要求はキャッシュされる必要がない。

【0071】

一例において、「フロントエンドサーバからキャッシュ用のパラメータ情報を取得し、パラメータ情報をパラメータテーブルに記憶する」プロセスは、限定されないが、以下の方法を含んでもよい。
方式１：フロントエンドサーバはデータベース作成要求を受信し、データベース作成要求は、キャッシュ用のパラメータ情報を運び、データベース作成要求によって運ばれたパラメータ情報をパラメータテーブルに記録する。

【0072】

一部のパラメータ情報がキャッシュされる必要がある場合、キャッシュ用のそれらのパラメータ情報が指定されてもよい。具体的には、パラメータ情報を含むデータベース作成要求は、キャッシュ用のパラメータ情報をフロントエンドサーバに通知するためにフロントエンドサーバに送信されてもよい。次に、フロントエンドサーバは、データベース作成要求によって運ばれたパラメータ情報をパラメータテーブルに記録する。

【0073】

例えば、データベース作成要求は、ｃｒｅａｔｅ ｄａｔａｂａｓｅ ｔｅｓｔ ｏｐｔｉｏｎｓ（ｒｅｓｏｕｒｃｅ＿ｔｙｐｅ＝’ｅｃｕ’ｅｃｕ＿ｔｙｐｅ＝’ｃ１’ｅｃｕ＿ｃｏｕｎｔ＝２ ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’）であり得、この場合、ｃｒｅａｔｅ ｄａｔａｂａｓｅ ｔｅｓｔ ｏｐｔｉｏｎｓは、現在のメッセージがデータベース作成要求であることを示し、ｒｅｓｏｕｒｃｅ＿ｔｙｐｅ＝’ｅｃｕ’は、対象のデータベースのリソースモデルの種類であり、ｅｃｕ＿ｔｙｐｅ＝’ｃ１’は、対象のデータベースのリソースモデルであり、ｅｃｕ＿ｃｏｕｎｔ＝２は、対象のデータベースのリソースモデルの数量情報であり、および、ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’は、キャッシュ用のパラメータ情報である。

【0074】

また、上記のパラメータ情報は、現在のデータベースにおけるすべてのテーブルに有効である。つまり、現在のデータベースにおけるすべてのテーブルについて、これらのテーブルに対するクエリ要求が受信され、クエリ要求が上記のキャッシュ用のパラメータ情報を運ぶ場合、クエリ要求はキャッシュされる必要があることを意味する。

【0075】

方式２：フロントエンドサーバは、キャッシュ用のパラメータ情報を運ぶテーブルグループ作成要求を受信し、テーブルグループ作成要求によって運ばれるパラメータ情報をパラメータテーブルに記録する。

【0076】

一部のパラメータ情報がキャッシュされる必要がある場合、データベーステーブルグループを作成するときに、キャッシュ用のパラメータ情報が指定されてもよい。具体的には、キャッシュ用のパラメータ情報をフロントエンドサーバに通知するためにパラメータ情報を運ぶテーブルグループ作成要求がフロントエンドサーバに送信されることができる。フロントエンドサーバは、テーブルグループ作成要求によって運ばれたパラメータ情報をパラメータテーブルに記録する。

【0077】

例えば、テーブルグループ作成要求の一例は、ｃｒｅａｔｅ ｔａｂｌｅｇｒｏｕｐ ｔｅｓｔ ｏｐｔｉｏｎｓ（ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’）を含んでもよく、この場合、ｃｒｅａｔｅ ｔａｂｌｅｇｒｏｕｐ ｔｅｓｔ ｏｐｔｉｏｎｓは、現在のメッセージがテーブルグループ作成要求であることを示し、および、ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’は、キャッシュ用のパラメータ情報である。

【0078】

また、上記のパラメータ情報は、現在のテーブルグループにおけるすべてのテーブルについて有効である。すなわち、現在のテーブルグループにおけるすべてのテーブルについて、これらのテーブルに対するクエリ要求が受信され、クエリ要求が上記のキャッシュ用のパラメータ情報を運ぶ場合、クエリ要求はキャッシュされる必要があることを示す。

【0079】

方式３：フロントエンドサーバがテーブル作成要求を受信し、テーブル作成要求がキャッシュ用のパラメータ情報を運び、次に、テーブル作成要求によって運ばれるパラメータ情報がパラメータテーブルに記録される。

【0080】

一部のパラメータ情報がキャッシュされる必要がある場合、データベーステーブルを作成するときに、キャッシュ用のパラメータ情報が指定されることができる。具体的には、パラメータ情報を運ぶテーブル作成要求はフロントエンドサーバに送信されることができ、その結果、フロントエンドサーバはキャッシュ用のパラメータ情報を通知されることができる。次に、フロントエンドサーバは、テーブル作成要求によって運ばれるパラメータ情報をパラメータテーブルに記録する。

【0081】

例えば、テーブル作成要求の一例は、ＣＲＥＡＴＥ ＴＡＢＬＥ ｔｅｓｔ （ｃｏｌ１ ｖａｒｃｈａｒ，ｃｏｌ２ ｖａｒｃｈａｒ，ＰＲＩＭＡＲＹ ＫＥＹ（ｃｏｌ１））ＰＡＲＴＩＴＩＯＮ ＢＹ ＨＡＳＨ ＫＥＹ（ｃｏｌ１）ＰＡＲＴＩＴＩＯＮ ＮＵＭ １０ ＳＵＢＰＡＲＴＩＴＩＯＮ ＢＹ ＬＩＳＴ ＫＥＹ（ｃｏｌ２）ＴＡＢＬＥＧＲＯＵＰ ｔｅｓｔ＿ｇｒｏｕｐ ＯＰＴＩＯＮＳ（ＵＰＤＡＴＥＴＹＰＥ＝’ｒｅａｌｔｉｍｅ’ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’）であり得、この場合、ＣＲＥＡＴＥ ＴＡＢＬＥ ｔｅｓｔは、現在のメッセージがテーブル作成要求であることを示し、（ｃｏｌ１ ｖａｒｃｈａｒ、ｃｏｌ２ ｖａｒｃｈａｒ、ＰＲＩＭＡＲＹ ＫＥＹ（ｃｏｌ１））ＰＡＲＴＩＴＩＯＮ ＢＹ ＨＡＳＨ ＫＥＹ（ｃｏｌ１）ＰＡＲＴＩＴＩＯＮ ＮＵＭ １０ ＳＵＢＰＡＲＴＩＴＩＯＮ ＢＹ ＬＩＳＴ ＫＥＹ（ｃｏｌ２）ＴＡＢＬＥＧＲＯＵＰ ｔｅｓｔ＿ｇｒｏｕｐ ＯＰＴＩＯＮＳはテーブルに関連し、ＵＰＤＡＴＥＴＹＰＥ＝’ｒｅａｌｔｉｍｅ’はテーブルの種類の情報であり、および、ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’は、キャッシュ用のパラメータ情報である。

【0082】

上記のパラメータ情報は、現在のテーブルに対してのみ有効である。つまり、現在のテーブルに対するクエリ要求が受信され、クエリ要求がパラメータ情報を運ぶ場合、クエリ要求がキャッシュされる必要があることを示す。

【0083】

上記の例示的な実施形態において、すべてのテーブルは、データベースにおけるデータテーブルを参照し、これは、本出願において限定されない。

【0084】

もちろん、上記の例示的な実施形態は、「クエリ要求をキャッシュするかどうか」のいくつかの例を提供するだけであり、本出願においてそれに対する限定はない。例えば、クエリ要求がキャッシュされる必要がある場合、ヒントパラメータがクエリ要求によって運ばれることができる。例えば、クエリ要求は／＊＋ｗｉｔｈＲｅｓｕｌｔＣａｃｈｅ＝ｔｒｕｅ＊／ｓｅｌｅｃｔ ｉｄ，ｎａｍｅ ｆｒｏｍ ｔｅｓｔ ｌｉｍｉｔ １００である。クエリ要求はヒントパラメータを運ぶため、フロントエンドサーバは、クエリ要求を受信した後、クエリ要求をキャッシュすることを決定する。別の例において、フロントエンドサーバは、グローバルスイッチ、データベーススイッチ、テーブルグループスイッチ、およびテーブルスイッチの具体的な状況を通してキャッシュを使用してもよい。具体的には、グローバルスイッチがオンである場合、すべてのクエリ要求がキャッシュされる。グローバルスイッチがオフであり、かつデータベーススイッチがオンである場合、データベースへのすべてのクエリ要求がキャッシュされる。グローバルスイッチおよびデータベーススイッチがオフであり、テーブルグループスイッチがオンである場合、テーブルグループに対するすべてのクエリ要求がキャッシュされる。グローバルスイッチ、データベーススイッチ、およびテーブルグループスイッチがオフであり、テーブルスイッチがオンである場合、テーブルに対するすべてのクエリ要求がキャッシュされる。

【0085】

ケース３、図４Ｃに示されるように、データクエリ方法の別のフローチャートが提供される。本方法は以下を含む。
ステップ４３１は、クエリ要求によって運ばれるパラメータ情報を解析することを含む。
ステップ４３２は、パラメータ情報がパラメータテーブルに存在するかどうかを決定することを含む。

【0086】

答えが「はい」である場合、ステップ４３３が実行され、答えが「いいえ」である場合、ステップ４３６が実行される。

【0087】

ステップ４３３は、クエリ要求に対応するデータセットのリソース占有情報を決定することを含む。

【0088】

ステップ４３４は、リソース占有情報に従ってクエリ要求をキャッシュするかどうかを決定することを含む。

【0089】

答えが「はい」である場合、ステップ４３５が実行され、答えが「いいえ」である場合、ステップ４３６が実行される。

【0090】

ステップ４３５は、クエリ要求に対応するコンテキスト情報を外部メモリに記憶することを含む。

【0091】

ステップ４３６は、クエリ要求に対応するデータセットを取得することと、データセットをクライアントに送信することと、を含む。

【0092】

上述のケース１、ケース２、およびケース３において、「クエリ要求に対応するデータセットを取得して、データセットをクライアントに送信する」プロセスについて、フロントエンドサーバはクエリ要求に対してＳＱＬ解析を実行でき、ＳＱＬ解析結果を使用してスケジューリング要求を生成することができ、ならびに、スケジューリング要求をコンピューティングサーバに送信することができ、この場合、スケジューリング要求は、クエリ要求に対応するデータを要求するために使用され、次に、フロントエンドサーバは、コンピューティングサーバによって返されたデータセットを受信してもよく、ならびに、データセットをクライアントに送信してもよい。

【0093】

ステップ３０３について、一例において、「外部メモリからコンテキスト情報を読み取る」プロセスは、限定されないが、外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応する優先度を決定し、次に、コンテキスト情報に対応する優先度を使用して、外部メモリにおけるコンテキスト情報をソートし、ソート結果に従って、優先度が最も高いコンテキスト情報を外部メモリから読み取ることを含んでもよい。

【0094】

外部メモリは、多数のコンテキスト情報を記憶してもよい。すべてのコンテキスト情報について、フロントエンドサーバは、各コンテキスト情報に対応する優先度を決定することができ、外部メモリにおけるすべてのコンテキスト情報を優先度の高い順にソートすることができ、次に、最も高い優先度を有するコンテキスト情報、すなわち、最初のコンテキスト情報を読み取ることができ、または、優先度の低い順に従って、外部メモリにおけるすべてのコンテキスト情報をソートすることができ、次に、最も高い優先度を有するコンテキスト情報、すなわち、最後のコンテキスト情報を読み取ることができる。

【0095】

一例において、表１に示されるように、コンテキスト情報は、限定されないが、クエリ要求の受信時間およびクエリ要求に対応する予測データ量を含んでもよい。これに基づいて、「外部メモリにおけるコンテキスト情報を使用して、コンテキスト情報に対応する優先度を決定する」プロセスは、限定されないが、フロントエンドサーバが、現在の時間と受信時間との間の差を使用してコンテキスト情報に対応する待機時間を決定し、次に、待機時間および予測データ量に従って、コンテキスト情報に対応する優先度を決定する。

【0096】

さらに、「待機時間および予測データ量に従ってコンテキスト情報に対応する優先度を決定する」プロセスは、限定されないが、待機時間に対して正規化処理を実行して、第１のサブウェイトを得ることと、予測データ量に対して正規化処理を実行して、第２のサブウェイトを取得することと、次に、第１のサブウェイトおよび第２のサブウェイトに従って第１の重み値を取得することと、次に、第１の重み値に従って、コンテキスト情報に対応する優先度を取得することと、を含んでもよく、この場合、第１の重み値が大きいほど、コンテキスト情報に対応する優先度は高くなり、第１の重み値が小さいほど、コンテキスト情報に対応する優先度は低くなる。

【0097】

例えば、外部メモリにおけるコンテキスト情報が表３に示されるとすると、フロントエンドサーバは、クエリＩＤ１０１に対応する優先度Ａ、クエリＩＤ１０２に対応する優先度Ｂ、およびクエリＩＤ１０３に対応する優先度Ｃを決定することができる。具体的には、現在の時間が２０１７．１１．６．１４．１６．１８（すなわち、２０１７年１１月６日の１４：１６：１８）であるとすると、クエリ識別子１０１に対応する待機時間は８秒であり、クエリ識別子１０２に対応する待機時間は３秒であり、およびクエリ識別子１０３に対応する待機時間は１秒である。

【0098】

【表3】

【0099】

次に、待機時間に対して正規化処理が実行され、すなわち、待機時間は０～１の値に変換されることができる。変換プロセスにおいて、待機時間が長いほど、正規化された第１のサブウェイトが大きくなる。例えば、クエリ識別子に対応する待機時間は、すべてのクエリ識別子の待機時間の合計で除算される。したがって、クエリ識別子１０１に対応する第１のサブウェイトは８／１２、つまり０．６６７である。クエリ識別子１０２に対応する第１のサブウェイトは３／１２、つまり０．２５である。クエリ識別子１０３に対応する第１のサブウェイトは１／１２、つまり０．０８３である。もちろん、上記の方法は待機時間の正規化処理の一例に過ぎず、処理方法に対する制限はない。

【0100】

予測データ量に対して正規化処理を実行してもよく、すなわち、予測データ量は０～１の値に変換されることができる。変換プロセスにおいて、予測データ量が多いほど、正規化された第２のサブウェイトは小さくなり、具体的な計算は、例えば、すべてのクエリ識別子の予測データ量の合計から、このクエリ識別子に対応する予測データ量を引き、次に、前述の結果をすべてのクエリ識別子の予測データ量の合計で除算する。したがって、クエリ識別子１０１に対応する第２のサブウェイトは（３７．６－２５．６）／３７．６であり、つまり、０．３１９である。クエリ識別子１０２に対応する第２のサブウェイトは（３７．６－１０）／３７．６であり、つまり、０．７３４である。クエリ識別子１０３に対応する第２のサブウェイトは（３７．６－２）／３７．６であり、つまり、０．９４７である。もちろん、上記は正規化処理の一例に過ぎず、処理方法に対する制限はない。

【0101】

次に、第１のサブウェイトと第２のサブウェイトの積が第１の重み値として使用される。例えば、クエリ識別子１０１に対応する第１の重み値は０．６６７＊０．３１９、または０．２１３であり、クエリ識別子１０２に対応する第１の重み値は０．２５＊０．７３４、または０．１８３であり、およびクエリ識別子１０３に対応する第１の重み値は、０．０８３＊０．９４７、または０．０７９である。

【0102】

次に、第１の重み値に従って、クエリ識別子に対応する優先度が取得される。第１の重み値が大きいほど優先度が高くなり、第１の重み値が小さいほど優先度が低くなるという条件が満たされている限り、この問題に対する制限はない。例えば、第１の重み値０．２１３に対応する優先度は２１３（または２１）であり、第１の重み値０．１８３に対応する優先度は１８３（または１８）であり、第１の重み値０．０７９に対応する優先度は７９（または８）である。

【0103】

要約すると、クエリ識別子１０１に対応する優先度は、クエリ識別子１０２に対応する優先度より高くてもよく、クエリ識別子１０２に対応する優先度は、クエリ識別子１０３に対応する優先度より高くてもよい。つまり、外部メモリにおけるすべてのコンテキスト情報のソート結果は、クエリ識別子１０１に対応するコンテキスト情報、クエリ識別子１０２に対応するコンテキスト情報、およびクエリ識別子１０３に対応するコンテキスト情報である。したがって、フロントエンドサーバは、クエリ識別子１０１に対応するコンテキスト情報を外部メモリから読み取ることができる。

【0104】

次に、フロントエンドサーバは、クエリ識別子１０１に対応するコンテキスト情報からクエリ要求１を解析し、クエリ要求１に対応するデータセットを取得する。取得したデータセットをデータセットＡとする。次に、データセットＡは外部メモリに記憶される。データセットＡを記憶した後の一例を示す表４を参照されたい。

【0105】

【表4】

【0106】

ステップ３０３について、一例において、「クエリ情報に対応するデータセットを取得するためにコンテキスト情報を使用する」プロセスは、限定されないが、フロントエンドサーバは、コンテキスト情報からクエリ要求を解析し、クエリ要求に対応するスケジューリング要求を生成し、次に、スケジューリング要求をコンピューティングサーバに送信し、次に、フロントエンドサーバは、スケジューリング要求に対応するコンピューティングサーバによって返されたデータセットを受信し、データセットは、上述のクエリ要求に対応するデータセットでもある、ステップを含んでもよい。説明の便宜のため、コンピューティングサーバによってフロントエンドサーバに返されるデータは、データセットと呼ばれ得る。

【0107】

上記のクエリ要求は、ＳＱＬクエリ要求であってもよい。したがって、フロントエンドサーバは、クエリ要求に対してＳＱＬ解析を実行し、および、クエリ要求がデータセット１およびデータセット２などのデータセットを要求するために使用されることを学習する。次に、フロントエンドサーバは、データセット１に対応するコンピューティングサーバを見つけるための分析を実行し、次に、データセット１を要求するために、スケジューリング要求をコンピューティングサーバに送信し、スケジューリング要求を受信した後、コンピューティングサーバはデータセット１をフロントエンドサーバに送信する。また、フロントエンドサーバは、データセット２に対応する別のコンピューティングサーバを見つけるために分析を実行し、次に、データセット２を要求するためにコンピューティングサーバにスケジューリング要求を送信し、スケジューリング要求を受信した後、コンピューティングサーバはデータセット２をフロントエンドサーバに送信する。データセット１およびデータセット２を受信した後、フロントエンドサーバは、データセット１およびデータセット２をデータセット、すなわちクエリ要求に対応するデータセットに形成することができる。

【0108】

ステップ３０３において、フロントエンドサーバが外部メモリからコンテキスト情報を読み取る場合、外部メモリに多数のコンテキスト情報がある場合でも、フロントエンドサーバは１回の読み取りプロセスにおいて１つのコンテキスト情報しか読み取ることができない。コンテキスト情報を使用してクエリ要求に対応するデータセットを取得し、および、データセットを外部メモリに記憶した後、別のコンテキスト情報が外部メモリから読み取られ得（読み取りプロセス、優先度を決定するステップ、ソートおよび他の動作が再び実行されるが、ここでは繰り返されない）、同様に続く。

【0109】

図２Ｂに示されるように、フロントエンドサーバはスケジューリングスレッドを開始でき、このスレッドは、最初に、外部メモリにおけるクエリ要求３を処理し、クエリ要求３に対応するデータセットを取得し、および、外部メモリにデータセットを記憶した後、スケジューリングスレッドは外部メモリにおけるクエリ要求４を処理し、同様に続く。

【0110】

ステップ３０４について、一例において、「外部メモリからデータセットを読み取る」プロセスは、限定されないが、外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応するデータセットを決定し、次に、データセットの優先度を使用して外部メモリにおけるデータセットをソートし、次に、データセットのソート結果に従って外部メモリからデータセットを読み取るステップを含んでもよい。

【0111】

多数のデータセットが外部メモリに記憶されてもよく、各データセットは対応するコンテキスト情報を有する。すべてのデータセットについて、フロントエンドサーバは、データセットの優先度を決定し、外部メモリにおけるすべてのデータセットを優先度の高い順にソートするために、各データセットに対応するコンテキスト情報を使用してもよく、あるいは、外部メモリにおけるすべてのデータセットを優先度の高い順にソートしてもよい。

【0112】

一例において、クエリ要求に対応するデータセットを取得した後、フロントエンドサーバはデータセットのデータ量（すなわち、予測データ量とは異なり得る、実際のデータ量）を集計してもよく、次に、データセットのコンテキスト情報にデータセットのデータ量を記憶する。表５に示されるように、これはコンテキスト情報の例である。

【0113】

【表5】

【0114】

要約すると、コンテキスト情報は、限定されないが、クエリ要求の受信時間と、クエリ要求に対応するデータセットのデータ量と、を含んでもよい。前述に基づいて、「外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応するデータセットの優先度を決定する」プロセスは、限定されないが、フロントエンドサーバが、現在の時間と受信時間との間の差を使用して、コンテキスト情報に対応する待機時間を決定し、次に、データセットの待機時間とデータ量に従って、コンテキスト情報に対応するデータセットの優先度が決定されることを含んでもよい。

【0115】

さらに、「待機時間およびデータセットのデータ量に従ってコンテキスト情報に対応するデータセットの優先度を決定する」プロセスは、限定されないが、待機時間に対して正規化処理を実行して、第３のサブウェイトを取得することと、データ量に対して正規化処理を実行して、第４のサブウェイトを取得することと、第３のサブウェイトおよび第４のサブウェイトに従って第２の重み値を取得することと、第２の重み値に従ってデータセットの優先度を取得することと、を含み、この場合、第２の重み値が大きいほど優先度は高くなり、第２の重み値が小さいほど優先度は低くなる。

【0116】

待機時間に対する正規化処理により、待機時間は０～１の値に変換され得る。変換プロセスにおいて、待機時間が長いほど、正規化された第３のサブウェイトが大きくなる。データ量が正規化された後、データ量は０～１の値に変換され得る。変換プロセスにおいて、データ量が多いほど、正規化された第４のサブウェイトが小さくなる。第３のサブウェイトおよび第４のサブウェイトに基づいて第２の重み値が取得されるときに、第３のサブウェイトと第４のサブウェイトの積が第２の重み値として使用される。

【0117】

「待機時間およびデータセットのデータ量に従ってデータセットの優先度を決定する」プロセスは、「待機時間および予測データ量に従ってコンテキスト情報に対応する優先度を決定する」プロセスと同様であり、これらの間の違いは、ここで使用されるデータセットのデータ量が予測データ量とは異なることであり、このプロセスはここでは繰り返されない。

【0118】

要約すると、データセットＡの優先度がデータセットＢの優先度より高く、かつ、データセットＢの優先度がデータセットＣの優先度より高いとすると、ソート結果は、データセットＡ、データセットＢ、データセットＣとなる。

【0119】

一例において、「データセットのソート結果に従って外部メモリからデータセットを読み取る」プロセスは、限定されないが、優先度が高い順にソートされる場合、フロントエンドサーバは、データセットのソート結果に従って外部メモリから上位Ｎ個のデータセットを読み取ってもよく、または優先度が低い順にソートされる場合、フロントエンドサーバは、データセットのソート結果に従って外部メモリから下位Ｎ個のデータセットを読み取ってもよいことを含んでもよい。

【0120】

Ｎは１以上の正の整数である。また、Ｎ個のデータセットに対応するリソース占有情報とフロントエンドサーバの現在占有されているリソースの合計は、現在のリソース閾値よりも小さい。

【0121】

リソース占有情報がメモリ占有率、ＣＰＵ占有率、およびデータセットのデータ量を含む場合、リソース閾値は、メモリ閾値、ＣＰＵ閾値、およびデータ量閾値を含んでもよい。さらに、フロントエンドサーバは、現在のメモリ使用量、現在のＣＰＵ使用量、および現在の帯域幅の使用量も集計できる。

【0122】

これに基づいて、フロントエンドサーバは、メモリ占有率（ステップ４１１を参照）、ＣＰＵ使用率（ステップ４１１を参照）、および最も高い優先度を有するデータセットに対応するデータセットのデータ量（表５から取得される）を決定する。

【0123】

メモリ占有率と現在のメモリ使用量の合計がメモリ閾値よりも少ない一方で、ＣＰＵ使用量と現在のＣＰＵ使用量の合計がＣＰＵ閾値より少なく、かつ、データセットのデータ量と現在の帯域幅の使用量の合計がデータ量閾値より少ない場合、最も高い優先度を有するデータセットが外部メモリから読み取られる。上記の３つの条件のうちの１つ以上が満たされない場合、データセットは外部メモリから読み取られない。予め設定された時間だけ待機した後、最も高い優先度を有するデータセットが外部メモリから読み取られ得るかどうかが再度決定される。

【0124】

フロントエンドサーバは、外部メモリから最も高い優先度を有するデータセットを読み取った後、メモリ占有率、ＣＰＵ使用率、および２番目に高い優先度を有するデータセットに対応するデータセットのデータ量を決定する。最も高い優先度を有するデータセットに対応するメモリ占有率、２番目に高い優先度を有するデータセットに対応するメモリ占有率、および現在のメモリ使用量の合計が、メモリ閾値未満である一方で、最も高い優先度を有するデータセットに対応するＣＰＵ使用量、２番目に高い優先度を有するデータセットに対応するＣＰＵ使用量、および現在のＣＰＵ使用量の合計が、ＣＰＵ閾値未満であり、かつ最も高い優先度を有するデータに対応するデータ量、２番目に高い優先度を有するデータセットに対応するデータ量、および現在の帯域幅の使用量の合計が、データ量閾値未満である場合、２番目に高い優先度を有するデータセットが外部メモリから読み取られ、同様に続く。上記の３つの条件のうちの１つ以上が満たされない場合、２番目に高い優先度を有するデータセットは外部メモリから読み取られず、読み取りプロセスが終了する。

【0125】

要約すると、フロントエンドサーバは外部メモリからＮ個のデータセットを読み取ることができ、Ｎ個のデータセットに対応するリソース占有情報とフロントエンドサーバの現在占有されているリソースの合計は、リソース閾値未満である。

【0126】

一例において、フロントエンドサーバが外部メモリからＮ個のデータセットを読み取った後、読み取ったＮ個のデータセットをクライアントに送信する。例えば、コンテキスト情報におけるユーザ情報は、対応するクライアントにデータセットを送信するために使用され、送信プロセスはここでは繰り返されない。次に、フロントエンドサーバは、データセットに対応するコンテキスト情報を外部メモリから削除し、したがって、データセットを送信するプロセス全体を完了してもよい。

【0127】

ステップ３０４において、フロントエンドサーバが外部メモリからデータセットを読み取るとき、外部メモリに多数のデータセットがある場合でも、フロントエンドサーバは、単一の読み取りプロセスでＮ個のデータセットしか読み取ることができない。Ｎ個のデータセットがクライアントに送信された後、フロントエンドサーバは外部メモリから別のデータセットを再度読み取り、同様に続く。

【0128】

上記の技術的解決策に基づいて、本出願の例示的な実施形態において、クエリ要求を受信した後、データセットをクライアントに直接送信する代わりに、クエリ要求およびデータセットが実際に最初に外部メモリに記憶される。このようにして、クエリ要求に対応するデータセットがローカルにキャッシュされることができ、これによって、多数のクエリ要求を短時間内に処理する問題を回避し、多数のデータセットをクライアントに短時間内に返すことを回避し、これによって、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅の占有を削減し、クライアントクエリのタイムアウトまたは不具合の問題を回避し、ユーザエクスペリエンスを向上させる。さらに、上記の方法では、大量のデータを含むクエリ要求をローカルストレージにキャッシュできるが、少量のデータを含むクエリ要求はローカルストレージにキャッシュされない。このようにして、少量のデータを含むクエリ要求に影響を与えずに、少量のデータを含むデータセットがクライアントに直接送信され得、したがって、フルｇｃの頻度が可能な限り削減される。

【0129】

図５Ａは、テスト結果の概略図である。／＊＋ｗｉｔｈＲｅｓｕｌｔＣａｃｈｅ＝ｔｒｕｅ＊／ｓｅｌｅｃｔ ｉｄ，ｎａｍｅ，．．．．，ｒｅｇｉｏｎ ｆｒｏｍ ｔｅｓｔ ｗｈｅｒｅ ｉｄ＝ｘｘｘ ｌｉｍｉｔ ｘｘｘ、ｌｉｍｉｔ １０，ｌｉｍｉｔ １００，ｌｉｍｉｔ ５００，ｌｉｍｉｔ １０００，ｌｉｍｉｔ ２０００，ｌｉｍｉｔ ５０００，ｌｉｍｉｔ ８０００，ｌｉｍｉｔ１００００が、それぞれデータセットの行数を限定するために使用される、大量のデータを有するテーブルに対してクエリが実行される。この場合、データセットにおける行数が多いほど、データセットのデータ量が多くなる。図５Ａにおいて、データセットのデータ量と平均クエリ時間との間の関係が提供される。メモリ使用量をシミュレートするために、テストの前に他のプログラムが実行されてメモリ使用量を約７５％に保ち、次に、上記のクエリ動作が非同期に実行される。図５Ａに見られるように、本出願の技術的解決策の実装により、データセットが大きい場合、クエリ時間が大幅に削減されることができ、フルｇｃの頻度も削減されることができる。

【0130】

図５Ｂは、メモリ使用量とクエリ時間との間の関係の概略図である。この場合、ＳＱＬクエリ要求は、他のプログラムを実行してメモリ使用量を制御することによってテストされる。テストにおいて、メモリ使用量が特定のレベルを超えたときに、本出願の方法が使用される場合、クエリ時間が大幅に削減され得ることが示される。

【0131】

図５Ｃに示されるように、これは、ユーザ詳細データにクエリを実行する概略図である。例えば、／＊＋ｗｉｔｈＲｅｓｕｌｔＣａｃｈｅ＝ｔｒｕｅ ＊／ｓｅｌｅｃｔ ｉｄ，ｎａｍｅ，．．．ｒｅｇｉｏｎ ｆｒｏｍ ｔｅｓｔ ｗｈｅｒｅ ｉｄ＝ｘｘｘ ｌｉｍｉｔ ５０００であり、合計１００列のデータにクエリが実行され、この場合、異なる同時実行性およびクエリのタイムアウト率に従って集計が実行される。図５Ｃに見られるように、同時クエリの数が多いほど、タイムアウト率が高くなる。さらに、特定の数の同時実行性が超過されると、クエリのタイムアウト率は大幅に増加する。明らかに、本出願の方法を使用した後、クエリのタイムアウト率の増加は遅くされることができる。

【0132】

図５Ｄに示されるように、これは、比較的小さいデータセットのみにクエリを実行する同時テストの概略図であり、例えば、／＊＋ｗｉｔｈＲｅｓｕｌｔＣａｃｈｅ＝ｔｒｕｅ＊／ｓｅｌｅｃｔ ｉｄ，ｎａｍｅ ｆｒｏｍ ｔｅｓｔ ｗｈｅｒｅ ｉｄ＝ｘｘｘ ｌｉｍｉｔ ５０である。クエリの同時実行性とクエリのタイムアウト率との間の関係が図５Ｄに示される。図５Ｃと同様に、同時実行性の特定の数が超過されると、クエリのタイムアウト率が継続的に増加し始める。明らかに、本出願の方法を使用した後、クエリのタイムアウト率が突然増加する同時実行性の臨界値が、より高くされることができる。したがって、同じシナリオにおいて、ユーザの同時実行数が増加されることができる。

【0133】

図５Ｅは、混合されたシナリオ（すなわち、大きなデータセットを使用するクエリ動作と小さなデータセットを使用するクエリ動作とが存在する）の概略図であり、大きなデータセットを使用するクエリ動作の小さなデータセットを使用するクエリ動作のタイムアウト率への影響を示す。図５Ｅに見られるように、大きなデータセットを使用するクエリ動作の同時実行数が特定の臨界値を超えると、小さなデータセットを使用するクエリ動作のクエリのタイムアウト率が継続的に増加し始める。明らかに、本出願の方法を使用した後、小さなデータセットを使用するクエリ動作のクエリのタイムアウト率が向上されることができる。

【0134】

上記の方法と同じ適用概念に基づいて、本出願の例示的な実施形態は、フロントエンドサーバに適用されることができるデータクエリデバイスをさらに提供する。図６に示されるように、これはデバイスの構造図であり、デバイスは、
クライアントによって送信されたクエリ要求を受信するために使用される受信モジュール６０１と、
クエリ要求に対応するデータセットのリソース占有情報を決定するために使用される決定モジュール６０２と、
リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得するために使用される取得モジュール６０３と、
データセットを外部メモリに記憶するために使用される記憶モジュール６０４と、
外部メモリからデータセットを読み取り、データセットをクライアントに送信するために使用される送信モジュール６０５と、を含んでもよい。

【0135】

取得モジュール６０３は、具体的に、クエリ要求に対応するデータセットを取得し、クエリ要求に対応するコンテキスト情報を外部メモリに記憶し、外部メモリからコンテキスト情報を読み取り、コンテキスト情報を使用してクエリ要求に対応するデータセットを取得するプロセスにおいて使用される。

【0136】

取得モジュール６０３はまた、具体的に、外部メモリからコンテキスト情報を読み取るプロセスにおいて、外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応する優先度を決定し、コンテキスト情報に対応する優先度を使用して、外部メモリにおけるコンテキスト情報をソートし、ソート結果に従って外部メモリから最も高い優先度のコンテキスト情報を読み取るためにも、使用される。

【0137】

また、コンテキスト情報を使用してクエリ要求に対応するデータセットを取得するプロセスは、クエリ要求に対応するスケジューリング要求を生成することと、スケジューリング要求をコンピューティングサーバに送信することと、コンピューティングサーバによって返されたスケジューリング要求に対応するデータセットを受信することと、を含む。

【0138】

送信モジュール６０５は、具体的に、外部メモリからデータセットを読み取るプロセスにおいて、外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応するデータセットの優先度を決定し、データセットの優先度を使用して外部メモリにおけるデータセットをソートし、データセットのソート結果に従って外部メモリからデータセットを読み取るために使用される。

【0139】

上記の方法と同じ適用概念に基づいて、本出願の例示的な実施形態は、フロントエンドサーバも提供し、フロントエンドサーバは、受信機、プロセッサ、および送信機を含んでもよい。受信機は、クライアントによって送信されたクエリ要求を受信するために使用される。プロセッサは、クエリ要求に対応するデータセットのリソース占有情報を決定するために使用され、リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、プロセッサは、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶し、データセットを外部メモリから読み取るために使用される。送信機は、データセットをクライアントに送信するために使用される。

【0140】

上記の方法と同じ適用概念に基づいて、本出願の例示的な実施形態はまた、フロントエンドサーバに適用されることができる機械可読記憶媒体を提供する。機械可読記憶媒体は、多数のコンピュータ命令を記憶し、コンピュータ命令が実行されると、クライアントによって送信されたクエリ要求を受信し、クエリ要求に対応するデータセットのリソース占有情報を決定し、リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶し、外部メモリからデータセットを読み取り、データセットをクライアントに送信する処理が実行される。

【0141】

上記の例示的な実施形態において説明されたシステム、デバイス、モジュールまたはユニットについて、それらは、コンピュータチップまたはエンティティによって、もしくは特定の機能を備えた製品によって具体的に実装されてもよい。典型的な実装デバイスはコンピュータであり、コンピュータの具体的な形態は、パーソナルコンピュータ、ラップトップコンピュータ、携帯電話、カメラ付き携帯電話、スマートフォン、携帯情報端末、メディアプレーヤー、ナビゲーションデバイス、電子メール送受信デバイス、ゲームコンソール、タブレットコンピューター、ウェアラブルデバイス、または前述のデバイスの任意の組み合わせであってもよい。

【0142】

説明の便宜上、上記のデバイスが説明される場合、それらの機能に基づいて様々なユニットに分割され、別々に説明される。もちろん、本出願を実装するとき、各ユニットの機能は、１つ以上のソフトウェアおよび／またはハードウェアで実装されることができる。

【0143】

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

【0144】

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

【0145】

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

【0146】

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

【0147】

上記は、本出願のいくつかの例のみを含み、本出願を限定することを意図されない。当業者にとって、本出願は、様々な修正および変更を有し得る。本出願の精神および原理の範囲内で行われたあらゆる修正、同等の置換、改良などは、本願の特許請求の範囲に含まれるべきである。

【図1】

【図2A】

【図2B】

【図3】

【図4A】

【図4B】

【図4C】

【図5A】

【図5B】

【図5C】

【図5D】

【図5E】

【図6】