(57)【要約】データクエリ方法、装置、およびデバイスである。本方法は、クライアントによって送信されたクエリ要求を受信すること（３０１）と、クエリ要求に対応するデータセットのリソース占有情報を決定すること（３０２）と、リソース占有情報に従って、クエリ要求をキャッシュすることが決定された場合、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶すること（３０３）と、外部メモリからデータセットを読み取り、データセットをクライアントに送信すること（３０４）と、を含む。本方法を使用することによって、短時間内に多数のデータセットをクライアントに返すことが回避されることができ、したがって、ＣＰＵリソース、メモリリソース、およびネットワークリソースの占有を削減し、クライアントクエリのタイムアウトや不具合を回避し、使用の使用経験を向上させる。
2021511588.tif 000002
【特許請求の範囲】
【請求項１】
フロントエンドサーバに適用されるデータクエリ方法であって、前記方法は、
クライアントによって送信されたクエリ要求を受信することと、
前記クエリ要求に対応するデータセットのリソース占有情報を決定することと、
前記リソース占有情報に従って前記クエリ要求をキャッシュすることを決定することに応答して、前記クエリ要求に対応する前記データセットを取得し、前記データセットを外部メモリに記憶することと、
前記外部メモリから前記データセットを読み取って、前記データセットを前記クライアントに送信することと、を含む、方法。
【請求項２】
前記クエリ要求に対応する前記データセットの前記リソース占有情報を決定した後、前記方法は、
前記リソース占有情報に従って前記クエリ要求をキャッシュしないことを決定することに応答して、前記クエリ要求に対応する前記データセットを取得し、前記データセットを前記クライアントに送信することをさらに含む、請求項１に記載の方法。
【請求項３】
前記クエリ要求に対応する前記データセットの前記リソース占有情報を前記決定することは、
前記クエリ要求によって運ばれるデータ識別子を介してマッピングテーブルにクエリを実行して、前記データ識別子に対応する前記データセットの前記リソース占有情報を取得することを含み、前記マッピングテーブルは前記データ識別子と前記リソース占有情報との間の対応関係を記録し、
前記クエリ要求に対応する前記データセットを取得した後、前記フロントエンドサーバは、前記クエリ要求によって運ばれる前記データ識別子と前記データセットの前記リソース占有情報との間の前記対応関係を前記マッピングテーブルに記録する、請求項１に記載の方法。
【請求項４】
前記クエリ要求に対応する前記データセットの前記リソース占有情報を決定した後、前記方法は、
前記リソース占有情報と前記フロントエンドサーバの現在占有されているリソースの合計がリソース閾値以上の場合、前記クエリ要求をキャッシュすることを決定すること、または
前記リソース占有情報と前記フロントエンドサーバの現在占有されているリソースの前記合計が前記リソース閾値よりも小さい場合、前記クエリ要求をキャッシュしないことを決定することをさらに含む、請求項１または２に記載の方法。
【請求項５】
前記データセットを前記クライアントに送信した後、前記方法は、
前記クエリ要求に対応する処理時間を取得することであって、前記処理時間は、前記クエリ要求が受信されてから前記データセットが前記クライアントに送信されるまでの時間である、取得することと、
前記クエリ要求に対応する前記処理時間に従って前記リソース閾値を調整することと、をさらに含む、請求項４に記載の方法。
【請求項６】
前記クエリ要求に対応する前記処理時間に従って前記リソース閾値を前記調整することは、
前記クエリ要求に対応する前記処理時間が予め設定された第１の時間閾値よりも長い場合、前記リソース閾値の値を増加させることであって、前記増加されたリソース閾値は、前記リソース閾値の上限よりも大きくない、増加させること、または
前記クエリ要求に対応する前記処理時間が予め設定された第２の時間閾値よりも短い場合、前記リソース閾値の前記値を減少させることであって、前記減少されたリソース閾値は、前記リソース閾値の下限よりも小さくない、減少させることを含む、請求項５に記載の方法。
【請求項７】
前記リソース占有情報は、
メモリ占有率、
ＣＰＵ占有率、および
前記データセットのデータ量のうちの１つまたは任意の組み合わせを含む、請求項１または２に記載の方法。
【請求項８】
前記クエリ要求に対応する前記データセットを前記取得すること、および前記外部メモリに前記データセットを記憶することは、
前記クエリ要求に対応するコンテキスト情報を前記外部メモリに記憶することと、
前記外部メモリから前記コンテキスト情報を読み取り、前記コンテキスト情報を使用して前記クエリ要求に対応する前記データセットを取得し、前記データセットを前記外部メモリに記憶することと、を含む、請求項１に記載の方法。
【請求項９】
前記クエリ要求に対応する前記コンテキスト情報を前記外部メモリに前記記憶することは、
前記クエリ要求によって運ばれるパラメータ情報を解析し、前記パラメータ情報がパラメータテーブルに存在するかどうかを決定することであって、前記パラメータテーブルは、キャッシュ用のパラメータ情報を記録する、決定することと、
前記パラメータ情報が存在する場合、前記クエリ要求に対応する前記コンテキスト情報を前記外部メモリに記憶することと、を含む、請求項８に記載の方法。
【請求項１０】
前記方法は、
データベース作成要求を受信することであって、前記データベース作成要求は、キャッシュ用の前記パラメータ情報を運ぶ、受信すること、および前記データベース作成要求よって運ばれる前記パラメータ情報を前記パラメータテーブルに記録すること、
テーブルグループ作成要求を受信することであって、前記テーブルグループ作成要求は、キャッシュ用の前記パラメータ情報を運ぶ、受信すること、および前記テーブルグループ作成要求によって運ばれる前記パラメータ情報を前記パラメータテーブルに記録すること、ならびに／または
テーブル作成要求を受信することであって、前記テーブル作成要求は、キャッシュ用の前記パラメータ情報を運ぶ、受信すること、および前記テーブル作成要求によって運ばれる前記パラメータ情報を前記パラメータテーブルに記録することをさらに含む、請求項９に記載の方法。
【請求項１１】
前記外部メモリから前記コンテキスト情報を前記読み取ることは、
前記外部メモリにおける前記コンテキスト情報を使用して、前記コンテキスト情報に対応する優先度を決定することと、
前記コンテキスト情報に対応する前記優先度を使用することによって、前記外部メモリにおける前記コンテキスト情報をソートすることと、
ソート結果に従って前記外部メモリから最も高い優先度を有するコンテキスト情報を読み取ることと、を含む、請求項８に記載の方法。
【請求項１２】
前記コンテキスト情報は、前記クエリ要求の受信時間と、前記クエリ要求に対応する予測データ量と、を含み、
前記外部メモリにおける前記コンテキスト情報を使用して前記コンテキスト情報に対応する前記優先度を前記決定することは、
現在の時間と受信時間との間の差を使用して、前記コンテキスト情報に対応する待機時間を決定することと、
前記待機時間および前記予測データ量に従って、コンテキスト情報に対応する前記優先度を決定することと、を含む、請求項１１に記載の方法。
【請求項１３】
前記待機時間および前記予測データ量に従って、コンテキスト情報に対応する前記優先度を前記決定することは、
前記待機時間に対して正規化処理を実行して、第１のサブウェイトを取得することと、
前記予測データ量に対して正規化処理を実行して、第２のサブウェイトを取得することと、
前記第１のサブウェイトおよび前記第２のサブウェイトに従って、第１の重み値を取得することと、
前記第１の重み値に従って、前記コンテキスト情報に対応する前記優先度を取得することと、を含み、前記第１の重み値が大きいほど前記優先度は高く、前記第１の重み値が小さいほど前記優先度は低い、請求項１２に記載の方法。
【請求項１４】
前記コンテキスト情報は前記クエリ要求を含み、
前記コンテキスト情報を使用して前記クエリ要求に対応する前記データセットを前記取得することは、
前記クエリ要求に対応するスケジューリング要求を生成し、前記スケジューリング要求をコンピューティングサーバに送信することと、
前記コンピューティングサーバによって返された前記スケジューリング要求に対応する前記データセットを受信することと、を含む、請求項８に記載の方法。
【請求項１５】
前記外部メモリから前記データセットを前記読み取ることは、
前記外部メモリにおける前記コンテキスト情報を使用して、コンテキスト情報に対応するデータセットの優先度を決定することと、
前記データセットの前記優先度を使用して、前記外部メモリにおけるデータセットをソートすることと、
前記データセットのソート結果に従って、前記外部メモリから前記データセットを読み取ることと、を含む、請求項１に記載の方法。
【請求項１６】
前記コンテキスト情報は、前記クエリ要求の受信時間および前記クエリ要求に対応する前記データセットのデータ量を含み、
前記外部メモリにおける前記コンテキスト情報を使用して、前記コンテキスト情報に対応する前記データセットの前記優先度を前記決定することは、
現在の時間と前記受信時間との間の差を使用して、前記コンテキスト情報に対応する待機時間を決定することと、
前記待機時間および前記データ量に従って、前記コンテキスト情報に対応する前記データセットの優先度を決定することと、を含む、請求項１５に記載の方法。
【請求項１７】
前記待機時間および前記データ量に従って、前記コンテキスト情報に対応する前記データセットの前記優先度を前記決定することは、
前記待機時間に対して正規化処理を実行して、第３のサブウェイトを取得することと、
前記データ量に対して正規化処理を実行して、第４のサブウェイトを取得することと、
前記第３のサブウェイトおよび前記第４のサブウェイトに従って、第２の重み値を取得することと、
前記第２の重み値に従って、前記データセットの前記優先度を取得することと、を含み、前記第２の重み値が大きいほど前記優先度が高く、前記第２の重み値が小さいほど前記優先度が低い、請求項１６に記載の方法。
【請求項１８】
前記データセットの前記ソート結果に従って、前記外部メモリから前記データセットを前記読み取ることは、
優先度の高い順に前記ソートが実行される場合、前記データセットの前記ソート結果に従って前記外部メモリから上位Ｎ個のデータセットを読み取ること、または
優先度の低い順に前記ソートが実行される場合、前記データセットの前記ソート結果に従って前記外部メモリから下位Ｎ個のデータセットを読み取ることを含み、
Ｎは１以上の正の整数であり、
前記Ｎ個のデータセットに対応する前記リソース占有情報と前記フロントエンドサーバの現在占有されているリソースの合計が、リソース閾値未満である、請求項１６に記載の方法。
【請求項１９】
フロントエンドサーバに適用されるデータクエリデバイスであって、前記デバイスは、
クライアントによって送信されたクエリ要求を受信する受信モジュールと、
前記クエリ要求に対応するデータセットのリソース占有情報を決定する決定モジュールと、
前記リソース占有情報に従って、前記クエリ要求をキャッシュすることを決定することに応答して、前記クエリ要求に対応する前記データセットを取得する取得モジュールと、
前記データセットを外部メモリに記憶する記憶モジュールと、
前記外部メモリから前記データセットを読み取り、前記クライアントに前記データセットを送信する送信モジュールと、を含む、デバイス。
【請求項２０】
前記取得モジュールは、前記クエリ要求に対応する前記データセットを取得するプロセスにおいて、前記クエリ要求に対応する前記コンテキスト情報を前記外部メモリに記憶し、前記外部メモリから前記コンテキスト情報を読み取り、前記コンテキスト情報を使用して前記クエリ要求に対応する前記データセットを取得する、請求項１９に記載のデバイス。
【請求項２１】
前記取得モジュールは、
前記外部メモリから前記コンテキスト情報を読み取るプロセスにおいて、前記外部メモリにおける前記コンテキスト情報を使用して、前記コンテキスト情報に対応する優先度を決定し、前記コンテキスト情報に対応する前記優先度を使用して、前記外部メモリにおける前記コンテキスト情報をソートし、および、ソート結果に従って、前記外部メモリから最も優先度の高い前記コンテキスト情報を読み取り、ならびに、
前記コンテキスト情報を使用して前記クエリ要求に対応する前記データセットを取得するプロセスにおいて、前記クエリ要求に対応するスケジューリング要求を生成し、前記スケジューリング要求をコンピューティングサーバに送信し、前記コンピューティングサーバによって返された前記スケジューリング要求に対応する前記データセットを受信する、請求項２０に記載のデバイス。
【請求項２２】
前記送信モジュールは、前記外部メモリから前記データセットを読み取るプロセスにおいて、前記外部メモリにおける前記コンテキスト情報を使用して、前記コンテキスト情報に対応する前記データセットの前記優先度を決定し、前記データセットの前記優先度を使用して、前記外部メモリにおける前記データセットをソートし、前記データセットのソート結果に従って、前記外部メモリから前記データセットを読み取る、請求項１９に記載のデバイス。
【請求項２３】
クライアントによって送信されたクエリ要求を受信する受信機と、
前記クエリ要求に対応するデータセットのリソース占有情報を決定し、前記リソース占有情報に従って前記クエリ要求をキャッシュすることを決定することに応答して、前記クエリ要求に対応する前記データセットを取得し、前記データセットを外部メモリに記憶し、前記外部メモリから前記データセットを読み取る、プロセッサと、
前記データセットを前記クライアントに送信する送信機と、を含むフロントエンドサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２０１８年１月１９日に出願され、「データクエリ方法、装置およびデバイス」と題された中国特許出願第２０１８１００５３９７７．８号の優先権を主張し、その全体が参照により本明細書に組み込まれる。
【０００２】
本出願は、インターネット技術の分野に関し、より詳細には、データクエリ方法、装置、およびデバイスに関する。
【背景技術】
【０００３】
分析データベースは、あらゆる次元の大量のデータの分析および統計タスクを実行できるリアルタイムコンピューティングエンジンであり、高い同時実行性、低いレイテンシ（ミリ秒の応答）、リアルタイムのオンライン分析、大量のデータクエリ、および多くの他の機能をサポートする。また、分析データベースは大量のデータを記憶できる。クライアントによって送信されたクエリ要求を受信した後、クエリ要求に対応するデータにクエリを実行し、クエリが実行されたデータをクライアントに返すことができる。
【０００４】
しかしながら、特定のシナリオ（マップデータクエリ、データプロファイリングクエリなど）において、短期間内に多数のクエリ要求が受信されてもよく（すなわち、同時要求数が非常に多い）、各クエリ要求に対応するデータ量も非常に多くなる。このような場合においては、多数のクエリ要求が非常に短時間に処理される必要があり、各クエリ要求に対して大量のデータが返され、中央処理装置（ＣＰＵ）リソース、メモリリソース、ネットワーク帯域幅などに異常が発生する。このような状況は、クライアントクエリのタイムアウト、または場合によっては不具合をもたらし、これはユーザエクスペリエンスに影響する。
【発明の概要】
【０００５】
本出願は、データクエリ方法を提供し、本方法はフロントエンドサーバに適用され、本方法は、
クライアントによって送信されたクエリ要求を受信することと、
クエリ要求に対応するデータセットのリソース占有情報を決定することと、
リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶することと、
外部メモリからデータセットを読み取り、データセットをクライアントに送信することと、を含む。
【０００６】
本出願はさらに、データクエリデバイスを提供し、デバイスはフロントエンドサーバに適用され、デバイスは、
クライアントによって送信されたクエリ要求を受信するために使用される受信モジュールと、
クエリ要求に対応するデータセットのリソース占有情報を決定するために使用される決定モジュールと、
リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得するために使用される取得モジュールと、
データセットを外部メモリに記憶するために使用される記憶モジュールと、
外部メモリからデータセットを読み取り、クライアントにデータセットを送信するために使用される送信モジュールと、を含む。
【０００７】
本出願はさらに、フロントエンドサーバを提供し、フロントエンドサーバは、
クライアントによって送信されたクエリ要求を受信するために使用される受信機と、
クエリ要求に対応するデータセットのリソース占有情報を決定し、リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶し、外部メモリからデータセットを読み取るために使用されるプロセッサと、
データセットをクライアントに送信するために使用される送信機と、を含む。
【０００８】
上記で提供された技術的解決策に基づいて、本出願の例示的な実施形態では、クエリ要求が受信された後、データセットをクライアントに直接送信する代わりに、クエリ要求およびデータセットが最初に外部メモリに記憶される。このようにして、クエリ要求に対応するデータセットがローカルにキャッシュされることによって、短期間内に多数のクエリ要求を処理することを回避する。すなわち、短期間内に多数のデータセットをクライアントに返すことを回避することによって、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅の占有を削減し、クライアントクエリのタイムアウトまたは場合によっては不具合を回避し、ユーザエクスペリエンスを向上させる。
【図面の簡単な説明】
【０００９】
本出願の例示的な実施形態または従来技術の技術的解決策をより明確に説明するために、本出願の例示的な実施形態または従来技術の図面を簡単に説明する。明らかに、以下の説明の図面は、本出願のいくつかの例示的な実施形態にすぎない。当業者に対して、本出願の例示的な実施形態のこれらの図面に基づいて、他の図面も取得され得る。
【図１】本出願の例示的な実施形態におけるシステム構造の概略図である。
【図２Ａ】本出願の例示的な実施形態におけるクエリ要求処理の概略図である。
【図２Ｂ】本出願の別の例示的な実施形態におけるクエリ要求処理の概略図である。
【図３】本出願の例示的な実施形態におけるデータクエリ方法のフローチャートである。
【図４Ａ】本出願の別の例示的な実施形態におけるデータクエリ方法のフローチャートである。
【図４Ｂ】本出願の別の例示的な実施形態におけるデータクエリ方法のフローチャートである。
【図４Ｃ】本出願のさらに別の例示的な実施形態におけるデータクエリ方法のフローチャートである。
【図５Ａ】本出願の例示的な実施形態における効果の概略図である。
【図５Ｂ】本出願の別の例示的な実施形態における効果の概略図である。
【図５Ｃ】本出願の別の例示的な実施形態における効果の概略図である。
【図５Ｄ】は、本出願の別の例示的な実施形態における効果の概略図である。
【図５Ｅ】本出願のさらに別の例示的な実施形態における効果の概略図である。
【図６】本出願の例示的な実施形態におけるデータクエリデバイスの構造図である。
【発明を実施するための形態】
【００１０】
本出願で使用される用語は、特定の例示的な実施形態を説明することのみを目的としており、本出願を限定するものではない。本出願および特許請求の範囲で使用される単数形「１つの」、「前記」、および「その」は、文脈がそうでないことを明確に示さない限り、複数形を含むことも意図される。本明細書で使用される「および／または」という用語は、列挙された項目の１つ以上を含む任意の、またはすべての可能な組み合わせを指すことも理解されたい。
【００１１】
本明細書では、第１、第２、第３などの用語が本出願における様々な情報を説明するために使用され得るが、情報はこれらの用語に限定されるべきではないことを理解されたい。これらの用語は、同じ種類の情報を互いから区別するためにのみ使用される。例えば、本出願の範囲から逸脱することなく、第１の情報は、第２の情報とも呼ばれ得る。同様に、第２の情報は、文脈に応じて、第１の情報とも呼ばれ得る。また、「場合」という単語は、「とき」または「間」もしくは「決定に応答して」として解釈され得る。
【００１２】
本出願の例示的な実施形態は、クライアント、フロントエンドサーバ（フロントノードとも呼ばれる）、コンピューティングサーバ（コンピューティングノードとも呼ばれる）、および分析データベース（ＡＤＳと呼ばれる分析ＤＢなど）を実装するために使用されるシステムなどのデータベースを含むシステムに適用されることができるデータクエリ方法を提案する。もちろん、本出願において限定されない、リソーススケジューリングサーバなどの他のサーバも含まれ得る。
【００１３】
本出願の例示的な実施形態による適用シナリオの概略図である図１を参照すると、クライアント、フロントエンドサーバ、コンピューティングサーバ、およびデータベースの数は、１つ以上であり得る。図１において、３つのクライアント、１つのフロントエンドサーバ、３つのコンピューティングサーバ、および３つのデータベースが例において使用される。もちろん、クライアント、フロントエンドサーバ、コンピューティングサーバ、およびデータベースの数は他の値であり得、本出願において限定されない。
【００１４】
その中でも、分析データベースはリアルタイムの計算エンジンであり、あらゆる次元の大量のデータを使用して分析および統計タスクを実行でき、高い同時実行性、低いレイテンシ、リアルタイムのオンライン分析、大量のデータクエリ、およびその他の機能をサポートできる。
【００１５】
クライアントは、端末デバイス（ＰＣ（パーソナルコンピュータ）、ノートブックコンピュータ、モバイル端末など）上のＡＰＰ（アプリケーション）または端末デバイス上のブラウザなどのデータベースからのデータにクエリを実行するために使用される。クライアントの具体的な種類に限定はない。
【００１６】
データベースは、様々な種類のデータを記憶するために使用され、データベースに記憶されたデータをクライアントに提供できる。データベースに記憶されるデータの具体的な種類に関しては、本出願の例示的な実施形態において限定はなく、ユーザデータ、データ、地図データ、ビデオデータ、画像データ、音声データなどであり得る。
【００１７】
フロントエンドサーバは、クライアントによって送信されたクエリ要求を受信し、クエリ要求に対してＳＱＬ（構造化クエリ言語）解析を実行し、ＳＱＬ解析結果を使用してスケジューリング要求を生成し、次に、スケジューリング要求をコンピューティングサーバに送信するために使用される。スケジューリング要求は、クエリ要求に対応するデータを要求するために使用される。さらに、コンピューティングサーバによって返されたデータを受信し、次に、データをクライアントに送信する。
【００１８】
コンピューティングサーバは、フロントエンドサーバによって送信されたスケジューリング要求を受信し、スケジューリング要求を使用して、データベースからスケジューリング要求に対応するデータを読み取り、次に、データをフロントエンドサーバに送信する。
【００１９】
図２Ａに示されるように、フロントエンドサーバは多数のスレッドを開始でき、各スレッドはクエリ要求を処理するために使用される。例えば、クエリ要求１を受信した後、フロントエンドサーバはクエリ要求１に対するスレッド１を開始し、スレッド１はクエリ要求１を処理し、すなわち、スケジューリング要求をコンピューティングサーバに送信すること、およびコンピューティングサーバによってクライアントに返されたデータを送信することなどの動作を実行する。データをクライアントに送信した後、スレッド１は解放される。スレッド１が作動しているときに、フロントエンドサーバがクエリ要求２を受信した場合、クエリ要求２に対してスレッド２が開始され、スレッド２はクエリ要求２を処理する。スレッド１とスレッド２の両方が作動しているときに、フロントエンドサーバがクエリ要求３を受信した場合、クエリ要求３に対してスレッド３が開始され、したがって、スレッド３がクエリ要求３を処理し、同様に続く。
【００２０】
要約すると、フロントエンドサーバが短期間内に多数のクエリ要求を受信すると（すなわち、同時実行数が多い）、フロントエンドサーバは多数のスレッドを開始してもよく、次に、多数のスレッドが多数のクエリ要求を処理する。この場合、各クエリ要求に対応するデータ量が多い場合、各クエリ要求に対して大量のデータが返される必要があり、ＣＰＵリソース、メモリリソース、ネットワーク帯域幅などに異常をもたらし、フロントエンドサーバの処理性能における低下をもたらし、およびクライアントクエリのタイムアウト、または場合によっては不具合の問題をさらに引き起こし、これはユーザエクスペリエンスに悪影響を与える。例えば、各クエリ要求に対して大量のデータが返される必要があるとき、これらのデータは大量のメモリリソースを占有する。その結果、メモリオーバーフローまたは頻繁なメモリリサイクルなどの問題になり得、クエリのタイムアウトまたは不具合をもたらす。
【００２１】
前述の問題に対処するために、図２Ｂに示されるように、本出願の例示的な実施形態において、フロントエンドサーバは多数のクエリスレッドを開始してもよく、各クエリスレッドはクエリ要求を処理するために使用される。また、フロントエンドサーバは、外部メモリにおけるクエリ要求を順次処理するために使用されるスケジューリングスレッドを開始できる。例えば、クエリ要求１を受信した後、フロントエンドサーバはクエリ要求１に対してクエリスレッド１を開始し、クエリスレッド１はクエリ要求１を処理する。クエリスレッド１が作動しているときに、フロントエンドサーバがクエリ要求２を受信した場合、クエリ要求２に対してクエリスレッド２が開始され、したがって、クエリスレッド２はクエリ要求２を処理する。クエリスレッド１とクエリスレッド２の両方が作動しているときに、フロントエンドサーバがクエリ要求３、クエリ要求４、クエリ要求５などを受信した場合、これらのクエリ要求に対してクエリスレッドはさらに開始されないが、これらのクエリ要求は外部メモリに記憶される。
【００２２】
フロントエンドサーバは、スケジューリングスレッドを開始できる。スケジューリングスレッドは、最初に外部メモリにおけるクエリ要求３を処理する。クエリ要求３の処理が完了すると、スケジューリングスレッドは外部メモリにおけるクエリ要求４を処理する。クエリ要求４の処理が完了した後、次に、スケジューリングスレッドは外部メモリにおけるクエリ要求５を処理し、同様に続く。
【００２３】
要約すると、フロントエンドサーバが短期間内に多数のクエリ要求を受信する（すなわち、同時実行数が多い）場合、開始されるクエリスレッドの数が制御され、短期間内に多数のクエリ要求を処理することを回避できる。このようにして、本出願は、短期間内に大量のデータをクライアントに返すことを回避でき、これによって、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅の占有を削減し、処理性能を向上させ、クライアントクエリのタイムアウトまたは不具合を回避し、これによって、ユーザエクスペリエンスを向上させる。
【００２４】
上記の適用シナリオにおいて、本出願の例示的な一実施形態において提案されるデータクエリ方法のフローチャートである図３を参照すると、この方法はフロントエンドサーバに適用されることができ、本方法は以下のステップを含むことができる。
ステップ３０１は、クライアントによって送信されたクエリ要求を受信することを含み、
ステップ３０２は、クエリ要求に対応するデータセットのリソース占有情報を決定することを含み、
ステップ３０３は、リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶することを含み、
ステップ３０４は、外部メモリからデータセットを読み取り、データセットをクライアントに送信することを含む。
【００２５】
一例において、上記の実行順序は、説明の便宜のために与えられた例にすぎない。実際の適用では、ステップの実行順序も変更され得、本出願において実行順序に限定はない。さらに、他の例示的な実施形態では、対応する方法のステップは、本説明において示され、および説明される順序で必ずしも実行される必要はない。この方法は、本説明において説明されるよりも多いまたは少ないステップを含んでもよい。また、本説明において説明される個々のステップは、他の例示的な実施形態の説明において多数のステップに分割されてもよい。本説明において説明される多数のステップは、他の例示的な実施形態の説明において単一のステップに組み合わせられてもよい。
【００２６】
ステップ３０１について、一例において、クライアントがデータを要求するとき、クエリ要求が送信されてもよく、フロントエンドサーバがクライアントによって送信されたクエリ要求を受信し、次に、データベースにおいてデータを要求するためにクエリ要求が使用される。
【００２７】
ステップ３０２について、クエリ要求に対応するデータセットのリソース占有情報を決定した後、クエリ要求がリソース占有情報に従ってキャッシュされないことが決定された場合、クエリ要求に対応するデータセットが取得されることができ、次に、データセットが、データセットをキャッシュせずにクライアントに送信される。
【００２８】
ステップ３０３について、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶するプロセスは、限定されないが、クエリ要求に対応するコンテキスト情報を外部メモリに記憶し、次に、外部メモリからコンテキスト情報を読み取り、コンテキスト情報を使用してクエリ要求に対応するデータセットを取得し、次に、データセットを外部メモリに記憶することを含んでもよい。
【００２９】
ステップ３０３について、一例において、クエリ要求を受信した後、フロントエンドサーバは、クエリ要求に対応するコンテキスト情報を外部メモリに直接記憶してもよく、あるいは、フロントエンドサーバは、具体的な固有の条件が満たされた場合にのみ、クエリ要求に対応するコンテキスト情報を外部メモリに記憶してもよい。
【００３０】
クエリ要求に対応するコンテキスト情報およびデータセットを記憶するための記憶媒体（説明の便宜のため、最終的にクライアントに返されるデータはデータセットと呼ばれ、データセットは、本出願の以下の区分においてさらに詳細に説明される）は、内部メモリのリソースを占有することを回避するために、内部メモリ（またはメモリ）ではなく、外部メモリと呼ばれる。外部メモリは、内部メモリおよびＣＰＵキャッシュ以外の記憶デバイスを指す。外部メモリは、限定されないが、ハードディスク、フロッピーディスク、光ディスク、Ｕディスクなどを含んでもよい。外部メモリの種類に対しては、内部メモリと異なる限り、制限はない。
【００３１】
クエリ要求に対応するコンテキスト情報は、限定されないが、クエリ要求に対応するクエリ識別子、クエリ要求の受信時間、クエリ要求に対応するユーザ情報（クライアントのＩＰアドレスなど）、クエリ要求に対応する予測データ量、クエリ要求のうちの１つ、または任意の組み合わせを含んでもよい。クエリ要求に対応するコンテキスト情報の一例については、表１を参照されたく、本出願において限定されない。
【００３２】
【表１】
2021511588.tif 000003
【００３３】
クエリ要求は、一意であり得るクエリ識別子に対応でき、すなわち、異なるクエリ要求は異なるクエリ識別子を有する。クエリ識別子（表１に示されるクエリ識別子１０１など）を介して、フロントエンドサーバは、受信時間、ユーザ情報、予測データ量、クエリ要求などのコンテンツを取得でき、同様に続く。
【００３４】
受信時間は、フロントエンドサーバがクエリ要求を受信した時間を指し、すなわち、フロントエンドサーバがクエリ要求を受信したとき、２０１７．１１．６．１４．１６．１０などのクエリ要求の受信時間を記録してもよい。
【００３５】
ユーザ情報は、限定されないが、クライアントのＩＰアドレス（クエリ要求のソースＩＰアドレス）、ユーザ識別情報（クエリ要求から取得されることができるユーザ名、パスワードなど）を含んでもよく、本出願において、これに対する制限はない。
【００３６】
予測データ量は、クエリ要求に対応するデータセットの決定されたデータ量（すなわち、データセットのデータサイズ）を指す。例えば、クエリ要求１を受信した後、フロントエンドサーバは実際にはまだクエリ要求１に対応するデータセットを取得していないため、最初にクエリ要求１に対応するデータセットのデータ量に対して決定されることができる。本明細書におけるデータ量は予測データ量であり、決定プロセスについては後の区分において説明される。
【００３７】
クエリ要求は、フロントエンドサーバによって受信されたクエリ要求であり、クエリ要求によって運ばれるすべてのコンテンツを含む。
【００３８】
一例において、「特定の条件が満たされたときに、クエリ要求に対応するコンテキスト情報を外部メモリに記憶するフロントエンドサーバ」のプロセスは、限定されないが、以下の状況を含むことができ、
図４Ａに示されるようなケース１は、データクエリ方法の別のフローチャートである。本方法は次のステップを含む。
ステップ４１１は、クエリ要求に対応するデータセットのリソース占有情報を決定することを含む。
【００３９】
ステップ４１２は、リソース占有情報に従ってクエリ要求をキャッシュするかどうかを決定することを含む。
【００４０】
「はい」である場合、ステップ４１３が実行され、「いいえ」の場合、ステップ４１４が実行される。
【００４１】
ステップ４１３は、クエリ要求に対応するコンテキスト情報を外部メモリに記憶することを含む。
【００４２】
さらに、外部メモリからコンテキスト情報を読み取るステップが実行される。コンテキスト情報は、クエリ要求に対応するデータセットを取得するために使用され、次に、データセットは外部メモリに記憶される。
【００４３】
ステップ４１４は、クエリ要求に対応するデータセットを取得し、データセットをクライアントに送信することを含む。
【００４４】
ステップ３０２またはステップ４１１について、一例において、「クエリ要求に対応するデータセットのリソース占有情報を決定する」プロセスは、限定されないが、クエリ要求によって運ばれるデータ識別子を介してマッピングテーブルにクエリを実行し、データ識別子に対応するデータセットのリソース占有情報を取得することを含んでもよく、この場合、マッピングテーブルは、データ識別子とリソース占有情報との間の対応関係を記録するために使用される。さらに、マッピングテーブルを生成するために、クエリ要求に対応するデータセットを取得した後、フロントエンドサーバは、クエリ要求によって運ばれるデータ識別子とマッピングテーブルにおけるデータセットのリソース占有情報との間の対応関係を記録してもよい。
【００４５】
例えば、データセットＡに対するクエリ要求を初めて受信した後、フロントエンドサーバは、クエリ要求によって運ばれるデータ識別子（データセットＡに対応するデータ識別子１など）を介してマッピングテーブルにクエリを実行する。データ識別子１に対応するリソース占有情報がマッピングテーブルに存在しないため、フロントエンドサーバは、リソース占有情報がデフォルトのリソース占有情報１であることを決定する（リソース占有情報１は、経験に基づいて事前に構成され、データ識別子に対応するリソース占有情報がマッピングテーブルに存在しないとき、リソース占有情報１が決定される）。
【００４６】
さらに、フロントエンドサーバがクエリ要求に対応するデータセットを取得した後（後の区分において、クエリ要求に対応するデータセットを取得する方法について説明される）、データセットのリソース占有情報が取得されることができる。リソース占有情報がリソース占有情報Ａであるとすると、データ識別子１とリソース占有情報Ａとの間の対応関係がマッピングテーブルに記録されることができる。表２に示されるように、これはマッピングテーブルの一例である。
【００４７】
【表２】
2021511588.tif 000004
【００４８】
フロントエンドサーバがデータセットＡを再度要求するためのクエリ要求を受信した後（２回目、３回目など）、クエリ要求によって運ばれたデータ識別子１を使用してマッピングテーブルにクエリを実行することによって、データ識別子１に対応するリソース占有情報Ａが取得されることができる。すなわち、決定結果はリソース占有情報Ａである。クエリ要求に対応するデータセットを取得した後、フロントエンドサーバは、データセットのリソース占有情報を集計することができる。現在の集計結果がリソース占有情報Ａと同じである場合、リソース占有情報Ａは変更されないままにされ、現在の集計結果がリソース占有情報Ａと異なる場合、リソース占有情報Ａが現在の集計結果に置き換えられる。
【００４９】
一例において、上記のリソース占有情報は、限定されないが、メモリ占有率、ＣＰＵ占有率、データセットのデータ量（すなわち、データセットのサイズ）のうちの１つ、または任意の組み合わせを含んでもよい。
【００５０】
「データセットのリソース占有情報を集計する」プロセスは、クエリ要求に対応するデータセットが取得された後、データセットに対応するメモリ占有率が集計されることができることを含んでもよく、すなわち、５％など、データセットによってどれだけメモリが占有されているかを集計することができ、これは、このデータセットがメモリの合計の５％を占めることを意味する。クエリ要求に対応するデータセットが取得された後、データセットに対応するＣＰＵ使用率も集計されることができ、すなわち、データセットはＣＰＵの合計の５％を占有することを示す、５％など、データセットによってＣＰＵがどれほど占有されているか、などが集計されることができる。クエリ要求に対応するデータセットが取得された後、データセットに対応するデータ量が集計されることができ、すなわち、データセットのサイズが集計されることができる。
【００５１】
ステップ４１２について、一例において、「リソース占有情報に従ってクエリ要求をキャッシュするかどうかを決定する」プロセスは、限定されないが、リソース占有情報とフロントエンドサーバの現在占有されているリソースの合計がリソース閾値以上である場合、クエリ要求がキャッシュされると決定されることができ、または、リソース占有情報とフロントエンドサーバの現在占有されているリソースの合計がリソース閾値未満である場合、クエリ要求がキャッシュされないと決定されてもよいことを含んでもよい。
【００５２】
リソース占有情報がメモリ占有率、ＣＰＵ占有率、およびデータセットのデータ量を含むとすると、リソース閾値はメモリ閾値（８５％など）、ＣＰＵ閾値（９０％など）、データ閾値の量（２００Ｍなど）を含んでもよい。フロントエンドサーバは、現在のメモリ使用量（６０％など、メモリの６０％が現在使用されていることを示す）、現在のＣＰＵ使用量（６０％など、ＣＰＵの６０％が現在使用されていることを示す）、および現在の帯域幅の使用量（１００Ｍなど、１００Ｍの帯域幅が現在占有されていることを示す）を集計できる。
【００５３】
次に、メモリ占有率と現在のメモリ使用量の合計がメモリ閾値未満である、ＣＰＵ占有率と現在のＣＰＵ使用量の合計がＣＰＵ閾値未満である、および、データセットのデータ量と現在の帯域幅の使用量の合計がデータ量閾値未満である場合、クエリ要求をキャッシュしないと決定される。メモリ占有率と現在のメモリ使用量の合計がメモリ閾値以上である、ＣＰＵ占有率と現在のＣＰＵ使用量の合計がＣＰＵ閾値以上である、およびデータセットのデータ量と現在の帯域幅の使用量の合計がデータ量閾値以上である、の３つの条件のうちの１つ以上が満たされた場合、クエリ要求はキャッシュされると決定される。
【００５４】
一例において、リソース閾値（メモリ閾値、ＣＰＵ閾値、データ量閾値など）は、経験に基づいて構成された固定値であってもよく、すなわち、リソース閾値は変化しない。別の例では、リソース閾値は動的に調整されることができ、すなわち、リソース閾値の初期値が経験に従って構成された後、次に、リソース閾値が動的に調整されることができる。リソース閾値の動的調整プロセスは、特定の具体的で例示的な実施形態に関連して以下で説明される。
【００５５】
外部メモリにおけるクエリ要求について、クエリ要求のデータセットをクライアントに送信した後、リソース閾値は動的に調整されることができ、すなわち、外部メモリにおける各クエリ要求がリソース閾値の調整をトリガする。
【００５６】
例えば、クエリ要求１を受信した後、クエリ要求１をキャッシュするかどうかを決定するためにリソース閾値１が使用され、キャッシュする場合、クエリ要求１に対応するコンテキスト情報が外部メモリに記憶され、クエリ要求１に対応するデータセットをクライアントに送信した後、リソース閾値１はリソース閾値２になるように調整される。クエリ要求２を受信した後、クエリ要求２をキャッシュするかどうかを決定するためにリソース閾値２が使用され、キャッシュされない場合、クエリ要求２に対応するコンテキスト情報は外部メモリに記憶されない。クエリ要求２に対応するデータセットをクライアントに送信した後、リソース閾値２を調整する必要はない。
【００５７】
一例において、リソース閾値を動的に調整するプロセスは、クエリ要求に対応する処理時間を取得することを含んでもよく、処理時間は、クエリ要求を受信してからデータセットをクライアントに送信するまでの時間であり得る。次に、リソース閾値は、クエリ要求に対応する処理時間に従って調整されてもよい。さらに、「クエリ要求に対応する処理時間に従ってリソース閾値を調整する」プロセスは、限定されないが、クエリ要求に対応する処理時間が予め設定された第１の時間閾値より長い場合、リソース閾値の値は増加されることができ、この場合、増加したリソース閾値はリソース閾値の上限より大きくなく、クエリ要求に対応する処理時間が事前に設定された第２の時間閾値よりも短い場合、リソース閾値の値は減少されることができ、この場合、減少したリソース閾値は、リソース閾値の下限未満ではないことを含んでもよい。
【００５８】
クエリ要求の受信時間はコンテキスト情報から取得されることができ、データセットがクライアントに送信される時間は、リソース閾値が調整される現在の時間である。要約すると、フロントエンドサーバは、現在の時間と受信時間との間の差を、クエリ要求に対応する処理時間として決定してもよい。
【００５９】
上述の予め設定された第１の時間閾値と予め設定された第２の時間閾値の両方は、経験に従って構成されることができる。それらに制限はなく、事前に設定された第１の時間閾値は、事前に設定された第２の時間閾値よりも大きくなり得る。
【００６０】
リソース閾値の上限は経験に従って構成されることができ、リソース閾値の上限に制限はない。リソース閾値の下限閾値は、経験に従って構成されることができ、リソース閾値の下限閾値に制限はない。もちろん、リソース閾値の上限およびリソース閾値の下限を構成するとき、リソース閾値の上限は、リソース閾値の下限より大きくなり得る。
【００６１】
リソース閾値の値を増加させることは、現在のリソース閾値と第１のリソース調整値の合計を計算することを含んでもよく、２つの合計がリソース閾値の上限より大きくない場合、増加したリソース閾値は２つの合計になり、一方で、２つの合計がリソース閾値の上限より大きい場合、増加したリソース閾値はリソース閾値の上限である。
【００６２】
リソース閾値の値を減少させることは、現在のリソース閾値と第２のリソース調整値との間の差を計算することを含んでもよく、２つの間の差がリソース閾値の下限閾値より小さくない場合、減少されたリソース閾値は２つの間の差であり、一方で、２つの間の差がリソース閾値のより小さな閾値未満である場合、減少されたリソース閾値はリソース閾値の、より小さな閾値である。
【００６３】
第１のリソース調整値および第２のリソース調整値の両方は経験に基づいて構成されてもよく、第１のリソース調整値および第２のリソース調整値は同じであってもよく、または異なっていてもよい。
【００６４】
上記の例示的な実施形態において、クエリ要求に対応する処理時間が予め設定された第１の時間閾値より長い場合、クエリ要求がキャッシュに記憶されるとき、クエリ要求の処理時間が比較的長いことを意味する。したがって、キャッシュされる必要があるクエリ要求の数は最小限にされるべきである。これに基づいて、リソース閾値の値が増加されることができ、その結果、リソース占有情報とフロントエンドサーバの現在占有されているリソースの合計はリソース閾値未満である。その結果、クエリ要求はキャッシュされる必要がなく、クエリ要求の処理時間が長すぎるという問題を回避する。
【００６５】
上記の例示的な実施形態において、クエリ要求に対応する処理時間が予め設定された第２の時間閾値未満である場合、クエリ要求がキャッシュに記憶されるとき、クエリ要求の処理時間が短縮され得ることを意味する。したがって、キャッシュされる必要のあるクエリ要求の数が増加され得る。これに基づいて、リソース閾値の値が減少され得る。このようにして、リソース占有情報とフロントエンドサーバの現在占有されているリソースの合計は、リソース閾値以上であるべきである。その結果、クエリ要求がキャッシュされ得、フロントエンドサーバの処理リソースが節約され得る。
【００６６】
ケース２：図４Ｂを参照すると、データクエリ方法の別のフローチャートが示される。本方法は以下を含む。
ステップ４２１は、クエリ要求によって運ばれるパラメータ情報を解析することを含む。
ステップ４２２は、パラメータ情報がパラメータテーブルに存在するかどうかを決定することを含み、パラメータテーブルは、キャッシュ用のパラメータ情報を記録するために使用され、パラメータ情報が存在する場合、ステップ４２３を実行し、パラメータ情報が存在しない場合、ステップ４２４を実行する。
【００６７】
ステップ４２３は、クエリ要求に対応するコンテキスト情報を外部メモリに記憶することを含む。
【００６８】
さらに、外部メモリからコンテキスト情報を読み取ることと、コンテキスト情報を使用してクエリ要求に対応するデータセットを取得することと、データセットを外部メモリに記憶することと、を含むステップが次に実行される。
【００６９】
ステップ４２４は、クエリ要求に対応するデータセットを取得することと、データセットをクライアントに送信することと、を含む。
【００７０】
一例において、フロントエンドサーバは、パラメータ情報をパラメータテーブルにキャッシュする、および記憶するためのパラメータ情報を取得することができる。これに基づいて、クエリ要求を受信した後、クエリ要求によって運ばれたパラメータ情報が解析され、次に、パラメータ情報がパラメータテーブルに存在するかどうかが決定される。答えが「はい」の場合、クエリ要求はキャッシュされる必要があり、一方で、答えが「いいえ」の場合、クエリ要求はキャッシュされる必要がない。
【００７１】
一例において、「フロントエンドサーバからキャッシュ用のパラメータ情報を取得し、パラメータ情報をパラメータテーブルに記憶する」プロセスは、限定されないが、以下の方法を含んでもよい。
方式１：フロントエンドサーバはデータベース作成要求を受信し、データベース作成要求は、キャッシュ用のパラメータ情報を運び、データベース作成要求によって運ばれたパラメータ情報をパラメータテーブルに記録する。
【００７２】
一部のパラメータ情報がキャッシュされる必要がある場合、キャッシュ用のそれらのパラメータ情報が指定されてもよい。具体的には、パラメータ情報を含むデータベース作成要求は、キャッシュ用のパラメータ情報をフロントエンドサーバに通知するためにフロントエンドサーバに送信されてもよい。次に、フロントエンドサーバは、データベース作成要求によって運ばれたパラメータ情報をパラメータテーブルに記録する。
【００７３】
例えば、データベース作成要求は、ｃｒｅａｔｅ  ｄａｔａｂａｓｅ  ｔｅｓｔ  ｏｐｔｉｏｎｓ（ｒｅｓｏｕｒｃｅ＿ｔｙｐｅ＝’ｅｃｕ’ｅｃｕ＿ｔｙｐｅ＝’ｃ１’ｅｃｕ＿ｃｏｕｎｔ＝２  ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’）であり得、この場合、ｃｒｅａｔｅ  ｄａｔａｂａｓｅ  ｔｅｓｔ  ｏｐｔｉｏｎｓは、現在のメッセージがデータベース作成要求であることを示し、ｒｅｓｏｕｒｃｅ＿ｔｙｐｅ＝’ｅｃｕ’は、対象のデータベースのリソースモデルの種類であり、ｅｃｕ＿ｔｙｐｅ＝’ｃ１’は、対象のデータベースのリソースモデルであり、ｅｃｕ＿ｃｏｕｎｔ＝２は、対象のデータベースのリソースモデルの数量情報であり、および、ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’は、キャッシュ用のパラメータ情報である。
【００７４】
また、上記のパラメータ情報は、現在のデータベースにおけるすべてのテーブルに有効である。つまり、現在のデータベースにおけるすべてのテーブルについて、これらのテーブルに対するクエリ要求が受信され、クエリ要求が上記のキャッシュ用のパラメータ情報を運ぶ場合、クエリ要求はキャッシュされる必要があることを意味する。
【００７５】
方式２：フロントエンドサーバは、キャッシュ用のパラメータ情報を運ぶテーブルグループ作成要求を受信し、テーブルグループ作成要求によって運ばれるパラメータ情報をパラメータテーブルに記録する。
【００７６】
一部のパラメータ情報がキャッシュされる必要がある場合、データベーステーブルグループを作成するときに、キャッシュ用のパラメータ情報が指定されてもよい。具体的には、キャッシュ用のパラメータ情報をフロントエンドサーバに通知するためにパラメータ情報を運ぶテーブルグループ作成要求がフロントエンドサーバに送信されることができる。フロントエンドサーバは、テーブルグループ作成要求によって運ばれたパラメータ情報をパラメータテーブルに記録する。
【００７７】
例えば、テーブルグループ作成要求の一例は、ｃｒｅａｔｅ  ｔａｂｌｅｇｒｏｕｐ  ｔｅｓｔ  ｏｐｔｉｏｎｓ（ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’）を含んでもよく、この場合、ｃｒｅａｔｅ  ｔａｂｌｅｇｒｏｕｐ  ｔｅｓｔ  ｏｐｔｉｏｎｓは、現在のメッセージがテーブルグループ作成要求であることを示し、および、ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’は、キャッシュ用のパラメータ情報である。
【００７８】
また、上記のパラメータ情報は、現在のテーブルグループにおけるすべてのテーブルについて有効である。すなわち、現在のテーブルグループにおけるすべてのテーブルについて、これらのテーブルに対するクエリ要求が受信され、クエリ要求が上記のキャッシュ用のパラメータ情報を運ぶ場合、クエリ要求はキャッシュされる必要があることを示す。
【００７９】
方式３：フロントエンドサーバがテーブル作成要求を受信し、テーブル作成要求がキャッシュ用のパラメータ情報を運び、次に、テーブル作成要求によって運ばれるパラメータ情報がパラメータテーブルに記録される。
【００８０】
一部のパラメータ情報がキャッシュされる必要がある場合、データベーステーブルを作成するときに、キャッシュ用のパラメータ情報が指定されることができる。具体的には、パラメータ情報を運ぶテーブル作成要求はフロントエンドサーバに送信されることができ、その結果、フロントエンドサーバはキャッシュ用のパラメータ情報を通知されることができる。次に、フロントエンドサーバは、テーブル作成要求によって運ばれるパラメータ情報をパラメータテーブルに記録する。
【００８１】
例えば、テーブル作成要求の一例は、ＣＲＥＡＴＥ  ＴＡＢＬＥ  ｔｅｓｔ  （ｃｏｌ１  ｖａｒｃｈａｒ，ｃｏｌ２  ｖａｒｃｈａｒ，ＰＲＩＭＡＲＹ  ＫＥＹ（ｃｏｌ１））ＰＡＲＴＩＴＩＯＮ  ＢＹ  ＨＡＳＨ  ＫＥＹ（ｃｏｌ１）ＰＡＲＴＩＴＩＯＮ  ＮＵＭ  １０  ＳＵＢＰＡＲＴＩＴＩＯＮ  ＢＹ  ＬＩＳＴ  ＫＥＹ（ｃｏｌ２）ＴＡＢＬＥＧＲＯＵＰ  ｔｅｓｔ＿ｇｒｏｕｐ  ＯＰＴＩＯＮＳ（ＵＰＤＡＴＥＴＹＰＥ＝’ｒｅａｌｔｉｍｅ’ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’）であり得、この場合、ＣＲＥＡＴＥ  ＴＡＢＬＥ  ｔｅｓｔは、現在のメッセージがテーブル作成要求であることを示し、（ｃｏｌ１  ｖａｒｃｈａｒ、ｃｏｌ２  ｖａｒｃｈａｒ、ＰＲＩＭＡＲＹ  ＫＥＹ（ｃｏｌ１））ＰＡＲＴＩＴＩＯＮ  ＢＹ  ＨＡＳＨ  ＫＥＹ（ｃｏｌ１）ＰＡＲＴＩＴＩＯＮ  ＮＵＭ  １０  ＳＵＢＰＡＲＴＩＴＩＯＮ  ＢＹ  ＬＩＳＴ  ＫＥＹ（ｃｏｌ２）ＴＡＢＬＥＧＲＯＵＰ  ｔｅｓｔ＿ｇｒｏｕｐ  ＯＰＴＩＯＮＳはテーブルに関連し、ＵＰＤＡＴＥＴＹＰＥ＝’ｒｅａｌｔｉｍｅ’はテーブルの種類の情報であり、および、ｗｉｔｈ＿ｒｅｓｕｌｔ＿ｃａｃｈｅ＝’ｔｒｕｅ’は、キャッシュ用のパラメータ情報である。
【００８２】
上記のパラメータ情報は、現在のテーブルに対してのみ有効である。つまり、現在のテーブルに対するクエリ要求が受信され、クエリ要求がパラメータ情報を運ぶ場合、クエリ要求がキャッシュされる必要があることを示す。
【００８３】
上記の例示的な実施形態において、すべてのテーブルは、データベースにおけるデータテーブルを参照し、これは、本出願において限定されない。
【００８４】
もちろん、上記の例示的な実施形態は、「クエリ要求をキャッシュするかどうか」のいくつかの例を提供するだけであり、本出願においてそれに対する限定はない。例えば、クエリ要求がキャッシュされる必要がある場合、ヒントパラメータがクエリ要求によって運ばれることができる。例えば、クエリ要求は／＊＋ｗｉｔｈＲｅｓｕｌｔＣａｃｈｅ＝ｔｒｕｅ＊／ｓｅｌｅｃｔ  ｉｄ，ｎａｍｅ  ｆｒｏｍ  ｔｅｓｔ  ｌｉｍｉｔ  １００である。クエリ要求はヒントパラメータを運ぶため、フロントエンドサーバは、クエリ要求を受信した後、クエリ要求をキャッシュすることを決定する。別の例において、フロントエンドサーバは、グローバルスイッチ、データベーススイッチ、テーブルグループスイッチ、およびテーブルスイッチの具体的な状況を通してキャッシュを使用してもよい。具体的には、グローバルスイッチがオンである場合、すべてのクエリ要求がキャッシュされる。グローバルスイッチがオフであり、かつデータベーススイッチがオンである場合、データベースへのすべてのクエリ要求がキャッシュされる。グローバルスイッチおよびデータベーススイッチがオフであり、テーブルグループスイッチがオンである場合、テーブルグループに対するすべてのクエリ要求がキャッシュされる。グローバルスイッチ、データベーススイッチ、およびテーブルグループスイッチがオフであり、テーブルスイッチがオンである場合、テーブルに対するすべてのクエリ要求がキャッシュされる。
【００８５】
ケース３、図４Ｃに示されるように、データクエリ方法の別のフローチャートが提供される。本方法は以下を含む。
ステップ４３１は、クエリ要求によって運ばれるパラメータ情報を解析することを含む。
ステップ４３２は、パラメータ情報がパラメータテーブルに存在するかどうかを決定することを含む。
【００８６】
答えが「はい」である場合、ステップ４３３が実行され、答えが「いいえ」である場合、ステップ４３６が実行される。
【００８７】
ステップ４３３は、クエリ要求に対応するデータセットのリソース占有情報を決定することを含む。
【００８８】
ステップ４３４は、リソース占有情報に従ってクエリ要求をキャッシュするかどうかを決定することを含む。
【００８９】
答えが「はい」である場合、ステップ４３５が実行され、答えが「いいえ」である場合、ステップ４３６が実行される。
【００９０】
ステップ４３５は、クエリ要求に対応するコンテキスト情報を外部メモリに記憶することを含む。
【００９１】
ステップ４３６は、クエリ要求に対応するデータセットを取得することと、データセットをクライアントに送信することと、を含む。
【００９２】
上述のケース１、ケース２、およびケース３において、「クエリ要求に対応するデータセットを取得して、データセットをクライアントに送信する」プロセスについて、フロントエンドサーバはクエリ要求に対してＳＱＬ解析を実行でき、ＳＱＬ解析結果を使用してスケジューリング要求を生成することができ、ならびに、スケジューリング要求をコンピューティングサーバに送信することができ、この場合、スケジューリング要求は、クエリ要求に対応するデータを要求するために使用され、次に、フロントエンドサーバは、コンピューティングサーバによって返されたデータセットを受信してもよく、ならびに、データセットをクライアントに送信してもよい。
【００９３】
ステップ３０３について、一例において、「外部メモリからコンテキスト情報を読み取る」プロセスは、限定されないが、外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応する優先度を決定し、次に、コンテキスト情報に対応する優先度を使用して、外部メモリにおけるコンテキスト情報をソートし、ソート結果に従って、優先度が最も高いコンテキスト情報を外部メモリから読み取ることを含んでもよい。
【００９４】
外部メモリは、多数のコンテキスト情報を記憶してもよい。すべてのコンテキスト情報について、フロントエンドサーバは、各コンテキスト情報に対応する優先度を決定することができ、外部メモリにおけるすべてのコンテキスト情報を優先度の高い順にソートすることができ、次に、最も高い優先度を有するコンテキスト情報、すなわち、最初のコンテキスト情報を読み取ることができ、または、優先度の低い順に従って、外部メモリにおけるすべてのコンテキスト情報をソートすることができ、次に、最も高い優先度を有するコンテキスト情報、すなわち、最後のコンテキスト情報を読み取ることができる。
【００９５】
一例において、表１に示されるように、コンテキスト情報は、限定されないが、クエリ要求の受信時間およびクエリ要求に対応する予測データ量を含んでもよい。これに基づいて、「外部メモリにおけるコンテキスト情報を使用して、コンテキスト情報に対応する優先度を決定する」プロセスは、限定されないが、フロントエンドサーバが、現在の時間と受信時間との間の差を使用してコンテキスト情報に対応する待機時間を決定し、次に、待機時間および予測データ量に従って、コンテキスト情報に対応する優先度を決定する。
【００９６】
さらに、「待機時間および予測データ量に従ってコンテキスト情報に対応する優先度を決定する」プロセスは、限定されないが、待機時間に対して正規化処理を実行して、第１のサブウェイトを得ることと、予測データ量に対して正規化処理を実行して、第２のサブウェイトを取得することと、次に、第１のサブウェイトおよび第２のサブウェイトに従って第１の重み値を取得することと、次に、第１の重み値に従って、コンテキスト情報に対応する優先度を取得することと、を含んでもよく、この場合、第１の重み値が大きいほど、コンテキスト情報に対応する優先度は高くなり、第１の重み値が小さいほど、コンテキスト情報に対応する優先度は低くなる。
【００９７】
例えば、外部メモリにおけるコンテキスト情報が表３に示されるとすると、フロントエンドサーバは、クエリＩＤ１０１に対応する優先度Ａ、クエリＩＤ１０２に対応する優先度Ｂ、およびクエリＩＤ１０３に対応する優先度Ｃを決定することができる。具体的には、現在の時間が２０１７．１１．６．１４．１６．１８（すなわち、２０１７年１１月６日の１４：１６：１８）であるとすると、クエリ識別子１０１に対応する待機時間は８秒であり、クエリ識別子１０２に対応する待機時間は３秒であり、およびクエリ識別子１０３に対応する待機時間は１秒である。
【００９８】
【表３】
2021511588.tif 000005
【００９９】
次に、待機時間に対して正規化処理が実行され、すなわち、待機時間は０〜１の値に変換されることができる。変換プロセスにおいて、待機時間が長いほど、正規化された第１のサブウェイトが大きくなる。例えば、クエリ識別子に対応する待機時間は、すべてのクエリ識別子の待機時間の合計で除算される。したがって、クエリ識別子１０１に対応する第１のサブウェイトは８／１２、つまり０．６６７である。クエリ識別子１０２に対応する第１のサブウェイトは３／１２、つまり０．２５である。クエリ識別子１０３に対応する第１のサブウェイトは１／１２、つまり０．０８３である。もちろん、上記の方法は待機時間の正規化処理の一例に過ぎず、処理方法に対する制限はない。
【０１００】
予測データ量に対して正規化処理を実行してもよく、すなわち、予測データ量は０〜１の値に変換されることができる。変換プロセスにおいて、予測データ量が多いほど、正規化された第２のサブウェイトは小さくなり、具体的な計算は、例えば、すべてのクエリ識別子の予測データ量の合計から、このクエリ識別子に対応する予測データ量を引き、次に、前述の結果をすべてのクエリ識別子の予測データ量の合計で除算する。したがって、クエリ識別子１０１に対応する第２のサブウェイトは（３７．６−２５．６）／３７．６であり、つまり、０．３１９である。クエリ識別子１０２に対応する第２のサブウェイトは（３７．６−１０）／３７．６であり、つまり、０．７３４である。クエリ識別子１０３に対応する第２のサブウェイトは（３７．６−２）／３７．６であり、つまり、０．９４７である。もちろん、上記は正規化処理の一例に過ぎず、処理方法に対する制限はない。
【０１０１】
次に、第１のサブウェイトと第２のサブウェイトの積が第１の重み値として使用される。例えば、クエリ識別子１０１に対応する第１の重み値は０．６６７＊０．３１９、または０．２１３であり、クエリ識別子１０２に対応する第１の重み値は０．２５＊０．７３４、または０．１８３であり、およびクエリ識別子１０３に対応する第１の重み値は、０．０８３＊０．９４７、または０．０７９である。
【０１０２】
次に、第１の重み値に従って、クエリ識別子に対応する優先度が取得される。第１の重み値が大きいほど優先度が高くなり、第１の重み値が小さいほど優先度が低くなるという条件が満たされている限り、この問題に対する制限はない。例えば、第１の重み値０．２１３に対応する優先度は２１３（または２１）であり、第１の重み値０．１８３に対応する優先度は１８３（または１８）であり、第１の重み値０．０７９に対応する優先度は７９（または８）である。
【０１０３】
要約すると、クエリ識別子１０１に対応する優先度は、クエリ識別子１０２に対応する優先度より高くてもよく、クエリ識別子１０２に対応する優先度は、クエリ識別子１０３に対応する優先度より高くてもよい。つまり、外部メモリにおけるすべてのコンテキスト情報のソート結果は、クエリ識別子１０１に対応するコンテキスト情報、クエリ識別子１０２に対応するコンテキスト情報、およびクエリ識別子１０３に対応するコンテキスト情報である。したがって、フロントエンドサーバは、クエリ識別子１０１に対応するコンテキスト情報を外部メモリから読み取ることができる。
【０１０４】
次に、フロントエンドサーバは、クエリ識別子１０１に対応するコンテキスト情報からクエリ要求１を解析し、クエリ要求１に対応するデータセットを取得する。取得したデータセットをデータセットＡとする。次に、データセットＡは外部メモリに記憶される。データセットＡを記憶した後の一例を示す表４を参照されたい。
【０１０５】
【表４】
2021511588.tif 000006
【０１０６】
ステップ３０３について、一例において、「クエリ情報に対応するデータセットを取得するためにコンテキスト情報を使用する」プロセスは、限定されないが、フロントエンドサーバは、コンテキスト情報からクエリ要求を解析し、クエリ要求に対応するスケジューリング要求を生成し、次に、スケジューリング要求をコンピューティングサーバに送信し、次に、フロントエンドサーバは、スケジューリング要求に対応するコンピューティングサーバによって返されたデータセットを受信し、データセットは、上述のクエリ要求に対応するデータセットでもある、ステップを含んでもよい。説明の便宜のため、コンピューティングサーバによってフロントエンドサーバに返されるデータは、データセットと呼ばれ得る。
【０１０７】
上記のクエリ要求は、ＳＱＬクエリ要求であってもよい。したがって、フロントエンドサーバは、クエリ要求に対してＳＱＬ解析を実行し、および、クエリ要求がデータセット１およびデータセット２などのデータセットを要求するために使用されることを学習する。次に、フロントエンドサーバは、データセット１に対応するコンピューティングサーバを見つけるための分析を実行し、次に、データセット１を要求するために、スケジューリング要求をコンピューティングサーバに送信し、スケジューリング要求を受信した後、コンピューティングサーバはデータセット１をフロントエンドサーバに送信する。また、フロントエンドサーバは、データセット２に対応する別のコンピューティングサーバを見つけるために分析を実行し、次に、データセット２を要求するためにコンピューティングサーバにスケジューリング要求を送信し、スケジューリング要求を受信した後、コンピューティングサーバはデータセット２をフロントエンドサーバに送信する。データセット１およびデータセット２を受信した後、フロントエンドサーバは、データセット１およびデータセット２をデータセット、すなわちクエリ要求に対応するデータセットに形成することができる。
【０１０８】
ステップ３０３において、フロントエンドサーバが外部メモリからコンテキスト情報を読み取る場合、外部メモリに多数のコンテキスト情報がある場合でも、フロントエンドサーバは１回の読み取りプロセスにおいて１つのコンテキスト情報しか読み取ることができない。コンテキスト情報を使用してクエリ要求に対応するデータセットを取得し、および、データセットを外部メモリに記憶した後、別のコンテキスト情報が外部メモリから読み取られ得（読み取りプロセス、優先度を決定するステップ、ソートおよび他の動作が再び実行されるが、ここでは繰り返されない）、同様に続く。
【０１０９】
図２Ｂに示されるように、フロントエンドサーバはスケジューリングスレッドを開始でき、このスレッドは、最初に、外部メモリにおけるクエリ要求３を処理し、クエリ要求３に対応するデータセットを取得し、および、外部メモリにデータセットを記憶した後、スケジューリングスレッドは外部メモリにおけるクエリ要求４を処理し、同様に続く。
【０１１０】
ステップ３０４について、一例において、「外部メモリからデータセットを読み取る」プロセスは、限定されないが、外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応するデータセットを決定し、次に、データセットの優先度を使用して外部メモリにおけるデータセットをソートし、次に、データセットのソート結果に従って外部メモリからデータセットを読み取るステップを含んでもよい。
【０１１１】
多数のデータセットが外部メモリに記憶されてもよく、各データセットは対応するコンテキスト情報を有する。すべてのデータセットについて、フロントエンドサーバは、データセットの優先度を決定し、外部メモリにおけるすべてのデータセットを優先度の高い順にソートするために、各データセットに対応するコンテキスト情報を使用してもよく、あるいは、外部メモリにおけるすべてのデータセットを優先度の高い順にソートしてもよい。
【０１１２】
一例において、クエリ要求に対応するデータセットを取得した後、フロントエンドサーバはデータセットのデータ量（すなわち、予測データ量とは異なり得る、実際のデータ量）を集計してもよく、次に、データセットのコンテキスト情報にデータセットのデータ量を記憶する。表５に示されるように、これはコンテキスト情報の例である。
【０１１３】
【表５】
2021511588.tif 000007
【０１１４】
要約すると、コンテキスト情報は、限定されないが、クエリ要求の受信時間と、クエリ要求に対応するデータセットのデータ量と、を含んでもよい。前述に基づいて、「外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応するデータセットの優先度を決定する」プロセスは、限定されないが、フロントエンドサーバが、現在の時間と受信時間との間の差を使用して、コンテキスト情報に対応する待機時間を決定し、次に、データセットの待機時間とデータ量に従って、コンテキスト情報に対応するデータセットの優先度が決定されることを含んでもよい。
【０１１５】
さらに、「待機時間およびデータセットのデータ量に従ってコンテキスト情報に対応するデータセットの優先度を決定する」プロセスは、限定されないが、待機時間に対して正規化処理を実行して、第３のサブウェイトを取得することと、データ量に対して正規化処理を実行して、第４のサブウェイトを取得することと、第３のサブウェイトおよび第４のサブウェイトに従って第２の重み値を取得することと、第２の重み値に従ってデータセットの優先度を取得することと、を含み、この場合、第２の重み値が大きいほど優先度は高くなり、第２の重み値が小さいほど優先度は低くなる。
【０１１６】
待機時間に対する正規化処理により、待機時間は０〜１の値に変換され得る。変換プロセスにおいて、待機時間が長いほど、正規化された第３のサブウェイトが大きくなる。データ量が正規化された後、データ量は０〜１の値に変換され得る。変換プロセスにおいて、データ量が多いほど、正規化された第４のサブウェイトが小さくなる。第３のサブウェイトおよび第４のサブウェイトに基づいて第２の重み値が取得されるときに、第３のサブウェイトと第４のサブウェイトの積が第２の重み値として使用される。
【０１１７】
「待機時間およびデータセットのデータ量に従ってデータセットの優先度を決定する」プロセスは、「待機時間および予測データ量に従ってコンテキスト情報に対応する優先度を決定する」プロセスと同様であり、これらの間の違いは、ここで使用されるデータセットのデータ量が予測データ量とは異なることであり、このプロセスはここでは繰り返されない。
【０１１８】
要約すると、データセットＡの優先度がデータセットＢの優先度より高く、かつ、データセットＢの優先度がデータセットＣの優先度より高いとすると、ソート結果は、データセットＡ、データセットＢ、データセットＣとなる。
【０１１９】
一例において、「データセットのソート結果に従って外部メモリからデータセットを読み取る」プロセスは、限定されないが、優先度が高い順にソートされる場合、フロントエンドサーバは、データセットのソート結果に従って外部メモリから上位Ｎ個のデータセットを読み取ってもよく、または優先度が低い順にソートされる場合、フロントエンドサーバは、データセットのソート結果に従って外部メモリから下位Ｎ個のデータセットを読み取ってもよいことを含んでもよい。
【０１２０】
Ｎは１以上の正の整数である。また、Ｎ個のデータセットに対応するリソース占有情報とフロントエンドサーバの現在占有されているリソースの合計は、現在のリソース閾値よりも小さい。
【０１２１】
リソース占有情報がメモリ占有率、ＣＰＵ占有率、およびデータセットのデータ量を含む場合、リソース閾値は、メモリ閾値、ＣＰＵ閾値、およびデータ量閾値を含んでもよい。さらに、フロントエンドサーバは、現在のメモリ使用量、現在のＣＰＵ使用量、および現在の帯域幅の使用量も集計できる。
【０１２２】
これに基づいて、フロントエンドサーバは、メモリ占有率（ステップ４１１を参照）、ＣＰＵ使用率（ステップ４１１を参照）、および最も高い優先度を有するデータセットに対応するデータセットのデータ量（表５から取得される）を決定する。
【０１２３】
メモリ占有率と現在のメモリ使用量の合計がメモリ閾値よりも少ない一方で、ＣＰＵ使用量と現在のＣＰＵ使用量の合計がＣＰＵ閾値より少なく、かつ、データセットのデータ量と現在の帯域幅の使用量の合計がデータ量閾値より少ない場合、最も高い優先度を有するデータセットが外部メモリから読み取られる。上記の３つの条件のうちの１つ以上が満たされない場合、データセットは外部メモリから読み取られない。予め設定された時間だけ待機した後、最も高い優先度を有するデータセットが外部メモリから読み取られ得るかどうかが再度決定される。
【０１２４】
フロントエンドサーバは、外部メモリから最も高い優先度を有するデータセットを読み取った後、メモリ占有率、ＣＰＵ使用率、および２番目に高い優先度を有するデータセットに対応するデータセットのデータ量を決定する。最も高い優先度を有するデータセットに対応するメモリ占有率、２番目に高い優先度を有するデータセットに対応するメモリ占有率、および現在のメモリ使用量の合計が、メモリ閾値未満である一方で、最も高い優先度を有するデータセットに対応するＣＰＵ使用量、２番目に高い優先度を有するデータセットに対応するＣＰＵ使用量、および現在のＣＰＵ使用量の合計が、ＣＰＵ閾値未満であり、かつ最も高い優先度を有するデータに対応するデータ量、２番目に高い優先度を有するデータセットに対応するデータ量、および現在の帯域幅の使用量の合計が、データ量閾値未満である場合、２番目に高い優先度を有するデータセットが外部メモリから読み取られ、同様に続く。上記の３つの条件のうちの１つ以上が満たされない場合、２番目に高い優先度を有するデータセットは外部メモリから読み取られず、読み取りプロセスが終了する。
【０１２５】
要約すると、フロントエンドサーバは外部メモリからＮ個のデータセットを読み取ることができ、Ｎ個のデータセットに対応するリソース占有情報とフロントエンドサーバの現在占有されているリソースの合計は、リソース閾値未満である。
【０１２６】
一例において、フロントエンドサーバが外部メモリからＮ個のデータセットを読み取った後、読み取ったＮ個のデータセットをクライアントに送信する。例えば、コンテキスト情報におけるユーザ情報は、対応するクライアントにデータセットを送信するために使用され、送信プロセスはここでは繰り返されない。次に、フロントエンドサーバは、データセットに対応するコンテキスト情報を外部メモリから削除し、したがって、データセットを送信するプロセス全体を完了してもよい。
【０１２７】
ステップ３０４において、フロントエンドサーバが外部メモリからデータセットを読み取るとき、外部メモリに多数のデータセットがある場合でも、フロントエンドサーバは、単一の読み取りプロセスでＮ個のデータセットしか読み取ることができない。Ｎ個のデータセットがクライアントに送信された後、フロントエンドサーバは外部メモリから別のデータセットを再度読み取り、同様に続く。
【０１２８】
上記の技術的解決策に基づいて、本出願の例示的な実施形態において、クエリ要求を受信した後、データセットをクライアントに直接送信する代わりに、クエリ要求およびデータセットが実際に最初に外部メモリに記憶される。このようにして、クエリ要求に対応するデータセットがローカルにキャッシュされることができ、これによって、多数のクエリ要求を短時間内に処理する問題を回避し、多数のデータセットをクライアントに短時間内に返すことを回避し、これによって、ＣＰＵリソース、メモリリソース、およびネットワーク帯域幅の占有を削減し、クライアントクエリのタイムアウトまたは不具合の問題を回避し、ユーザエクスペリエンスを向上させる。さらに、上記の方法では、大量のデータを含むクエリ要求をローカルストレージにキャッシュできるが、少量のデータを含むクエリ要求はローカルストレージにキャッシュされない。このようにして、少量のデータを含むクエリ要求に影響を与えずに、少量のデータを含むデータセットがクライアントに直接送信され得、したがって、フルｇｃの頻度が可能な限り削減される。
【０１２９】
図５Ａは、テスト結果の概略図である。／＊＋ｗｉｔｈＲｅｓｕｌｔＣａｃｈｅ＝ｔｒｕｅ＊／ｓｅｌｅｃｔ  ｉｄ，ｎａｍｅ，．．．．，ｒｅｇｉｏｎ  ｆｒｏｍ  ｔｅｓｔ  ｗｈｅｒｅ  ｉｄ＝ｘｘｘ  ｌｉｍｉｔ  ｘｘｘ、ｌｉｍｉｔ  １０，ｌｉｍｉｔ  １００，ｌｉｍｉｔ  ５００，ｌｉｍｉｔ  １０００，ｌｉｍｉｔ  ２０００，ｌｉｍｉｔ  ５０００，ｌｉｍｉｔ  ８０００，ｌｉｍｉｔ１００００が、それぞれデータセットの行数を限定するために使用される、大量のデータを有するテーブルに対してクエリが実行される。この場合、データセットにおける行数が多いほど、データセットのデータ量が多くなる。図５Ａにおいて、データセットのデータ量と平均クエリ時間との間の関係が提供される。メモリ使用量をシミュレートするために、テストの前に他のプログラムが実行されてメモリ使用量を約７５％に保ち、次に、上記のクエリ動作が非同期に実行される。図５Ａに見られるように、本出願の技術的解決策の実装により、データセットが大きい場合、クエリ時間が大幅に削減されることができ、フルｇｃの頻度も削減されることができる。
【０１３０】
図５Ｂは、メモリ使用量とクエリ時間との間の関係の概略図である。この場合、ＳＱＬクエリ要求は、他のプログラムを実行してメモリ使用量を制御することによってテストされる。テストにおいて、メモリ使用量が特定のレベルを超えたときに、本出願の方法が使用される場合、クエリ時間が大幅に削減され得ることが示される。
【０１３１】
図５Ｃに示されるように、これは、ユーザ詳細データにクエリを実行する概略図である。例えば、／＊＋ｗｉｔｈＲｅｓｕｌｔＣａｃｈｅ＝ｔｒｕｅ  ＊／ｓｅｌｅｃｔ  ｉｄ，ｎａｍｅ，．．．ｒｅｇｉｏｎ  ｆｒｏｍ  ｔｅｓｔ  ｗｈｅｒｅ  ｉｄ＝ｘｘｘ  ｌｉｍｉｔ  ５０００であり、合計１００列のデータにクエリが実行され、この場合、異なる同時実行性およびクエリのタイムアウト率に従って集計が実行される。図５Ｃに見られるように、同時クエリの数が多いほど、タイムアウト率が高くなる。さらに、特定の数の同時実行性が超過されると、クエリのタイムアウト率は大幅に増加する。明らかに、本出願の方法を使用した後、クエリのタイムアウト率の増加は遅くされることができる。
【０１３２】
図５Ｄに示されるように、これは、比較的小さいデータセットのみにクエリを実行する同時テストの概略図であり、例えば、／＊＋ｗｉｔｈＲｅｓｕｌｔＣａｃｈｅ＝ｔｒｕｅ＊／ｓｅｌｅｃｔ  ｉｄ，ｎａｍｅ  ｆｒｏｍ  ｔｅｓｔ  ｗｈｅｒｅ  ｉｄ＝ｘｘｘ  ｌｉｍｉｔ  ５０である。クエリの同時実行性とクエリのタイムアウト率との間の関係が図５Ｄに示される。図５Ｃと同様に、同時実行性の特定の数が超過されると、クエリのタイムアウト率が継続的に増加し始める。明らかに、本出願の方法を使用した後、クエリのタイムアウト率が突然増加する同時実行性の臨界値が、より高くされることができる。したがって、同じシナリオにおいて、ユーザの同時実行数が増加されることができる。
【０１３３】
図５Ｅは、混合されたシナリオ（すなわち、大きなデータセットを使用するクエリ動作と小さなデータセットを使用するクエリ動作とが存在する）の概略図であり、大きなデータセットを使用するクエリ動作の小さなデータセットを使用するクエリ動作のタイムアウト率への影響を示す。図５Ｅに見られるように、大きなデータセットを使用するクエリ動作の同時実行数が特定の臨界値を超えると、小さなデータセットを使用するクエリ動作のクエリのタイムアウト率が継続的に増加し始める。明らかに、本出願の方法を使用した後、小さなデータセットを使用するクエリ動作のクエリのタイムアウト率が向上されることができる。
【０１３４】
上記の方法と同じ適用概念に基づいて、本出願の例示的な実施形態は、フロントエンドサーバに適用されることができるデータクエリデバイスをさらに提供する。図６に示されるように、これはデバイスの構造図であり、デバイスは、
クライアントによって送信されたクエリ要求を受信するために使用される受信モジュール６０１と、
クエリ要求に対応するデータセットのリソース占有情報を決定するために使用される決定モジュール６０２と、
リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得するために使用される取得モジュール６０３と、
データセットを外部メモリに記憶するために使用される記憶モジュール６０４と、
外部メモリからデータセットを読み取り、データセットをクライアントに送信するために使用される送信モジュール６０５と、を含んでもよい。
【０１３５】
取得モジュール６０３は、具体的に、クエリ要求に対応するデータセットを取得し、クエリ要求に対応するコンテキスト情報を外部メモリに記憶し、外部メモリからコンテキスト情報を読み取り、コンテキスト情報を使用してクエリ要求に対応するデータセットを取得するプロセスにおいて使用される。
【０１３６】
取得モジュール６０３はまた、具体的に、外部メモリからコンテキスト情報を読み取るプロセスにおいて、外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応する優先度を決定し、コンテキスト情報に対応する優先度を使用して、外部メモリにおけるコンテキスト情報をソートし、ソート結果に従って外部メモリから最も高い優先度のコンテキスト情報を読み取るためにも、使用される。
【０１３７】
また、コンテキスト情報を使用してクエリ要求に対応するデータセットを取得するプロセスは、クエリ要求に対応するスケジューリング要求を生成することと、スケジューリング要求をコンピューティングサーバに送信することと、コンピューティングサーバによって返されたスケジューリング要求に対応するデータセットを受信することと、を含む。
【０１３８】
送信モジュール６０５は、具体的に、外部メモリからデータセットを読み取るプロセスにおいて、外部メモリにおけるコンテキスト情報を使用してコンテキスト情報に対応するデータセットの優先度を決定し、データセットの優先度を使用して外部メモリにおけるデータセットをソートし、データセットのソート結果に従って外部メモリからデータセットを読み取るために使用される。
【０１３９】
上記の方法と同じ適用概念に基づいて、本出願の例示的な実施形態は、フロントエンドサーバも提供し、フロントエンドサーバは、受信機、プロセッサ、および送信機を含んでもよい。受信機は、クライアントによって送信されたクエリ要求を受信するために使用される。プロセッサは、クエリ要求に対応するデータセットのリソース占有情報を決定するために使用され、リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、プロセッサは、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶し、データセットを外部メモリから読み取るために使用される。送信機は、データセットをクライアントに送信するために使用される。
【０１４０】
上記の方法と同じ適用概念に基づいて、本出願の例示的な実施形態はまた、フロントエンドサーバに適用されることができる機械可読記憶媒体を提供する。機械可読記憶媒体は、多数のコンピュータ命令を記憶し、コンピュータ命令が実行されると、クライアントによって送信されたクエリ要求を受信し、クエリ要求に対応するデータセットのリソース占有情報を決定し、リソース占有情報に従ってクエリ要求をキャッシュすることを決定することに応答して、クエリ要求に対応するデータセットを取得し、データセットを外部メモリに記憶し、外部メモリからデータセットを読み取り、データセットをクライアントに送信する処理が実行される。
【０１４１】
上記の例示的な実施形態において説明されたシステム、デバイス、モジュールまたはユニットについて、それらは、コンピュータチップまたはエンティティによって、もしくは特定の機能を備えた製品によって具体的に実装されてもよい。典型的な実装デバイスはコンピュータであり、コンピュータの具体的な形態は、パーソナルコンピュータ、ラップトップコンピュータ、携帯電話、カメラ付き携帯電話、スマートフォン、携帯情報端末、メディアプレーヤー、ナビゲーションデバイス、電子メール送受信デバイス、ゲームコンソール、タブレットコンピューター、ウェアラブルデバイス、または前述のデバイスの任意の組み合わせであってもよい。
【０１４２】
説明の便宜上、上記のデバイスが説明される場合、それらの機能に基づいて様々なユニットに分割され、別々に説明される。もちろん、本出願を実装するとき、各ユニットの機能は、１つ以上のソフトウェアおよび／またはハードウェアで実装されることができる。
【０１４３】
当業者は、本出願の例示的な実施形態が、方法、システム、またはコンピュータプログラム製品として提供されてもよいことを理解するであろう。したがって、本出願は、完全にハードウェアの例示的な実施形態、完全にソフトウェアの例示的な実施形態、またはソフトウェアとハードウェアを組み合わせた例示的な実施形態の形をとってもよい。さらに、本出願の例示的な実施形態は、コンピュータ使用可能プログラムコードを含む、１つ以上のコンピュータ使用可能記憶媒体（限定されないが、ディスク記憶装置、ＣＤ−ＲＯＭ、光記憶装置などを含む）上に実装されるコンピュータプログラム製品の形をとってもよい。
【０１４４】
本出願は、本出願の例示的な実施形態による方法、デバイス（システム）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して説明される。フローチャートおよび／またはブロック図における各ステップおよび／またはブロック、ならびにフローチャートおよび／またはブロック図におけるステップおよび／またはブロックの組み合わせは、コンピュータプログラム命令によって実装されてもよいことを理解されたい。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、またはその他のプログラム可能なデータ処理デバイスのプロセッサに提供されて、コンピュータまたは他のプログラム可能なデータ処理デバイスのプロセッサによって実行される命令を使用することによって、フローチャートおよび／もしくは１つのブロックまたは多数のブロックにおける１つのステップまたは多数のステップにおいて指定された機能を実装するためのデバイスの生成を可能にす機械を生成する。
【０１４５】
さらに、これらのコンピュータプログラム命令は、コンピュータまたは他のプログラム可能なデータ処理デバイスに具体的な方式で作動するように命令することができるコンピュータ可読メモリに記憶されることもでき、コンピュータ可読メモリに記憶された命令に命令デバイスを含む製品を生成させ、ならびに命令デバイスは、フローチャートの１つのステップまたは多数のステップおよび／またはブロック図の１つのブロックまたは多数のブロック図において指定された機能を実装することができる。
【０１４６】
これらのコンピュータプログラム命令はまた、コンピュータまたは他のプログラム可能なデータ処理デバイス上にロードされ、コンピュータまたはプログラム可能なデータ処理デバイス上で一連の動作ステップを実行させて、コンピュータ実装処理を生成してもよく、その結果、コンピュータまたはプログラム可能なデータ処理装置上で実行される命令は、フローチャートの１つのステップまたは多数のステップおよび／もしくはブロック図の１つのブロックまたは多数のブロックにおいて指定された機能を実装するためのステップを提供する。
【０１４７】
上記は、本出願のいくつかの例のみを含み、本出願を限定することを意図されない。当業者にとって、本出願は、様々な修正および変更を有し得る。本出願の精神および原理の範囲内で行われたあらゆる修正、同等の置換、改良などは、本願の特許請求の範囲に含まれるべきである。
【図１】
2021511588.tif 000008
【図２Ａ】
2021511588.tif 000009
【図２Ｂ】
2021511588.tif 000010
【図３】
2021511588.tif 000011
【図４Ａ】
2021511588.tif 000012
【図４Ｂ】
2021511588.tif 000013
【図４Ｃ】
2021511588.tif 000014
【図５Ａ】
2021511588.tif 000015
【図５Ｂ】
2021511588.tif 000016
【図５Ｃ】
2021511588.tif 000017
【図５Ｄ】
2021511588.tif 000018
【図５Ｅ】
2021511588.tif 000019
【図６】
2021511588.tif 000020
【国際調査報告】
2021511588.tif 000021
2021511588.tif 000022
2021511588.tif 000023
2021511588.tif 000024