ＯＬＴＰ環境における統計アプリケーション
本発明は、統計計算のためにＳＱＬ文を呼び出す集中的な計算負荷を低減する、ＯＬＴＰ環境における統計アプリケーションの方法を提供する。当該方法は、時間要素を統計レコードに導入し、当該時間要素を使用して、以前に計算した統計レコードの時間状態を判定する。当該システムは、統計レコードに対する問い合わせを受け取ると、最初に既存の統計レコードのコピーを検索し、見つかった場合に、該統計レコードの時間状態を照合する。当該システムは、記録が存在し、かつ失効していない場合に、該統計レコードを照会者に送り、記録が存在しないか、失効していた場合にだけ、ＳＱＬ文を呼び出して統計レコードを計算する。統計レコードは、データベース内の統計表および／またはアプリケーションサーバのキャッシュ内に配置され得る。開示される戦略は、システムの攻撃耐性も増加させ得る。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００７年１１月９日出願の「ＯＬＴＰ環境における統計アプリケーションのための方法およびシステム（ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＳＴＡＴＩＳＴＩＣＡＬ ＡＰＰＬＩＣＡＴＩＯＮＳ ＩＮ ＯＬＴＰ ＥＮＶＩＲＯＮＭＥＮＴ）」と題する中国特許出願第２００７１０１８８１０４．Ｘ号の優先権を主張するものであり、この中国特許出願は、参照することによってその全体が本明細書に組み込まれる。本発明は、コンピュータネットワークアプリケーションの分野に関し、より具体的には、オンライントランザクション処理（Ｏｎｌｉｎｅ Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ：ＯＬＴＰ）環境における統計アプリケーションの方法およびシステムに関する。
【背景技術】
【０００２】
コンピュータアプリケーションは、長期間にわたって全ての分野に深く浸透している。電子商取引を処理するためのコンピュータネットワークおよび統計アプリケーションを使用することが、現代ビジネスの流れとなってきている。統計アプリケーションの一例は、実表の統計に基づく集計表である統計表を使用することである。高可用性ＯＬＴＰ環境において、実表は、通常、相当な量のデータを有し、かつ連続的に変化している。統計表内のレコードは、アプリケーションのアクセスの必要性を満たすように、特定のルールに従って更新される。統計表は、リアルタイムの情報に迅速かつ好都合にアクセスできるようにし、また、リアルタイムの監視を行うことができる。しかし、このような利益を受けるには、より厳しい基準が統計表アプリケーションに必要である。
【０００３】
ＯＬＴＰ環境において、システム実表は、特定のデータベースのメタデータを実際に記憶する、基になる表である。ユーザは、通常、特定のルールに従って、比較的多数のレコードを有する基になる表に基づいて、リアルタイムの統計を計算する。当初は、この種類の統計戦略は、アプリケーションの必要性を満たし、許容可能な機能を提供することができていた。しかしながら、ユーザの数が増加するにつれて、ウェブサイトへの訪問数が指数関数的に増加し、その結果、統計ＳＱＬ（Ｓｔｒｕｃｔｕｒａｌ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：構造的問い合わせ言語）文を実行する頻度が急速に増加した。さらに、各統計計算において走査されるレコードの平均数が増加するため、統計関数を実行するＳＱＬ文の各実行にかかる平均コストが増加し続けている。一例は、大きい電子商取引ウェブサイトにおける会員レビューの統計である。比較的に高評価の（例えば、他の会員によるレビュー評価が高い）ユーザに対して、この種類の統計は、非常に複雑になり得る。ユーザのレビュー数が高い場合、多数のユーザが、ウェブページ上に表示されるユーザのレビュー結果を同時に閲覧している時、またはレビュー結果を表示するウェブページが不当にリフレッシュされた時は、データベース性能の問題が生じ得る。その結果、ユーザによって要求されるウェブページが、長時間経過した後であっても表示されない場合があり、不十分なユーザエクスペリエンスをもたらす。別の例は、ユーザの異常なログオン行為数の監視である。不当なログオン攻撃の下では、ユーザのログオン操作を記録する実表内のレコード数が、短期間に数十万に達し得る。ユーザのログオンが正常であるかどうかをリアルタイムで判定する統計ＳＱＬは、ログオン攻撃の数が増加するにつれて、実行がますます遅くなる。アプリケーションサーバは、データベースから戻される結果をすぐに受け取らないので、データベースサーバの待ち行列がより長くなり、接続プールのための待ち行列も増加する。これは、アプリケーションサーバ内の故障をもたらす。
【０００４】
既存の技術におけるＯＬＴＰの顕著な特徴のうちの１つは、ＳＱＬ文のその頻繁な実行である。これらのＳＱＬ文のうちのいくつかは、統計関数を完了するために必要とされ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央処理装置）の占有率が高いこと、および論理および物理的読み取り数が特に高いことを特徴とする。これらの文の実行が一定の頻度に到達した場合、データベースシステムの機能性が悪化する場合があり、ユーザの要求に対するアプリケーションシステムの応答がより遅くなる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＯＬＴＰ環境では、高いページ閲覧数が避けられない場合がある。上述のように、実表に対する直接的な統計の計算は、大量のＣＰＵ時間を費やし、比較的に高い論理および物理的読み取り数を有するので、データベースサーバの作業負荷が、常に高いままになり得る。さらに、この方法の１つの非常に深刻な不利な点は、システムが、攻撃に対する弱い耐性を有し得ることである。例えば、大きい電子商取引ウェブサイトに対して、ユーザが統計ウェブページを頻繁にリフレッシュする、または不当にログオンし続ける場合、データベースシステムの性能に影響を及ぼす恐れがあり、また、ビジネスシステム全体の信頼性および一貫性が低下する恐れがある。
【０００６】
したがって、実表に対して統計を直接計算する従来の方法は、ビジネス開発の必要性を満たすことができなくなりつつあり、早急に変更することが必要となり得る。
【課題を解決するための手段】
【０００７】
本発明は、統計演算のためにＳＱＬ文を呼び出す集中的な計算負荷を低減し、かつより良好なユーザエクスペリエンスのためにビジネスシステム全体の信頼性および一貫性を向上させる、ＯＬＴＰにおける統計アプリケーションの方法を提供する。開示される統計アプリケーションのための戦略は、攻撃耐性を増加させ、かつシステム全体の信頼性も向上させ得る。
【０００８】
本発明は、時間要素を統計レコードに導入し、該時間要素を使用して、以前に計算した統計レコードの時間状態を判定する。システムは、統計レコードに対する問い合わせを受け取ると、最初に既存の統計レコードのコピーを検索し、見つかった場合に、当該統計レコードの時間状態を照合する。システムは、レコードが存在し、かつ失効していない場合に、当該統計レコードを照会者に送り、レコードが存在しないか、失効していた場合にだけ、ＳＱＬ文を呼び出して統計レコードを計算する。統計レコードは、データベース内の統計表および／またはアプリケーションサーバのキャッシュ内に配置される。
【０００９】
本発明の一態様は、ＯＬＴＰ環境における統計アプリケーションの方法である。当該方法は、統計表を含むデータベースに問い合わせて、記録の同一性を有する統計レコードが存在するかどうかを判定する。統計レコードが存在する場合に、当該方法は、統計レコードの時間要素を照合し、統計レコードが失効しているかどうかを判定する。統計レコードが失効していない場合、当該方法は、その統計レコードを照会者に送り、また、統計レコードが存在しない、または失効していた場合には、当該方法は、統計レコードを計算するように、ＳＱＬ文を呼び出す。
【００１０】
一実施形態において、データベースは、データベースサーバ内に記憶される。データベースは電子商取引システムの一部であってもよく、また、統計レコードは、電子商取引システムのユーザの統計データを含んでもよい。アプリケーションサーバは、問い合わせをデータベースに送るのに使用されてもよい。本実施形態において、当該方法は、データベースに問い合わせる前に、最初に、統計レコードがアプリケーションサーバのキャッシュ内に存在しているかどうかを判定してもよい。統計レコードがキャッシュ内に存在する場合に、当該方法は、キャッシュ内の統計レコードが失効しているかどうかを判定する。キャッシュ内の統計レコードが失効していない場合に、当該方法は、キャッシュ内の統計レコードを照会者に送る。
【００１１】
統計レコードの時間要素は、統計レコードが最後に更新または作成された時を示す、時間マーカーを有してもよい。統計レコードの時間要素は、統計レコードが最後に更新または作成された時の時間から現在の照会の時間までをカウントする閾値時間幅をさらに有してもよい。時間マーカーは、統計レコードのデータフィールド内に保存することができる。
【００１２】
統計レコードの同一性識別子は、キーワードを有してもよく、したがって、データベースの問い合わせは、キーワードに一致する問い合わせ語によって行われてもよい。この場合、統計レコードの時間要素は、統計レコードのキーワードに対応する、予め設定された時間マーカーを有してもよい。
【００１３】
一実施形態において、統計を計算するためにＳＱＬ文を呼び出すと、当該方法は、ＳＱＬ文の計算結果を統計表に挿入して、統計レコードを更新または作成する。アプリケーションサーバが使用される時、当該方法は、計算結果をアプリケーションサーバ内にキャッシュして、その中の統計レコードのコピーを作成または更新してもよい。
【００１４】
別の実施形態において、ＯＬＴＰ環境における統計アプリケーションの方法は、最初に、統計表を記憶しているキャッシュメモリを有するアプリケーションサーバに問い合わせ、失効していない要求された統計レコードのコピーが統計表内に存在するかどうかを判定する。存在する場合に、当該方法は、その統計レコードを照会者に戻し、統計レコードが存在しない、または失効していた場合には、当該方法は、統計レコードについてデータベースサーバに問い合わせる。
【００１５】
本発明の別の態様は、ＯＬＴＰ環境における統計アプリケーションのシステムである。当該システムは、データベースサーバ内にホストされるデータベースであって、それぞれがレコードの識別子および時間要素を有する複数の統計レコードを有する統計表を含む、データベースを有する。当該システムは、複数の統計レコードの中の要求された統計レコードについて、データベースに問い合わせるための問い合わせ手段と、論理手段であって、要求された統計レコードが見つかった場合に、統計レコードの時間要素を照合して、統計レコードが失効しているかどうかを判定する決定と、統計レコードが失効していない場合に、統計レコードを照会者に送る決定と、統計レコードが存在しない、または失効していた場合に、要求された統計レコードを計算するように、ＳＱＬ文を呼び出す決定と、を行うための論理手段と、を備える。当該システムは、呼び出されたＳＱＬ文を実行し、かつデータベースの統計表において要求された統計レコードを作成または更新するための計算手段を有する。一実施形態において、当該システムは、要求された統計レコードのコピーについて、アプリケーション内のキャッシュに問い合わせるための問い合わせ手段と、同様の決定を行うための論理手段と、をさらに有する。
【００１６】
本開示のさらに別の態様は、複数の命令をそこに記憶させた１つ以上のコンピュータ可読媒体であって、その命令は、１つ以上のプロセッサによって実行された時に、当該命令がプロセッサに本明細書で説明されるプロセスの動作を実行させる、１つ以上のコンピュータ可読媒体に関する。
【００１７】
既存の技術と比較して、本明細書で開示される方法およびシステムは、潜在的に複数の利点を有する。当該方法およびシステムは、実表にのみに基づくのではなく、統計表に基づいて構築される統計戦略に基づいている。この設計は、全体として、ＯＬＴＰデータベースシステムの作業負荷を低減すること、攻撃耐性を増加させること、かつシステムの信頼性を向上させることができる。
【００１８】
この要約は、詳細な説明において以下でさらに説明される概念のいくつかを選択して、簡素化された形態で紹介するために提示される。この要約は、請求される主題の主要な特徴または基本的特徴を特定することを目的としておらず、請求される主題の範囲を決定する一助として使用されるものでもない。
【図面の簡単な説明】
【００１９】
詳細な説明は、添付の図面を参照して記載される。図面において、参照番号の左端の数字は、参照番号が最初に現れる図面を識別する。異なる図面における同一の参照番号の使用は、同様または同一の項目を示す。
【図１】本開示による、ＯＬＴＰ環境における例示的な統計アプリケーションの全体的なプロセスのフローチャートである。
【図２】例示的な統計アプリケーションにおけるアプリケーションサーバプロセスのフローチャートである。
【図３】例示的な統計アプリケーションにおけるデータベースサーバプロセスのフローチャートである。
【図４】本開示による、ＯＬＴＰ環境における統計アプリケーションのシステムの概略構造図である。
【図５】本開示の方法を実施するための例示的な環境を示す図である。
【発明を実施するための形態】
【００２０】
開示される方法およびシステムの例示的な実施形態を、図面を参照して以下に詳細に説明する。この説明において、プロセスが説明される順序は、限定として見なされるものではなく、任意の数の説明されるプロセスブロックを任意の順序で組み合わせて、当該方法または代替方法を実施することができる。
【００２１】
図１は、本開示による、ＯＬＴＰ環境における例示的な統計アプリケーションの全体的なプロセスのフローチャートを示している。
【００２２】
ブロックＳ１０１において、統計レコードに対する要求が受け取られる。要求は、統計レコード内に含まれる特定の統計結果または統計データを要求するエンドユーザによって開始されてもよい。ユーザの要求は、通常、統計レコードを呼び出すように、アプリケーションサーバまたはデータベースサーバに送られる内部問い合わせに変換される。従来のＳＱＬに基づく統計アプリケーションでは、問い合わせは、ＳＱＬ文を呼び出すように、統計のための基本データ（例えば、作表された生データを含む実表）を含むデータベースサーバに直接送られ、データベースサーバによって実行されると、要求された統計結果を計算し、かつ計算された統計結果をユーザに戻す。しかしながら、図１の例示的なプロセスにおいて、問い合わせは、アプリケーションサーバに送られ、最初に処理される。以下にさらに示されるように、アプリケーションサーバは、以前に計算された統計結果のコピーをキャッシュ内に含む。
【００２３】
ブロックＳ１１０において、アプリケーションサーバは、要求を処理して、要求された統計レコードがアプリケーションサーバのキャッシュ内に存在するかどうかを判定する。統計レコード（またはそのコピー）がアプリケーションサーバ内に見つかり、かつ失効していない場合に、アプリケーションサーバは、統計レコードを照会者（エンドユーザまたは内部照会を行う別のシステム構成要素）に送る。統計レコードが、アプリケーションサーバのキャッシュ内に存在しない、または失効している場合に、アプリケーションサーバは、データベースサーバ上のデータベース内の統計表に問い合わせる。
【００２４】
本明細書に示されているように、特定の統計レコードが失効しているかどうかを示す時間状態は、統計レコードに関連する時間要素を使用して判定されてもよい。アプリケーションサーバプロセスＳ１１０において、時間マーカーが、アプリケーションサーバのキャッシュ内に設定されてもよい。
【００２５】
換言すれば、図示の実施形態は、アプリケーションサーバ内にキャッシュを設定し、統計レコードがアプリケーションサーバで利用できる場合に、統計レコードを照会者に直接戻す統計戦略を使用する。この戦略は、全ての要求に応答してデータベースサーバにおいてＳＱＬプロセスを呼び出さなければならない状態を条件付きで回避する。
【００２６】
アプリケーションサーバが、統計レコードの時間状態（有効または失効状態）を照合することができるように、本開示は、時間要素を統計レコードに導入する。以下に示されるように、一実施形態において、統計レコードの時間要素は、統計レコードが最後に更新または作成されたのがいつなのかを示す、時間マーカーを含む。統計レコードが最後に更新または作成された時の時間から現在の照会の時間までをカウントする閾値時間幅も、時間マーカーとともに、統計レコードの時間状態を判定するために使用される。
【００２７】
一実施形態において、時間フィールドは、複数の統計レコードを含む統計表の通常フィールドに追加される。通常フィールドは、統計のオブジェクトの属性または特性に基づく。例えば、統計のオブジェクトは、ユーザ名、取引履歴、活動履歴、および他の顧客による評価またはフィードバック等の、複数の属性または特性によって特徴付けられる顧客であってもよい。例示的な時間フィールドは、統計レコードが最終更新された時間のフィールドであり、本文書ではＵｐｄａｔｅｄ＿Ｔｉｍｅと称される。この追加的な時間フィールドは、統計の結果として生じるオブジェクトの最後の更新の時間を示し、また、特定の統計のオブジェクトに関連する統計レコードが有効であるか、または失効しているかどうかを判定するための時間基準である。追加的な時間フィールドを含む複数のフィールドを有する統計表の実施例を、表１に示す。
【００２８】
【００２９】
表１において、主キーは、統計のオブジェクト（または統計的オブジェクト）の識別子、すなわちＩＤであってもよく、統計のオブジェクトに関連する統計レコードの固有の同一性識別子である。主キーは、統計レコードを検索可能にするように、１つ以上のキーワードを含んでもよい。集計フィールドＡ、Ｂ、Ｃ、およびＤは、統計のオブジェクトを特徴付ける任意の属性または特性とすることができ、ここでは、単に例示の目的のための実施例として使用される。統計および実際のビジネスが必要とするオブジェクトの特徴に従って、他の集計フィールドが追加されてもよい。
【００３０】
ブロックＳ１２０において、データベースサーバは、プロセスを継続する。プロセスは、特定の状況下でだけ、例えば、要求された統計レコードが、アプリケーションサーバのキャッシュ内に見つけられなかった、または失効していることが分かった時にだけ、ブロックＳ１２０を実行するように、データベースサーバに到達する。一実施形態において、データベースサーバは、複数の統計レコードを含む統計表を記憶しているデータベースを有する。データベースサーバは、統計表内の要求された統計レコードの失効時間マーカーを事前に設定する。失効時間マーカーは、要求された統計レコードに関連付けられてもよい。例えば、失効時間マーカーは、統計レコードのキーワードに対応してもよい。データベースサーバは、統計レコードのキーワードに基づいて、統計表内の統計レコードについて問い合わせてもよい。
【００３１】
統計レコードが存在し、かつ失効していない場合に、データベースサーバは、統計レコードを照会者に送る。統計レコードの時間状態は、本明細書に説明されているように、その対応する失効時間マーカーを通して判定されてもよい。統計レコードが存在しない、または失効していた場合に、データベースサーバは、ＳＱＬ文を呼び出して、統計レコードを計算する。これは、統計データの実表を走査して、要求された統計レコードを取得することによって行うことができる。ＳＱＬ文を実行した計算結果として統計レコードを取得した後に、データベースサーバは、該計算結果を使用して、統計表内の統計レコードを挿入または更新する。統計レコードはまた、アプリケーションサーバのキャッシュ内に配置されてもよい。データベースサーバの統計表は、表１に示されているものを使用してもよい。
【００３２】
統計表は、複数の統計レコードを含んでもよく、また、各統計レコードは、それ自体の失効時間マーカーを有してもよいことに留意されたい。さらに、２つのインスタンスの統計レコードおよびその失効時間マーカーが存在し得、１つは、データベースサーバの統計表内にあり、もう１つは、アプリケーションサーバのキャッシュメモリ内にある。好ましくは、アプリケーションサーバおよびデータベースサーバ内の失効時間マーカーは、常に一定に保たれる。しかしながら、古いバージョンの統計レコードがアプリケーションサーバのキャッシュ内に保たれ、かつ新しいバージョンの同じ統計レコードがデータベースサーバの統計表内に存在する場合においても、方法およびシステムは、効率的には劣るが依然として機能する。１つの状況では、アプリケーションサーバ内の古いバージョンが失効しておらず、したがって、ユーザに戻される。したがって、ユーザは、わずかに古い統計レコードを受け取る。別の状況では、キャッシュ内の古いバージョンが失効しているので、データベースサーバによって問い合わせが処理され、その結果、新しいバージョンがユーザに戻される。これは、アプリケーションサーバのキャッシュが、適時に更新されている場合に、要求が、アプリケーションサーバレベルで成功裏に処理されており、データベースサーバには全く到達しないので、ユーザによって受け取られる統計レコードの新しさには影響を及ぼさないが、システム全体の意図する効率にはわずかに影響を及ぼし得る。
【００３３】
上述したアプリケーションサーバレベルのプロセス、およびデータベースレベルのプロセスを、以下に詳述する。
【００３４】
図２は、例示的な統計アプリケーションにおけるアプリケーションサーバプロセスのフローチャートを示している。
【００３５】
上述のように、アプリケーションサーバのプロセスは、特定の条件が満たされる場合に、データベースサーバを呼び出さずに、要求を満たす機会を提供する。この場合、統計レコードは、データベースサーバにアクセスせずに、アプリケーションサーバからユーザに直接戻され得る。
【００３６】
ブロック２１０は、アプリケーションサーバレベルでの問い合わせプロセスを表している。このブロックは、それぞれが問い合わせのステップを表す、２つのサブブロックＳ２１１およびＳ２１２を含む。
【００３７】
ブロックＳ２１１において、アプリケーションサーバは、ユーザによって要求される統計レコードが、アプリケーションサーバのキャッシュ内にあるかどうかを判定する。統計レコードがキャッシュ内に存在する場合に、プロセスは、ブロックＳ２１２へと続く。存在しない場合に、プロセスは、ブロックＳ２２０へ進む。
【００３８】
ブロックＳ２１２において、アプリケーションサーバは、要求された統計レコードが失効しているかどうかを判定する。このブロックにおける動作は、要求された統計レコードが、アプリケーションサーバのキャッシュ内に見つかった場合にだけ行われる。統計結果が失効していた場合、プロセスは、ブロックＳ２２０へと続く。データが失効していない場合、プロセスは、ブロックＳ２３０へ進む。
【００３９】
一実施形態において、図１および表１を参照して上述したように、各統計レコードは、現在の統計レコードが直前に更新された時の時間を示す項目Ｕｐｄａｔｅ＿Ｔｉｍｅを含む、時間フィールドを有する。統計アプリケーションのためのシステムは、更新時間と組み合わせて、統計レコードが、依然として有効である、すなわち失効していないと認められる、更新時間から現在の時間までをカウントする最大時間幅に対する閾値を設定することができる。この失効閾値は、データベース内の統計レコードの時間状態を判定するための、データベースサーバによって使用される失効閾値と同一である必要はない。しかしながら、好ましくは、アプリケーションサーバにおける失効閾値およびデータベースサーバにおける失効閾値は、互いに矛盾する結果をもたらすように互いに食い違うべきではない。失効閾値の設定においては、多くの柔軟性がある。例えば、同じ統計表内の全ての統計レコードに適用可能な、普遍的な表現式の閾値が使用されてもよい。しかしながら、必要に応じて、異なる統計レコード、または異なる統計レコード群は、所与の異なる失効閾値であってもよい。アプリケーションサーバにおける失効閾値は、アプリケーションサーバ自体、またはデータベースサーバによって設定されるか、またはアプリケーションサーバおよびデータベースサーバの両方を制御する独立した制御装置によって設定されてもよい。アプリケーションサーバにおける失効閾値は、固定値として設定されるか、データベースサーバまたは別個の中央制御装置との通信を通して、動的に調整されてもよい。
【００４０】
ブロックＳ２２０は、データベースサーバ段階での問い合わせプロセスを表す。このプロセスは、図３を参照して以下にさらに詳しく説明する。
【００４１】
ブロックＳ２３０において、統計レコードは、照会者に送られる。この説明において、照会者は、システムの別の構成要素、またはシステムの実際の人間ユーザのいずれかであってもよい。
【００４２】
アプリケーションサーバの上述のプロセスは、以下の擬似コードを使用して説明することができる。
【００４３】
if (アプリケーションサーバのキャシュに統計レコードが存在する) then
{
if (現在のシステム時間 - Updated_Time > 閾値) then
キャッシュ内の統計レコードは失効しているので、データベースを呼ぶ;
else
キャッシュ内の統計レコードは有効なので、ユーザに送る;
end if;
}
Else
データベースを呼ぶ;
end if;
アプリケーションサーバのキャッシュ内の統計レコードが、失効している、または当該レコードがアプリケーションサーバのキャッシュ内に存在しない場合に、データベースの統計戦略が呼び出される。
【００４４】
図３は、例示的なデータベースサーバプロセスのフローチャートを示している。プロセスＳ３２０は、図２のブロックＳ２２０の例示的な一実施形態である。図２において説明したように、プロセスは、アプリケーションサーバから送られる問い合わせによって開始される。代替として、このプロセスは、最初にアプリケーションサーバを通さずに、照会者から直接送られる問い合わせによって開始することができる。
【００４５】
ブロックＳ３２１において、データベースサーバは、データベースサーバ内のデータベースの統計表内の要求された統計レコードについて問い合わせる。問い合わせは、表１に示されているように、統計レコードの主キーフィールドに従って行われてもよい。主キーフィールドは、統計レコードのＩＤとして機能する。主キーフィールドがキーワードを有する場合、問い合わせは、キーワードに基づくものであってもよい。
【００４６】
統計レコードが統計表内に存在する場合に、プロセスは、ブロックＳ３２２へと続く。統計レコードが存在しない場合に、プロセスは、ブロックＳ３２７へ進み、ＳＱＬ計算を呼び出す。
【００４７】
ブロックＳ３２２において、データベースサーバは、統計レコードが失効しているかどうかを判定する。図２で説明されたアプリケーションサーバ内の統計レコードの時間状態を判定するために使用されるものと同様の方法を、この目的のために使用することができる。失効している場合に、プロセスは、ブロックＳ３２３へと続く。失効していない場合に、プロセスは、ブロックＳ３２５へ進む。
【００４８】
ブロックＳ３２３において、データベースサーバは、要求された統計レコードの再計算のための統計ＳＱＬ文を呼び出す。記録が存在しない場合に、統計ＳＱＬ文は、ブロックＳ３２７において、初めてその記録を計算する。
【００４９】
ブロックＳ３２４において、データベースサーバは、統計表内の統計レコードを更新する。
【００５０】
ブロックＳ３２５において、データベースサーバは、キャッシュするためにアプリケーションサーバに統計レコードを送る。
【００５１】
ブロックＳ３２１において、統計レコードがデータベーステーブル内に存在しないことを決定した後に、ブロックＳ３２７において、データベースサーバは、統計レコードの計算のために統計ＳＱＬを呼び出す。
【００５２】
ブロックＳ３２８において、データベースサーバは、統計レコードを統計表に挿入する。プロセスは、次いで、ブロックにＳ３２５に戻る。
【００５３】
上述のデータベースサーバプロセスＳ３２０の後に、プロセスは、次いで、ブロックＳ３３０へと続き、照会者に統計レコードを戻す。
【００５４】
既存の技術において、統計ＳＱＬ文を呼び出すステップは、プロセス全体の中で、システムリソースの大部分を消費する。開示される方法は、一度作成された統計レコードを一定の期間再利用することができるように、統計レコードの有効なライフサイクルを定めるよう失効時間フィールドを統計表内に設定することによって、この問題を解決する。これは、ＳＱＬルーチンの高頻度の呼び出しを回避する。開示される方法は、統計情報にアクセスする戦略的な方法を確立する。アプリケーションサーバは、データベースにアクセスせずに、多数の繰り返しアクセスがアプリケーションサーバ内で完了され得るように作成された統計情報をキャッシュし、したがって、データベースの作業負荷を低減する。データベースへのアクセスが必要な時であっても、当該方法は、ＳＱＬ計算の無条件の呼び出しを行わない。その代わりに、統計表を、もうひとつの層のバッファとして使用することができる。統計レコードが統計表内に存在しない、または統計レコードが失効していることが分かった時にだけ、要求された統計結果を計算するために実表を走査するように、統計ＳＱＬ文が呼び出される。したがって、ＳＱＬ文を実行する計算負荷が低減される。
【００５５】
換言すれば、システムは、２層のキャッシュまたはバッファを有し、一方の層は、アプリケーションサーバのキャッシュ内にあり、他方は、データベースの統計表内にある。両方の層が、要求された統計レコードを提供できなかった時にだけ、統計計算のための実表を走査するように、統計ＳＱＬ文が呼び出される。よって、統計ＳＱＬ文の実数が大幅に低減される。大部分の要求について、概して、アプリケーションサーバのキャッシュ内にヒットを見つけることができるので、データベースサーバの攻撃耐性が大幅に向上する。当該方法は、非常に高い頻度の要求に対して特に有効である。それは、この状況では、全ての要求に対して統計レコードが更新されることが必要となる可能性がほとんど無いからである。要求頻度が低い統計レコードの場合、データベースサーバのＳＱＬ文は、全ての要求に対して最も更新された統計レコードを計算することが必要となり得る可能性が高いが、そのようにしても、データベースに対して過度の負担を生じさせない。
【００５６】
会員レビューの統計表について、極端な状況を考察する。会員の評価情報が全く要求されていない場合に、統計表は、この会員の評価の統計レコードを持たないことになる。同様に、ユーザの評価情報が長期間要求されていない場合は、評価の統計レコードが失効している可能性が高い。この統計レコードは、評価情報が要求されるまで更新されない。
【００５７】
本開示は、ＯＬＴＰ環境における統計アプリケーションのシステムも提供する。当該システムは、データベースサーバ内にホストされるデータベースを有する。データベースは、それぞれが記録の同一性識別子および時間要素を有する複数の統計レコードを有する統計表を含む。当該システムは、統計レコードの中の要求された統計レコードについて、データベースに問い合わせるための問い合わせ手段と、論理手段であって、要求された統計レコードが見つかった場合に、要求された統計レコードの時間要素を照合して、統計レコードが失効しているかどうかを判定する決定と、要求された統計レコードが失効していない場合に、統計レコードを照会者に戻す決定と、要求された統計レコードが存在しない、または失効していた場合に、実表を走査して要求された統計レコードを取得するように、ＳＱＬ文を呼び出す決定と、を行うための論理手段と、も有する。
【００５８】
一実施形態において、システムは、要求された統計レコードのコピーについて、アプリケーション内のキャッシュに問い合わせるための問い合わせ手段と、論理手段であって、要求された統計レコードのコピーが、キャッシュ内に見つかった場合に、統計レコードのコピーの時間要素を照合して、統計レコードのコピーが失効しているかどうかを判定する決定と、統計レコードのコピーが失効していない場合に、統計レコードのコピーを照会者に送る決定と、を行うための論理手段と、をさらに有する。
【００５９】
上述の問い合わせ手段、論理手段、および計算手段は、当技術分野で現在利用可能である、または将来的に利用可能になり得る種々の方法で実現することができる。問い合わせ手段、論理手段、および計算手段が実現される特定の様態は、この開示の不可欠な部分ではない。
【００６０】
図４は、本開示による、ＯＬＴＰ環境における統計アプリケーションのシステムの概略構造図を示している。この開示において、「ユニット」は、特定のタスクまたは機能を実行するように設計されたツールまたは機械である、装置である。ユニットまたは装置は、特定のタスクまたは機能に関連する目的を遂行するための、ハードウェア、ソフトウェア、計画またはスキーム、あるいはそれらの組み合わせとすることができる。
【００６１】
図４に示されているように、統計アプリケーションシステム４００は、アプリケーションサーバ４１０と、データベースサーバ４２０と、を含む。アプリケーションサーバ４１０は、データベースサーバ４２０から受け取ったキャッシュされた統計レコードのコピーを記憶する、キャッシングユニット４１２を有する。ユーザの要求を受け取ると、問い合わせユニット４１６は、キャッシングユニット４１２を検索して、要求された統計レコードが、キャッシュされた統計レコードのコピーの中に存在するかどうかを判定する。論理ユニット４１４は、統計レコードが存在する場合に、統計レコードの時間要素を照合して、統計レコードが失効しているかどうかを判定する決定と、統計レコードが失効していない場合に、統計レコードを、要求を行った照会者に送る決定と、統計レコードが存在しない、または失効していた場合に、統計レコードについて、データベースサーバ４２０に問い合わせる決定と、を行う。
【００６２】
データベースサーバ４２０は、それぞれが記録の同一性識別子および時間要素を有する統計レコードを含む統計表を含む、データベース４２１をホストする。問い合わせユニット４２２は、統計表内の要求された統計レコードについて、データベース４２１に問い合わせるのに使用される。決定を行うための論理ユニット４２３は、データベースサーバプロセスに関して本明細書で説明される。
【００６３】
計算ユニット４２４は、失効していない統計レコードが見つからなかった時に、要求された統計レコードを計算するように、ＳＱＬ文を実行する。計算ユニット４２４は、データベース４２１の統計表における統計レコードの作成または更新に、さらには、アプリケーションサーバ４１０に統計結果をキャッシュするように送るためにも使用される。計算ユニット４２４は、統計表内の統計レコードに対して失効時間マーカーを設定する、および要求された統計レコードの失効時間マーカーが、記録が失効していることを示しているかどうかを判定するのにも使用される。
【００６４】
実施環境
以下、それらの実施およびアプリケーション環境を示すために、方法およびシステムの例示的な実施環境が提供される。開示される方法およびシステムは、ソフトウェアまたはハードウェアのいずれかだけを使用して実施することができるが、好ましくは、ソフトウェアおよびハードウェアの組み合わせを使用して実施すべきであることに留意されたい。開示される方法自体は、記憶媒体内に記憶されるソフトウェア製品の形態で実施することができる。ソフトウェアは、本開示の例示的な実施形態において説明される方法を実行するように、（スタンドアロンまたはネットワーク化された）コンピュータデバイスのための命令を含む。
【００６５】
より具体的には、上述の手法は、以下に図示されるように、計算ユニットを有するサーバまたはパーソナルコンピュータ（ＰＣ）等の計算デバイスを用いて実施されてもよい。
【００６６】
図５は、本開示の方法を実施するための例示的な環境を示している。図示の環境５００において、いくつかの構成要素は、クライアント側に存在し、他の構成要素は、サーバ側に存在する。しかしながら、これらの構成要素は、複数の他の場所に存在してもよい。さらに、図示の構成要素のうちの２つ以上は、単一の場所で単一の構成要素を形成するように組み合わせてもよい。
【００６７】
ＯＬＴＰ環境における統計アプリケーションのシステムは、アプリケーションサーバ５１０およびデータベースサーバ５２０を含む、サーバ側にある。アプリケーションサーバ５１０は、プロセッサ５３０と、入出力装置５３２と、コンピュータ可読媒体（例えば、メモリ）５３４と、ネットワークインターフェース（図示せず）と、を含む。データベースサーバ５２０は、プロセッサ５２４と、入出力装置５３４と、コンピュータ可読媒体（例えば、メモリ）５３６と、ネットワークインターフェース（図示せず）と、を含む。アプリケーションサーバ５１０およびデータベースサーバ５２０は、ネットワーク５９０（インターネット等）を通して、クライアント装置５４１、５４２、および５４３に接続される。クライアント装置５４１、５４２、および５４３は、ユーザがアプリケーションサーバ５１０およびデータベースサーバ５２０にアクセスするための、パーソナルコンピュータ、ＰＤＡ、および携帯電話を含む、任意の好適な装置とすることができる。
【００６８】
アプリケーションサーバ５１０のコンピュータ可読媒体５３４は、データベースサーバ５２０から受け取られるキャッシュされた統計レコードのコピーを記憶する、キャッシュメモリ５１２を含む。コンピュータ可読媒体５３４はまた、アプリケーションプログラム５３７を記憶してもよい。同様に、データベースサーバ５２０のコンピュータ可読媒体５３６は、本明細書に説明されるように、アプリケーションプログラム５３８およびデータベース５２１を記憶し、統計レコードを含む統計表を含む。
【００６９】
アプリケーションプログラム５３７は、本明細書に説明されているように、プロセッサ５３０によって実行された時に、プロセッサ５２０に、アプリケーションサーバ５１０によって実行されるプロセスの動作を実行させる命令を含む。同様に、アプリケーションプログラム５３８は、本明細書に説明されているように、プロセッサ５２４によって実行された時に、プロセッサ５２４に、データベースサーバ５２０によって実行されるプロセスの動作を実行させる命令を含む。
【００７０】
コンピュータ可読媒体は、コンピュータデータを記憶するための好適なメモリ装置のうちのいずれかであってもよいことを認識されたい。このようなメモリ装置には、ハードディスク、フラッシュメモリ装置、光データ記憶装置、およびフロッピーディスクが挙げられるが、これに限定されない。さらに、コンピュータ実行可能な命令を含むコンピュータ可読媒体は、ローカルシステム内の構成要素、または複数のリモートシステムのネットワークを通じて配信される構成要素で構成されてもよい。コンピュータ実行可能な命令のデータは、有形の物理メモリ装置内に提供されてもよく、または電子的に伝送されてもよい。
【００７１】
コンピュータ可読媒体は、コンピュータデータを保存するための好適な記憶装置のいずれかであり得ることを理解されたい。かかる記憶装置は、ハードディスク、フラッシュメモリ装置、光学データストレージ、およびフロッピーディスクを含むが、それらに限定されない。さらに、コンピュータ実行可能な指示を含むコンピュータ可読媒体は、ローカルシステムにおける構成要素、または複数のリモートシステムのネットワーク上に分散される構成要素から成り得る。コンピュータ実行可能な指示のデータは、有形の物理メモリ装置において送達されるか、または電子的に伝送され得る。
【００７２】
アプリケーションサーバ５１０およびデータベースサーバ５２０の媒体のそれぞれは、単一のサーバコンピュータ、またはサーバのクラスタであってもよいことも認識されたい。
【００７３】
本明細書で論じられる可能な利益および利点は、添付の請求項の範囲に限定または制限されるものと見なされない。
【００７４】
主題は構造的特徴および／または方法論的動作に対して具体的な言語で説明されているが、添付の請求項において定義される主題は、説明される特定の特徴または動作に必ずしも限定されない。むしろ、特定の特徴および動作は、請求項を実施する例示的な形態として開示される。
【技術分野】
【０００１】
本出願は、２００７年１１月９日出願の「ＯＬＴＰ環境における統計アプリケーションのための方法およびシステム（ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＳＴＡＴＩＳＴＩＣＡＬ ＡＰＰＬＩＣＡＴＩＯＮＳ ＩＮ ＯＬＴＰ ＥＮＶＩＲＯＮＭＥＮＴ）」と題する中国特許出願第２００７１０１８８１０４．Ｘ号の優先権を主張するものであり、この中国特許出願は、参照することによってその全体が本明細書に組み込まれる。本発明は、コンピュータネットワークアプリケーションの分野に関し、より具体的には、オンライントランザクション処理（Ｏｎｌｉｎｅ Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ：ＯＬＴＰ）環境における統計アプリケーションの方法およびシステムに関する。
【背景技術】
【０００２】
コンピュータアプリケーションは、長期間にわたって全ての分野に深く浸透している。電子商取引を処理するためのコンピュータネットワークおよび統計アプリケーションを使用することが、現代ビジネスの流れとなってきている。統計アプリケーションの一例は、実表の統計に基づく集計表である統計表を使用することである。高可用性ＯＬＴＰ環境において、実表は、通常、相当な量のデータを有し、かつ連続的に変化している。統計表内のレコードは、アプリケーションのアクセスの必要性を満たすように、特定のルールに従って更新される。統計表は、リアルタイムの情報に迅速かつ好都合にアクセスできるようにし、また、リアルタイムの監視を行うことができる。しかし、このような利益を受けるには、より厳しい基準が統計表アプリケーションに必要である。
【０００３】
ＯＬＴＰ環境において、システム実表は、特定のデータベースのメタデータを実際に記憶する、基になる表である。ユーザは、通常、特定のルールに従って、比較的多数のレコードを有する基になる表に基づいて、リアルタイムの統計を計算する。当初は、この種類の統計戦略は、アプリケーションの必要性を満たし、許容可能な機能を提供することができていた。しかしながら、ユーザの数が増加するにつれて、ウェブサイトへの訪問数が指数関数的に増加し、その結果、統計ＳＱＬ（Ｓｔｒｕｃｔｕｒａｌ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：構造的問い合わせ言語）文を実行する頻度が急速に増加した。さらに、各統計計算において走査されるレコードの平均数が増加するため、統計関数を実行するＳＱＬ文の各実行にかかる平均コストが増加し続けている。一例は、大きい電子商取引ウェブサイトにおける会員レビューの統計である。比較的に高評価の（例えば、他の会員によるレビュー評価が高い）ユーザに対して、この種類の統計は、非常に複雑になり得る。ユーザのレビュー数が高い場合、多数のユーザが、ウェブページ上に表示されるユーザのレビュー結果を同時に閲覧している時、またはレビュー結果を表示するウェブページが不当にリフレッシュされた時は、データベース性能の問題が生じ得る。その結果、ユーザによって要求されるウェブページが、長時間経過した後であっても表示されない場合があり、不十分なユーザエクスペリエンスをもたらす。別の例は、ユーザの異常なログオン行為数の監視である。不当なログオン攻撃の下では、ユーザのログオン操作を記録する実表内のレコード数が、短期間に数十万に達し得る。ユーザのログオンが正常であるかどうかをリアルタイムで判定する統計ＳＱＬは、ログオン攻撃の数が増加するにつれて、実行がますます遅くなる。アプリケーションサーバは、データベースから戻される結果をすぐに受け取らないので、データベースサーバの待ち行列がより長くなり、接続プールのための待ち行列も増加する。これは、アプリケーションサーバ内の故障をもたらす。
【０００４】
既存の技術におけるＯＬＴＰの顕著な特徴のうちの１つは、ＳＱＬ文のその頻繁な実行である。これらのＳＱＬ文のうちのいくつかは、統計関数を完了するために必要とされ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央処理装置）の占有率が高いこと、および論理および物理的読み取り数が特に高いことを特徴とする。これらの文の実行が一定の頻度に到達した場合、データベースシステムの機能性が悪化する場合があり、ユーザの要求に対するアプリケーションシステムの応答がより遅くなる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＯＬＴＰ環境では、高いページ閲覧数が避けられない場合がある。上述のように、実表に対する直接的な統計の計算は、大量のＣＰＵ時間を費やし、比較的に高い論理および物理的読み取り数を有するので、データベースサーバの作業負荷が、常に高いままになり得る。さらに、この方法の１つの非常に深刻な不利な点は、システムが、攻撃に対する弱い耐性を有し得ることである。例えば、大きい電子商取引ウェブサイトに対して、ユーザが統計ウェブページを頻繁にリフレッシュする、または不当にログオンし続ける場合、データベースシステムの性能に影響を及ぼす恐れがあり、また、ビジネスシステム全体の信頼性および一貫性が低下する恐れがある。
【０００６】
したがって、実表に対して統計を直接計算する従来の方法は、ビジネス開発の必要性を満たすことができなくなりつつあり、早急に変更することが必要となり得る。
【課題を解決するための手段】
【０００７】
本発明は、統計演算のためにＳＱＬ文を呼び出す集中的な計算負荷を低減し、かつより良好なユーザエクスペリエンスのためにビジネスシステム全体の信頼性および一貫性を向上させる、ＯＬＴＰにおける統計アプリケーションの方法を提供する。開示される統計アプリケーションのための戦略は、攻撃耐性を増加させ、かつシステム全体の信頼性も向上させ得る。
【０００８】
本発明は、時間要素を統計レコードに導入し、該時間要素を使用して、以前に計算した統計レコードの時間状態を判定する。システムは、統計レコードに対する問い合わせを受け取ると、最初に既存の統計レコードのコピーを検索し、見つかった場合に、当該統計レコードの時間状態を照合する。システムは、レコードが存在し、かつ失効していない場合に、当該統計レコードを照会者に送り、レコードが存在しないか、失効していた場合にだけ、ＳＱＬ文を呼び出して統計レコードを計算する。統計レコードは、データベース内の統計表および／またはアプリケーションサーバのキャッシュ内に配置される。
【０００９】
本発明の一態様は、ＯＬＴＰ環境における統計アプリケーションの方法である。当該方法は、統計表を含むデータベースに問い合わせて、記録の同一性を有する統計レコードが存在するかどうかを判定する。統計レコードが存在する場合に、当該方法は、統計レコードの時間要素を照合し、統計レコードが失効しているかどうかを判定する。統計レコードが失効していない場合、当該方法は、その統計レコードを照会者に送り、また、統計レコードが存在しない、または失効していた場合には、当該方法は、統計レコードを計算するように、ＳＱＬ文を呼び出す。
【００１０】
一実施形態において、データベースは、データベースサーバ内に記憶される。データベースは電子商取引システムの一部であってもよく、また、統計レコードは、電子商取引システムのユーザの統計データを含んでもよい。アプリケーションサーバは、問い合わせをデータベースに送るのに使用されてもよい。本実施形態において、当該方法は、データベースに問い合わせる前に、最初に、統計レコードがアプリケーションサーバのキャッシュ内に存在しているかどうかを判定してもよい。統計レコードがキャッシュ内に存在する場合に、当該方法は、キャッシュ内の統計レコードが失効しているかどうかを判定する。キャッシュ内の統計レコードが失効していない場合に、当該方法は、キャッシュ内の統計レコードを照会者に送る。
【００１１】
統計レコードの時間要素は、統計レコードが最後に更新または作成された時を示す、時間マーカーを有してもよい。統計レコードの時間要素は、統計レコードが最後に更新または作成された時の時間から現在の照会の時間までをカウントする閾値時間幅をさらに有してもよい。時間マーカーは、統計レコードのデータフィールド内に保存することができる。
【００１２】
統計レコードの同一性識別子は、キーワードを有してもよく、したがって、データベースの問い合わせは、キーワードに一致する問い合わせ語によって行われてもよい。この場合、統計レコードの時間要素は、統計レコードのキーワードに対応する、予め設定された時間マーカーを有してもよい。
【００１３】
一実施形態において、統計を計算するためにＳＱＬ文を呼び出すと、当該方法は、ＳＱＬ文の計算結果を統計表に挿入して、統計レコードを更新または作成する。アプリケーションサーバが使用される時、当該方法は、計算結果をアプリケーションサーバ内にキャッシュして、その中の統計レコードのコピーを作成または更新してもよい。
【００１４】
別の実施形態において、ＯＬＴＰ環境における統計アプリケーションの方法は、最初に、統計表を記憶しているキャッシュメモリを有するアプリケーションサーバに問い合わせ、失効していない要求された統計レコードのコピーが統計表内に存在するかどうかを判定する。存在する場合に、当該方法は、その統計レコードを照会者に戻し、統計レコードが存在しない、または失効していた場合には、当該方法は、統計レコードについてデータベースサーバに問い合わせる。
【００１５】
本発明の別の態様は、ＯＬＴＰ環境における統計アプリケーションのシステムである。当該システムは、データベースサーバ内にホストされるデータベースであって、それぞれがレコードの識別子および時間要素を有する複数の統計レコードを有する統計表を含む、データベースを有する。当該システムは、複数の統計レコードの中の要求された統計レコードについて、データベースに問い合わせるための問い合わせ手段と、論理手段であって、要求された統計レコードが見つかった場合に、統計レコードの時間要素を照合して、統計レコードが失効しているかどうかを判定する決定と、統計レコードが失効していない場合に、統計レコードを照会者に送る決定と、統計レコードが存在しない、または失効していた場合に、要求された統計レコードを計算するように、ＳＱＬ文を呼び出す決定と、を行うための論理手段と、を備える。当該システムは、呼び出されたＳＱＬ文を実行し、かつデータベースの統計表において要求された統計レコードを作成または更新するための計算手段を有する。一実施形態において、当該システムは、要求された統計レコードのコピーについて、アプリケーション内のキャッシュに問い合わせるための問い合わせ手段と、同様の決定を行うための論理手段と、をさらに有する。
【００１６】
本開示のさらに別の態様は、複数の命令をそこに記憶させた１つ以上のコンピュータ可読媒体であって、その命令は、１つ以上のプロセッサによって実行された時に、当該命令がプロセッサに本明細書で説明されるプロセスの動作を実行させる、１つ以上のコンピュータ可読媒体に関する。
【００１７】
既存の技術と比較して、本明細書で開示される方法およびシステムは、潜在的に複数の利点を有する。当該方法およびシステムは、実表にのみに基づくのではなく、統計表に基づいて構築される統計戦略に基づいている。この設計は、全体として、ＯＬＴＰデータベースシステムの作業負荷を低減すること、攻撃耐性を増加させること、かつシステムの信頼性を向上させることができる。
【００１８】
この要約は、詳細な説明において以下でさらに説明される概念のいくつかを選択して、簡素化された形態で紹介するために提示される。この要約は、請求される主題の主要な特徴または基本的特徴を特定することを目的としておらず、請求される主題の範囲を決定する一助として使用されるものでもない。
【図面の簡単な説明】
【００１９】
詳細な説明は、添付の図面を参照して記載される。図面において、参照番号の左端の数字は、参照番号が最初に現れる図面を識別する。異なる図面における同一の参照番号の使用は、同様または同一の項目を示す。
【図１】本開示による、ＯＬＴＰ環境における例示的な統計アプリケーションの全体的なプロセスのフローチャートである。
【図２】例示的な統計アプリケーションにおけるアプリケーションサーバプロセスのフローチャートである。
【図３】例示的な統計アプリケーションにおけるデータベースサーバプロセスのフローチャートである。
【図４】本開示による、ＯＬＴＰ環境における統計アプリケーションのシステムの概略構造図である。
【図５】本開示の方法を実施するための例示的な環境を示す図である。
【発明を実施するための形態】
【００２０】
開示される方法およびシステムの例示的な実施形態を、図面を参照して以下に詳細に説明する。この説明において、プロセスが説明される順序は、限定として見なされるものではなく、任意の数の説明されるプロセスブロックを任意の順序で組み合わせて、当該方法または代替方法を実施することができる。
【００２１】
図１は、本開示による、ＯＬＴＰ環境における例示的な統計アプリケーションの全体的なプロセスのフローチャートを示している。
【００２２】
ブロックＳ１０１において、統計レコードに対する要求が受け取られる。要求は、統計レコード内に含まれる特定の統計結果または統計データを要求するエンドユーザによって開始されてもよい。ユーザの要求は、通常、統計レコードを呼び出すように、アプリケーションサーバまたはデータベースサーバに送られる内部問い合わせに変換される。従来のＳＱＬに基づく統計アプリケーションでは、問い合わせは、ＳＱＬ文を呼び出すように、統計のための基本データ（例えば、作表された生データを含む実表）を含むデータベースサーバに直接送られ、データベースサーバによって実行されると、要求された統計結果を計算し、かつ計算された統計結果をユーザに戻す。しかしながら、図１の例示的なプロセスにおいて、問い合わせは、アプリケーションサーバに送られ、最初に処理される。以下にさらに示されるように、アプリケーションサーバは、以前に計算された統計結果のコピーをキャッシュ内に含む。
【００２３】
ブロックＳ１１０において、アプリケーションサーバは、要求を処理して、要求された統計レコードがアプリケーションサーバのキャッシュ内に存在するかどうかを判定する。統計レコード（またはそのコピー）がアプリケーションサーバ内に見つかり、かつ失効していない場合に、アプリケーションサーバは、統計レコードを照会者（エンドユーザまたは内部照会を行う別のシステム構成要素）に送る。統計レコードが、アプリケーションサーバのキャッシュ内に存在しない、または失効している場合に、アプリケーションサーバは、データベースサーバ上のデータベース内の統計表に問い合わせる。
【００２４】
本明細書に示されているように、特定の統計レコードが失効しているかどうかを示す時間状態は、統計レコードに関連する時間要素を使用して判定されてもよい。アプリケーションサーバプロセスＳ１１０において、時間マーカーが、アプリケーションサーバのキャッシュ内に設定されてもよい。
【００２５】
換言すれば、図示の実施形態は、アプリケーションサーバ内にキャッシュを設定し、統計レコードがアプリケーションサーバで利用できる場合に、統計レコードを照会者に直接戻す統計戦略を使用する。この戦略は、全ての要求に応答してデータベースサーバにおいてＳＱＬプロセスを呼び出さなければならない状態を条件付きで回避する。
【００２６】
アプリケーションサーバが、統計レコードの時間状態（有効または失効状態）を照合することができるように、本開示は、時間要素を統計レコードに導入する。以下に示されるように、一実施形態において、統計レコードの時間要素は、統計レコードが最後に更新または作成されたのがいつなのかを示す、時間マーカーを含む。統計レコードが最後に更新または作成された時の時間から現在の照会の時間までをカウントする閾値時間幅も、時間マーカーとともに、統計レコードの時間状態を判定するために使用される。
【００２７】
一実施形態において、時間フィールドは、複数の統計レコードを含む統計表の通常フィールドに追加される。通常フィールドは、統計のオブジェクトの属性または特性に基づく。例えば、統計のオブジェクトは、ユーザ名、取引履歴、活動履歴、および他の顧客による評価またはフィードバック等の、複数の属性または特性によって特徴付けられる顧客であってもよい。例示的な時間フィールドは、統計レコードが最終更新された時間のフィールドであり、本文書ではＵｐｄａｔｅｄ＿Ｔｉｍｅと称される。この追加的な時間フィールドは、統計の結果として生じるオブジェクトの最後の更新の時間を示し、また、特定の統計のオブジェクトに関連する統計レコードが有効であるか、または失効しているかどうかを判定するための時間基準である。追加的な時間フィールドを含む複数のフィールドを有する統計表の実施例を、表１に示す。
【００２８】
【００２９】
表１において、主キーは、統計のオブジェクト（または統計的オブジェクト）の識別子、すなわちＩＤであってもよく、統計のオブジェクトに関連する統計レコードの固有の同一性識別子である。主キーは、統計レコードを検索可能にするように、１つ以上のキーワードを含んでもよい。集計フィールドＡ、Ｂ、Ｃ、およびＤは、統計のオブジェクトを特徴付ける任意の属性または特性とすることができ、ここでは、単に例示の目的のための実施例として使用される。統計および実際のビジネスが必要とするオブジェクトの特徴に従って、他の集計フィールドが追加されてもよい。
【００３０】
ブロックＳ１２０において、データベースサーバは、プロセスを継続する。プロセスは、特定の状況下でだけ、例えば、要求された統計レコードが、アプリケーションサーバのキャッシュ内に見つけられなかった、または失効していることが分かった時にだけ、ブロックＳ１２０を実行するように、データベースサーバに到達する。一実施形態において、データベースサーバは、複数の統計レコードを含む統計表を記憶しているデータベースを有する。データベースサーバは、統計表内の要求された統計レコードの失効時間マーカーを事前に設定する。失効時間マーカーは、要求された統計レコードに関連付けられてもよい。例えば、失効時間マーカーは、統計レコードのキーワードに対応してもよい。データベースサーバは、統計レコードのキーワードに基づいて、統計表内の統計レコードについて問い合わせてもよい。
【００３１】
統計レコードが存在し、かつ失効していない場合に、データベースサーバは、統計レコードを照会者に送る。統計レコードの時間状態は、本明細書に説明されているように、その対応する失効時間マーカーを通して判定されてもよい。統計レコードが存在しない、または失効していた場合に、データベースサーバは、ＳＱＬ文を呼び出して、統計レコードを計算する。これは、統計データの実表を走査して、要求された統計レコードを取得することによって行うことができる。ＳＱＬ文を実行した計算結果として統計レコードを取得した後に、データベースサーバは、該計算結果を使用して、統計表内の統計レコードを挿入または更新する。統計レコードはまた、アプリケーションサーバのキャッシュ内に配置されてもよい。データベースサーバの統計表は、表１に示されているものを使用してもよい。
【００３２】
統計表は、複数の統計レコードを含んでもよく、また、各統計レコードは、それ自体の失効時間マーカーを有してもよいことに留意されたい。さらに、２つのインスタンスの統計レコードおよびその失効時間マーカーが存在し得、１つは、データベースサーバの統計表内にあり、もう１つは、アプリケーションサーバのキャッシュメモリ内にある。好ましくは、アプリケーションサーバおよびデータベースサーバ内の失効時間マーカーは、常に一定に保たれる。しかしながら、古いバージョンの統計レコードがアプリケーションサーバのキャッシュ内に保たれ、かつ新しいバージョンの同じ統計レコードがデータベースサーバの統計表内に存在する場合においても、方法およびシステムは、効率的には劣るが依然として機能する。１つの状況では、アプリケーションサーバ内の古いバージョンが失効しておらず、したがって、ユーザに戻される。したがって、ユーザは、わずかに古い統計レコードを受け取る。別の状況では、キャッシュ内の古いバージョンが失効しているので、データベースサーバによって問い合わせが処理され、その結果、新しいバージョンがユーザに戻される。これは、アプリケーションサーバのキャッシュが、適時に更新されている場合に、要求が、アプリケーションサーバレベルで成功裏に処理されており、データベースサーバには全く到達しないので、ユーザによって受け取られる統計レコードの新しさには影響を及ぼさないが、システム全体の意図する効率にはわずかに影響を及ぼし得る。
【００３３】
上述したアプリケーションサーバレベルのプロセス、およびデータベースレベルのプロセスを、以下に詳述する。
【００３４】
図２は、例示的な統計アプリケーションにおけるアプリケーションサーバプロセスのフローチャートを示している。
【００３５】
上述のように、アプリケーションサーバのプロセスは、特定の条件が満たされる場合に、データベースサーバを呼び出さずに、要求を満たす機会を提供する。この場合、統計レコードは、データベースサーバにアクセスせずに、アプリケーションサーバからユーザに直接戻され得る。
【００３６】
ブロック２１０は、アプリケーションサーバレベルでの問い合わせプロセスを表している。このブロックは、それぞれが問い合わせのステップを表す、２つのサブブロックＳ２１１およびＳ２１２を含む。
【００３７】
ブロックＳ２１１において、アプリケーションサーバは、ユーザによって要求される統計レコードが、アプリケーションサーバのキャッシュ内にあるかどうかを判定する。統計レコードがキャッシュ内に存在する場合に、プロセスは、ブロックＳ２１２へと続く。存在しない場合に、プロセスは、ブロックＳ２２０へ進む。
【００３８】
ブロックＳ２１２において、アプリケーションサーバは、要求された統計レコードが失効しているかどうかを判定する。このブロックにおける動作は、要求された統計レコードが、アプリケーションサーバのキャッシュ内に見つかった場合にだけ行われる。統計結果が失効していた場合、プロセスは、ブロックＳ２２０へと続く。データが失効していない場合、プロセスは、ブロックＳ２３０へ進む。
【００３９】
一実施形態において、図１および表１を参照して上述したように、各統計レコードは、現在の統計レコードが直前に更新された時の時間を示す項目Ｕｐｄａｔｅ＿Ｔｉｍｅを含む、時間フィールドを有する。統計アプリケーションのためのシステムは、更新時間と組み合わせて、統計レコードが、依然として有効である、すなわち失効していないと認められる、更新時間から現在の時間までをカウントする最大時間幅に対する閾値を設定することができる。この失効閾値は、データベース内の統計レコードの時間状態を判定するための、データベースサーバによって使用される失効閾値と同一である必要はない。しかしながら、好ましくは、アプリケーションサーバにおける失効閾値およびデータベースサーバにおける失効閾値は、互いに矛盾する結果をもたらすように互いに食い違うべきではない。失効閾値の設定においては、多くの柔軟性がある。例えば、同じ統計表内の全ての統計レコードに適用可能な、普遍的な表現式の閾値が使用されてもよい。しかしながら、必要に応じて、異なる統計レコード、または異なる統計レコード群は、所与の異なる失効閾値であってもよい。アプリケーションサーバにおける失効閾値は、アプリケーションサーバ自体、またはデータベースサーバによって設定されるか、またはアプリケーションサーバおよびデータベースサーバの両方を制御する独立した制御装置によって設定されてもよい。アプリケーションサーバにおける失効閾値は、固定値として設定されるか、データベースサーバまたは別個の中央制御装置との通信を通して、動的に調整されてもよい。
【００４０】
ブロックＳ２２０は、データベースサーバ段階での問い合わせプロセスを表す。このプロセスは、図３を参照して以下にさらに詳しく説明する。
【００４１】
ブロックＳ２３０において、統計レコードは、照会者に送られる。この説明において、照会者は、システムの別の構成要素、またはシステムの実際の人間ユーザのいずれかであってもよい。
【００４２】
アプリケーションサーバの上述のプロセスは、以下の擬似コードを使用して説明することができる。
【００４３】
if (アプリケーションサーバのキャシュに統計レコードが存在する) then
{
if (現在のシステム時間 - Updated_Time > 閾値) then
キャッシュ内の統計レコードは失効しているので、データベースを呼ぶ;
else
キャッシュ内の統計レコードは有効なので、ユーザに送る;
end if;
}
Else
データベースを呼ぶ;
end if;
アプリケーションサーバのキャッシュ内の統計レコードが、失効している、または当該レコードがアプリケーションサーバのキャッシュ内に存在しない場合に、データベースの統計戦略が呼び出される。
【００４４】
図３は、例示的なデータベースサーバプロセスのフローチャートを示している。プロセスＳ３２０は、図２のブロックＳ２２０の例示的な一実施形態である。図２において説明したように、プロセスは、アプリケーションサーバから送られる問い合わせによって開始される。代替として、このプロセスは、最初にアプリケーションサーバを通さずに、照会者から直接送られる問い合わせによって開始することができる。
【００４５】
ブロックＳ３２１において、データベースサーバは、データベースサーバ内のデータベースの統計表内の要求された統計レコードについて問い合わせる。問い合わせは、表１に示されているように、統計レコードの主キーフィールドに従って行われてもよい。主キーフィールドは、統計レコードのＩＤとして機能する。主キーフィールドがキーワードを有する場合、問い合わせは、キーワードに基づくものであってもよい。
【００４６】
統計レコードが統計表内に存在する場合に、プロセスは、ブロックＳ３２２へと続く。統計レコードが存在しない場合に、プロセスは、ブロックＳ３２７へ進み、ＳＱＬ計算を呼び出す。
【００４７】
ブロックＳ３２２において、データベースサーバは、統計レコードが失効しているかどうかを判定する。図２で説明されたアプリケーションサーバ内の統計レコードの時間状態を判定するために使用されるものと同様の方法を、この目的のために使用することができる。失効している場合に、プロセスは、ブロックＳ３２３へと続く。失効していない場合に、プロセスは、ブロックＳ３２５へ進む。
【００４８】
ブロックＳ３２３において、データベースサーバは、要求された統計レコードの再計算のための統計ＳＱＬ文を呼び出す。記録が存在しない場合に、統計ＳＱＬ文は、ブロックＳ３２７において、初めてその記録を計算する。
【００４９】
ブロックＳ３２４において、データベースサーバは、統計表内の統計レコードを更新する。
【００５０】
ブロックＳ３２５において、データベースサーバは、キャッシュするためにアプリケーションサーバに統計レコードを送る。
【００５１】
ブロックＳ３２１において、統計レコードがデータベーステーブル内に存在しないことを決定した後に、ブロックＳ３２７において、データベースサーバは、統計レコードの計算のために統計ＳＱＬを呼び出す。
【００５２】
ブロックＳ３２８において、データベースサーバは、統計レコードを統計表に挿入する。プロセスは、次いで、ブロックにＳ３２５に戻る。
【００５３】
上述のデータベースサーバプロセスＳ３２０の後に、プロセスは、次いで、ブロックＳ３３０へと続き、照会者に統計レコードを戻す。
【００５４】
既存の技術において、統計ＳＱＬ文を呼び出すステップは、プロセス全体の中で、システムリソースの大部分を消費する。開示される方法は、一度作成された統計レコードを一定の期間再利用することができるように、統計レコードの有効なライフサイクルを定めるよう失効時間フィールドを統計表内に設定することによって、この問題を解決する。これは、ＳＱＬルーチンの高頻度の呼び出しを回避する。開示される方法は、統計情報にアクセスする戦略的な方法を確立する。アプリケーションサーバは、データベースにアクセスせずに、多数の繰り返しアクセスがアプリケーションサーバ内で完了され得るように作成された統計情報をキャッシュし、したがって、データベースの作業負荷を低減する。データベースへのアクセスが必要な時であっても、当該方法は、ＳＱＬ計算の無条件の呼び出しを行わない。その代わりに、統計表を、もうひとつの層のバッファとして使用することができる。統計レコードが統計表内に存在しない、または統計レコードが失効していることが分かった時にだけ、要求された統計結果を計算するために実表を走査するように、統計ＳＱＬ文が呼び出される。したがって、ＳＱＬ文を実行する計算負荷が低減される。
【００５５】
換言すれば、システムは、２層のキャッシュまたはバッファを有し、一方の層は、アプリケーションサーバのキャッシュ内にあり、他方は、データベースの統計表内にある。両方の層が、要求された統計レコードを提供できなかった時にだけ、統計計算のための実表を走査するように、統計ＳＱＬ文が呼び出される。よって、統計ＳＱＬ文の実数が大幅に低減される。大部分の要求について、概して、アプリケーションサーバのキャッシュ内にヒットを見つけることができるので、データベースサーバの攻撃耐性が大幅に向上する。当該方法は、非常に高い頻度の要求に対して特に有効である。それは、この状況では、全ての要求に対して統計レコードが更新されることが必要となる可能性がほとんど無いからである。要求頻度が低い統計レコードの場合、データベースサーバのＳＱＬ文は、全ての要求に対して最も更新された統計レコードを計算することが必要となり得る可能性が高いが、そのようにしても、データベースに対して過度の負担を生じさせない。
【００５６】
会員レビューの統計表について、極端な状況を考察する。会員の評価情報が全く要求されていない場合に、統計表は、この会員の評価の統計レコードを持たないことになる。同様に、ユーザの評価情報が長期間要求されていない場合は、評価の統計レコードが失効している可能性が高い。この統計レコードは、評価情報が要求されるまで更新されない。
【００５７】
本開示は、ＯＬＴＰ環境における統計アプリケーションのシステムも提供する。当該システムは、データベースサーバ内にホストされるデータベースを有する。データベースは、それぞれが記録の同一性識別子および時間要素を有する複数の統計レコードを有する統計表を含む。当該システムは、統計レコードの中の要求された統計レコードについて、データベースに問い合わせるための問い合わせ手段と、論理手段であって、要求された統計レコードが見つかった場合に、要求された統計レコードの時間要素を照合して、統計レコードが失効しているかどうかを判定する決定と、要求された統計レコードが失効していない場合に、統計レコードを照会者に戻す決定と、要求された統計レコードが存在しない、または失効していた場合に、実表を走査して要求された統計レコードを取得するように、ＳＱＬ文を呼び出す決定と、を行うための論理手段と、も有する。
【００５８】
一実施形態において、システムは、要求された統計レコードのコピーについて、アプリケーション内のキャッシュに問い合わせるための問い合わせ手段と、論理手段であって、要求された統計レコードのコピーが、キャッシュ内に見つかった場合に、統計レコードのコピーの時間要素を照合して、統計レコードのコピーが失効しているかどうかを判定する決定と、統計レコードのコピーが失効していない場合に、統計レコードのコピーを照会者に送る決定と、を行うための論理手段と、をさらに有する。
【００５９】
上述の問い合わせ手段、論理手段、および計算手段は、当技術分野で現在利用可能である、または将来的に利用可能になり得る種々の方法で実現することができる。問い合わせ手段、論理手段、および計算手段が実現される特定の様態は、この開示の不可欠な部分ではない。
【００６０】
図４は、本開示による、ＯＬＴＰ環境における統計アプリケーションのシステムの概略構造図を示している。この開示において、「ユニット」は、特定のタスクまたは機能を実行するように設計されたツールまたは機械である、装置である。ユニットまたは装置は、特定のタスクまたは機能に関連する目的を遂行するための、ハードウェア、ソフトウェア、計画またはスキーム、あるいはそれらの組み合わせとすることができる。
【００６１】
図４に示されているように、統計アプリケーションシステム４００は、アプリケーションサーバ４１０と、データベースサーバ４２０と、を含む。アプリケーションサーバ４１０は、データベースサーバ４２０から受け取ったキャッシュされた統計レコードのコピーを記憶する、キャッシングユニット４１２を有する。ユーザの要求を受け取ると、問い合わせユニット４１６は、キャッシングユニット４１２を検索して、要求された統計レコードが、キャッシュされた統計レコードのコピーの中に存在するかどうかを判定する。論理ユニット４１４は、統計レコードが存在する場合に、統計レコードの時間要素を照合して、統計レコードが失効しているかどうかを判定する決定と、統計レコードが失効していない場合に、統計レコードを、要求を行った照会者に送る決定と、統計レコードが存在しない、または失効していた場合に、統計レコードについて、データベースサーバ４２０に問い合わせる決定と、を行う。
【００６２】
データベースサーバ４２０は、それぞれが記録の同一性識別子および時間要素を有する統計レコードを含む統計表を含む、データベース４２１をホストする。問い合わせユニット４２２は、統計表内の要求された統計レコードについて、データベース４２１に問い合わせるのに使用される。決定を行うための論理ユニット４２３は、データベースサーバプロセスに関して本明細書で説明される。
【００６３】
計算ユニット４２４は、失効していない統計レコードが見つからなかった時に、要求された統計レコードを計算するように、ＳＱＬ文を実行する。計算ユニット４２４は、データベース４２１の統計表における統計レコードの作成または更新に、さらには、アプリケーションサーバ４１０に統計結果をキャッシュするように送るためにも使用される。計算ユニット４２４は、統計表内の統計レコードに対して失効時間マーカーを設定する、および要求された統計レコードの失効時間マーカーが、記録が失効していることを示しているかどうかを判定するのにも使用される。
【００６４】
実施環境
以下、それらの実施およびアプリケーション環境を示すために、方法およびシステムの例示的な実施環境が提供される。開示される方法およびシステムは、ソフトウェアまたはハードウェアのいずれかだけを使用して実施することができるが、好ましくは、ソフトウェアおよびハードウェアの組み合わせを使用して実施すべきであることに留意されたい。開示される方法自体は、記憶媒体内に記憶されるソフトウェア製品の形態で実施することができる。ソフトウェアは、本開示の例示的な実施形態において説明される方法を実行するように、（スタンドアロンまたはネットワーク化された）コンピュータデバイスのための命令を含む。
【００６５】
より具体的には、上述の手法は、以下に図示されるように、計算ユニットを有するサーバまたはパーソナルコンピュータ（ＰＣ）等の計算デバイスを用いて実施されてもよい。
【００６６】
図５は、本開示の方法を実施するための例示的な環境を示している。図示の環境５００において、いくつかの構成要素は、クライアント側に存在し、他の構成要素は、サーバ側に存在する。しかしながら、これらの構成要素は、複数の他の場所に存在してもよい。さらに、図示の構成要素のうちの２つ以上は、単一の場所で単一の構成要素を形成するように組み合わせてもよい。
【００６７】
ＯＬＴＰ環境における統計アプリケーションのシステムは、アプリケーションサーバ５１０およびデータベースサーバ５２０を含む、サーバ側にある。アプリケーションサーバ５１０は、プロセッサ５３０と、入出力装置５３２と、コンピュータ可読媒体（例えば、メモリ）５３４と、ネットワークインターフェース（図示せず）と、を含む。データベースサーバ５２０は、プロセッサ５２４と、入出力装置５３４と、コンピュータ可読媒体（例えば、メモリ）５３６と、ネットワークインターフェース（図示せず）と、を含む。アプリケーションサーバ５１０およびデータベースサーバ５２０は、ネットワーク５９０（インターネット等）を通して、クライアント装置５４１、５４２、および５４３に接続される。クライアント装置５４１、５４２、および５４３は、ユーザがアプリケーションサーバ５１０およびデータベースサーバ５２０にアクセスするための、パーソナルコンピュータ、ＰＤＡ、および携帯電話を含む、任意の好適な装置とすることができる。
【００６８】
アプリケーションサーバ５１０のコンピュータ可読媒体５３４は、データベースサーバ５２０から受け取られるキャッシュされた統計レコードのコピーを記憶する、キャッシュメモリ５１２を含む。コンピュータ可読媒体５３４はまた、アプリケーションプログラム５３７を記憶してもよい。同様に、データベースサーバ５２０のコンピュータ可読媒体５３６は、本明細書に説明されるように、アプリケーションプログラム５３８およびデータベース５２１を記憶し、統計レコードを含む統計表を含む。
【００６９】
アプリケーションプログラム５３７は、本明細書に説明されているように、プロセッサ５３０によって実行された時に、プロセッサ５２０に、アプリケーションサーバ５１０によって実行されるプロセスの動作を実行させる命令を含む。同様に、アプリケーションプログラム５３８は、本明細書に説明されているように、プロセッサ５２４によって実行された時に、プロセッサ５２４に、データベースサーバ５２０によって実行されるプロセスの動作を実行させる命令を含む。
【００７０】
コンピュータ可読媒体は、コンピュータデータを記憶するための好適なメモリ装置のうちのいずれかであってもよいことを認識されたい。このようなメモリ装置には、ハードディスク、フラッシュメモリ装置、光データ記憶装置、およびフロッピーディスクが挙げられるが、これに限定されない。さらに、コンピュータ実行可能な命令を含むコンピュータ可読媒体は、ローカルシステム内の構成要素、または複数のリモートシステムのネットワークを通じて配信される構成要素で構成されてもよい。コンピュータ実行可能な命令のデータは、有形の物理メモリ装置内に提供されてもよく、または電子的に伝送されてもよい。
【００７１】
コンピュータ可読媒体は、コンピュータデータを保存するための好適な記憶装置のいずれかであり得ることを理解されたい。かかる記憶装置は、ハードディスク、フラッシュメモリ装置、光学データストレージ、およびフロッピーディスクを含むが、それらに限定されない。さらに、コンピュータ実行可能な指示を含むコンピュータ可読媒体は、ローカルシステムにおける構成要素、または複数のリモートシステムのネットワーク上に分散される構成要素から成り得る。コンピュータ実行可能な指示のデータは、有形の物理メモリ装置において送達されるか、または電子的に伝送され得る。
【００７２】
アプリケーションサーバ５１０およびデータベースサーバ５２０の媒体のそれぞれは、単一のサーバコンピュータ、またはサーバのクラスタであってもよいことも認識されたい。
【００７３】
本明細書で論じられる可能な利益および利点は、添付の請求項の範囲に限定または制限されるものと見なされない。
【００７４】
主題は構造的特徴および／または方法論的動作に対して具体的な言語で説明されているが、添付の請求項において定義される主題は、説明される特定の特徴または動作に必ずしも限定されない。むしろ、特定の特徴および動作は、請求項を実施する例示的な形態として開示される。
【特許請求の範囲】
【請求項１】
ＯＬＴＰ環境における統計アプリケーションの方法であって、
記録の同一性を有する統計レコードが、統計表内に存在するかどうかを判定するように、前記統計表を含むデータベースに問い合わせるステップと、
前記統計レコードが存在する場合に、前記統計レコードの時間要素を照合して、前記統計レコードが失効しているかどうかを判定するステップと、
前記統計レコードが失効していない場合に、前記統計レコードを照会者に送るステップと、
前記統計レコードが存在しない、または失効していた場合に、ＳＱＬ文を呼び出して、前記統計レコードを計算するステップと
を含むことを特徴とする方法。
【請求項２】
前記データベースは、データベースサーバ内に記憶され、前記データベースに問い合わせるステップは、
前記統計レコードに対する問い合わせを、アプリケーションサーバから前記データベースサーバに送るステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記統計レコードの前記時間要素は、前記統計レコードが最後に更新または作成されたのがいつなのかを示す時間マーカーを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記統計レコードの前記時間要素は、前記統計レコードが最後に更新または作成された時の時間から現在の照会の時間までをカウントする閾値時間幅をさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記時間マーカーは、前記統計レコードのデータフィールドに保存されることを特徴とする請求項３に記載の方法。
【請求項６】
前記データベースに問い合わせるステップは、
前記統計レコードのキーワードに一致する問い合わせ語によって前記データベースに問い合わせるステップを含み、
前記統計レコードの前記時間要素は、前記統計レコードの前記キーワードに対応する、予め設定された時間マーカーを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記統計レコードの前記記録の同一性識別子は、キーワードを含み、前記データベースに問い合わせるステップは、
前記キーワードに一致する問い合わせ語によって前記データベースに問い合わせるステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記データベースは、電子商取引システムの一部であり、前記統計レコードは、前記電子商取引システムのユーザの統計データを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記データベースに問い合わせる前に、前記統計レコードが、アプリケーションサーバのキャッシュ内に存在しているかどうかを判定するステップと、
前記統計レコードが前記キャッシュ内に存在する場合に、前記キャッシュ内の前記統計レコードが失効しているかどうかを判定するステップと、
前記キャッシュ内の前記統計レコードが失効していない場合に、前記キャッシュ内の前記統計レコードを照会者に送るステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記キャッシュ内の前記統計レコードが失効しているかどうかを判定するステップは、
前記統計レコードに対応する前記時間要素と、前記統計レコードが最後に更新または作成された時の時間から現在の照会の時間までをカウントする閾値時間幅とを照合するステップを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記キャッシュ内の前記統計レコードが失効しているかどうかを判定するステップは、
前記キャッシュの前記統計レコードのデータフィールド内の時間マーカーを照合するステップを含むことを特徴とする請求項９に記載の方法。
【請求項１２】
前記ＳＱＬ文の計算結果を使用して、前記統計表内の前記統計レコードを挿入または更新するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記計算結果を、その中にキャッシュされるようにアプリケーションサーバに送るステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
ＯＬＴＰ環境における統計アプリケーションの方法であって、
記録の同一性を有する統計レコードが、複数の統計レコードの中に存在するかどうかを判定するように、前記複数の統計レコードを記憶しているキャッシュメモリを有するアプリケーションサーバに問い合わせるステップと、
前記統計レコードが存在する場合に、前記統計レコードの時間要素を照合して、前記統計レコードが失効しているかどうかを判定するステップと、
前記統計レコードが失効していない場合に、前記統計レコードを照会者に送るステップと、
前記統計レコードが存在しない、または失効していた場合に、前記統計レコードについて前記データベースサーバに問い合わせるステップと
を含むことを特徴とする方法。
【請求項１５】
前記統計レコードについて前記データベースサーバに問い合わせるステップは、
前記データベースサーバの前記データベースに問い合わせて、前記統計レコードが、データベース内の統計表内に存在するかどうかを判定するステップと、
前記統計レコードが存在する場合に、前記統計レコードの前記時間要素を照合して、前記統計レコードが失効しているかどうかを判定するステップと、
前記統計レコードが失効していない場合に、前記統計レコードを照会者に送るステップと、
前記統計レコードが存在しない、または失効していた場合に、前記統計レコードを計算するように、ＳＱＬ文を呼び出すステップと
を含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
ＯＬＴＰ環境における統計アプリケーションのシステムであって、
データベースサーバ内にホストされるデータベースであって、それぞれが記録の同一性識別子および時間要素を有する複数の統計レコードを有する統計表を含む、データベースと、
前記複数の統計レコードの中の要求された統計レコードについて、前記データベースに問い合わせるための問い合わせ手段と、
論理手段であって、
前記要求された統計レコードが見つかった場合に、前記要求された統計レコードの時間要素を照合して、前記統計レコードが失効しているかどうかを判定する決定と、
前記要求された統計レコードが失効していない場合に、前記要求された統計レコードを照会者に戻す決定と、
前記要求された統計レコードが存在しない、または失効していた場合に、ＳＱＬ文を呼び出して、前記要求された統計レコードを計算する決定と、
を行うための論理手段と
を備えることを特徴とするシステム。
【請求項１７】
前記要求された統計レコードのコピーについて、アプリケーション内のキャッシュに問い合わせるための問い合わせ手段と、
論理手段であって、
前記要求された統計レコードの前記コピーが、前記キャッシュ内に見つかった場合に、前記統計レコードの前記コピーの前記時間要素を照合して、前記統計レコードの前記コピーが失効しているかどうかを判定する決定と、
前記統計レコードの前記コピーが失効していない場合に、前記統計レコードの前記 コピーを照会者に送る決定と
を行うための論理手段と
をさらに備えることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記呼び出されたＳＱＬ文を実行し、前記要求された統計レコードを計算して、前記データベースの前記統計表において前記要求された統計レコードを作成または更新するための計算手段をさらに備えることを特徴とする請求項１６に記載のシステム。
【請求項１９】
複数の命令をそこに記憶させた１つ以上のコンピュータ可読媒体であって、１つ以上のプロセッサによって実行された時に、当該命令が、前記プロセッサに、
統計表を含むデータベースに問い合わせ、記録の同一性を有する統計レコードが存在するかどうかを判定させ、
前記統計レコードが存在する場合に、前記統計レコードの時間要素を照合して、前記統計レコードが失効しているかどうかを判定させ、
前記統計レコードが失効していない場合に、前記統計レコードを照会者に送らせ、かつ前記統計レコードが存在しない、または失効していた場合に、前記統計レコードを計算するように、ＳＱＬ文を呼び出させる
ことを特徴とする１つ以上のコンピュータ可読媒体。
【請求項２０】
１つ以上のプロセッサによって実行された時に、前記複数の命令が、前記プロセッサにさらに、
前記呼び出されたＳＱＬ文を実行させ、かつ前記データベースの前記統計表において前記統計レコードを作成または更新させる
ことを特徴とする請求項１９に記載の１つ以上のコンピュータ可読媒体。
【請求項１】
ＯＬＴＰ環境における統計アプリケーションの方法であって、
記録の同一性を有する統計レコードが、統計表内に存在するかどうかを判定するように、前記統計表を含むデータベースに問い合わせるステップと、
前記統計レコードが存在する場合に、前記統計レコードの時間要素を照合して、前記統計レコードが失効しているかどうかを判定するステップと、
前記統計レコードが失効していない場合に、前記統計レコードを照会者に送るステップと、
前記統計レコードが存在しない、または失効していた場合に、ＳＱＬ文を呼び出して、前記統計レコードを計算するステップと
を含むことを特徴とする方法。
【請求項２】
前記データベースは、データベースサーバ内に記憶され、前記データベースに問い合わせるステップは、
前記統計レコードに対する問い合わせを、アプリケーションサーバから前記データベースサーバに送るステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記統計レコードの前記時間要素は、前記統計レコードが最後に更新または作成されたのがいつなのかを示す時間マーカーを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記統計レコードの前記時間要素は、前記統計レコードが最後に更新または作成された時の時間から現在の照会の時間までをカウントする閾値時間幅をさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記時間マーカーは、前記統計レコードのデータフィールドに保存されることを特徴とする請求項３に記載の方法。
【請求項６】
前記データベースに問い合わせるステップは、
前記統計レコードのキーワードに一致する問い合わせ語によって前記データベースに問い合わせるステップを含み、
前記統計レコードの前記時間要素は、前記統計レコードの前記キーワードに対応する、予め設定された時間マーカーを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記統計レコードの前記記録の同一性識別子は、キーワードを含み、前記データベースに問い合わせるステップは、
前記キーワードに一致する問い合わせ語によって前記データベースに問い合わせるステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記データベースは、電子商取引システムの一部であり、前記統計レコードは、前記電子商取引システムのユーザの統計データを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記データベースに問い合わせる前に、前記統計レコードが、アプリケーションサーバのキャッシュ内に存在しているかどうかを判定するステップと、
前記統計レコードが前記キャッシュ内に存在する場合に、前記キャッシュ内の前記統計レコードが失効しているかどうかを判定するステップと、
前記キャッシュ内の前記統計レコードが失効していない場合に、前記キャッシュ内の前記統計レコードを照会者に送るステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記キャッシュ内の前記統計レコードが失効しているかどうかを判定するステップは、
前記統計レコードに対応する前記時間要素と、前記統計レコードが最後に更新または作成された時の時間から現在の照会の時間までをカウントする閾値時間幅とを照合するステップを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記キャッシュ内の前記統計レコードが失効しているかどうかを判定するステップは、
前記キャッシュの前記統計レコードのデータフィールド内の時間マーカーを照合するステップを含むことを特徴とする請求項９に記載の方法。
【請求項１２】
前記ＳＱＬ文の計算結果を使用して、前記統計表内の前記統計レコードを挿入または更新するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記計算結果を、その中にキャッシュされるようにアプリケーションサーバに送るステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
ＯＬＴＰ環境における統計アプリケーションの方法であって、
記録の同一性を有する統計レコードが、複数の統計レコードの中に存在するかどうかを判定するように、前記複数の統計レコードを記憶しているキャッシュメモリを有するアプリケーションサーバに問い合わせるステップと、
前記統計レコードが存在する場合に、前記統計レコードの時間要素を照合して、前記統計レコードが失効しているかどうかを判定するステップと、
前記統計レコードが失効していない場合に、前記統計レコードを照会者に送るステップと、
前記統計レコードが存在しない、または失効していた場合に、前記統計レコードについて前記データベースサーバに問い合わせるステップと
を含むことを特徴とする方法。
【請求項１５】
前記統計レコードについて前記データベースサーバに問い合わせるステップは、
前記データベースサーバの前記データベースに問い合わせて、前記統計レコードが、データベース内の統計表内に存在するかどうかを判定するステップと、
前記統計レコードが存在する場合に、前記統計レコードの前記時間要素を照合して、前記統計レコードが失効しているかどうかを判定するステップと、
前記統計レコードが失効していない場合に、前記統計レコードを照会者に送るステップと、
前記統計レコードが存在しない、または失効していた場合に、前記統計レコードを計算するように、ＳＱＬ文を呼び出すステップと
を含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
ＯＬＴＰ環境における統計アプリケーションのシステムであって、
データベースサーバ内にホストされるデータベースであって、それぞれが記録の同一性識別子および時間要素を有する複数の統計レコードを有する統計表を含む、データベースと、
前記複数の統計レコードの中の要求された統計レコードについて、前記データベースに問い合わせるための問い合わせ手段と、
論理手段であって、
前記要求された統計レコードが見つかった場合に、前記要求された統計レコードの時間要素を照合して、前記統計レコードが失効しているかどうかを判定する決定と、
前記要求された統計レコードが失効していない場合に、前記要求された統計レコードを照会者に戻す決定と、
前記要求された統計レコードが存在しない、または失効していた場合に、ＳＱＬ文を呼び出して、前記要求された統計レコードを計算する決定と、
を行うための論理手段と
を備えることを特徴とするシステム。
【請求項１７】
前記要求された統計レコードのコピーについて、アプリケーション内のキャッシュに問い合わせるための問い合わせ手段と、
論理手段であって、
前記要求された統計レコードの前記コピーが、前記キャッシュ内に見つかった場合に、前記統計レコードの前記コピーの前記時間要素を照合して、前記統計レコードの前記コピーが失効しているかどうかを判定する決定と、
前記統計レコードの前記コピーが失効していない場合に、前記統計レコードの前記 コピーを照会者に送る決定と
を行うための論理手段と
をさらに備えることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記呼び出されたＳＱＬ文を実行し、前記要求された統計レコードを計算して、前記データベースの前記統計表において前記要求された統計レコードを作成または更新するための計算手段をさらに備えることを特徴とする請求項１６に記載のシステム。
【請求項１９】
複数の命令をそこに記憶させた１つ以上のコンピュータ可読媒体であって、１つ以上のプロセッサによって実行された時に、当該命令が、前記プロセッサに、
統計表を含むデータベースに問い合わせ、記録の同一性を有する統計レコードが存在するかどうかを判定させ、
前記統計レコードが存在する場合に、前記統計レコードの時間要素を照合して、前記統計レコードが失効しているかどうかを判定させ、
前記統計レコードが失効していない場合に、前記統計レコードを照会者に送らせ、かつ前記統計レコードが存在しない、または失効していた場合に、前記統計レコードを計算するように、ＳＱＬ文を呼び出させる
ことを特徴とする１つ以上のコンピュータ可読媒体。
【請求項２０】
１つ以上のプロセッサによって実行された時に、前記複数の命令が、前記プロセッサにさらに、
前記呼び出されたＳＱＬ文を実行させ、かつ前記データベースの前記統計表において前記統計レコードを作成または更新させる
ことを特徴とする請求項１９に記載の１つ以上のコンピュータ可読媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１１−５０５６１５（Ｐ２０１１−５０５６１５Ａ）
【公表日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２０１０−５３３２８４（Ｐ２０１０−５３３２８４）
【出願日】平成２０年１１月７日（２００８．１１．７）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０８２８４５
【国際公開番号】ＷＯ２００９／０６２０６７
【国際公開日】平成２１年５月１４日（２００９．５．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（５０８２４８０６９）アリババ グループ ホールディング リミテッド (105)
【Ｆターム（参考）】
【公表日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２０年１１月７日（２００８．１１．７）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０８２８４５
【国際公開番号】ＷＯ２００９／０６２０６７
【国際公開日】平成２１年５月１４日（２００９．５．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（５０８２４８０６９）アリババ グループ ホールディング リミテッド (105)
【Ｆターム（参考）】
[ Back to top ]