データベース作業負荷に対する入出力の優先順位付け

著者らは特許

G06F17/30 - 情報検索;そのためのデータベース構造

の所有者の特許 JP2016528578:

アマゾン テクノロジーズ インコーポレイテッド

 

データベース管理システムは、データセンターでシステムをホストし、種々の事業体に代わってエンドユーザにシステムへのアクセスを提供する、第三者プロバイダにより運営され得る。総容量消費の制限が課され得るが、容量消費がこれらの制限を超過するとき、サービス停止をもたらし得る。システムでの動作を遂行する要求は、分類され得る。要求の分類は、要求を承諾または拒絶するためのポリシーに関連付けられ得る。動作を遂行する要求に対して利用可能な容量を表す1つ以上のトークンバケットが、要求を承諾するために使用され、動作を遂行する経費に基づいて更新され得る。

 

 

関連出願の相互参照
本出願は、2013年5月17日に出願された米国特許出願第13,897,232号の利益を主張し、その開示は参照によりその全体が本明細書に組み込まれる。
データベース管理システム(「DBMS」)は、DBMSをデータセンターのサーバーでホストし、DBMSをサービスとして法人、大学、政府機関、および他の種類の顧客等の種々の事業体に提供する、第三者プロバイダにより運営され得る。DBMSをホストし、そのサービスを種々の事業体に提供するために、プロバイダは典型的には、かなりのリソースをハードウェア、ソフトウェア、およびインフラストラクチャ内に維持する。加えて、プロバイダは、電力、保守経費、および技術者の給料等のDBMSの運営に関連する種々の継続的な諸経費を課され得る。したがって、種々の事業体に応答性に優れるサービスを提供するために、プロバイダは、そのデータセンターに設置されたハードウェアおよび他のリソースの容量および利用度を最大化することを試み得る。
本明細書中に提供される図面は、例となる実施形態を例示するためのもので、本開示の範囲を限定するようには意図されていない。
ウェブサービスを通してエンドユーザに公開され、トークン割り当ておよび消費メカニズムの使用により容量消費を制限するデータベース管理システムを示すブロック図である。 トークン割り当ておよび消費メカニズムを用いたプロビジョニングされた容量の実施を示すフローチャートである。 トークンのトークンバケットへの割り当ておよびトークンバケットからの複数の要求種類のトークン消費を示す図である。 要求の種類に従って分類される複数のトークンバケットへのトークンの割り当て、および対応する要求種類の処理に基づくバケットからのトークンの引き出しを示す図である。 要求種類の複数の要求クラスへの割り振り、ならびにクラスの、いずれのトークンバケットが承諾を決定するかおよびいずれのバケットからトークンが引き出されるかを制御し得る承諾ポリシーとの関連付けを示す図である。 要求の分類に基づいて承諾ポリシーを取得かつ適用するための実施形態を示すフローチャートである。 要求種類の複数の要求クラスへの割り振り、ならびにクラスの、要求の承諾および階層的配置のトークンバケットからのトークンの引き出しを調整する承諾ポリシーとの関連付けを示す図である。 階層的配置のトークンバケット中の親バケットからのトークンの差し引きを示す図である。 階層的配置のトークンバケット中の子バケットからのトークンバケットの差し引きを示す図である。 親バケットから、その親に利用可能であるよりも多いトークンの差し引きを示す図である。 子バケットから、子バケットまたは親バケットのいずれかに利用可能であるよりも多いトークンの差し引きを示す図である。 同等の優先度の2つ以上のクラスが親バケットを共有する階層的配置のトークンバケットを示す図である。 要求クラス、トークンバケット、および承諾ポリシーに関する顧客提供情報を取得するためのユーザインターフェースの図示実施例を示す図である。 階層的トークンバケットモデルを利用する手法に適合された、要求クラス、トークンバケット、および承諾ポリシーに関する顧客提供情報を取得するためのユーザインターフェースの図示実施例を示す図である。 新たなテーブルの顧客の定義と連携して容量割り当ておよび承諾ポリシー情報を受信し、ならびにその情報を用いてトークンバケットを作成し、承諾ポリシーを区分毎に適用するためのステップを示すフローチャートである。 本開示の態様が実施され得るコンピューティング環境の実施形態を示すブロック図である。
上述のように、プロバイダは、DBMSをデータセンターでホストし、DBMSへのアクセスをサービスとして種々の事業体に対して提供し得る。このことに関して、DBMSは、ウェブサービス、ウェブアプリケーション、遠隔手続き呼び出し等を通して、公開され得る。これらのメカニズムおよび他は、本明細書ではサービスと呼ばれ得る。いくつかの実施形態では、DBMSは、サービスのうちの1つ以上を公開する統合フロントエンドを、事業体のエンドユーザまたは顧客に提供し得る。サービスを通して、エンドユーザは、サービスに対するアプリケーションプログラミングインターフェース(「API」)呼び出しを利用して、DBMSで遂行される種々の動作および問合せを含む要求を行い得る。要求は、例えば、顧客に代わってのAPIの呼び出し、ならびに顧客に代わってのDBMSでの動作の呼び出しを含み得る。
プロバイダはまた、この容量の使用の見返りに顧客から報酬を要求し得る。しかし、この努力の収益性は、そのために消費された容量に比例して金額を支払う顧客に依存し得る。容量消費の制限が顧客に課され、スロットリング、キューイング等の種々の技法により実施され得る。使用が顧客にプロビジョニングされた量を超過すると、顧客に代わってのサービスに対する要求は、拒絶されるまたは一時停止される場合がある。このことは、種々の状況で顧客にとって不都合であり得る。例えば、そのサービスは、電子商取引ウェブサイトまたは類似のアプリケーションの構成要素となり得、その場合当該サービスに対する要求が拒絶された場合には機能しなくなる場合がある。しかし、サービスに対する全ての要求が、顧客にとって必ずしも同等に重要であるとは限らない場合がある。電子商取引でのショッピングカートの内容の表示または顧客の注文の処理等の種々の要求は、重要度は高い場合があるが、その他についてはそうでない場合がある。例えば、比較的重要度の低いある特定の種類の要求としては、保守タスク、報告の生成、データ掘り起こし等が含まれ得る。これらのタスクはまた、図らずも比較的大きい容量部分を消費し、そのため顧客のプロビジョニングされた容量を超過したときには、停止、ブラックアウト期間、または遅延を生じやすい。
エンドユーザは、動作の識別子および1つ以上のパラメータを含めて要求を送信することにより、DBMS上に動作を呼び出し得る。任意の数の動作が識別され得、データの読み出しまたは書き込み等の操作、データでの問合せの遂行、ならびにテーブルの作成および削除等の種々のデータ定義およびスキーマ関連の命令を含み得る。要求と共に含まれ得るパラメータは、テキスト値、列挙値、整数等の、任意の種類であり得る。特定の組み合わせのパラメータは、呼び出されている動作の種類に基づいて異なることになる。
DBMSは、編成された収集データを維持するためのソフトウェアおよびハードウェアシステムである。DBMSでは、データは典型的には、キー値と追加のデータとの間の関連付けにより編成される。関連付けの性質は、収集データ中に存在する実世界の関係に基づき得るか、または任意であり得る。データ定義、問合せ、更新、および管理を含めて、種々の動作がDBMSにより遂行され得る。いくつかのDBMSは、構造化問合せ言語(「SQL」)等の、問合せ言語を用いてデータベースとのやりとりを規定し、他は、put()およびget()等の動作を含むAPIを使用する。データベースとのやりとりはまた、ハイパーテキストマークアップ言語(「HTML」)および拡張マークアップ言語(「XML」)等の、種々のプロトコルまたは標準に基づき得る。DBMSは、データを、ソリッドステートドライブ等の1つ以上の記憶デバイスに記憶するように作用する記憶エンジン等の、種々の構築要素を含み得る。
プロバイダは、任意の数のDBMSをそのデータセンター内に提供し得る。DBMSは、任意の数のコンピューティングノード上で動作し、種々の記憶デバイスに関連付けられ、様々なネットワーク設備および接続形態を用いて接続され得る。しかも、関連型データベース、オブジェクト指向データベース、無構造化問合せ言語(「NoSQL」)データベース等を含めて、種々のDBMSが提供され得る。
上述のように、容量消費の制限が、顧客に課され得る。実施形態では、顧客は、設定された容量消費のレベルを有し得る。顧客の容量消費のレベルは、種々の推定および測定技法により制限され得る。要求の処理に関与し得る様々なコンピューティングリソースに起因して、容量消費は決定するのが困難であり得る。しかし、種々の測定可能量が、容量消費の合理的代理として機能し得る。種々の実施形態では、クライアントアプリケーションに送信されまたはそれから受信されるデータ量等の量が、特定の要求を処理することにより消費される容量を推定するために使用され得る。例えば、問合せ要求が、問合せに特定された制約に従う行を推定するために、データベーステーブルを走査し得る。返される行の数は、容量消費の代理であり得る。例えば、単一行のデータが返されれば、問合せは範囲が制限されており、したがって多数行でデータの返された問合せよりもより少ない容量しか消費しなかった可能性が高い。例となる実施形態のより詳細な事項を、図面と関連して以下に説明する。
上述のように、例示の実施形態では、プロバイダは、1つ以上のDBMSをデータセンター内に提供し、ウェブサービスを介して種々のDBMSへのアクセスを提供する。図1は、プロビジョニングされたウェブサービスおよびデータベースをデータセンター内でホストするための環境を示す。エンドユーザ側のアプリケーション102は、通信ネットワーク103、ゲートウェイ104、およびルータ106によりデータセンター100内の要素に接続され得る。当業者であれば、本ネットワーク構成が本開示の実施形態に組み込まれ得る多数の可能な構成のうちの1つであることを認識するであろう。
ウェブサービス110は、データベース116の動作に関連する諸機能を提供する種々のAPIを提供し得る。いくつかの場合では、APIは、より複雑なデータベースインターフェースまたはプロトコル上に構築される軽量ラッパーとして機能し得る。例えば、図示のAPI111は、リプレゼンテーショナルステートトランスファ(「REST」)原理に従うインターフェースの使用により、データベース116の問合せ機能へのアクセスを提供し得る。エンドユーザ側のアプリケーション102は、そこで、比較的単純なREST意味規則を用いて、API111を呼び出して、データベース116の技術的詳細についての理解を要することなく、キー値データベースを問合せ得る。
ウェブサービス110およびデータベース116は、総括的にコンピューティングノードと呼び得る、1つ以上のコンピュータ、仮想マシンまたは他の形態のコンピューティングサービス等の、種々のプラットフォーム上で動作し得る。これらのノードの動作、ならびに関連する記憶デバイス、ネットワークインフラストラクチャ等は、種々の経費を伴う。これらの経費には、ハードウェアおよびソフトウェアの取得、保守、電力、要員等に関連するものが含まれる。経費には、一顧客によるリソースの消費が他人のサービスの利用を妨げるときに生じる機会経費等の要因も含み得る。
顧客に代わってウェブサービス110およびデータベース116により遂行される動作は、所与のコンピューティングノード上の容量の量の消費と相関し得る。この相関は、ホスト側サービスプロバイダがサービスを提供することにより生じる経費を計算するのを可能にし得る。例えば、所与の顧客がコンピューティングノードの終日に亘る容量の100パーセントを利用するウェブサービスを呼び出す場合、サービスを提供する経費は、24時間の期間に割り当てられるコンピューティングノードに対する取得、保守および動作の経費の合計であり得る。
したがって、容量の消費は、図1に示す実施形態等の種々の手段により制限され得る。承諾ポリシー108は、要求が処理されるべきか否かの決定を含む。大まかにいえば、承諾ポリシー108の目的は、顧客に代わって遂行される要求が、プロビジョニングされた量の容量を超過するのを許可されないことを確実にし得る。例えば、顧客は、コンピューティングノードの容量の25パーセントをプロビジョニングされ得る。承諾ポリシー108は、そこで、その顧客の容量平均消費量を25パーセント以下に制限するように作用する。いくつかの実施形態では、使用のピークが限定期間に当該量を上回るのを許可され得る。
顧客の容量が使われ過ぎたとき、承諾ポリシー108は入来要求を拒絶し得る。要求の性質に応じて、このことは、顧客にとって重要な結果を招き得る。例えば、顧客は、要求をデータベース116に向けて、エンドユーザのショッピングカートのコンテンツを取得するショッピングウェブサイトを運営し得る。要求が拒絶されると、販売完了ではなくエラーメッセージの結果となり得る。他方、いくつかの種類の要求は、重大な結果を生じることなく見合わされる。可能性がある例として、保守タスク、レポートの生成等が含まれる。したがって、承諾ポリシー108は、承諾または拒絶の判断をするとき、関連した要求の種類を考慮するように実施され得る。
実施形態は、容量消費を制限するためにトークンバケットモデルを使用し得る。トークンバケットは、概念上トークンの収集として考えることができ、トークンの各々はバケットの所有者が認可を受けて遂行する作業の単位を表す。トークンは、例えば、サービスのレベルに基づき得る蓄積速度でバケットに追加され得る。作業が遂行されると、遂行された作業量に相当する数のトークンがバケットから引き出される。トークンが得られない場合は、作業は遂行されない。この手法を用いて、遂行され得る作業量が、時間経過とともにトークンがバケットに追加される率により制限される。
容量の短期の過剰使用を防止するためには、バケットに追加されるトークンの最大数に制限を課すことができる。当該制限を超えて追加されるいかなるトークンも廃棄され得る。
データベースの動作に関連して、トークンは、データベースの動作の遂行に関連するする経費の単位を表すとみなし得る。例えば、データベース116で動作を行うための要求の経費は、その動作が実行されたときに返送されるデータのサイズに対応し得る。トークンで測られた場合の、動作を遂行する経費は、当該データのサイズをトークン値当たりのサイズで除算することにより決定され得る。
要求された動作は、少なくとも1トークンでの経費とみなされ得るが、全体経費は動作が実際に遂行された後まで分からない場合がある。一実施形態では、多くの可能な実施形態の中で、少なくとも1トークンが利用可能であるとき、要求が承諾され得る。この要求は、次いで処理され、要求の総経費が1つ以上の測定量に基づいて決定され得る。
図1で、トークンは、トークンバケット112等の仮想容器内に蓄積し得る。トークンバケットは、トークンにより表される許可容量消費量の単位と、顧客またはサービス等の事業体との間の関連付けを表すものとみなし得る。例えば、顧客がデータベース116上でテーブルを作成するとき、トークンバケット112がこのテーブル上で行われる全ての動作に関連付けられ得る。他の実施形態では、トークンバケットをテーブル区分、顧客、コンピューティングノード等に関連付け得る。
トークン蓄積ポリシー114は、トークンバケット112内へのトークンの追加を調整し得る。実施形態では、蓄積ポリシー114は、追加率および最大トークン容量を含む。例えば、ポリシーは、所与のバケットがトークンを毎秒20の率で蓄積すべきであるが、百を超えたトークンの蓄積が許可されるべきではないことを示し得る。
トークンおよびトークンバケットは、種々の構造により表され得る。実施形態では、承諾ポリシー108、トークンバケット112およびトークン蓄積ポリシー114は、ソフトウェアライブラリ、実行可能なプログラム等の、機能性モジュールにより実現される。モジュールは、現在のトークン数、最大トークン数、蓄積速度および前回のトークン追加時間を記録することにより、トークンおよびトークンの蓄積を表し得る。要求を承諾または拒絶するか否かを決定するとき、モジュールは先ず、蓄積速度、トークンが追加された最後の時間、および現在の時間に基づいて現在のトークンの数を更新し得る。例えば、トークンバケットに対応するデータ構造を調べて容量が利用可能であるかを決定するとき、蓄積された新たなトークンの数は、蓄積速度を前回の更新から経過した時間量で乗算することにより、利用可能なトークンの計数に決定され得る。この値は、現在利用可能なトークンの計数に加算され得るが、バケットに許可された最大トークン数を超過することは許可され得ない。定期的に呼び出されるルーチンに基づくもの等の、トークンバケットを維持するための他の技法もまた可能である。
図2は、承諾およびトークン蓄積ポリシー適用の実施形態を示す。動作200で開始すると共に動作216で終了する動作の順序として示すが、当業者であれば図示された動作は実施形態を示すように意図されたものであって、図示の動作の少なくとも一部を改変、省略、再順序付け、または並列に遂行させるようにしてもよいことを認識するであろう。
動作202で、サービスを遂行する要求が受信される。例として、要求はデータベースの問合せを含み得る。データベースの問合せの経費は、おそらくはエンドユーザに返されるデータのバイト数により測られる、問合せを行うことにより返送されるデータの量に基づいて決定され得る。
動作204は、利用可能なトークンの計数の更新を示す。実施形態では、利用可能なトークンの数は、前回の更新の時間、トークン蓄積速度、および現在の時間に基づいて調節され得る。利用可能なトークンの最大数もまた制限され得る。要求が承諾されると、現在のトークンの数からトークンが差し引かれる。しかし、種々の実施形態では現在のトークン計数が零を下回るのを許可するので、差し引きにトークンを利用し得ない場合もあり得る。動作206は、差し引きにトークンを利用可能であるかの決定を示す。いくつかの実施形態では、1トークンが要求を承諾するのに十分であるとみなされ得るが、他では、要求の処理により消費されるトークンの数、即ち容量、を推定するように試み得る。本明細書に用いる場合、十分なトークンまたは十分な容量という用語は、1トークン、固定数のトークン、要求を処理することにより利用されることになる容量の推定に基づくトークンの数等を指し得る。不十分なトークンしか利用し得ない場合、要求は動作208に示すように拒絶される。クライアントのアプリケーションおよび/または提供するサービスの顧客は、拒絶を通知され得る。
動作210は、少なくとも1トークンが利用可能であるとき、要求を承諾することを示す。動作212により示すように、利用可能なトークンの計数が1だけ差し引かれ、要求が処理され得る。要求が一旦処理されたら、利用可能なトークンの数は、動作214により示すように、要求を遂行する実際の経費に基づいて、更に下方に調節され得る。種々の実施形態では、返送されたデータの量、CPUの利用、メモリの消費、ネットワーク帯域幅の消費、等の測定基準に基づいて測定され得る。
図2により示される実施形態は、バケット中の現在のトークンの計数が零を下回るのを可能にする。負のトークン残高は、トークンバケットに応じた要求の承諾がされ得ないブラックアウト期間に対応し得る。ブラックアウト期間の長さは、現在の負のトークン計数およびトークン蓄積速度に依存し得る。例えば、トークン蓄積速度が10毎秒で、利用可能なトークンの数が−100である場合、ブラックアウト期間の長さは10秒であり得る。
保守、報告、要約等を含むもの等の、特定の種類の要求は、集約的で高経費として扱われるデータであり得る。したがって、これらの種類の要求は、長いブラックアウト期間を生じるかもしれず、その時には経費は低いが重要性が高いものを含めて、いかなる要求も作動し得ない。図3Aは、この種類の状況の例を示す。テーブル、区分、コンピューティングノード等の、特定の事業体に割り当てられた総プロビジョニングされた容量は、トークン流入308により表され得、その率でトークンバケット302にトークンが追加される。例えば、長期の保守タスク306は、比較的大量のトークン流出310を生じるデータ集約型タスクであり得る。タスクが作動される度に、トークンバケット302中の利用可能なトークンの数が負数に低減してブラックアウト期間が結果的に生じるような場合もあり得る。他方、問合せ要求304は、データ流出をほとんど要さず、比較的少量のトークン流出312を生じ得る。しかし、先に実行された保守タスクがブラックアウト期間を生じたかもしれず、問合せ要求は、それらが低経費であるにも拘わらず拒絶され得る。そのような状況を回避するのが好都合である。
図3Bは、プロビジョニングされた容量の2つの別個のトークンバケット314および316への割り振りを示す。トークン流入は、トークン流入308aおよびトークン流入308bにより示されるように、等しく割り振られる。長期の保守タスクおよび問合せを遂行する経費は一定のままであり、したがってトークン流出率310および312は不変である。本配置は、問合せ要求が、長期の保守タスクを実行することにより阻止されるのを防止する。しかし、保守タスクは求められることはほとんどない場合がある。そうであれば、長期のタスクに予蓄された容量の多くが浪費となり得る。
要求の承諾は、1つより多いバケットに基づいて、1つより多いバケットから差し引かれ得るトークンに対して、決定され得る。例えば、実施形態では、要求の種類を、高、中および低の優先度に割り振り得る。高優先度の要求は任意のバケットから、中の要求は3つのバケットのうちの2つから、低優先度の要求はただ1つのバケットから引き出され得る。同様の種類の要求の範疇は、クラスとして表現され得る。これらのクラスは、承諾ポリシーに関連付けられ得る。承諾ポリシーは、要求を承諾すべきか否かを決定するためにいずれのトークンバケットが使用されるべきであるかの表示、およびトークン要求の総経費が一旦既知になったときトークンを引き出すための技法または手法を含み得る。
図4は、要求クラスおよび承諾ポリシーに基づいて容量を割り当てるための実施形態を示す。入来要求は、クラス「A」要求400、クラス「B」要求402、およびクラス「C」要求404等の、要求クラスに属するようにされ得る。承諾ポリシーが、このように適用されて、要求を承諾または拒絶する際にいずれのバケットを介入させるか、およびこれらのバケットからどのようにトークンを差し引くかを決定し得る。
各要求クラスは、承諾ポリシーに関連付けられ得る。承諾ポリシーは、トークンの使用に関する種々の論理上および手続き上のメカニズムを含む。承諾ポリシーの一態様では、要求を承諾して処理するべきか否かの決定を含む。図4を例に用いれば、ポリシー406は、少なくとも1つのトークンがバケット「Y」414で利用可能であれば、クラス「A」要求400は承諾されるべきであることを特定し得る。第2のポリシー408は、トークンがバケット「X」412またはバケット「Y」414のいずれかに存在すれば、クラス「B」要求は承諾されるべきであることを特定し得る。クラス「C」要求404に対する第3のポリシー410は、バケット「X」412のみに基づいて要求が承諾されるべきことを示し得る。これらの例は説明的なもので、他の多くの組み合わせも可能である。
実施形態では、要求は、可変のまたは事前定義されたトークン閾値に基づいて承諾され得る。一実施例は、消費され得るトークンの予測数と等しい数のトークンをバケットが有するときのみ、要求を承諾することを含む。別の実施例は、最小数のトークンを設定するために以前の経費の移動平均を使用することを含む。多数の追加の実施形態が可能である。
承諾ポリシーはまた、いかにしてトークンが差し引かれるかの決定を含む。要求が先ず承諾されると、1以上のトークンが、承諾の基になったバケットから差し引かれ得る。しかし、要求の総経費は、要求が少なくとも部分的に処理されるまでは知られ得ない場合がある。したがって、要求が承諾された後のある時点で、第2のトークンの差し引きが起こり得る。ポリシーは、1つ以上のバケットを差し引きの対象として特定し、またバケット間の割り振りを特定し得る。
実施形態では、トークンは、承諾が決定された同一のバケットから引き出され得る。例えば、要求が図4に示すバケット「X」412中のトークンの存在に基づいて承諾された場合、全トークン経費もまたバケット「X」412から差し引かれ得る。本手法を採用する1つの理由は、さもなければ、負数の利用可能なトークンを有するバケットが更に落ち込む可能性があり、そのバケットのみに専ら依存する要求に対するブラックアウト期間を引き延ばすことになることである。
別の実施形態は、承諾を決定するのに用いられたバケットから先ず差し引きし、次いで1つ以上の後続のバケットから差し引く。例えば、要求がバケット「X」412中の利用可能なトークンに基づいて許可されたら、一旦決定された総経費の一部分がバケット「X」412から差し引かれ得、一部分がバケット「Y」414から差し引かれ得る。第1のバケット412から差し引かれる量は、利用可能なトークン計数が零等の閾値を下回るのを防止するように決定され得る。残余は、一連のバケット中の第2のバケットまたは最後のバケットから差し引かれ得、そのバケットの利用可能なトークン計数を零未満にせしめ得る。したがって、図4で、クラス「B」要求402を処理するためにこの手法を使用することは、バケット「Y」414に対して利用可能なトークン計数を負にならしめ得る。しかし、バケット「X」412に対する計数は、クラス「B」要求402により負にはならないであろう。本手法は、さもなければクラス「B」要求402を処理することにより引き起こされ得るクラス「C」要求404に対するブラックアウト期間を防止し得るので、好都合である。
図5は、承諾ポリシーを取得かつ適用するための実施形態を示す。動作500で開始して動作516で終了する動作の順序として示すが、当業者であれば図示された動作は例示であるように意図されたものであって、図示の動作の少なくとも一部を改変、省略、再順序付け、または並列に遂行させるようにしてもよいことを認識するであろう。
承諾ポリシーを適用するためのプロセスは、動作502により示すように、要求の受信を含み得る。要求が属するクラスが、次いで決定され得る。これは種々の手段を介して行われる。実施形態では、要求の呼び出しに関連付けられたAPIは、クラスを識別する1つ以上のパラメータを可能とし得る。一実施例は、要求が対応するクラスを指定するテキストパラメータを含む。しかし、数値を使用して要求クラスを識別することは、種々の性能を考慮すると、好都合である。
いくつかの実施形態では、要求はそれらの種類に基づいて分類され得る。例えば、書き込み要求は、読み出し要求とは別個に分類され得る。他の実施形態では、要求を分析して、それらの潜在的経費を決定し、また同様の経費レベルの要求を同一のクラスに割り当てる。
要求のクラスは、要求パラメータに特定されたものに加えてまたはそれらに代えて、諸要因に基づき得る。例えば、所与の顧客、識別子、またはセキュリティの役割が、要求クラスに関連付けられ得る。顧客または役割は、要求が呼び出された状況から利用可能であり得、または要求中のパラメータとして特定され得る。他の可能性のある要因には、要求のソースのインターネットプロトコルアドレス、呼び出されている特定のAPI等が含まれる。加えて、構成または他のメカニズムが、分類ルールを定義付けるために使用され得る。例えば、顧客、ウェブサービス、APIまたは他の実体に関連付けられた構成が、要求に関連付けられ得る。おそらくは構成に特定される、種々のデフォルトルール、もまた適用し得る。デフォルト値は、他の分類ルールが適用可能でないとき、適用可能である。実施形態は、デフォルト値が覆されるのを可能にする。実施形態はまた、特定のデフォルト値を、それらが覆され得ないように、固定値とすることを可能にする。
要求クラスが一旦決定されたら、動作504により示すように、対応する承諾ポリシーが受信、取得、またはさもなければアプリケーション用に準備され得る。これには、トークンを引き出し得るバケットのリスト等の、承諾ポリシーを記述したレコードへのアクセスを含む。レコードは、例えば、データベースに記憶され、符号リソース、構成ファイル等に埋め込まれ得る。いくつかの実施形態では、バケットを表す構造は、ポリシーの記述の一部であり得、換言すれば、バケットおよびポリシー定義は一体化構造を含み得る。いくつかの実施形態は、このステップを省略して、本明細書に説明された種々の技法を遂行する命令中の適合する実行パスを選択することにより適用され得る。
要求は、動作506により承諾または拒絶され得る。承諾ポリシーは、利用可能なトークンに対してチェックされることになる1つ以上のバケットを記述し得る。いくつかの実施形態では、複数のトークンまたは少なくとも閾値レベルを上回っているトークンについての基準承諾を要し得る。いくつかの実施形態では、トークン計数が負のとき、要求が許可されることを可能にし得、ポリシー記述には、下回る要求を承諾しない閾値の負値を示し得る。
動作506はまた、少なくとも1トークンを差し引くことを含む。差し引かれるトークン数は、要求が承諾されるべきか否かを決定するために使用されたトークン量と同一であり得る。このように、同一のトークンまたはトークンの組に基づいて別の要求が承諾されることになることはない。実施形態ではまた、同一のトークンまたはトークンの組に基づいて複数の要求が承諾されるのを防止するために、バケットへのアクセスを同期化させ得る。
承諾された後、要求は、動作508により示されるように処理され得る。要求の総経費は、要求の処理に少なくとも基づいて決定され得る。種々の実施形態では、サービスのクライアントに返されたデータのサイズを、使用し得る。例えば、要求がデータベースの問合せである場合、トークン経費は、問合せ実行後にクライアントに返されたデータの全サイズから導かれ得る。他の実施形態では、要求が経費決定の基礎として処理および使用される間、種々の性能測定基準を収集し得る。
種々の実施形態では、要求が一旦遂行されると、動作の経費を差し引き得る。このステップは、動作514により示すように、承諾ポリシーに従って遂行され得る。承諾ポリシーには、複数のバケットの間に分配する等の、トークン経費の差し引きや、または承諾が決定されるのに用いられたバケットからの経費の差し引きに対する種々の手法を記述し得る。種々の他のポリシーが採用され得る
いくつかの実施形態では、トークンバケットは階層的関係を有し得る。この手法は、優先順位付け方式を要求クラスとトークンバケットとの間の1対1のマッピングで規定するのを可能にするので、選択された承諾ポリシーの好都合な管理を可能にする。階層的トークンバケットは、トークンバケット間で親子の関係を、それぞれの最大トークン容量と共に特定することにより、好都合に規定され得る。図6Aは、階層的トークンバケットの例を用いた実施形態を示す。2つのトークンバケットが示されている。バケット「X」608は、「Y」610の親バケットであり、30トークンの最大容量を有する。バケット「Y」610は、親「X」608の子であり、5トークンの最大容量を有する。トークンは、バケット間で階層様式で共有され、子バケットはその親のトークンにアクセスすることができる。したがって、トークンバケット608および610の両方が最大容量であるとき、それらの間で共有される30トークンが存在する。
図6Aでは、クラス「A」要求600は、クラス「A」ポリシー604の適用に基づいてバケット「Y」610に関連付けられる。同様に、クラス「B」要求は、クラスBポリシー606に基づいてバケット「X」608に関連付けられる。承諾ポリシーは、要求クラスとバケットとの間の1対1のマッピングを含み得、これは、要求を承諾するべきか否か、およびいずれのトークンバケット、またはバケット、からトークンを差し引くかの決定に使用され得る。承諾ポリシーはまた、要求の承諾に必要な利用可能なトークンの最小数等の、追加の要素を含み得る。非階層的手法に関して本明細書に説明する種々の方法および技法が、階層的手法にも適用され得る。
要求は、要求クラスに対してマッピングされたトークンバケット中の少なくとも1つのトークンの利用可能性に基づいて承諾され得る。例えば、クラス「A」要求600は、バケット「Y」610が利用可能なトークンを有するとき、承諾され得る。同様に、クラス「B」要求602は、バケット「X」608が利用可能なトークンを有するとき、承諾され得る。いくつかの実施形態は、例えば、要求の処理の推定経費に基づいて、1より多いトークンが利用可能であることを要し得る。
承諾に要されるトークン(単数または複数)は、要求が処理のために承諾されたとき、差し引かれ得る。実施形態では、要求を承諾するとき、1を差し引かれ得る。残存経費は、一旦既知になれば、承諾を決定するのに用いられた同一のバケットから差し引かれ得る。
図6Bは、バケット「X」608から2トークンを減じる動作650を示す図である。バケット「X」608および「Y」610の差し引き前の状態が、図中要素651により示され、差し引き後の状態が要素652により示されている。トークンがバケット「X」608から差し引かれた結果、28のトークン計数となっている。「Y」610に利用可能なトークンは、不変である。
図6Cで、動作660は、バケット「Y」610から2トークンを差し引くことを示す。差し引き前の状態は、図中要素661で示されている。差し引き後の状態は、要素662により示すように、両バケット「X」608および「Y」610に利用可能なトークンが2だけ差し引かれていることを示す。この手法は、利用可能なトークンを2つのバケット間で階様式で共有することを反映する。要求が子バケット中の利用可能なトークンに基づいて承諾または処理されるとき、トークンは子バケットおよびその親の各々から差し引かれ得る。加えて、種々の実施形態では、要求が承諾されるためには、トークンは両方の子バケット中およびその親の各々中で利用可能でなければならない。図6Cで、バケット「Y」610およびその親バケット「X」608の両方が少なくとも1トークンを有するので、要求は、差し引き前の状態661に基づいて承諾され得る。他方、実施形態では、子バケット中に不十分なトークンしか存在しない場合であっても、要求を処理するためにバケット「X」608等の、親バケットを承諾する。
図6D中の動作670は、利用可能な数より多い大量のトークンをバケット「X」608から減じることを示す。差し引き前は、要素671により示すように、トークンバケット「X」608は、それに利用可能な30トークンを有する。35トークンを差し引いた後は、差し引き後状態672により示すように、その総数がマイナス5に減じられている。図6Dは、バケット「Y」610を、差し引き後にそれに利用可能な5トークンを有しているものとして示す。承諾がバケット「Y」610に依存する要求に対して、実施形態は、少なくとも1トークンが親バケット「X」608中に存在することを要し得る。したがって、これらの実施形態では、両バケット「X」608およびバケット「Y」610に利用可能なトークンの数が零を上回るまで、バケット「Y」610に依存する要求は承諾されることはないであろう。しかし、実施形態では、トークンがその親から差し引かれたときに、子バケット中のトークンの数を減少させない場合がある。実施形態では、少なくとも1トークンが子バケットの親の各々中に存在するのを依然要し得る。しかし、子のトークン計数が負になるのを防止することは、子バケットに関連付けられたサービスに対するブラックアウト期間を防止するのに役立ち得る。
諸要因によりブラックアウト期間の長さを決定させる要因には、子バケットおよびその親中のトークン計数が負である程度、および子および親バケットの再充填率が含まれる。例えば、図6Dで、バケット「Y」610に依存する要求は、少なくとも1トークンがバケット「X」608およびバケット「Y」610中両方に利用可能になるまでは、承諾され得ない。バケット「X」608がトークンで再充填される率は、したがって、バケット「Y」610に依存する要求で見られるブラックアウト期間の長さに影響を及ぼし得る。しかし、バケット「X」608は、バケット「Y」610に割り当てられるものより比例的に高い蓄積速度を割り当てられ得る。
図6Eは、バケット「Y」610から、それに利用可能であるより多いトークンを差し引く動作680を示す。差し引き前は、バケット「Y」610は、要素681に図の一部分として示すように、それに利用可能な5トークンを有する。35トークンを差し引いた後は、バケット「Y」610は、それに利用可能なマイナス30トークンを有し、一方バケット「X」608は、マイナス5トークンのままである。この状態は、要素682で示され、承諾が基いとする子バケット「Y」610から、およびその親バケット「X」608からの差し引きを反映する。
階層的トークンバケットの実施形態は、種々の技法、アルゴリズム、データ構造等を採用することができる。実施形態では、親トークンバケットに利用可能なトークンの数を追跡するために記録が使用され得る。その子に利用可能なトークン数は、その後、ルールの組、アルゴリズム等に基づいて決定され得る。例えば、子トークンバケットに利用可能なトークン数は、親トークンバケットに利用可能なトークン数、および子トークンバケットが蓄積可能なトークンの最大数に基づいて決定され得る。
トークンバケットの階層構造は、新たなトークンをグループとして蓄積し得る。図6Aに示すトークンバケットを基準点として用いると、トークン蓄積速度は、バケット「X」608および「Y」610を含む階層構造に関連付けられ得る。トークンを階層構造に追加したとき、両バケット「X」608および「Y」610に利用可能なトークン数は、それらのそれぞれの最大値まで増加し得る。
図6Fは、2つ以上の要求クラスが同等の優先度を有するバケットを共有する場合のトークンバケットの階層的配置を示す。クラス「A」要求6000はバケット「X」6010に向けられ、クラス「B」要求6002はバケット「Y」6012に向けられ得る。親バケット「P」6008は、100の総容量を有し得、80トークン毎秒の割り当てを受信するバケット「X」6010および20トークン毎秒の割り当てを受信するバケット「Y」6012に対応する。バケットの最大容量は、それらのそれぞれのトークン割り当て率と同一であり得る。
承諾ポリシーは、子バケットが同等の優先度を共有する図6Fに示す配置に対して定義付けられ得る。承諾ポリシーは、以下のように進行し得る。クラス「A」要求6000に対応する要求の着信時に、バケット「Y」6012は、トークンの利用可能性について参照され得る。少なくとも1トークンが利用可能であれば、要求は承諾され得る。バケット「Y」6012および親バケット「P」での利用可能なトークンの計数は、承諾時におよび再度要求の処理時に、各々減少され得る。バケット「Y」6012に不十分なトークンしか利用可能でない場合、親バケット「P」6008に少なくとも1トークンが存在すれば、要求は承諾され得る。トークンは、承諾時におよび再度要求の処理時に、親バケット「P」6008から差し引かれ得る。クラス「B」要求6002は、クラス「B」ポリシー6006をクラス「A」ポリシー6004と同様の仕方で定義付けるクラスにより同様に処理され得、トークン割り当て率の差異に対して調節される。
この手法は、結果として、それらのプロビジョニングされた容量にアクセスする各クラスからの要求を含むが、兄弟バケットがそれにプロビジョニングされた容量を十分に利用していなければ、追加の容量を利用し得る。例えば、クラス「A」要求6000のみが発せられた場合、最大100トークン毎秒がそれらを処理するために利用可能となる。作業負荷が混合され、クラス「A」要求6000が10トークン毎秒を消費するとすれば、クラス「B」要求6002は、最大で90トークン毎秒を消費可能になる。
承諾ポリシーの態様は、提供するプロバイダの顧客により定義付けられ得る。定義は、サービスプロバイダにより提供されるユーザインターフェースとの顧客のやりとりにより遂行され得る。例えば、ウェブページが、ユーザが、クラスおよびトークンが差し引かれ得るそれぞれのバケットを定義付けることを可能にし得る。ユーザはまた、各クラスの要求に対する最小トークン量等の、種々の追加のパラメータを設定し得る。
種々の実施形態では、入力/出力優先順位を調整するポリシーを管理するための手段を提供し得るが、これには、例えば、要求クラス、トークンバケット、承諾ポリシー等の定義付けが含まれ得る。図7Aで、ユーザインターフェース700は、ホストされたデータベーステーブルの作成中にユーザに提示されるユーザインターフェースページの順序の一部を含み得る。先行ステップ701のユーザインターフェース部品は、提供されたデータベーステーブルを定義付けるためのユーザインターフェースウィザードの以前の箇所にナビゲートするためのボタン、ハイパーリンク、または類似の要素を表し得る。テーブル作成702のユーザインターフェース要素は、ユーザがパラメータをテーブル作成プロセスに供給し終えたことおよびテーブルを作成すべきことを表示し得る。図示のユーザインターフェース要素は、そのようなインターフェースを提供する手法の一般例であることを意図するもので、本開示の範囲を限定するように解するべきではない。
ユーザインターフェース700は、1つ以上のポリシー定義704a、704b、および704cを含み得るが、これらは、要求クラスとトークンを引き出し得る1つ以上のバケットとの間の関係を示すパラメータ、および可能性として承諾ポリシーの他の種々の要素を供給するために使用され得る。例えば、ポリシー定義要素704aは、クラス表示706a、一次バケット表示708aおよび二次バケット表示710aを含み得る。クラス表示706aは、クラスを記述する種々のパラメータを含み得、これにはクラス名称および1つ以上の要求の種類が含まれ得る。いくつかの実施形態では、要求クラスおよび要求の種類は提供するサービスプロバイダにより事前定義される。クラス表示706b、一次バケット表示708b、および二次バケット表示710bを含むポリシー定義704b、およびクラス表示706c、一次バケット表示708cおよび二次バケット表示710cを含むポリシー定義704c等の、多数の追加のクラス表示が、ユーザインターフェース700に提示され得る。
一次バケット要素708aおよび二次バケット要素710aは、承諾ポリシーの一部を含むトークンバケットを、それらのそれぞれの優先度と共に示す。例えば、708aで示されるトークンバケットは、クラス表示706aにより特定されたクラスに該当する要求に対する承諾判断の適用に際して最初に参照されるであろう。二次トークンバケット710aにより特定されたトークンバケットは、2番目に参照されるであろう。ポリシー定義704a、704b、および704cは同一のトークンバケット、またはトークンバケットの重複する組を指し得る。
図7Bは、階層状トークンバケットを採用した承諾ポリシーを定義付けるユーザインターフェースの図示実施形態である。ユーザインターフェース750は、プロセス中の他のステップにナビゲートし、かつプロセスを完了すべきことを表示するための先行ステップ751およびテーブル作成752のユーザインターフェース要素を採用するテーブル定義プロセスの一部を含み得る。
ユーザインターフェース750は、1つ以上のポリシー定義754a、754b、および754cを含み得、これらは、顧客が承諾ポリシーおよび階層的トークンバケットを作成するためのパラメータを供給するのを可能にする。例えば、ポリシー定義754aは、トークンバケットの名称を示すバケット名756aのユーザインターフェース要素を含み得る。いくつかの実施形態では、これは、事前定義されたバケット名称を含むドロップボックスまたは他のユーザインターフェース要素であり得る。要求クラス760aは、コンボボックス、リストボックスまたは他のユーザインターフェース要素を含み得、これらは、要求クラスを、バケット名称756aにより示されたバケットに割り当てるのを可能にする。子トークンバケット758aのユーザインターフェース要素は、図6Aに示すバケット「Y」610等の、1つ以上の子トークンバケットを特定するために使用され得る。これは、1つ以上の子トークンバケットを選択するのを可能にする、リストボックスまたは他のユーザインターフェース要素であり得る。いくつかの実施形態では、親トークンバケットは、1つ以上の子トークンバケットに代えて特定され得る。ユーザインターフェース750は、多数の追加のポリシー定義が定義付けられるのを可能にする。例えば、ユーザインターフェース750はまた、バケット名756b、要求クラス760b、および子バケット758bを含むポリシー定義754b、ならびにバケット名756c、要求クラス760c、および子バケット758cを含むポリシー定義754cを定義付けまたは編集するためのユーザインターフェース要素を含み得る。
図7Aおよび図7Bは、両図共、図7A中の一次バケット708aおよび図7B中のバケット名756a等の、トークンバケットを特定するためのユーザインターフェース要素を提供するように示されている。しかし、ユーザインターフェース700および750は、トークンバケットおよび対応する要求クラスを直接または間接的に特定するための代替表現を使用し得る。例えば、ユーザインターフェース700は、要求クラスに関連付けられ得る高、中または低優先度の選択を提示し得る。バケット間の関係は、ユーザにより選択された優先度レベルから推定され得る。同様の手法を、ユーザインターフェース750に採用し得る。
実施形態では、図7Aおよび7Bに示したものと同様のユーザインターフェースを採用し得、顧客が、要求クラス、バケット、バケット間の関係等を引き続き編集するのを可能にする。一例では、テーブルの定義の変更を含む。顧客は、例えば、追加の列を加えることにより、データベーステーブルの定義に対して種々の修正を行い得る。修正されたテーブルは、異なる使用パターンに関連付けられ得る。したがって、顧客はまた、テーブルに割り当てられた容量、承諾ポリシー、バケットの数等の変更を特定し得る。関連する情報を供給するために、種々のユーザインターフェース要素またはAPIを使用し得る。
図7Aおよび7Bに示した例示のユーザインターフェースは、シッククライアント、n階層または他のアーキテクチャを含む、様々な技術を使用して実現され得る。実施形態では、ホスト側プロバイダのデータセンター内で動作するウェブサーバーは、ハイパーテキストマークアップ言語(「HTML」)フォームを顧客のブラウザに供する。フォームの提出時には、ホスト側プロバイダのデータセンター内のウェブサービスAPIは、顧客により供給された情報の受信および処理を行う。
図8は、関連付けられたトークンバケットおよび承諾ポリシーでデータベーステーブルを作成するためのプロセスを示すフローチャートである。動作800で開始し、動作814で終了する動作の順序として示すが、図示の動作の少なくとも一部を改変、省略、再順序付け、または並列に遂行させるようにしてもよいことが当業者により認識されるであろう。例えば、動作802〜808により示された情報は、ホスト側プロバイダデータセンターで同時に受信され得る。
動作802は、テーブル定義を示す情報の受信を示す。本開示の実施形態は、テーブル毎、または定義付けられテーブルが1つより多い区分を含む場合には区分毎に容量を割り当て得る。区分は、テーブルの細区分を含み得、その各々は1つ以上のコンピューティングノード上で動作するDBMSにより維持され得る。容量がテーブル毎または区分毎に割り当てられ得るため、承諾ポリシーおよびトークンバケットは、同様に定義付けられ得る。
動作804は、1つ以上の要求クラスを示す情報の受信を示す。これらのクラスは、例えば、図7Aおよび7Bに示すもの等のユーザインターフェースを介して、ユーザにより定義付けられ得る。他の実施形態では、ホストするプロバイダは、要求クラスを事前定義し得る。実施形態では、要求クラスは「高」、「中」、および「低」のように、ラベル付けされる。
動作806は、作成されるべきバケットを示す情報の受信を示す。いくつかの実施形態では、情報にはバケットのリスティングまたは計数を含み得、他では、情報が推定され得る。例えば、要求クラスとトークンバケットとの間の1対1の対応関係が推定され得る。実施形態では、3つのトークンバケットを形成して、「高」、「中」、および「低」要求クラスに対応させ得る。
動作808では、1つ以上の承諾ポリシーを示す情報が受信され得る。この情報は、要求クラスとバケットとの間のマッピングを含み得、承諾を決定するためにバケットを参照する順番、トークンを減じる方法等を示す情報を含み得る。情報は、動作802〜806により参照された他の情報と組み合わされ得る。その情報のある特定の側面は、推定的に決定され、または動作802〜806で受信される情報の他の側面を推定するために使用され得る。例えば、いくつかの実施形態では、バケットを参照するポリシー記述は、参照したバケットが作成されるべきことを推定するために使用され得る。
動作810では、区分化方式が決定され得る。提供されるテーブルまたは他のサービスは、複数のコンピューティングノードの間で割り振られ得る。したがって、実施形態では、いくつのおよびいずれのコンピューティングノードが関与するか、ならびにテーブルにより維持されるデータの割り振りの仕方の決定等のテーブルを区分ことの他の側面を決定し得る。テーブルを含まないサービスに対して、これは、それぞれの区分により取り扱われる作業負荷の割り振りの仕方の決定を含み得る。
区分化方式に基づいて、容量が種々の区分またはコンピューティングノードに割り当てられ得る。顧客当たりの容量は、例えば、区分間で同等に割り振られるか、または区分またはコンピューティングノードが取り扱う予期される作業負荷の量に基づいて割り振られ得る。例えば、第1の区分がテーブルの作業負荷の4分の3を扱うと予期される場合、それには容量の4分の3が割り当てられ得る。
区分への顧客当たりの容量の割り当ては、トークンの全生成量のある割合の区分への割り当てを含み得る。例えば、顧客のサービス階層に少なくとも部分的に基づいて、顧客が所与のトークン量毎秒を割り当てられるべきことが、決定され得る。先の実施例を続けると、その容量の4分の3が、一つの区分またはコンピューティングノードに割り当てられ、残余の4分の1が別の区分に割り当てられ得る。これは、動作810により示されている。
区分に割り当てられた顧客当たりの容量は、動作812により示すように、その区分に作成されるトークンバケットに細割り当てられ得る。先の実施例を続けると、総容量の4分の3が毎秒75トークンの率のトークン生成に対応するとすれば、毎秒75トークンの計数が、その区分またはコンピューティングノードに関連付けられたトークンバケットに割り当てられ得る。その区分に対して3つのトークンバケットが存在するとすれば、各々には毎秒25トークンが割り当てられ得る。
一旦決定されると、バケット当たりのトークン割り当て率は、トークンバケットを作成、初期化またはあるいは表現するために使用され得る。種々の実施形態では、バケットの作成は、最大トークン容量、現在の容量、トークン割り当て率、および前回の追加時間を含むレコード等の、種々のデータ構造の初期化を含み得る。多数の他の実施形態も可能である。例えば、いくつかの実施形態では、論理的に定義付けられたバケットとメモリに記憶されたデータ構造との間の1対1の対応関係は存在しない場合がある。
図8に示す動作はまた、更新を可能にするように適合される。例えば、動作802は、現存のテーブルの定義の変更を示す情報の受信を含み得る。加えて、要求クラス、バケットの定義および関係、承諾ポリシー、区分化方式等に関する情報は、それらの初期の定義に続いて受信され得、対応する事業体および関係がそれに応じて更新される。
図9は、本発明の態様が実施され得る分散コンピューティング環境の例を示す図である。種々のユーザ900aは、任意の種類のコンピューティングデバイス902a上で動作する種々のクライアントアプリケーションとやりとり可能であり、データセンター920内で種々のコンピューティングノード910a、910b、および910c上で実行されるプロセスと通信ネットワーク904を介して通信を行う。あるいは、クライアントアプリケーション902bは、ユーザの介入が無くても通信を行い得る。通信ネットワーク904は、インターネット、有線および無線のローカルエリアネットワーク、光ファイバネットワーク、衛星通信等を含む、任意の組み合わせの通信技術を含み得る。任意の数のネットワークプロトコルを採用し得る。
データセンター920内で動作するコンピューティングノード910a、910b、および910c上で実行されるプロセスとの通信は、ゲートウェイ906およびルータ908を介して提供され得る。多数の他のネットワーク構成もまた、採用し得る。図9には明示的に示していないが、種々の認証メカニズム、ウェブサービス層、ビジネスオブジェクトまたは他の中間層を提供して、コンピューティングノード910a、910b、および910c上で実行されるプロセスとの通信をとりなし得る。これらの中間層のいくつかは、それら自体、コンピューティングノードのうちの1つ以上で実行されるプロセスを含み得る。コンピューティングノード910a、910b、および910c、ならびにその上で実行されるプロセスはまた、ルータ908を介して互いに通信を行い得る。あるいは、別個の通信経路を採用し得る。いくつかの実施形態では、データセンター920は、追加のデータセンターと通信を行うように構成され得、コンピューティングノードおよびその上で実行されるプロセスが他のデータセンター内で動作するコンピューティングノードおよびプロセスと通信を行い得るようにする。
コンピューティングノード910aは、1つ以上のプロセッサ916、1つ以上のメモリ918、および1つ以上の記憶デバイス914を備える物理的ハードウェア上に存在するように示されている。コンピューティングノード910aでのプロセスは、オペレーティングシステムと連携して実行され得るか、またはそれに代えて、プロセッサ916、メモリ918または記憶デバイス914等の、物理的リソースと直接とやりとりをするベアメタルプロセスとして実行され得る。
コンピューティングノード910b、および910cは、物理的プロセッサ、メモリおよび記憶デバイス等の、種々の物理的リソースへの共有アクセスを提供し得る仮想マシンホスト912上で動作するように示されている。任意の数の仮想化メカニズムを採用して、コンピューティングノードを提供し得る。
図9に示す種々のコンピューティングノードは、ウェブサービス、データベース管理システム、ビジネスオブジェクト、監視および診断施設等を提供するように構成され得る。コンピューティングノードは、パーソナルコンピュータ、サーバー、クラスタ化されたコンピューティングデバイス等の、種々の種類のコンピューティングリソースを指し得る。ハードウェア形態中に実現されたとき、コンピューティングノードは概して、コンピュータ可読命令を記憶するように構成された1つ以上のメモリ、および指示を読み出してそれを実行するように構成された1つ以上のプロセッサに関連付けられる。ハードウェアに基づくコンピューティングノードはまた、1つ以上の記憶デバイス、ネットワークインターフェース、通信バス、ユーザインターフェースデバイス等を備え得る。コンピューティングノードはまた、ハイパーバイザーでまたはそれ無しに実装される仮想マシン等の、仮想化コンピューティングリソース、仮想化ベアメタル環境等を包含する。作製された仮想化に基づくコンピューティングノードは、ハードウェアリソースへの仮想化アクセス、ならびに非仮想化アクセスを有する。コンピューティングノードは、オペレーティングシステム、ならびに1つ以上のアプリケーションプログラムを実行するように構成され得る。いくつかの実施形態では、コンピューティングノードはまた、ベアメタルアプリケーションプログラムを含み得る。
これまでの部分で記載したプロセス、方法、およびアルゴリズムの各々は、1つ以上のコンピュータまたはコンピュータプロセッサにより実行される符号モジュールによって具現化され、かつそれにより完全または部分的に自動化され得る。符号モジュールは、ハードドライブ、ソリッドステートメモリ、光ディスク、および/または同様のもの等の、任意の種類の非一時的コンピュータ可読媒体またはコンピュータ記憶デバイスに記憶される。プロセスおよびアルゴリズムは、特定用途向け回路構成に部分的または全体的に実現され得る。開示したプロセスおよびプロセスステップの結果は、例えば、揮発性または非揮発性の記憶装置等の任意の種類の非一時的コンピュータ記憶装置に、永続的にまたはそれ以外で、記憶され得る。
以上記載を行った種々の特徴およびプロセスは、互いに独立に使用され得るか、または種々の方法で組み合わされ得る。全ての可能な組み合わせおよび部分組み合わせが、本開示の範囲内に収まるように意図される。加えて、ある特定の方法またはプロセスブロックが、一部の実現形態では省略され得る。本明細書に記載する方法およびプロセスはまた、何らかの特定の順序にも限定されず、それに関連するブロックまたは状態は、適切な他の順序で遂行され得る。例えば、記載したブロックまたは状態は、具体的に開示した以外の順番で遂行され得、または複数のブロックまたは状態は、単一のブロックまたは状態に組み合わされ得る。例示のブロックまたは状態は、順次に、並行して、または何らかの他の様式で遂行され得る。ブロックまたは状態は、開示した例示的施形態に追加されるかまたはそれらから除去され得る。本明細書に記載する例示のシステムまたは構成要素は、記載したものとは異なって構成され得る。例えば、要素を開示した例となる実施形態に追加し、それから除去し、またはそれに対して再配置され得る。
種々の要素が、使用される間に、メモリまたは記憶装置に記憶させるように示されること、これらの要素またはそれらの部分がメモリ管理およびデータ完全性の目的でメモリと他の記憶デバイスとの間で転送され得ることが、また認識されるであろう。あるいは、他の実施形態では、ソフトウェアモジュールおよび/またはシステムのいくつかまたは全部が、別のデバイスのメモリで実行され、コンピュータ間通信を介して図示のコンピューティングシステムと通信し得る。更に、いくつかの実施形態では、システムおよび/またはモジュールのいくつかまたは全部は、1つ以上の特定用途向け集積回路(ASIC)、標準集積回路、コントローラ(例えば、適合した指示により実行され、マイクロコントローラおよび/または埋込マイクロコントローラを含む)、フィールドプログラマブルゲートアレー(FPGA)、複合プログラマブル論理デバイス(CPLD)等、を限定されずに含む、少なくとも部分的にファームウェアおよび/またはハードウェア内に等、他の方法で実現または提供され得る。モジュール、システムおよびデータ構造のいくつかまたは全部はまた、適合した接続を介して適合したドライブにより読み出され得るハードディスク、メモリ、ネットワーク、または携帯型媒体物品等の、コンピュータ可読媒体に(例えば、ソフトウェア指示または構造化データとして)記憶され得る。システム、モジュール、およびデータ構造はまた、無線に基づく媒体および有線/ケーブルに基づく媒体を含む、種々のコンピュータ可読伝送媒体で生成データ信号(例えば、搬送波の一部もしくは他のアナログまたはデジタル伝播信号として)送信され、種々の形態(例えば、単一または多重アナログ信号として、または複数の個別デジタルパケットまたはフレームとして)を取り得る。そのようなコンピュータプログラム製品は、他の実施形態で他の形態も取り得る。したがって、本発明は、他のコンピュータシステム構成で実施してもよい。
以上の事項は、以下の付記に鑑みて更に理解され得る。
1.データベース管理システムの容量消費を優先順位付けするためのシステムであって、
データベース管理システムを動作させるように構成された1つ以上のコンピューティングノードと、
コンピュータ可読命令を上に記憶した1つ以上のメモリであって、実行時に、システムに少なくとも
要求クラスを示す情報を含み、かつ顧客に代わって遂行される動作をデータベース管理システム上で遂行させる要求を受信させ、
複数のトークンバケットを備える1つ以上のデータ構造から、関連付けられた第1の容量表示を有する第1のトークンバケットを要求クラスに少なくとも部分的に基づいて選択させ、
第1の容量表示が顧客に代わって動作を遂行するための容量を示すことを決定させ、
動作を遂行させ、かつ
動作を遂行することにより利用された容量に少なくとも部分的に基づいて第1の容量表示を更新させる、
コンピュータ可読命令を上に記憶した1つ以上のメモリと、
を備えるシステム。
2.コンピューティングデバイスによる実行時に、システムに少なくとも、
要求クラスと第1のトークンバケットとの関連付けを示す情報を受信させる、
コンピュータ可読命令を上に記憶した1つ以上のメモリを更に備える、付記1に記載のシステム。
3.コンピューティングデバイスによる実行時に、システムに少なくとも、
動作を遂行することにより利用された容量に少なくとも部分的に基づいて、複数のトークンバケットのうちの第2のトークンバケットに関連付けられた第2の容量表示を更新させる、
コンピュータ可読命令を上に記憶した1つ以上のメモリを備える、付記1に記載のシステム。
4.コンピューティングデバイスによる実行時に、システムに少なくとも、
複数のトークンバケットのうちの第2のトークンバケットに関連付けられた第2の容量表示が、顧客に代わって動作を遂行するための容量の不足を示すことを決定させる、
コンピュータ可読命令を上に記憶した1つ以上のメモリを更に備える、付記1に記載のシステム。
5.容量消費を優先順位付けするためのコンピュータ実装方法であって、
顧客に代わって遂行される動作を1つ以上のコンピューティングノード上で遂行させる要求であって、要求クラスを示す情報を含む要求、を受信することと、
複数のデータ構造から第1の容量表示を含む第1のデータ構造を、要求クラスに少なくとも部分的に基づいて、選択することと、
第1の容量表示が、顧客に代わって動作を遂行するための1つ以上のコンピューティングノードの容量を示すことを決定することと、
動作を遂行することと、
動作を遂行するのに利用された容量に少なくとも部分的に基づいて第1の容量表示を更新することと、
を含む、方法。
6.動作は、ウェブサービス、ウェブサイト、およびデータベース管理システムのうちの1つ以上で遂行される、付記5に記載の方法。
7.要求クラスを示す情報は、パラメータを含む、付記5に記載の方法。
8.要求クラスを示す情報は、構成値を含む、付記5に記載の方法。
9.顧客識別子、セキュリティ役割、およびアプリケーションプログラミングインターフェースのうちの1つ以上を更に備える、付記5に記載の方法。
10.要求クラスと第1の容量表示との間のマッピングを示す情報を受信すること、
を更に含む、付記5に記載の方法。
11.複数のデータ構造からの第2の容量表示が、顧客に代わって動作を遂行するための容量の不足を示すことを決定すること、
を更に含む、付記5に記載の方法。
12.動作を遂行するのに利用された容量に少なくとも部分的に基づいて複数のデータ構造からの第2の容量表示を更新すること、
を更に含む、付記5に記載の方法。
13.第1の容量表示および複数のデータ構造からの1つ以上の追加の容量表示は、1つ以上のメモリ場所を、顧客に代わって動作を遂行するための容量を示す複数のデータ構造中に、共有する、 付記5に記載の方法。
14.第1の容量表示は、1つ以上のコンピューティングノードの総容量のサブセットに対応する、付記5に記載の方法。
15.第1の容量表示は、顧客に代わって動作を遂行するのに利用可能な容量単位の計数を含む、付記5に記載の方法。
16.計数は、割り当てられた容量の蓄積速度に少なくとも部分的に基づいて増大される、付記15に記載の方法。
17.非一時的コンピュータ可読記憶媒体であって、コンピューティングデバイスよる実行時に、コンピューティングデバイスに少なくとも、
動作を1つ以上のコンピューティングノード上で遂行させる要求であって、要求クラスを示す情報を含む要求、を受信させ、
複数のデータ構造から第1の容量表示を含む第1のデータ構造を、要求クラスに少なくとも部分的に基づいて、選択させ、
第1の容量表示が処理のための動作を許可するのに十分な容量を示すことを決定させ
動作を遂行させ、かつ
第1の容量表示を、動作を遂行するために利用された容量に少なくとも部分的に基づいて更新させる、
命令を上に記憶した非一時的コンピュータ可読記憶媒体。
18.要求クラスを示す情報は、パラメータを含む、付記17に記載のコンピュータ可読記憶媒体。
19.コンピューティングデバイスによる実行時に、システムに少なくとも、
複数のデータ構造のうちの第2のデータ構造が、動作を遂行するための容量の不足を示すことを決定させる、
更なる命令を上に記憶した、付記17に記載のコンピュータ可読記憶媒体。
20.コンピューティングデバイスによる実行時に、システムに少なくとも、
第1の容量表示が動作を遂行するための容量の不足を示すとき複数のデータ構造からの第2の容量表示を更新させる、
更なる命令を上に記憶し、更新は、動作を遂行するために利用した容量に少なくとも部分的に基づく、付記17に記載のコンピュータ可読記憶媒体。
21.第1の容量表示は、動作を遂行するために利用可能な容量の単位の計数を含む、付記17に記載のコンピュータ可読記憶媒体。
22.計数は、割り当てられた容量の蓄積速度に少なくとも部分的に基づいて増大される、付記21に記載のコンピュータ可読記憶媒体。
23.容量消費を優先順位付けするためのシステムであって、
1つ以上のコンピューティングノードと、
コンピュータ可読命令を上に記憶した1つ以上のメモリであって、コンピューティングデバイスによる実行時に、システムに少なくとも、
1つ以上の要求クラスを示す情報を受信させ、
1つ以上の要求クラスと第1の容量表示を備えた1つ以上のデータ構造との間のマッピングを示す情報を受信させ、
1つ以上のコンピューティングノード上で動作を遂行するための総容量のサブセットを、第1の容量表示に割り当てさせ、かつ
第1の容量表示が動作を1つ以上のコンピューティングノード上で遂行するために利用可能な容量を示すことを決定したとき動作を遂行させる、
コンピュータ可読命令を上に記憶した1つ以上のメモリと、
を備える、システム。
24.コンピュータ可読命令を上に記憶した1つ以上のメモリであって、コンピューティングデバイスによる実行時に、システムに少なくとも、
顧客に代わってデータベーステーブルを作成するための指示を示す情報を受信させる
コンピュータ可読命令を上に記憶した1つ以上のメモリを更に備える、付記23に記載のシステム。
25.コンピュータ可読命令を上に記憶した1つ以上のメモリであって、コンピューティングデバイスによる実行時に、システムに少なくとも、
データベーステーブルを修正するための指示を示す情報を受信させ、かつ
データベーステーブルに割り当てられた容量を修正するための指示を示す情報を受信させる、
コンピュータ可読命令を上に記憶した1つ以上のメモリを更に備える、付記23に記載のシステム。
26.コンピュータ可読命令を上に記憶した1つ以上のメモリであって、コンピューティングデバイスによる実行時に、システムに少なくとも、
データベーステーブルの区分の数に少なくとも部分的に基づいて総容量のサブセットを決定させる
コンピュータ可読命令を上に記憶した1つ以上のメモリを更に備える、付記24に記載のシステム。
27.コンピュータ可読命令を上に記憶した1つ以上のメモリであって、コンピューティングデバイスによる実行時に、システムに少なくとも、
顧客に入力を承諾させるための命令を含むユーザインターフェース命令を送信させる、
コンピュータ可読命令を上に記憶した1つ以上のメモリを更に備える、付記23に記載のシステム。
とりわけ、「can」、「could」、「might」、「may」、「e.g.」等の、本明細書に使用する条件付言い回しは、他に具体的に述べない限り、またはさもなければ使用する前後関係内で理解されない限り、ある特定の特徴、要素および/またはステップをある特定の実施形態が含むが、他の実施形態は含まないことを伝えるように概して意図される。したがって、そのような条件付言い回しは、特徴、要素および/またはステップが、如何様にも1つ以上の実施形態に必要とされること、または1つ以上の実施形態が、これらの特徴、要素および/またはステップが含まれるのかまたは任意の特定の実施形態で遂行されるのかを判断するための論理を必然的に含むことを暗示するようには概して意図されない。「備える(comprising)」、「含む(including)」、「有する(having)」等の用語は、同義であり、制約無く包括的に使用され、追加の要素、特徴、作用、動作等を排除しない。また、「または(or)」という用語は、その包括的な意味に(かつその排他的意味にではなく)使用され、例えば、要素の一覧を接続するとき、用語「または(or)」はその一覧中の要素のうちの1つ、いくつか、または全てを意味する。
ある特定の例となる実施形態を記載したが、これらの実施形態は例として提示したのであり、本明細書に開示した発明の範囲を限定するようには意図されない。したがって、これまでの記載中に何らかの特定の特長、特性、ステップ、モジュール、またはブロックが必要または不可欠であることを暗示するように意図されるものはない。実際、本明細書に記載した新規な方法およびシステムは、様々な他の形態に具体化され得、更に、本明細書に記載した方法およびシステムの形態での種々の省略、置き換え、および変更を、本明細書に開示する本発明の趣旨から逸脱することなく行い得る。添付の特許請求の範囲およびそれらの均等物は、本明細書に記載した本発明の特定の範囲および趣旨内に収まるであろう場合、そのような形態または変形例にも及ぶように意図される。



  1. データベース管理システムの容量消費を優先順位付けするためのシステムであって、前記システムは、
    前記データベース管理システムを動作させるように構成された1つ以上のコンピューティングノードと、
    コンピュータ可読命令が記憶されている1つ以上のメモリと、
    を具え、
    前記1つ以上のメモリは、前記コンピュータ可読命令の実行時に、前記システムに、少なくとも、
    顧客に代わって遂行される動作を、前記データベース管理システム上で遂行させる要求であって、要求クラスを示す情報を含む要求を受信するステップと、
    関連付けられた第1の容量表示を有する第1のトークンバケットを、複数のトークンバケットを含む1つ以上のデータ構造から、前記要求クラスに少なくとも部分的に基づいて選択するステップと、
    前記第1の容量表示が前記顧客に代わって前記動作を遂行するための容量を示すことを決定するステップと、
    前記動作を遂行するステップと、
    前記動作を遂行するステップにより利用された容量に少なくとも部分的に基づいて前記第1の容量表示を更新するステップと、
    を行わせる、
    システム。

  2. 前記システムは、コンピュータ可読命令が記憶されている1つ以上のメモリをさらに具え、
    前記1つ以上のメモリは、前記コンピュータ可読命令がコンピューティングデバイスによって実行される時に、前記システムに、少なくとも、
    前記要求クラスと前記第1のトークンバケットとの間の関連付けを示す情報を受信するステップを行わせる、
    請求項1に記載のシステム。

  3. 前記システムは、コンピュータ可読命令が記憶されている1つ以上のメモリをさらに具え、
    前記1つ以上のメモリは、前記コンピュータ可読命令がコンピューティングデバイスによって実行される時に、前記システムに、少なくとも、
    前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて、前記複数のトークンバケットのうちの第2のトークンバケットに関連付けられた第2の容量表示を更新するステップを行わせる、
    請求項1に記載のシステム。

  4. 前記システムは、コンピュータ可読命令が記憶されている1つ以上のメモリをさらに具え、
    前記1つ以上のメモリは、前記コンピュータ可読命令がコンピューティングデバイスによって実行される時に、前記システムに、少なくとも、
    前記複数のトークンバケットのうちの第2のトークンバケットに関連付けられた第2の容量表示が、前記顧客に代わって前記動作を遂行するための容量の不足を示すことを決定するステップを行わせる、
    請求項1に記載のシステム。

  5. 容量消費を優先順位付けするためのコンピュータ実装方法であって、前記方法は、
    顧客に代わって遂行される動作を、1つ以上のコンピューティングノード上で遂行させる要求であって、要求クラスを示す情報を含む要求を受信するステップと、
    第1の容量表示を含む第1のデータ構造を、複数のデータ構造から、前記要求クラスに少なくとも部分的に基づいて選択するステップと、
    前記第1の容量表示が前記顧客に代わって前記動作を遂行するための前記1つ以上のコンピューティングノードの容量を示すことを決定するステップと、
    前記動作を遂行するステップと、
    前記動作を遂行するステップに利用された容量に少なくとも部分的に基づいて、前記第1の容量表示を更新するステップと、
    を含む、
    方法。

  6. 前記動作は、ウェブサービス、ウェブサイト、およびデータベース管理システムのうちの1つ以上で遂行される、
    請求項5に記載の方法。

  7. 前記複数のデータ構造からの第2の容量表示が、前記顧客に代わって前記動作を遂行するための容量の不足を示すことを決定するステップをさらに含む、
    請求項5に記載の方法。

  8. 前記動作を遂行するステップに利用された前記容量に少なくとも部分的に基づいて、前記複数のデータ構造からの第2の容量表示の第2の状態を更新するステップをさらに含む、
    請求項5に記載の方法。

  9. 前記複数のデータ構造からの前記第1の容量表示および1つ以上の追加の容量表示は、前記顧客に代わって前記動作を遂行するための容量を示す前記複数のデータ構造中の1つ以上のメモリ場所を共有する、
    請求項5に記載の方法。

  10. 前記第1の容量表示は、前記顧客に代わって動作を遂行するのに利用可能な容量単位の計数を含む、
    請求項5に記載の方法。

  11. 前記計数は、割り当てられた容量の蓄積速度に少なくとも部分的に基づいて増大される、
    請求項10に記載の方法。

  12. 容量消費を優先順位付けするためのシステムであって、前記システムは、
    1つ以上のコンピューティングノードと、
    コンピュータ可読命令が記憶されている1つ以上のメモリと、
    を具え、
    前記1つ以上のメモリは、前記コンピュータ可読命令の実行時に、前記システムに、少なくとも、
    1つ以上の要求クラスを示す情報を受信するステップと、
    前記1つ以上の要求クラスと第1の容量表示を含む1つ以上のデータ構造との間のマッピングを示す情報を受信するステップと、
    1つ以上のコンピューティングノード上で動作を遂行するための総容量のサブセットを、前記第1の容量表示に割り当てるステップと
    前記第1の容量表示が前記1つ以上のコンピューティングノード上で前記動作を遂行するために利用可能な容量を示すことを決定したとき、前記動作を遂行するステップと、
    を行わせる、
    システム。

  13. 前記システムは、コンピュータ可読命令が記憶されている1つ以上のメモリをさらに具え、
    前記1つ以上のメモリは、前記コンピュータ可読命令がコンピューティングデバイスによって実行される時に、前記システムに、少なくとも、
    データベーステーブルを修正する命令を示す情報を受信するステップと、
    前記データベーステーブルに割り当てられた容量を修正する命令を示す情報を受信するステップと、
    を行わせる、
    請求項12に記載のシステム。

  14. 前記システムは、コンピュータ可読命令が記憶されている1つ以上のメモリをさらに具え、
    前記1つ以上のメモリは、前記コンピュータ可読命令がコンピューティングデバイスによって実行される時に、前記システムに、少なくとも、
    前記データベーステーブルの区分の数に少なくとも部分的に基づいて、総容量の前記サブセットを決定するステップを行わせる、
    請求項13に記載のシステム。

  15. 前記システムは、コンピュータ可読命令が記憶されている1つ以上のメモリをさらに具え、
    前記1つ以上のメモリは、前記コンピュータ可読命令がコンピューティングデバイスによって実行される時に、前記システムに、少なくとも、
    前記マッピングを示す情報を含む顧客入力を承諾するための命令を含むユーザインターフェース命令を送信するステップを行わせる、
    請求項12に記載のシステム。

 

 

Patent trol of patentswamp
類似の特許
本開示のうちの少なくともいくつかの態様は、メモを管理するシステム及び方法を特徴とする。メモ管理システムは、メモソース、メモ認識モジュール、メモ抽出モジュール、及びメモラベル付けモジュールを含む。メモソースは、メモを有する場面の視覚的表現である。メモ認識モジュールは、視覚的表現を受信して、視覚的表現からメモの一般的な境界を決定するように構成される。メモ抽出モジュールは、決定された一般的な境界に基づいて、視覚的表現からメモのコンテンツを抽出するように構成される。メモラベル付けモジュールは、メモをカテゴリーでラベル付けするように構成される。
本技術の実施形態は、データサニタイゼーション及び正規化、並びにこれを適用したジオコーディング方法に関する。例示的な方法は、ジオデータセットをサニタイジングするステップと、正規化されたレーベンシュタイン距離アルゴリズムを用いて、サニタイジングされたジオデータを正規化するステップを含む。
【選択図】図1
特に視床下核(STN)等の大脳基底核の領域であるがこれらに限定されない脳領域分析の体積分割方法が開示される。これは、脳深部刺激処置で関心領域の予測の例として、大脳基底核の皮質下領域内を視覚化し局所化するように機能する。統計学的形状モデルが、高磁場、例えば、7TのMR撮像から得られた高品質トレーニングセットでの様々なモードのSTN又は対応する関心領域及びその予測子に適用される。部分最小二乗回帰(PLSR)法が適用されて、予測すべき領域、例えば、STNと、その予測子との空間関係が誘導される。本発明を検証する予測正確性は、手動でセグメント化されたSTNとその予測されたものとの形状類似性並びに位置、サイズ、及び向きの誤差を測定することによって評価される。
クライアントデバイスとコンテンツ管理システムとの間の同期のために並べられたコンテンツアイテムを自動的に優先付けすることで、共有処理を改善できる。すなわち、コンテンツアイテムへの共有リンクが生成されたか否かに基づいて、コンテンツアイテムを優先付けできる。共有リンクにより、ユーザはコンテンツ管理システムから共有コンテンツアイテムへアクセス可能となる。共有リンクを使用して共有されたコンテンツアイテムにはより高い優先度が付与され、共有されていないコンテンツアイテムよりも前に同期される。キューに入っているコンテンツアイテムは優先付けの結果として得られる同期順序にしたがって同期されうる。さらに、同期のために並べられている複数の共有コンテンツアイテムはひとつ以上のサブ優先付け基準に基づいてサブ優先付けされうる。
【選択図】図3
自動プロセスを動作させるシステムを提供する。前記システムは、データベース(106)に対して通信可能に接続された第1コンピュータ(102)を備える。前記第1コンピュータ(102)は、前記データベース(106)が格納しているデータを利用して、自動プロセスの動作に対して影響する命令を実行するように構成されている。さらに、自動プロセスを動作させる方法を提供する。前記方法は、データベース(106)に対して通信可能に接続された第1コンピュータ(102)を提供するステップ;自動プロセスを実行するように前記第1コンピュータ(102)を構成するステップ;前記データベース(106)が格納しているデータを用いて前記自動プロセスを実行するステップ、を有する。
【選択図】図1
本発明は、複数のクライアント・コンピュータ100と、第1のファイル・システムを管理し、複数のクライアント・コンピュータ100に接続されるようにするための第1のファイル・システム管理ユニット310と、第2のファイル・システムを管理し、第1のファイル・システム管理ユニット310に接続されるようにするための第2のファイル・システム管理ユニット410とを備えるデータ・ストレージ・システムにおいて第1のファイル・システムのデータ・マイグレーションを行うための、第2のファイル・システムは複数のデータ・ファイルを備え、第1のファイル・システムは複数の外部リンク・オブジェクトを備え、第1のファイル・システムの各外部リンク・オブジェクトは第2のファイル・システムのそれぞれのデータ・ファイルへのクライアント・アクセスを可能にするように第2のファイル・システムのそれぞれのデータ・ファイルに関連付けられる、方法および装置に関係する。
本発明は、複数のクライアント・コンピュータ100と第2のファイル・システムを管理し、第2のファイル・システムへのクライアント・アクセスを可能にするための第2のファイル・システム管理ユニット410とを備えるデータ・ストレージ・システムにおいて第2のファイル・システムへの間接的アクセスを可能にする仮想化されたファイル・システムを実現するための方法および装置に関するものであり、この方法は複数のクライアント・コンピュータ100と第2のファイル・システム管理ユニット410との間で第1のファイル・システム管理ユニット310を相互接続することと、第1のファイル・システム管理ユニット310によって管理される第1のファイル・システム内に第1のディレクトリ/rootを作成することと、第2のファイル・システムの第1のディレクトリ/rootを第1のファイル・システムの第1のディレクトリ/rootに関連付けることと、第1のファイル・システム管理ユニット310においてクライアント・コンピュータ100から受信されたクライアント要求に基づき、また第1のファイル・システムの第1のディレクトリと第2のファイル・システムの第1のディレクトリとの間の関連付けに基づき第1のファイル・システム管理ユニット310による第2のファイル・システムのオンデマンド仮想化を可能にすることと、第1のファイル・システムを通じて第2のファイル・システムへの間接的クライアント・アクセスを可能にすることとを含む。
本発明はアプリケーション情報の検索方法及びその装置を提供する。前記方法はクライアントから検索語を受信するステップと、前記検索語の関連アプリケーションおよび関連ページを取得するとともに、前記クライアントに前記関連アプリケーションおよび関連ページを含む検索結果を返送し、前記クライアントがローカルに前記関連アプリケーションがあると判定した場合には、前記関連アプリケーションを開くとともに、前記関連ページを表示するようにするステップとを含む。本発明実施形態のアプリケーション情報の検索方法は、検索語の関連アプリケーションおよび関連ページを取得することによって、ユーザーが望むアプリケーションおよびその関連情報をより迅速かつ便利に取得し、更に、クライアントが関連アプリケーションを開く場合には、関連ページを表示することができるため、ユーザーの時間を節約し、ユーザー体験を向上することができる。
本開示は、検索エンジンによるコメントの順位付けを実施する例示的方法及び装置を提供する。対象物に関するコメントから、対象物を説明する一以上の用語が抽出される。対象物を説明する用語に応じて、コメントに含まれる一以上の有用属性が取得される。有用属性の数に応じて、コメントの採点指標が決定される。指標に従ってコメントが採点される。得点に従ってコメントが順位付けられる。本技術は、ユーザが素早くかつ効率的に有益なコメントを見ることを可能にし、かつユーザが十分な情報を得たうえで決断することを助ける。
方法は、モバイルデバイスにおいて、モバイルデバイスからリモートデバイスに転送される第1のメディアアイテムの選択を受信することを含む。方法は、モバイルデバイスによって、第1のメディアアイテムとの第2のメディアアイテムの類似性に基づいて、リモートデバイスに転送するように第2のメディアアイテムを選択することも含む。方法は、モバイルデバイスによって、リモートデバイスに転送するようにパッケージ化されたモーメントのデータを生成することをさらに含み、ここでパッケージ化されたモーメントのデータは、第1のメディアアイテムと第2のメディアアイテムとを含む複数のメディアアイテムに関連付けられたメディアデータを含む。
To top