(57)【要約】  検索可能なデータサービスのための方法及び装置を説明する。検索可能なデータサービスは、検索可能なインデックスのデータストアに保存される存在物に関連するロケータ及び他の属性の保存を可能にするウェブサービスインターフェースにウェブサービスとして実装されてもよい。属性は｛名前、値｝の一組で示されてもよい。インターフェースは、クライアントアプリケーションが、各ロケータに関連する属性に従い、バックエンドデータストアにおける存在物のためのロケータを取り出すために、検索可能なインデックスのクエリを行うことを可能にしてもよい。検索速度は、例えばインデックス、クエリプラン、及び並行処理を使用し、自動的に最適化されてもよい。検索可能なデータサービスは、検索可能なインデックスを提供するがそれ自体がデータストアではない。検索可能なデータサービスは、データの検索及び索引と実際のデータの保存とを分離する。
2009522660.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサービスを検索可能なデータサービスに提供するように構成される、ウェブサービスプラットフォームであって、前記ウェブサービスプラットフォームは、前記ウェブサービスインターフェ−スに従い、クライアントアプリケーションからサービス要求を受信するように構成され、前記サービス要求は、クエリ要求とストレージ要求を備える、ウェブサービスプラットフォームと、
複数のノードであって、
クライアントアプリケーションによって使用されるデータストアのための検索可能なインデックスにおいて受信されたストレージ要求に指定される検索可能なデータサービスオブジェクトであって、各検索可能なデータサービスオブジェクトが、前記データストアにおける特定のエンティティの２つ以上の属性を特定し、前記属性が前記データストアに前記特定のエンティティを位置付けるための固有のエンティティ識別子を含む、検索可能なデータサービスオブジェクト、を保存するためと、
受信されたクエリ要求を満たす検索可能なインデックスから１つ以上の検索可能なデータサービスオブジェクトの組を位置付けるためと、
前記ウェブサービスインターフェースに従い、少なくとも前記エンティティ識別子を、前記クエリ要求を満たす１つ以上の検索可能なデータサービスオブジェクトの前記数組から、前記クライアントアプリケーションへ返すため、
に、前記検索可能なデータサービスに関与するように構成される、複数のノードと
を備える、システム。
【請求項２】
前記各属性は、｛名前、値｝の一対として明示される、請求項１に記載のシステム。
【請求項３】
前記複数のノードは、前記検索可能なインデックスを持続的に保存するように構成される１つ以上のストレージノードを備える、請求項１に記載のシステム。
【請求項４】
前記複数のノードは、前回のクエリ要求への応答に対するローカルクエリキャッシュを維持するようにそれぞれ構成される、１つ以上のクエリノードを備える、請求項１に記載のシステム。
【請求項５】
前記複数のノードは、
前記検索可能なインデックスを持続的に保存するように構成される１つ以上のストレージノードと、
前回のクエリ要求への応答のローカルクエリキャッシュを維持するようにそれぞれ構成される１つ以上のクエリノードと、
１つ以上のコーディネータノードであって、それぞれが、
前記ウェブェブサービスプラットフォームからのサービス要求を受信し、
各ストレージ要求を適切な１つ以上の前記ストレージノードに転送し、
各クエリ要求を適切な１つ以上の前記クエリノード転送するように構成される、１つ以上のコーディネータと
を備える、請求項１に記載のシステム。
【請求項６】
前記１つ以上のストレージノードのそれぞれは、
コーディネータノードからストレージ要求を受信し、
前記ストレージ要求に指定された検索可能なデータサービスオブジェクトを前記検索可能なインデックスに加える
ように構成される、請求項５に記載のシステム。
【請求項７】
前記１つ以上のストレージノードのそれぞれは、
コーディネータノードからストレージ要求を受信し、
前記ストレージ要求に指定されるような前記検索可能なインデックスに保存される検索可能なデータサービスオブジェクトを修正する
ように構成される、請求項５に記載のシステム。
【請求項８】
前記１つ以上のストレージノードのそれぞれは、
コーディネータノードからストレージ要求を受信し、
前記ストレージ要求に指定されるような前記検索可能なインデックスから検索可能なデータサービスオブジェクトのうちの少なくとも一部を削除する
ように構成される、請求項５に記載のシステム。
【請求項９】
前記クエリノードのそれぞれは、
コーディネータノードからクエリ要求を受信し、
前記ローカルクエリキャッシュから前記クエリ要求を満たすことが出来るかどうかを判断するために、前記クエリノード上の前記ローカルクエリキャッシュにアクセスし、
前記ローカルクエリキャッシュから前記クエリ要求を満たすことができる場合には、前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションに、前記クエリ要求を満たす前記ローカルクエリキャッシュからの１つ以上の検索可能なデータサービスオブジェクトの一組から少なくとも識別子を返し、
前記ローカルクエリキャッシュから前記クエリ要求が満たされない場合には、前記クエリ要求を適切な１つ以上の前記ストレージノードに転送する
ように構成される、請求項５に記載のシステム。
【請求項１０】
前記１つ以上のストレージノードのそれぞれは、
クエリノードからクエリ要求を受信し、
前記クエリ要求を満たす前記検索可能なインデックスに、１つ以上の検索可能なデータサービスオブジェクトの１組を位置付けるために、前記ストレージノードによって持続的に保存される前記検索可能なインデックスのパーティションを検索し、
前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションに前記クエリ要求を満たす１つ以上の検索可能なデータサービスオブジェクトの前記組から少なくとも前記エンティティ識別子を返す
ように構成される、請求項９に記載のシステム。
【請求項１１】
前記クエリノードのそれぞれは、
コーディネータノードからクエリ要求を受信し、
前記検索可能なインデックスの異なるパーティションであって、前記クエリ要求の範囲内にある、前記検索可能なインデックスの異なるパーティションを、それぞれ持続的に保存する、２つ以上の前記ストレージノードに前記クエリ要求を転送し、
前記クエリ要求が転送された前記２つ以上のストレージノードのそれぞれからの前記クエリ要求を満たす前記検索可能なインデックスから、検索可能なデータサービスオブジェクトの異なる１組を受信し、
検索可能なデータサービスオブジェクトの前記異なる数組をマージし、
前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションに検索可能なデータサービスオブジェクトの前記マージされた組から少なくとも前記エンティティ識別子を返す
ように構成される、請求項５に記載のシステム。
【請求項１２】
前記クエリノードのそれぞれは、
コーディネータノードからクエリ要求を受信し、
１つ以上の前記ストレージノードに前記クエリ要求を転送し、
前記クエリ要求が転送された１つ以上のストレージノードのうちの少なくとも１つからの前記クエリ要求を満たす前記検索可能なインデックスから検索可能なデータサービスオブジェクトを受信し、
前記クエリ要求におけるソート仕様に従い、前記受信した検索可能なデータサービスオブジェクトをソートし、
前記ウェブサービスインターフェースとソートされた順序に従い、前記ソートされた検索可能なデータサービスオブジェクトから前記クライアントアプリケーションに少なくとも前記エンティティ識別子を返す
ように構成される、請求項５に記載のシステム。
【請求項１３】
前記複数のノードは２つ以上のストレージノードを備え、それぞれが
前記検索可能なインデックスのパーティションを持続的に保存し、
２つ以上の新しいパーティションであって、それぞれが、前記検索可能なインデックスに保存された前記検索可能なデータサービスオブジェクトの異なるサブセットを含む、２つ以上の新しいパーティションを前記ストレージノード上に生成するために前記パーティションを再区分し、
前記２つ以上の新しいパーティションのうちの１つを自ら受信する別のストレージノードを位置付けるために、前記ストレージノードのその他と通信し、
前記２つ以上の新しいパーティションのうちの１つを、前記他のストレージノードに移動するために、前記他のストレージノードと協力する
ように、構成される、請求項１に記載のシステム。
【請求項１４】
前記複数のノードは、２つ以上のストレージノードを備え、それぞれが、
前記検索可能なインデックスのパーティションを持続的に保存し、
前記パーティションの複製を自ら受信する別のストレージノードを位置付けるために、前記ストレージノードの１つ以上の他と通信し、
前記他のストレージノードに前記パーティションを複製するために、前記他のストレージノードと協力する
ように構成される、請求項１に記載のシステム。
【請求項１５】
前記複数のノードが２つ以上のストレージノードを備え、それぞれが
前記検索可能なインデックスのパーティションを持続的に保存し、
アンチエントロピープロトコルに従い、前記パーティションを別のストレージノードに複製し、
前記他のストレージノードに前記パーティションの前記複製を更新するための、ゴシッププロトコルに従い、前記他のストレージノードに前記複製されたアプリケーションに対する次のストレージ要求を通信する
ように構成される、請求項１に記載のシステム。
【請求項１６】
前記ウェブサービスインターフェースは、前記検索可能なデータサービスの操作を行うための複数のサービス要求を、前記検索可能なデータサービスのクライアントアプリケーションに公開し、前記サービス要求は、
特定された検索可能なインデックスに特定された検索可能なデータサービスオブジェクトを加えるための追加要求と、
特定された検索可能なインデックスに特定された検索可能なデータサービスオブジェクトの特定された一部又はすべてを置換するための置換要求と、
特定された検索可能なインデックスから少なくとも特定された検索可能なデータサービスオブジェクトの一部を削除するための削除要求と、
特定された検索可能なインデックスに１つ以上の特定された検索可能なデータサービスオブジェクトのための属性のリストを返すためのリスト属性要求と、
前記クエリ要求において特定されたクエリ式と一致する特定された検索可能なインデックスに検索可能なデータサービスオブジェクトのエンティティ識別子の１組を返すためのクエリ要求と
を含む、請求項１に記載のシステム。
【請求項１７】
前記ウェブサービスインターフェースは、前記検索可能なデータサービスの操作を行うための複数のサービス要求を、前記検索可能なデータサービスのクライアントアプリケーションの開発者に公開し、前記公開された複数のサービス要求は、前記クライアントアプリケーションに対するデータストアへのフロントエンド検索の実行に使用するために構成される、請求項１に記載のシステム。
【請求項１８】
各クエリ要求は、
前記検索可能なデータサービスにおける特定の検索可能なインデックスを識別するバケット識別子であって、バケットが前記検索可能なデータサービスにするクエリ要求の範囲を確定する、バケット識別子と、
前記クエリ式を満たす検索可能なデータサービスオブジェクトを位置付けるために、前記バケット識別子によって識別される前記検索可能なインデックスの特定された属性に適応される１つ以上の検索基準を特定する、クエリ式と
を含む、請求項１に記載のシステム。
【請求項１９】
各クエリ要求は、前記検索可能なデータサービスに対し、特定の加入者を個別に識別する加入者識別子をさらに含み、各加入者識別子が前記検索可能なデータサービスの１つ以上のバケット識別子と関連し、各バケット識別子が正確に１人の加入者と関連する、請求項１８に記載のシステム。
【請求項２０】
クエリ式は、
前記検索可能なインデックスの検索可能なデータサービスオブジェクトの１つ以上の属性と、
前記検索可能なインデックスの前記クエリ式を満たす検索可能なデータサービスオブジェクトの１組を位置付けるために、前記クエリ式の前記１つ以上の属性に適応される１つ以上の演算子と
を含む、請求項１８に記載のシステム。
【請求項２１】
前記演算子は１つ以上のブーリアン演算子を含む、請求項２０に記載のシステム。
【請求項２２】
前記演算子は１つ以上の算術演算子を含む、請求項２０に記載のシステム。
【請求項２３】
前記演算子は１つ以上の文字列比較演算子を含む、請求項２０に記載のシステム。
【請求項２４】
前記複数のノードは、
前記クエリ要求を満たすエンティティ識別子の２つ以上のページを生成するための前記クエリ要求を満たす１つ以上の検索可能なデータサービスオブジェクトの前記１組から前記エンティティ識別子のリストにページ番号を付け、
各応答メッセージがエンティティ識別子の前記ページの１つを含む、２つ以上の応答メッセージにおいて前記クライアントアプリケーションにエンティティ識別子の前記２つ以上のページを返す
ようにさらに構成される、請求項１に記載のシステム。
【請求項２５】
前記複数のノードは、２つ以上のデータセンタの間で分散される、請求項１に記載のシステム。
【請求項２６】
前記データセンタは地理的に分散している、請求項２５に記載のシステム。
【請求項２７】
各データセンタは、前記複数のノードから、
前記検索可能なインデックスの少なくとも一部を持続的に保存するように構成される、１つ以上のストレージノードと、
前回のクエリ要求への応答のローカルクエリキャッシュを維持するようにそれぞれ構成される、１つ以上のクエリノードと、
前記ウェブサービスプラットフォームからサービス要求を受信し、
各ストレージ要求を、前記データセンタの適切な１つ以上の前記ストレージノードに転送し、
各クエリ要求を、前記データセンタの適切な１つ以上の前記クエリノードに転送する
ように構成される、少なくとも１つのコーディネータノードと、
を含む、請求項２５に記載のシステム。
【請求項２８】
前記複数のノードは複数のストレージを備え、前記複数のストレージノードは２つ以上のデータセンタ間で分散され、各データセンタは２つ以上の前記複数のストレージノードを備え、
前記データセンタにおいて前記ストレージノードの少なくとも２つが前記検索可能なインデックスのパーティションの複製を持続的に保存し、
少なくとも１つの他のデータセンタにおいて少なくとも２つの他のストレージノードが前記検索可能なインデックスの前記パーティションの複製を持続的に保存する、請求項１に記載のシステム。
【請求項２９】
前記複数のノードのそれぞれは、ゴシッププロトコルに従い前記複数のノードのその他に検索可能なデータサービス情報を伝播するように構成される、請求項１に記載のシステム。
【請求項３０】
前記伝播された検索可能なデータサービス情報は、前記複数のノードの２つ以上に対して複製された前記検索可能なインデックスのパーティションの更新情報を含む、請求項２９に記載のシステム。
【請求項３１】
前記伝播された検索可能なデータサービス情報は、前記複数のノードのそれぞれのためのローカルヘルス情報及びローカル状態情報を含む、請求項２９に記載のシステム。
【請求項３２】
前記複数のノードは、前記複数のノードのサブセットをそれぞれ含むノードの群に体系づけられるように構成され、それぞれの群のノードは、前記ゴシッププロトコルに従い、前記グループ内で検索可能なデータサービス情報を伝播するように構成される、請求項２９に記載のシステム。
【請求項３３】
前記ウェブサービスプラットフォームは、計測、請求、認証、及び前記検索可能なデータサービスへの加入者のアクセス制御を行う１つ以上のサービスをさらに備え、加入者は、前記クライアントアプリケーションによって使用される１つ以上のデータストアへの検索フロントエンドとして、前記ウェブサービスインターフェースを介して前記検索可能なデータサービスにアクセスするようにそれぞれ構成される、１つ以上のクライアントアプリケーションと関連するエンティティである、請求項１に記載のシステム。
【請求項３４】
前記ウェブサービスプラットフォームは、前記検索可能なデータサービスへの前記ウェブサービスインターフェースに従い、複数のクライアントアプリケーションからサービス要求を受信するようにさらに構成される、請求項１に記載のシステム。
【請求項３５】
前記複数のノードは、複数のクライアントアプリケーションの１つ以上によって使用される別個かつ相異なるデータストアのための検索可能なデータサービスオブジェクトを保存するようにそれぞれ構成される、複数の検索可能なインデックスを保存するようにさらに構成される、請求項１に記載のシステム。
【請求項３６】
前記検索可能なデータサービスに関与するように構成される前記複数のノードのうちの少なくとも２つは、異種機器上に実装される、請求項１に記載のシステム。
【請求項３７】
ウェブサービスインターフェースのクライアントアプリケーションから検索可能なデータサービスへのサービス要求を受信するステップであって、前記サービス要求がクエリ要求及びストレージ要求を備える、ステップと、
前記ウェブサービスインターフェースから、前記検索可能なデータサービスに関与するように構成される複数のノードのうちの１へ、各サービス要求を転送するステップと、
前記クライアントアプリケーションによって使用されるデータストアのための検索可能なインデックス内の前記トレージ要求において指定された検索可能なデータサービスオブジェクトを保存するための、前記複数のノード上で受信したストレージ要求を処理するステップであって、各検索可能なデータサービスオブジェクトは、前記データストアにおける特定のエンティティの２つ以上の属性を特定し、前記属性は前記データストアにおける前記特定のエンティティを位置付けるための固有のエンティティ識別子を含む、ステップと、
クエリ要求を満たす前記検索可能なインデックスから１つ以上の検索可能なサービスオブェクトの１組を位置付けるために、前記複数のノード上の各受信した前記クエリ要求を処理するステップと、
前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションへの前記クエリ要求を満たす１つ以上の検索可能なデータサービスオブジェクトの前記１組から、少なくとも前記エンティティ識別子をかえすステップと
を備える、方法。
【請求項３８】
各属性は｛名前、値｝の対として明示される、請求項３７に記載の方法。
【請求項３９】
前記複数のノードは、前記検索可能なインデックスを持続的に保存するように構成される１つ以上のストレージノードを備える、請求項３７に記載の方法。
【請求項４０】
前記複数のノードが、前回のクエリ要求への応答のローカルクエリキャッシュを維持するようにそれぞれ構成される、１つ以上のクエリノードを備える、請求項３７に記載の方法。
【請求項４１】
前記複数のノードは、
前記検索可能なインデックスを持続的に保存するように構成される１つ以上のストレージノードと、
前回のクエリ要求への応答のローカルクエリキャッシュを維持するようにそれぞれが構成される１つ以上のクエリノードと、
前記複数のノードのその他に対してサービス要求を送るように構成される１つ以上のコーディネータノードと
を備える、請求項３７に記載の方法。
【請求項４２】
コーディネータノード上の前記ウェブサービスインターフェースから前記サービス要求を受信するステップと、
各ストレージ要求を、前記コーディネータノードから適切な１つ以上の前記ストレージのストレージノードに転送するステップと、
各クエリ要求を、前記コーディネータノードから適切な１つ以上の前記クエリノードに転送するステップと
をさらに備える、請求項４１に記載の方法。
【請求項４３】
ストレージ要求を、ストレージノード上の前記コーディネータから受信するステップと、
前記ストレージ要求に特定された検索可能なデータサービスオブジェクトを、前記ストレージノード上の前記検索可能なインデックスへ追加するステップと
を、さらに備える、請求項４２に記載の方法。
【請求項４４】
ストレージノード上の前記コーディネータから、ストレージ要求を受信するステップと、
前記ストレージ要求に特定されたように、前記ストレージノード上の、前記検索可能なインデックスに保存された、検索可能なデータサービスオブジェクトを改変するステップと
を、さらに備える、請求項４２に記載の方法。
【請求項４５】
ストレージノード上の前記コーディネータからストレージ要求を受信するステップと、
前記ストレージ要求に特定されたように、前記検索可能なインデックスから、検索可能なデータサービスオブジェクトの少なくとも一部を削除するステップと
を、さらに備える、請求項４２に記載の方法。
【請求項４６】
クエリノード上の前記コーディネータノードからクエリ要求を受信するステップと、
前記クエリ要求が前記ローカルクエリキャッシュから満たされることができるかどうかを判断するために、前記クエリノード上のローカルクエリキャッシュにアクセスするステップと、
前記クエリ要求が前記ローカルクエリキャッシュから満たされることができる場合には、前記ウェブサービスインターフェースに従い、前記クエリノードから、前記クライアントアプリケーションへの前記クエリ要求を満たす、前記ローカルクエリキャッシュからの、１つ以上の検索可能なデータサービスオブジェクトの１組から、すくなくとも前記エンティティ識別子を返すステップと、
前記クエリ要求が前記ローカルクエリキャッシュから満たされることができない場合には、前記クエリノードから適切な１つ以上の前記ストレージノードへ前記クエリ要求を転送するステップと
を、さらに備える、請求項４２に記載の方法。
【請求項４７】
ストレージノード上で前記クエリノードからクエリ要求を受信するステップと、
前記クエリ要求を満たす前記検索可能なインデックスに、１つ以上の検索可能なデータサービスオブジェクトの１組を位置付けるために、前記ストレージノードによって持続的に保存される、前記検索可能なインデックスのパーティションを検索するステップと、
前記ウェブサービスインターフェースに従い、前記クエリ要求を満たす、１つ以上の検索可能なデータサービスオブジェクトの前記組から、前記クライアントアプリケーションへ、少なくとも前記エンティティ識別子をかえすステップと
を、さらに備える、請求項４６に記載の方法。
【請求項４８】
クエリノード上でコーディネータノードからクエリ要求を受信するステップと、
前記クエリ要求を、前記クエリ要求からの前記検索可能なインデックスの、異なるパーティションをそれぞれ持続的に保存する、２つ以上の前記ストレージノードへ転送するステップであって、前記異なるパーティションが、前記クエリ要求の範囲内であるステップと、
前記クエリノード上で、前記クエリ要求が転送された２つ以上のストレージノードのそれぞれからの前記クエリ要求を満たす、前記検索可能なインデックスからの検索可能なデータサービスオブェクトの異なる１組を受信するステップと、
前記クエリノード上で、検索可能なデータサービスオブジェクトの前記異なる数組をマージするステップと、
前記ウェブサービスインターフェースに従い、検索可能なデータサービスオブジェクトの前記マージされた１組から、前記クライアントアプリケーションへ、少なくとも前記エンティティ識別子を返すステップと
を、さらに備える、請求項４２に記載のシステム。
【請求項４９】
ストレージノード上でコーディネータノードからのクエリ要求を受信するステップと、
前記クエリ要求を、１つ以上の前記ストレージノードへ転送するステップと、
前記クエリノード上で、前記クエリ要求が転送された、前記１つ以上のストレージノードの少なくとも１つからの前記クエリ要求を満たす、前記検索可能なインデックスから検索可能なデータサービスオブジェクトを受信するステップと、
前記クエリ要求のソート仕様に従い、前記受信された検索可能なデータサービスオブジェクトをソートするステップと、
前記ウェブサービスインターフェースと、ソートされた順序に従い、前記ソートされた検索可能なデータサービスオブジェクトから、前記クライアントアプリケーションへ、少なくとも前記エンティティ識別子を返すステップと
を、さらに備える、請求項４２に記載の方法。
【請求項５０】
前記複数のノードは、２つ以上のストレージノードを備え、
前記ストレージノードに、２つ以上の新しいパーティションを生成するために、前記ストレージノードの１つによって持続的に保存された、前記検索可能なインデックスのパーティションを再区分するステップであって、前記２つ以上の新しいパーティションのそれぞれは、前記検索可能なインデックスに保存された、前記検索可能なデータサービスオブジェクトの異なるサブセットを含む、ステップと、
２つ以上の新しいパーティションのうちの１つを自ら受信する、別のストレージノードを位置付けるために、前記ストレージノードと、前記ストレージノードの１つ以上のその他との間で通信するステップと、
前記ストレージノードから、前記他のストレージノードへ、前記２つ以上の新しいパーティションのうちの１つを移動するために、前記ストレージノードと、前記他のストレージノードとの間で、共同操作を行うステップと
を、さらに備える、請求項３７に記載の方法。
【請求項５１】
前記複数のノードは、２つ以上のストレージノードを備え、
前記ストレージノードの１つによって、持続的に保存される前記検索可能なインデックスのパーティションの複製を自ら受信するボランティアストレージノードを位置付けるために、前記ストレージノード間で通信するステップと、
前記パーティションを、前記他のストレージノードに複製するために、前記ストレージノードと前記ボランティアストレージノードとの間で共同操作を行うステップと
を、さらに備える、請求項３７に記載の方法。
【請求項５２】
前記複数のノードは、２つ以上のストレージノードを備え、
アンチエントロピープロトコルに従い、前記ストレージノードによって前記他のストレージノードへ持続的に保存された前記検索可能なインデックスのパーティションを複製するために、前記ストレージノードと、前記ストレージノードの別の１つとの間で共同操作を行うステップと、
前記他のストレージノード上の前記パーティションの前記複製を更新するために、ゴシッププロトコルに従い、前記ストレージノードから、前記他のストレージノードへ、前記複製されたパーティションのための、次のストレージ要求を通信するステップと
を、さらに備える、請求項３７に記載の方法。
【請求項５３】
前記検索可能なデータサービスの操作を行うための複数のサービス要求を、前記ウェブサービスインターフェースを介し、前記検索可能なデータサービスのクライアントアプリケーションへ公開するステップをさらに備え、
前記サービスインターフェースを介して公開された前記サービス要求は、
特定された検索可能なインデックスに対する特定された検索可能なデータサービスオブジェクトを加えるための追加要求と、
特定された検索可能なインデックスの特定された検索可能なデータサービスオブジェクトの特定された一部、又はすべてを置換するための置換要求と、
特定された検索可能なインデックスからの特定された検索可能なデータサービスオブジェクトの少なくとも一部を削除するための、削除要求と、
特定された検索可能なインデックスの１つ以上の特定された検索可能なデータサービスオブジェクトのための、属性のリストを返すためのリスト属性要求と、
前記クエリ要求において、特定されたクエリ式と一致する、特定された検索可能なインデックスの検索可能なデータサービスオブジェクトのエンティティ識別子の１組を返すためのクエリ要求と
を含む、請求項３７に記載の方法。
【請求項５４】
前記ウェブインターフェースを介し、前記検索可能なデータサービスのクライアントアプリケーションの開発者に、前記検索データサービスの操作を行うための複数のサービス要求を公開するステップをさらに備え、前記公開された複数のサービス要求は、前記クライアントアプリケーションのためのデータストアへのフロントエンドの検索の実行に使用するために構成される、請求項３７に記載の方法。
【請求項５５】
各クエリ要求は、
前記検索可能なデータサービスの特定の検索可能なインデックスを識別する、バケット識別子であって、バケットは、クエリ要求の範囲を、前記検索可能なデータサービスに画定する、バケット識別子と、
前記クエリ式を満たす、検索可能なデータサービスオブジェクトを位置付けるために、適応される１つ以上の検索基準を、前記バケット識別子によって識別された、前記検索可能なインデックスの特定された属性に特定するクエリ式と
を含む、請求項３７に記載の方法。
【請求項５６】
各クエリ要求は、前記検索可能なデータサービスに対する、特定の加入者を個別に識別する加入者識別子をさらに含み、各加入者識別子は、前記検索可能なデータサービスの１つ以上のバケット識別子と関連し、各バケット識別子は、正確に1人の加入者と関連する、請求項５５に記載の方法。
【請求項５７】
クエリ式は、
前記検索可能なインデックスの検索可能なデータサービスオブジェクトの１つ以上の属性と、
前記検索可能なインデックスの前記クエリ式を満たす検索可能なデータサービスオブジェクトの１組を位置付けるために、前記クエリ式の１つ以上の属性に適応される、１つ以上の演算子と
を含む、請求項５５に記載の方法。
【請求項５８】
前記演算子が１つ以上のブーリアン演算子を含む、請求項５７に記載の方法。
【請求項５９】
前記演算子は、１つ以上の算術演算子を含む、請求項５７に記載の方法。
【請求項６０】
前記演算子は、１つ以上の文字列比較演算子を含む、請求項５７に記載の方法。
【請求項６１】
前記クエリ要求を満たすエンティティ識別子の２つ以上のページを生成するための前記クエリ要求を満たす、１つ以上の検索可能なデータサービスオブジェクトの１組から、前記エンティティ識別子のリストにページ番号を付けるステップと、
２つ以上の応答メッセージでエンティティ識別子の前記２つ以上のページを、前記クライアントアプリケーションへ返すステップであって、各応答メッセージは、エンティティ識別子の前記ページの１つを含む、ステップと
を、さらに備える、請求項３７に記載の方法。
【請求項６２】
前記複数のノードが２つ以上のデータセンタ間で分散される、請求項３７に記載の方法。
【請求項６３】
前記データセンタは地理的に分散される、請求項６２に記載の方法。
【請求項６４】
各データセンタが、前記複数のノードから、
前記検索可能なインデックスの少なくとも１部を持続的に保存するように構成される１つ以上のストレージノードと、
前回のクエリ要求に対する応答のローカルクエリキャッシュを持続するようにそれぞれ構成される１つ以上のクエリノードと、
少なくとも１つのコーディネータノードと、
を、含み、
前記ウェブサービスインターフェースからのサービス要求を、データセンタのコーディネータノードで受信するステップと、
各ストレージ要求を、前記コーディネータノードから前記データセンタの適切な１つ以上のストレージのストレージノードへ転送するステップと、
各ストレージ要求を、前記コーディネータノードから前記データセンタの適切な１つ以上の前記クエリノードへ転送するステップと
を、さらに備える、請求項６２に記載の方法。
【請求項６５】
前記複数のノードは、複数のストレージノードを備え、前記複数のストレージノードは２つ以上のデータセンタの間で分散され、各データセンタは、前記複数のストレージノードの２つ以上を備え、
データセンタの前記ストレージノードの少なくとも２つは、前記検索可能なインデックスのパーティションの複製を持続的に保存し、
少なくとも1つの他のデータセンタの少なくとも２つのその他のストレージノードは、前記検索可能なインデックスの前記パーティションの複製を持続的に保存する、
請求項３７に記載の方法。
【請求項６６】
ゴシッププロトコルに従い、前記複数のノードのそれぞれから、前記複数のノードのその他へ、少なくともいくらかの検索可能なデータサービス情報を伝播するステップをさらに備える、請求項３７に記載の方法。
【請求項６７】
前記伝播された検索可能なデータサービス情報は、前記複数のノードの２つ以上に複製された前記検索可能なインデックスのパーティションのための更新情報を含む、請求項６６に記載の方法。
【請求項６８】
前記伝播された検索可能なデータサービス情報は、前記複数のノードのそれぞれのためのローカルヘルス情報及び状態情報を含む、請求項６６に記載の方法。
【請求項６９】
前記複数のノードを、前記複数のノードのサブセットをそれぞれ含むノードの群に体系化するステップと、
前記ゴシッププロトコルに従い、ノードの各群内で検索可能なサービス情報を伝播するステップと
をさらに備える、請求項６６に記載の方法。
【請求項７０】
前記ウェブサービスインターフェースは、ウェブサービスプラットフォームによって提供され、前記ウェブサービスプラットフォームは、計測、請求、認証、及び前記検索可能なデータサービスに対する加入者のアクセス制御を行う、１つ以上のサービスをさらに備え、加入者は、前記クライアントアプリケーションによって使用される、１つ以上のデータに対する検索フロントエンドとして、前記ウェブサービスインターフェースを介して前記検索可能なデータサービスにアクセスするようにそれぞれ構成される、１つ以上のクライアントアプリケーションと関連するエンティティである、請求項３７に記載の方法。
【請求項７１】
複数のクライアントアプリケーションからのサービス要求を、前記ウェブサービスインターフェース上で受信するステップを備える、請求項３７に記載の方法。
【請求項７２】
複数のクライアントアプリケーションのうちの１つ以上によって使用される、別個の相異なるデータストアのための検索可能なデータサービスオブジェクトを保存するようにそれぞれ構成される、複数の検索可能なインデックスを、前記複数のノードに保存するステップをさらに備える、請求項３７に記載の方法。
【請求項７３】
プログラム命令を備えるコンピュータアクセス可能なストレージ媒体であって、前記プログラム命令は、複数のノード上で検索可能なデータサービスを実装するように構成され、前記検索可能なデータサービスは、
クライアントアプリケーションから、ウェブサービスプラットフォームを介し、クエリ要求及びストレージ要求を含む、ウェブサービス要求を前記検索可能なデータサービスに提供するように構成される、サービス要求を受信し、
前記クライアントアプリケーションによって使用されるデータストアのための、検索可能なインデックスの前記ストレージ要求に特定された、検索可能なデータサービスオブジェクトを保存するために、各検索可能なデータサービスオブジェクトは、前記データストアの特定のエンティティの２つ以上の属性を特定し、前記属性は、前記データストアの前記特定のエンティティを位置付けるための個別のエンティティ識別子を含む、前記複数のノードで受信されたストレージ要求を処理し、
前記複数のノードで受信されたクエリ要求であって、各受信されたクエリ要求は、前記クエリ要求を満たす、前記検索可能なインデックスから、1つ以上の検索可能なデータサービスオブジェクトの1組を位置付けるために処理される、クエリ要求を処理し、
前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションに対する前記クエリ要求を満たす、１つ以上の検索可能なデータサービスオブジェクトの前記組から、少なくとも前記エンティティ識別子を返す
ように構成される、コンピュータアクセス可能なストレージ媒体。
【請求項７４】
各属性は、｛名前、値｝の対として明示される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項７５】
前記複数のノードは、前記検索可能なインデックスを持続的に保存するように構成される、１つ以上のストレージノードを備える、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項７６】
前記複数のノードは、前回のクエリ要求への応答のローカルクエリキャッシュを維持するようにそれぞれ構成される、１つ以上のクエリノードを備える、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項７７】
前記プログラム命令は、
前記検索可能なインデックスを持続的に保存するように構成される１つ以上のストレージノードと、
前回のクエリ要求への応答のローカルクエリキャッシュを維持するようにそれぞれ構成される１つ以上のクエリノードと、
１つ以上のコーディネータノードであって、それぞれが、
前記ウェブサービスプラットフォームからのサービス要求を受信し、
各ストレージ要求を、前記ストレージノードの適切な１つ以上へ転送し、
各クエリ要求を、前記クエリノードの適切な１つ以上に転送する、
ように構成される、１つ以上のコーディネータノードと、
として、前記複数のノード上で前記検索可能なデータサービスを実装するように構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項７８】
前記１つ以上のストレージノードのそれぞれは、
コーディネータノードからストレージ要求を受信し、
前記ストレージ要求に指定された検索可能なデータサービスオブジェクトを、前記検索可能なインデックスに加える
ように構成される、請求項７７に記載の、コンピュータアクセス可能なストレージ媒体。
【請求項７９】
前記１つ以上のストレージノードのそれぞれは、
コーディネータノードからストレージ要求を受信し、
前記ストレージ要求に指定されるように、前記検索可能なインデックスに保存された検索可能なデータサービスオブジェクトを修正する
ように構成される、請求項７７に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８０】
前記１つ以上のストレージノードのそれぞれは、
コーディネータノードからストレージ要求を受信し、
前記ストレージ要求に指定されるように、前記検索可能なインデックスからの検索可能なデータサービスオブジェクトの、少なくとも一部を削除する
ように構成される、請求項７７に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８１】
前記複数のノードのそれぞれは、
コーディネータノードからクエリ要求を受信し、
前記クエリ要求が、前記ローカルクエリキャッシュから前記クエリ要求を満たすことが出来るかどうかを判断するために、前記クエリノード上の前記ローカルクエリキャッシュにアクセスし、
前記クエリ要求が、前記ローカルクエリキャッシュから満たされることができる場合には、前記ウェブサービスインターフェースに従い、前記クエリ要求を満たす、前記ローカルクエリキャッシュから、前記クライアントアプリケーションへ、１つ以上の検索可能なデータサービスオブジェクトの１組から少なくとも前記エンティティ識別子を返し、
前記クエリ要求が前記ローカルクエリキャッシュから満たされない場合には、前記クエリ要求を前記ストレージノードの適切な１つ以上へ転送する
ように構成される、請求項７７に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８２】
前記１つ以上のストレージノードのそれぞれは、
クエリノードからクエリ要求を受信し、
前記クエリ要求を満たす前記検索可能なインデックスに、１つ以上の検索可能なデータサービスオブジェクトの１組を位置付けるために、前記ストレージノードによって持続的に保存される、前記検索可能なインデックスのパーティションを検索し、
前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションへ、前記クエリ要求を満たす１つ以上の検索可能なデータサービスオブジェクトの前記組から、少なくとも前記エンティティ識別子を返す
ように構成される、請求項８１に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８３】
前記複数のノードのそれぞれは、
コーディネータノードからクエリ要求を受信し、
前記クエリ要求の範囲内である、前記検索可能なインデックスの異なるパーティションを、それぞれ持続的に保存する、前記ストレージノードの２つ以上へ、前記クエリ要求を転送し、
前記クエリ要求が転送された前記２つ以上のストレージノードのそれぞれから前記クエリ要求を満たす、前記検索可能なインデックスからの検索可能なデータサービスオブジェクトの異なる１組を受信し、
検索可能なデータサービスオブジェクトの前記異なる組をマージし、
前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションへ、検索可能なデータサービスオブジェクトの前記マージされた組から、少なくとも前記エンティティ識別子を返す
ように構成される、請求項７７に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８４】
前記複数のノードのそれぞれは、
コーディネータノードからクエリ要求を受信し、
前記ストレージノードの１つ以上へ前記クエリ要求を転送し、
前記クエリ要求が転送された、前記１つ以上のストレージノードのうちの少なくとも１つから前記クエリ要求を満たす、前記検索可能なインデックスからの検索可能なデータサービスオブジェクトを受信し、
前記クエリ要求のソート仕様に従い、前記受信された検索可能なデータサービスオブジェクトをソートし、
前記ウェブサービスインターフェース及びソートされた順序に従い、前記ソートされた検索可能なデータサービスオブジェクトから、前記クライアントアプリケーションへ、少なくとも前記エンティティ識別子を返す、
ように構成される、請求項７７に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８５】
前記プログラム命令は、ストレージノードとして前記複数のノードの２つ以上を実装するように構成され、各ストレージノードは、
前記検索可能なインデックスのパーティションを持続的に保存し、
前記２つ以上の新しいパーティションのそれぞれが、前記検索可能なインデックスに保存された、前記検索可能なデータサービスオブジェクトの異なるサブセットを含む、２つ以上の新しいパーティションを生成するために、前記パーティションを再区分し、
前記２つ以上の新しいパーティションの１つを、自ら受信する別のストレージノードを位置付けるために、前記ストレージノードのその他と通信し、
前記２つ以上の新しいパーティションの１つを、前記他のストレージノードへ移動するために、前記他のストレージノードと協力する
ように構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８６】
前記プログラム命令は、ストレージノードとして前記複数のノードの２つ以上を実装するように構成され、各ストレージノードは、
前記検索可能なインデックスのパーティションを持続的に保存し、
前記パーティションの複製を自ら受信する、別のストレージノードを位置付けるために、前記ストレージノードの１つ以上のその他と通信し、
前記他のストレージノードへ前記パーティションを複製するために、前記他のストレージノードと協力する
ように構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８７】
前記プログラム命令は、ストレージノードとして前記複数のノードの２つ以上を実装するように構成され、各ストレージノードは、
前記検索可能なインデックスのパーティションを持続的に保存し、
アンチエントロピープロトコルに従い、前記パーティションを別のストレージノードに複製し、
前記他のストレージノードの前記パーティションの前記複製を更新するために、ゴシッププロトコルに従い、前記他のストレージノードへ、前記複製されたパーティションのための、次のストレージ要求を通信する
ように構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８８】
前記ウェブサービスインターフェースは、前記検索可能なデータサービスのクライアントアプリケーションへ、前記検索可能なデータサービスの操作を行うための複数のサービス要求を公開し、前記サービス要求は、
特定された検索可能なインデックスに特定された検索可能なデータサービスオブジェクトを加えるための追加要求と、
特定された検索可能なインデックスにおいて特定された検索可能なデータサービスオブジェクトの特定された一部又はすべてを置き換えるための置換え要求と、
特定された検索可能なインデックスから特定された検索可能なデータサービスオブジェクトの少なくとも一部を削除するための削除要求と、
特定された検索可能なインデックスの１つ以上の特定された検索可能なデータサービスオブジェクトのための属性のリストを返すためのリスト属性要求と、
前記クエリ要求において特定されたクエリ式と一致する、特定された検索可能なインデックスの検索可能なデータサービスオブジェクトのエンティティ識別子の１組を返すためのクエリ要求と
を含む、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項８９】
前記ウェブサービスインターフェースは、前記検索可能なデータサービスのクライアントアプリケーションに対する、前記検索可能なデータサービスの操作を行うための複数のサービス要求を公開し、前記公開された複数のサービス要求が、前記クライアントアプリケーションのためのデータストアに対する検索フロントエンドの実行で用いられるように構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９０】
各クエリ要求は、
前記検索可能なデータサービスの特定の検索可能なインデックスを識別するバケット識別子であって、バケットが、前記検索可能なデータサービスに対するクエリ要求の前記範囲を画定する、バケット識別子と、
前記クエリ式を満たす検索可能なデータサービスオブジェクトを位置付けるために、前記バケット識別子によって識別される前記検索可能なインデックスの特定された属性に対して適応される、１つ以上の検索基準を特定するクエリ式と
を含む、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９１】
各クエリ要求は、前記検索可能なデータサービスに対する特定の加入者を個別に識別する加入者識別子をさらに含み、各加入者識別子が、前記検索可能なデータサービスの1つ以上のバケット識別子と関連し、各バケット識別子が正確に１人の加入者と関連する、請求項９０に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９２】
各クエリ式は、
前記検索可能なインデックスの検索可能なデータサービスオブジェクトの１つ以上の属性と、
前記検索可能なインデックスの前記クエリ式を満たす検索可能なデータサービスオブジェクトの１組を位置付けるために、前記クエリ式において、前記１つ以上の属性に適応される１つ以上の演算子と
を含む、請求項９０に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９３】
前記演算子は、１つ以上のブーリアン演算子を含む、請求項９２に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９４】
前記演算子は、１つ以上の算術演算子を含む、請求項９２に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９５】
前記演算子は、１つ以上の文字列比較演算子を含む、請求項９２に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９６】
前記検索可能なデータサービスは、
前記クエリ要求を満たすエンティティ識別子の２つ以上のページを生成するために、前記クエリ要求を満たす１つ以上の検索可能なデータサービスオブジェクトの前記組から、前記エンティティ識別子のリストにページ番号を付け、
各応答メッセージがエンティティ識別子の前記ページの１つを含む、２つ以上の応答メッセージの前記クライアントアプリケーションに対するエンティティ識別子の前記２つ以上のページを返す
ように、さらに構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９７】
前記複数のノードは、前記２つ以上のデータセンタの間で分配される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項９８】
前記データセンタは、地理的に分散している、請求項９７に記載のコンピュータアクセス可能なストレ−ジ媒体。
【請求項９９】
前記プログラム命令は、前記データセンタのそれぞれにおいて、
前記検索可能なインデックスの少なくとも１部を持続的に保存するように構成される１つ以上のストレージノードと、
前回のクエリ要求への応答のローカルクエリキャッシュを維持するようにそれぞれ構成される１つ以上のクエリノードと、
少なくとも１つ以上のコーディネータノードであって、
前記ウェブサービスプラットフォームからサービス要求を受信し、
前記データセンタにおいて、各ストレージ要求を前記ストレージノードの適切な１つ以上へ転送し、
前記データセンタにおいて、各クエリ要求を前記クエリノードの適切な１つ以上へ転送する
ように構成される、少なくとも１つ以上のコーディネータノードと
を実装するように構成される、請求項９７に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１００】
前記プログラム命令は、前記検索可能なデータサービスのための複数のストレージノードを実装するように構成され、前記複数のストレージノードは、２つ以上のデータセンタに分散され、各データセンタは、前記複数のストレージノードの２つ以上を備え、
データセンタの前記ストレージノードの少なくとも２つが、前記検索可能なインデックスのパーティションの複製を持続的に保存し、
少なくとも１つの他のデータセンタの、少なくとも２つの他のストレージノードが、前記検索可能なインデックスの前記パーティションの複製を持続的に保存する、
請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１０１】
前記複数のノードのそれぞれは、ゴシッププロトコルに従い、前記複数のノードの他に検索可能なデータサービス情報を伝播するように構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１０２】
前記伝播された検索可能なデータサービス情報は、前記複数のノードの２つ以上に対して複製された前記検索可能なインデックスのパーティションのための更新情報を含む、請求項１０１に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１０３】
前記伝播された検索可能なデータサービス情報は、前記複数のノードのそれぞれのためのローカルヘルス情報及び状態情報を含む、請求項１０１に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１０４】
前記複数のノードは、前記複数のノードのサブセットをそれぞれ含むノードの群に体系づけられるように構成され、ノードの各群は、前記ゴシッププロトコルに従い、前記群内で検索可能なデータサービス情報を伝播するように構成される、請求項１０１に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１０５】
前記ウェブサービスプラットフォームは、計測、請求、認証、及び前記検索可能なデータサービスに対する加入者のアクセス制御を行う１つ以上のサービスをさらに備え、加入者は、前記クライアントアプリケーションによって使用される１つ以上のデータストアへ、検索フロントエンドとして前記ウェブサービスインターフェースを介して前記検索可能なデータサービスにアクセスするようにそれぞれ構成される、１つ以上のクライアントアプリケーションと関連するエンティティである、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１０６】
前記ウェブサービスプラットフォームは、前記検索可能なデータサービスに対する前記ウェブサービスインターフェースに従い、複数のクライアントアプリケーションから、サービス要求を受信するようにさらに構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１０７】
前記検索可能なデータサービスは、複数のクライアントアプリケーションの１つ以上によって使用される別個の相異なるデータストアのための検索可能なデータサービスオブジェクトを保存するようにそれぞれ構成される、複数の検索可能なインデックスを保存するようにさらに構成される、請求項７３に記載のコンピュータアクセス可能なストレージ媒体。
【請求項１０８】
１つ以上のプロセッサと、
ネットワークに通信的に連結するように構成されるネットワークインターフェースと、
プログラム命令を備えるメモリと、
を備え、
前記プログラム命令は、１つ以上のプロセッサによって
前記ウェブサービスインターフェースに従い、検索可能なデータサービス要求は、クエリ要求を備える、前記検索可能なデータサービス要求を、クライアントアプリケーションから、前記ネットワークを介し、受信し、
各検索可能なデータサービスオブジェクトは、前記データストアの特定のエンティティの２つ以上の属性を特定し、前記属性が、前記データストアの前記特定のエンティティを位置付けるための個別のエンティティ識別子を含む、受信されたクエリ要求を満たす前記クライアントアプリケーションによって使用されるデータストアのための、検索可能なインデックスからの１つ以上の検索可能なデータオブジェクトの組を位置付け、
前記ウェブサービスインターフェースに従い、前記ネットワークを介し、前記クエリ要求を満たす１つ以上の検索可能なデータサービスオブジェクトの前記組から、少なくとも前記エンティティ識別子を前記クライアントアプリケーションへ返す、
ことができる、
検索可能なデータサービスノード。
【請求項１０９】
前記検索可能なデータサービス要求は、ストレージ要求をさらに含み、前記プログラム命令は、前記クライアントアプリケーションによって使用される前記データストアのための前記検索可能なインデックスにおいて、受信されたストレージ要求に特定された検索可能なデータサービスオブジェクトを保存するために、１つ以上のプロセッサによってさらに実行可能である、請求項１０８に記載の検索可能なデータサービスノード。
【請求項１１０】
前記検索可能なデータサービスノードは、検索可能なデータサービスコーディネータノードであって、
前記検索可能なインデックスで受信されたストレージ要求において特定される検索可能なデータサービスオブジェクトを保存するために、前記プログラム命令は、１つ以上のプロセッサが各ストレージ要求を適切な１つ以上の検索可能なデータサービスストレージノードへ転送することによって、さらに実行可能であり、
受信したクエリ要求を満たす前記検索可能なインデックスから１つ以上の検索可能なデータサービスオブジェクトの組を位置付けるために、前記プログラム命令は、前記１つ以上のプロセッサが各クエリ要求を適切な１つ以上の検索可能なデータサービスクエリノードへ転送することによって、さらに実行可能である、
請求項１０９に記載の検索可能なデータサービスノード。
【請求項１１１】
各属性が｛名前、値｝の対として明示される、請求項１０８に記載の検索可能なデータサービスノード。
【請求項１１２】
前記検索可能なデータサービスノードは、１つ以上のデータストレージ機器をさらに備える検索可能なデータサービスストレージであり、前記プログラム命令は、前記1つ以上のデータストレージ機器上で前記検索可能なインデックスの少なくとも1つのパーティションを持続的に保存する、前記１つ以上のプロセッサによって、さらに実行可能である、請求項１０８に記載の検索可能なデータサービスノード。
【請求項１１３】
前記プログラム命令は、
前記２つ以上の新規パーティションのそれぞれが、前記検索可能なインデックスに保存された前記検索可能なデータサービスオブジェクトの異なるサブセットを含む、前記１つ以上のデータストレージ機器上の２つ以上の新規パーティションを生成するための前記１つ以上のデータストレージ機器上に保存される前記検索可能なインデックスのパーティションを再区分し、
前記２つ以上の新規パーティションの１つを受信するために、別の検索可能なデータサービスストレージノードを位置付けるための１つ以上の他の検索可能なデータサービスストレージノードと通信し、
前記２つ以上の新規パーティションの１つを他の検索可能なデータサービスストレージノードへ移動するために、前記他の検索可能なデータサービスストレージノードと協力する、
１つ以上のプロセッサによって、さらに実行可能である、請求項１１２に記載の検索可能なデータサービスノード。
【請求項１１４】
前記プログラム命令は、
前記１つ以上のデータストレージ機器上に保存される前記検索可能なインデックスのパーティションの複製を受信するために、別の検索可能なデータサービスストレージノードを位置付けるための１つ以上の他の検索可能なデータサービスストレージノードと通信し、
他の検索可能なデータサービスストレージノードへ前記パーティションを複製するために、前記他の検索可能なデータサービスストレージノードと協力する、
１つ以上のプロセッサによって、さらに実行可能である、請求項１１２に記載の検索可能なデータサービスノード。
【請求項１１５】
前記プログラム命令は、
アンチエントロピープロトコルに従い、１つ以上のデータストレージ機器に保存された前記検索なインデックスのパーティションを、別の検索可能なデータサービスストレージノードへ複製し、
前記他の検索可能なデータサービスストレージノード上の前記パーティションの前記複製を更新するために、ゴシッププロトコルに従い、前記他の検索可能なデータサービスストレージノードへ、前記複製されたパーティションのための次のストレージ要求を通信する、
１つ以上のプロセッサによって、さらに実行可能となる、請求項１０８に記載の検索可能なデータサービスノード。
【請求項１１６】
前記検索可能なデータサービスノードは、検索可能なデータサービスクエリノードであり、前記プログラム要求は、前回のクエリ要求への応答のローカルクエリキャッシュを維持するための前記１つ以上のプロセッサによってさらに実行可能である、請求項１０８に記載の検索可能なデータサービスノード。
【請求項１１７】
受信したクエリ要求を満たす前記検索可能なインデックスからの１つ以上の検索可能なデータサービスオブジェクトの組を位置付けるために、前記プログラム要求は、
クエリ要求を受信し、
前記クエリ要求が、前記ローカルクエリキャッシュから満たされることが出来るかどうかを判断するために、前記クエリノード上の前記ローカルクエリキャッシュへアクセスし、
前記ローカルクエリキャッシュから前記クエリ要求を満たすことができる場合には、前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションへ前記クエリ要求を満たす前記ローカルクエリキャッシュからの１つ以上の検索可能なデータサービスオブジェクトの組から、少なくとも前記エンティティ識別子を返し、
前記ローカルクエリキャッシュから前記クエリ要求が満たされない場合には、前記クエリ要求を適切な１つ以上の検索可能なデータサービスストレージノードへ転送する
１つ以上のプロセッサによって、さらに実行可能である、請求項１１６に記載の検索可能なデータサービスノード。
【請求項１１８】
各クエリ要求は、
前記検索可能なデータサービスの特定の検索可能なインデックスを識別するバケット識別子であって、バケットが、前記検索可能なデータサービスに対するクエリ要求の前記範囲を画定する、バケット識別子と、
前記クエリ式を満たす検索可能なデータサービスオブジェクトを位置付けるために、前記バケット識別子によって識別される前記検索可能なインデックスの特定された属性に適応される、１つ以上の検索基準を特定するクエリ式と
を含む、請求項１０８に記載の検索可能なデータサービスノード。
【請求項１１９】
前記プログラム命令は、ゴシッププロトコルに従い、１つ以上の他の検索可能なデータサービスノードへ、検索可能なデータサービス情報を伝播する、１つ以上のプロセッサによってさらに実行可能である、請求項１０８に記載の検索可能なデータサービスノード。
【請求項１２０】
前記伝播された検索可能なデータサービス情報は、前記検索可能なデータサービスノードの２つ以上に対して複製された前記検索可能なインデックスの１つ以上のパーティションのための更新情報を含む、請求項１１９に記載の検索可能なデータサービスノード。
【請求項１２１】
前記伝播された検索可能なデータサービス情報は、前記検索可能なデータサービスノードのためのローカルヘルス情報を含む、請求項１０８に記載の検索可能なデータサービスノード。
【請求項１２２】
ウェブサービスインターフェース上のクライアントアプリケーションから、検索可能なデータサービスに対するクエリ要求を受信するステップと、
各クエリ要求を、前記ウェブサービスインターフェースから、前記検索可能なデータサービスに関与するように構成される複数のノードの少なくとも１つへ転送するステップであって、各クエリ要求は、検索基準を備える、ステップと、
前記複数のノードのそれぞれ１つから、各クエリ要求に対するクエリ結果を受信するステップであって、各クエリ結果は、前記クエリの前記検索基準を満たす、前記検索可能なデータサービスの検索可能なインデックスから、１つ以上の検索可能なデータサービスオブジェクトのそれぞれからのエンティティ識別子を備える、ステップと、
前記ウェブサービスインターフェースに従い、前記クライアントアプリケーションに対する前記クエリ要求を満たす前記１つ以上の検索可能なデータサービスオブジェクトのそれぞれから、少なくとも前記エンティティ識別子を返すステップであって、各エンティティ識別子は、前記クライアントアプリケーションによって使用されるデータストアに、特定のエンティティを配置する、ステップと、
を備える、方法。
【請求項１２３】
前記ウェブサービスインターフェース上の前記クライアントアプリケーションから、前記検索可能なデータサービスに対するストレージ要求を受信するステップと、
前記検索可能なデータサービスに関与するように構成される前記複数のノードの少なくとも１つに対して、前記ウェブサービスインターフェースからの各ストレージ要求を転送するステップであって、各ストレージ要求は、前記検索可能なインデックスのための更新操作を特定する、ステップと、
前記複数のノードのそれぞれの１つから、各ストレージ要求のための更新結果を受信するステップと、
前記ウェブサービスインターフェースに従い、各ストレージ要求に対する前記クライアントアプリケーションへの更新応答を返すステップであって、各更新応答は、前記応答する更新要求によって特定される、前記更新操作のための前記更新結果を含む、ステップと
をさらに備える、請求項１２２に記載の方法。
【請求項１２４】
各検索可能なデータサービスオブジェクトは、前記データストアの特定のエンティティの２つ以上の属性を特定し、前記属性は、前記データストアの前記特定のエンティティを位置付けるための前記個別のエンティティ識別子を含む、請求項１２２に記載の方法。
【請求項１２５】
前記複数のノードは、
前記検索可能なインデックスを持続的に保存し、クエリ要求を満たすように構成される１つ以上のストレージノードと、
前回のクエリ要求に対する応答のローカルクエリキャッシュからクエリ要求を満たし、満たされないクエリ要求を前記ストレージノードへ転送するようにそれぞれ構成される、１つ以上のクエリノードと、
前記複数のノードの他へ、前記ウェブサービスインターフェースから受信されたクエリ要求を含む要求を送るように構成される、１つ以上のコーディネータノードと
を備える、請求項１２２に記載の方法。
【請求項１２６】
前記ウェブサービスインターフェースを介し、前記検索可能なデータサービスのクライアントアプリケーションに、前記検索可能なデータサービスの操作を行うための複数のサービス要求を公開することをさらに備え、前記ウェブサービスインターフェースを介して公開される前記サービス要求は、
特定された検索可能なインデックスへ特定された検索可能なデータサービスオブジェクトを加えるための追加要求と、
特定された検索可能なインデックスの特定された検索可能なデータサービスオブジェクトの特定の一部又はすべてを置き換えるための置換え要求と、
特定された検索可能なインデックスから、特定された検索可能なデータサービスオブジェクトの少なくとも一部を削除するための削除要求と、
特定された検索可能なインデックスの１つ以上の特定された検索可能なデータサービスオブジェクトのための属性のリストを返すためのリスト属性要求と、
前記クエリ要求において特定されたクエリ式と一致する、特定された検索可能なインデックスの検索可能なデータサービスオブジェクトのエンティティ識別子の１組を返すためのクエリ要求と
を含む、請求項１２２に記載の方法。
【請求項１２７】
前記ウェブインターフェースを介し、前記検索可能なデータサービスのクライアントアプリケーションの開発者に対し、前記検索なデータサービスの操作を行うための複数のサービス要求を公開するステップをさらに備え、前記公開された複数のサービス要求は、前記クライアントアプリケーションのためのデータストアに対する検索フロントエンドの実行に用いるように構成される、請求項１２２に記載の方法。
【請求項１２８】
各クエリ要求は、
前記検索可能なデータサービスの特定の検索可能なインデックスを識別するバケット識別子であって、バケットは、前記検索可能なデータサービスに対するクエリ要求の前記範囲を画定するバケットと、
前記クエリ式を満たす検索可能なデータサービスオブジェクトを位置付けるために、前記バケット識別子によって識別される前記検索可能なインデックスの特定された属性に適応される１つ以上の検索基準を特定するクエリ式と、
を含む、請求項１２２に記載の方法。
【請求項１２９】
前記ウェブサービスインターフェースは、ウェブサービスプラットフォームによって提供され、前記ウェブサービスプラットフォームは、計測、請求、認証、及び前記検索可能なデータサービスに対する加入者のアクセス制御を行う１つ以上のサービスをさらに備え、加入者は、前記クライアントアプリケーションによって使用される１つ以上のデータに対する検索フロントエンドとして、前記ウェブサービスインターフェースを介して、前記検索可能なデータサービスへアクセスするようにそれぞれ構成される、１つ以上のクライアントアプリケーションと関連するエンティティである、請求項１２２に記載の方法。
【請求項１３０】
前記ウェブサービスインターフェース上で、複数のクライアントアプリケーションからクエリ要求を受信するステップをさらに備える、請求項１２２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータストレージ及び取り出し、さらに具体的には、データストアのための検索可能なインデックスに関する。
【背景技術】
【０００２】
単に「ネット」と呼ばれることもあるインターネットは、いかなる１台のコンピュータを使用するクライアントが、許可を受け、その他のいかなるコンピュータから情報を獲得することができるコンピュータネットワークの世界的システムである。インターネットの中で最も広く一般的に使用されているのは、多くの場合「ＷＷＷ」と略され、「ウェブ」と一般的に称される、ワールドワイドウェブである。ウェブとは、リソースにアクセスするために、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、又はそのバリエーションを使用するインターネット上のすべてのリソース（例、ウェブページ及びウェブサイト）及びクライアントと定義される。ウェブサイトは、ホームページと呼ばれる開始ファイルを含むウェブファイルの関連集合体である。ホームページから、クライアントはウェブサイト上の別のウェブページへ移動することができる。ウェブサーバプログラムとは、クライアント／サーバモデル及びＨＴＴＰを使用して、ウェブサイトのウェブページを形成するファイルを、要求の転送、応答の表示を行うＨＴＴＰクライアントプログラム（例、ウェブブラウザ）を搭載するコンピュータを有するウェブクライアントに送信するプログラムである。ウェブサーバプログラムは、１つ以上のウェブサイトを所有する。
【０００３】
データストレージ
種々のアプリケーションによりアクセスするための様々なタイプのデータオブジェクトを保存するデータストレージは、コンピュータシステムとアプリケーション、ネットワーキング、インターネット、及び関連技術分野において、最も関心が高く、優先的に開発される分野である。従来、開発者は、データ保存ソリューションを開発するために、データオブジェクトを保存するための独自のデータストレージソリューションを作製するか、Ｏｒａｃｌｅ／ＭｙＳＱＬデータベースなど既製のデータベース製品を調達するか、又は、データストレージソリューションを提供する第三者のプロバイダーに依存してきた。しかし、データストレージソリューションが提供されると、データオブジェクトをデータストアに保存し、また取り出すことができる。典型的に、データ保存ソリューションは、データストアからデータオブジェクトを取り出すために使用できる１種以上のロケータを提供する。一般的な「ロケータ」は、クライアントが、ファイルパスで特定されるデータストアと併せて、一部のロケーションから特定のデータオブジェクト（例、ファイル）を取り出すために、特定のファイル名を含むファイルパスを提供する、ファイルパスタイプのロケータである。しかしながら、ファイルパスは、所望のデータオブジェクトがパス／ファイル名のみでしか特定できないため、あまり柔軟性がない。ファイルパス機構、及びデータストアからデータオブジェクトを取り出すその他の従来の「ロケータ」機構は、一般的に、所望のデータオブジェクトの属性に従い、データストアからデータオブジェクトを取り出すための柔軟性を提供しない。例えば、クライアントは、カテゴリ、会社、種類、又はデータオブジェクトに関連するその他の無数の属性のいずれかに基づき、データストアからデータオブジェクを取り出すことを希望する場合もある。従来のファイルパスは、そのような柔軟な取り出し方法を提供しない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ファイルパス／ファイル名以外のその他の属性に従い、データストアからデータオブジェクトをクエリし／取り出す、より柔軟な機構を提供することができる「１回限りの」データ保存ソリューションがある。従来より、様々な開発者は、他の問題に応用できず、その他のデータ保存ニーズに対処する柔軟性を持たない方法で、同一のデータストレージ問題を異なるアプリケーションで繰り返し解決しようとする傾向があり、及び／又は短期並びに／若しくは長期的に高価であると証明されたＯｒａｃｌｅ／ＭｙＳＱＬなどの「既製」技術によるソリューションに基いてきた。データストアが増大すると、これらの従来のデータ保存ソリューションは一般的に、モニタリング、分割、クエリ最適化、保存処理、新たなハードウェアの追加、危機／緊急処理（例、保存システムが故障した場合）などを実施又は管理するデータストアアドミニストレータを必要とする。さらに、これらの従来のデータストレージソリューションに対して、クライアントが、クエリ及びデータオブジェクトの取り出しに使用される可能性のある、さらなる属性を追加したい場合、当該の新しい属性をサポートするために、テーブルスキーマを変更する必要がある。
【課題を解決するための手段】
【０００５】
汎用の検索可能なデータサービスのための方法及び装置の種々の実施態様を説明する。一実施態様において、検索可能なデータサービスを、データストアに保存されるデータオブジェクト（エンティティ）に関連し、｛名前、値｝の１組として明示される属性の保存を可能にするウェブサービスとして実装することができる。エンティティに関連する属性は、検索で使用される場合に、自動的にインデックスが付けられる。検索可能なデータサービスの実施態様は、クライアントアプリケーションのためのデータストアに対するフロントエンド検索を開発し、信頼性があり迅速かつ拡張可能なデータストアに検索可能なインデックスを作成し更新するために、開発者にアクセス可能なアーキテクチャに従って実装することができる。検索可能なデータサービスの実装は、クライアント／開発者に透過的であってもよい。クライアント及び／又は開発者は、検索可能なデータサービスに対し、最少かつ外部に公開されるインターフェースのみを認識すればよい。
【０００６】
検索可能なデータサービスの実施態様は、検索可能なインデックスをバックエンドデータストアに、検索可能なインデックスを構築及びクエリするためにインターフェースを提供することで、クライアントアプリケーションが、各ロケータに関連する属性リストに従い、バックエンドデータストアの保存されたエンティティのロケータを検索し及び取り出せるようにする。エンティティは、エンティティのロケータにより、検索可能なデータサービスの検索可能なインデックスに指定される。各ロケータは、｛名前、値｝の１組で明示されるエンティティの関連属性群を有してもよい。ロケータ自体が、エンティティの属性の１つと考えられることができると考慮する。
【０００７】
検索可能なデータサービスの一実施態様は、検索データサービスの機能への１つ以上のコールをクライアントアプリケーションに接するウェブサービスインターフェースを伴うウェブサービスとして実装することができる。ウェブサービスインターフェースにより、開発者は、ウェブサービスインターフェースを介して、バックエンドデータストアに保存されているデータエンティティのロケータを検索し、取り出すために、検索可能なデータサービスの機能にアクセスする多様なクライアントアプリケーションの検索フロントエンドを構築することができる。データストアの検索フロントエンドとして検索可能なデータサービスを調達するアプリケーションは、スケーリングに必要なシステムアドミニストレーションオーバーヘッド有り又は無しで、いかなるサイズにも自動的に調製されてもよく、検索速度は、例えばインデックス、クエリプラン、及び並行処理を使用し、自動的に最適化される。
【０００８】
検索可能なデータサービスは、検索可能なインデックスを提供するが、それ自体がデータストアではない。検索可能なデータサービスの実施態様は、データの検索及びインデックスと実際のデータストレージとを分ける。バックエンドデータストアは、ロケータがエンティティを捜し、取り出すために使用される、データ保存システムの任意の種類として実装され、ネットワーク、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）のどこにでも、又はインターネット上に存在することができ、又はコンピュータシステム又はシステムにローカルに接続されるデータ保存上に実装されることもできる。検索可能なデータサービスの実施態様は、検索可能なインデックスをいかなる種類のデータにも提供する。例えば、実施態様は、データベースに保存されているデータ、及びテキスト、デジタル画像、及びデジタルオーディオファイルを含むがこれらに限定されない多様で特別又は混合された種類のファイル収納庫に、検索可能なインデックスを提供するために使用することができる。しかしながら、検索可能なインデックスの実施態様は、バックエンドデータストアが存在しないアプリケーションで使用されることを考慮する。これらのアプリケーションにおいて、検索可能なインデックスに、｛名前、値｝の１組として保存されている属性はデータである。
【０００９】
検索可能なデータサービスの実施態様は、検索可能なデータサービスのスケールを容易にし、クライアントアプリケーションの開発者によるいかなる知識又はさらなる労力を必要とすることなく、検索可能なインデックスの冗長性、信頼性、及び高い可用性を提供することを可能にする機構を含む。これらの機構は、検索可能なインデックスを構築する機構、検索可能なインデックスを区分する機構、検索可能なインデックスを複製する機構、検索可能なデータサービス内のノードの失敗を対処する機構、及び検索可能なデータサービス内のノードの自動モニタリング及びコントロールを司る機構を含むが、これらに限定されない。
【００１０】
検索可能なデータサービスの実施態様は、複数のホスト、又はノード上の分散型システムとして実装することができる。一実施態様において、ノードは、検索可能なデータサービス内の適切なノードへ、クライアントシステムからの要求を送るコーディネータノード、クエリ要求の処理をするクエリノード、及び検索可能なインデックスの保存及び管理をするストレージノードを含む。一実施態様において、検索可能なデータサービス実装のノード及びコンポーネント間の通信は、ゴシッププロトコル及びアンチエントロピープロトコルを少なくとも部分的に通じて実施することができる。
【発明を実施するための最良の形態】
【００１１】
本発明は一部の実施形態及び例示的図面によって一例として示され、本明細書に詳述されるが、本発明は記載される実施形態又は図面に限定されないことを当業者は認識するであろう。この図面及び詳細な説明は、本発明を開示される特定の形態に制限することを意図せず、逆に、添付の請求項によって定義される本発明の精神及び範囲内に含まれるすべての修正、同等物、及び代替手段を扱うと理解されたい。本明細書で使用される表題は、組織目的に限り、説明又は請求項の範囲を限定するために意図されるわけではない。本願で使用される「してもよい」という語は、強制的な意味ではなく、許容的な意味（すなわち、可能性を有するという意味）で使用される。同様に、「含む」という語は、限定することなく含むという意味である。
【００１２】
汎用検索可能なデータサービスのための方法及び装置の種々の実施形態を説明する。一実施形態において、開発者が、検索可能なデータサービスをデータストアに保存されるデータオブジェクト（エンティティ）に関連し、｛名前、値｝の１組として明示される属性を保存することを可能にするウェブサービスとして実装することができる。エンティティに関連する属性は、検索で使用される場合に、自動的にインデックスが付けられる。検索式は、属性に論理及び算術演算子を実施し、エンティティを識別するロケータにより（識別子、又はｅＩＤとも称される）識別される、データオブジェクト、又はエンティティの検索し、取り出しを実施する。検索可能なデータサービスの実施形態は、クライアントアプリケーションの検索フロントエンドの実装が容易であるデータストアに提供し、信頼性があり迅速かつ拡張可能なデータストアに検索可能なインデックスを作成及び更新するために、ウェブサービスを介して開発者にアクセス可能なアーキテクチャに従って実装することができる。
【００１３】
検索可能なデータサービスの実施形態は、検索可能なインデックスをバックエンドデータストアに、検索可能なインデックスを構築しクエリするためにインターフェースを提供することで、クライアントアプリケーションが、各ロケータに関連する属性リストに従い、バックエンドデータストアに保存された保存データ（データストアのデータ単位、又はデータオブジェクトは、本明細書においてエンティティと称する場合がある）のロケータを検索し、取り出せるようにする。バックエンドデータストアは、ロケータがエンティティを捜す及び取り出すために使用される、データストレージシステムの任意の種類として実装されてもよく、データオブジェクト（エンティティ）の任意の種類を保存することができる。エンティティは、識別子、又はｅＩＤと称される、データストアのエンティティのロケータにより、エンティティは、検索可能なデータサービスに記載される。各ロケータは、｛名前、値｝の１組で明示されるエンティティの関連属性群を有してもよい。ロケータ、又はｅＩＤ自体が、データストアのエンティティの属性の１つと考えられることができると考慮する。ｅＩＤに関連する１つ以上の属性に従い、検索可能なデータサービスからｅＩＤのリストを問い合わせる、及び受け取るために使用される、クエリインターフェース及びプロトコルを提供してもよい。
【００１４】
従来のウェブモデルにより、クライアントは、ウェブブラウザなどのＨＴＴＰクライアントプログラムを介して、ウェブリソース（例、アプリケーション、サービス、及びデータ）にアクセスができる。ウェブサービスと称される技術は、ウェブリソースへのプログラム的なアクセスを提供するために使用することができる。ウェブサービスは、ウェブサーバシステムなどのウェブに接続されたコンピュータ上にある技術プラットフォーム（例、アプリケーション及びサービス）及びデータ（例、製品カタログ及びその他のデータベース）を含むウェブリソースへのプログラム的アクセスを、ウェブソフトウェア開発者に提供するために使用することができる。一般的に言うと、ウェブサービスインターフェースは、処理されるサービスを要求するクライアントとサービスプロバイダーの通信に関わる、標準的クロスプラットフォームＡＰＩ（アプリケーションプログラミングインターフェース）を提供するように構成されることがある。一部の実施形態において、ウェブサービスインターフェースは、サービス要求及び該要求への応答を解説する上方を含む、文書又はメッセージの交換を支援するように構成されることがある。このような文書、又はメッセージは、例えば、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）などの標準化ウェブプロトコルを使用して交換することができ、例えば、ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）などのプラットフォーム独立型データフォーマットでフォーマット化することができる。
【００１５】
図１は、ウェブサービスインターフェースを提供する例示的システム構造を例示するブロック図であり、ウェブサービスクライアント及びウェブサービスプロバイダー間の情報のやり取りを示している。本実施形態において、ウェブサービスインターフェース１０６は、インターネット１００に接続されているサーバ１３０上に実装することができる。このサーバ１３０は、ウェブサービスプロバイダーと称される。サーバ１３０、又はサーバ１３０に接続される代替となる１つ以上のその他のサーバは、１つ以上のアプリケーション又はサービス１０８を含む。サーバ１３０は、データベース１４２に情報を保存するため、データストレージ１４０に接続される。データベース１４２は、いずれの種類のデータを含んでいてもよい。
【００１６】
サーバ１２０は、インターネット１００に接続される。サーバ１２０は、ウェブサービスクライアント１２４を所有する。ウェブサービスクライアント１２４は、ウェブサービスインターフェース１０６を介して、サーバ１３０及び／又はデータベース１４２のアプリケーション又はサービス１０８に、プログラム的にアクセスするように構成されている。ウェブサービスインターフェースは、ウェブブラウザインターフェースを提供しないが、代わりに、アプリケーション又はサービス１０８の少なくとも一部の機能及び／又はデータベース１４２の少なくとも一部のデータが、ウェブサービスクライアント１２４によってプログラム的にアクセスされるＡＰＩを介して、プログラム的インターフェースを提供することを考慮する。サーバ１２０は、ウェブブラウザを介して、クライアント１２２にアクセス可能なウェブサイトを提供することもまた考慮し、ウェブサービスクライアント１２４は、アプリケーション又はサービス１０８の少なくとも一部の機能及び／又はサーバ１３０のデータベース１４２の少なくとも一部のデータにアクセスするように構成されてもよく、サーバ１２０によって提供されるウェブサイトを介して、アプリケーション又はサービス１０８の少なくとも一部の機能及び／又はデータベース１４２の少なくとも一部のデータへのアクセスを提供する。さらに、ウェブサービスクライアント１２４自体が、別のウェブサービスであることを考慮する。
【００１７】
ウェブサービスプロバイダー１３０により提供されるアプリケーション、サービス又はデータにアクセスするために、ウェブサービスクライアント１２４は、インターネット１００を介して、ウェブサービスインターフェース１０６に要求メッセージを送信してもよい。この要求メッセージは、ネットワーク及びインターネットインフラストラクチャーを通過し、ウェブサービスクライアント１２４のローカルネットワークルーター、スイッチ、ファイヤーウォールなどを通過し、インターネット骨格を通過し、ウェブサービスプロバイダーのローカルネットワーク、サーバ１３０、そしてウェブサービスインターフェース１０６に送信される。ウェブサービスプロバイダー１３０はその後、例えば、アプリケーション又はサービス１０８の指定機能を実施することで、又はデータベース１４２の指示データにアクセスすることで、要求を処理してもよい。ウェブサービスインターフェース１０６は、そしてインターネット１００を介する応答メッセージにて、ローカルネットワーク及びインターネット基幹を通して処理結果をウェブサービスクライアント１２４に返す場合がある。
【００１８】
検索可能なデータサービスの一実施形態は、検索データサービスの機能への１つ以上のコールをクライアントアプリケーションに接するウェブサービスインターフェースを伴うウェブサービスとして実装することができる。このウェブサービスインターフェースにより、開発者は、ウェブサービスインターフェースを介して、バックエンドデータストアに保存されている多様なデータを検索し、取り出すために、検索可能なデータサービスの機能にアクセスする多様なクライアントアプリケーションの検索フロントエンドを容易に構築することができる。データストアの検索フロントエンドとして検索可能なデータサービスを調達するアプリケーションは、スケールに必要なシステムアドミニストレーションオーバーヘッド有り又は無しで、いかなるサイズにも自動的に調整されてもよく、検索速度は、例えばインデックス、クエリプラン、及び並行処理を使用し、自動的に最適化される。
【００１９】
検索可能なデータサービスの実施形態は、様々なアプリケーションへの検索要求を満たすデータストアに検索フロントエンドを提供するために調達される、低価格かつ実装、維持が容易な検索インデックスを提供する。検索可能なデータサービスは、検索可能なインデックスを提供するがそれ自体がデータストアではない。検索可能なデータサービスの実施形態は、データの検索及びインデックスと実際のデータストレージとを分ける。バックエンドデータストアは、ロケータがエンティティを捜し、取り出すために使用される、データ保存システムの任意の種類として実装され、ネットワーク、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）のどこにでも、又はインターネット上に存在することができ、又はコンピュータシステム又はシステムにローカルに接続されるデータ保存上に実装されることもできる。しかしながら、検索可能なインデックスの実施形態は、バックエンドデータストアが存在しないアプリケーションで使用されることを考慮する。これらのアプリケーションにおいて、検索可能なインデックスに、｛名前、値｝の１組として保存されている属性はデータである。
【００２０】
検索可能なデータサービスの実施形態により、開発者は望む場所どこにでもデータストアを置くことが可能になり、開発者はその後、検索可能なインデックスが構築される、｛名前、値｝の１組として明示されるｅＩＤへの属性群に従い、ロケータ（ｅＩＤｓ）を検索可能なデータサービスに提供し、検索可能なデータサービスはその後、クエリを満たす検索インデックスからｅＩＤのリストを戻すためにクエリされる。これらのｅＩＤのリストは、バックエンドデータストアに保存されるデータ保存物にアクセスするために使用されてもよい。上述の通り、一実施形態は、開発者がｅＩＤ及び関連属性を追加し、検索可能なインデックスを更新し（例、検索可能なインデックスのｅＩＤ及び属性を変更、置換又は削除することにより）、さらにｅＩＤのリストを獲得するために検索可能なデータサービスをクエリする、１つ以上のウェブサービスコールを提供するウェブサービスインターフェースを提供してもよい。
【００２１】
検索可能なデータサービスの実施形態は、検索可能なインデックスをいかなる種類のデータにも提供する。例えば、実施形態は、データベースに保存されているデータとテキスト、デジタル画像、及びデジタルオーディオファイルを含むがこれらに限定されない多様で特別又は混合された種類のファイル収納庫に、検索可能なインデックスを提供するために使用することができる。例えば、検索可能なデータサービスは、検索可能なインデックスをデジタル画像収納庫に提供するために使用されてもよい。ウェブサービスインターフェースから検索可能なデータサービスにおいて、インターネット上のクライアントは、アカウントを開き、デジタル画像を保存し、さらにデジタル画像のインデックス情報を提供してもよい。
【００２２】
一実施形態において、検索可能なデータサービスの実施形態は、データストアに、検索可能なインデックス及びデータストアを提供してもよい。一実施形態において、ウェブサービス又はその他のインターフェースから検索可能なデータサービスにおいて、クライアントは、エンティティをデータストアに保存し、データストアの検索可能なインデックスを作成するために使用される、エンティティのｅＩＤ及び関連属性を提供してもよい。クライアントは、インターフェースを介して、検索可能なデータサービスへ、検索可能なインデックスをクエリし、さらにクエリ結果を使用して、インターフェースを介して検索可能なデータサービスへデータストアをクエリしてもよい。
【００２３】
検索可能なインデックスの実施形態が、本明細書において一般的に、バックエンドデータストアに検索可能なインデックスを提供すると言及される一方、実施形態はバックエンドデータストアが存在しないアプリケーションで使用されることを考慮する。これらのアプリケーションにおいて、検索可能なインデックスに、｛名前、値｝の１組として保存されている属性はデータである。これらのアプリケーションにおいて、バックエンドデータストアに「エンティティ」は存在せず、その意味で、各エンティティは、検索可能なインデックスにある属性である。一実施形態において、ウェブサービス又はその他のインターフェースから検索可能なデータサービスにおいて、クライアントは、検索可能なインデックスを作成するために使用される、データを、｛名前、値｝の１組として提供してもよい。クライアントはその後、インターフェースを介して、検索可能なインデックスをクエリし、所望のデータを獲得する。検索可能なデータサービスが使用され、バックエンドデータストアが存在しないアプリケーションの実施形態は、製品カタログ及び電話帳を含むが、これらに限定されない。
【００２４】
検索可能なデータサービスの実施形態は、検索可能なデータサービスのスケール化を容易にし、検索フロントエンドをバックエンドデータストアに提供する検索可能なデータサービスを調達する開発者のいかなる知識又はさらなる労力を必要とすることなく、検索可能なインデックスの冗長性、信頼性、及び高い可用性を提供することを可能にする機構を含む。これらの機構は、検索可能なインデックスを構築する機構、検索可能なインデックスを区分する機構、検索可能なインデックスを複製する機構、検索可能なデータサービス内のノードの失敗を対処する機構、及び検索可能なデータサービス内のノードの自動モニタリング及びコントロールを司る機構を含むが、これらに限定されない。
【００２５】
検索可能なデータサービスの一部の実施形態は、様々な機能を実施するよう構成されたシステム内にウェブサービスフロントエンド、多様なノードを搭載する分散型システムとして実装することができる。例えば、一実施形態において、クライアントシステムから１つ以上のその他の適切なノードへの要求の経路を調整する、例えば、ウェブサービスインターフェースを解して受け取ったクライアントのクエリ（読み取り）要求を１つ以上の適切なクエリノードに、及びウェブサービスインターフェースを解して受け取ったクライアントのストレージ（書き込み）要求を１つ以上の適切なストレージノードに送る、１つ以上のコーディネータノード、クエリ要求の適切なストレージノードへの経路決定を含むクエリ要求の処理を担当するクエリノード、ストレージ要求に応じるｅＩＤ及び関連属性の保存、及びクエリノードから受け取ったクエリ要求に応じる保存されたｅＩＤの取り出しを管理する１つ以上のストレージノードがある場合がある。
【００２６】
分散型システムの種々のノードは、検索可能なインデックスが拡張可能で、一貫性、有用性、及び耐性を有するように通信により協働することができる。一実施形態において、検索可能なデータサービス実装のノード間の通信は、ゴシッププロトコルを通じて、少なくとも部分的に実施される場合がある。一実施形態において、検索可能なデータサービス実装のノード間の通信は、アンチエントロピープロトコルを通じて、少なくとも部分的に実施することができる。一実施形態において、検索可能なデータサービス実装のノード間の通信は、ゴシッププロトコル及びアンチエントロピープロトコルを通じて、少なくとも部分的に実施することができる。一実施形態において、検索可能なデータサービス実装の２つ以上のノードは、パーティションの共同動作又はストレージノードグループ内のパーティションの共同複製など、グループ内ノード間の種々の共同機能を円滑にするために、ゴシッププロトコル及び／又はアンチエントロピープロトコルを使用する、グループ通信プロトコルに従い、グループに関与することができる。
【００２７】
一実施形態において、加入者により作製される検索可能なインデックス（ドメイン、又はバケットとも称される）は、最初に１つのパーティションとして作製され、そのパーティション（及びその後続いて作製されたパーティション）はストレージノード上に再分割され、新規に現れたパーティションの１つは、データセンタ又はその他のデータセンタ内の別のストレージノードに共同的に移動するため、検索可能なインデックスは、１つのノード又は１つのデータセンタのストレージリミットを越えて増大することができる。クライアントストレージ（書き込み）要求を２つ以上のノード間に分散されるようにすることで、能力を改善するために区分を使用することもできる。
【００２８】
ドメインのパーティションは、データセンタ内又はいくつかのデータセンタを渡って、その他のストレージノードに複製することができるため、検索可能なインデックスの有用性が維持され、耐性を有することを確実にする。クライアントクエリ（読み取り）要求を２つ以上のノード間に分散されるようにすることで、能力を改善するために複製を使用することもできる。一実施形態において、１つのストレージノードから別のストレージノードへパーティションを複製するためにアンチエントロピーを使用し、複製パーティションを最新型に更新するためにゴシッププロトコルを使用することで、複製を実施することができる。あるパーティションの複製を保存するストレージノードは、複製グループに共同的に関与することができ、またグループ通信は、最信情報をパーティションに伝播するためにグループ内で使用することができる。一実施形態において、複製パーティションへの書き込みはまず複製グループ内の１つ以上のストレージノードに直接適用され、その後ゴシッププロトコルを使用して複製グループ内のその他のストレージノードに伝播される。
【００２９】
グループ通信は、検索可能なデータサービス実装内の種々のノード、コンポーネント、及びその他のリソースのヘルス状態及び状況を観察するために使用されてもよく、さらに新規リソースを自動追加することで、何らかの理由で失敗又は利用不可能となる既存リソースを複製することが可能となる。例えば、既存ストレージノードの１つがオフラインになる場合、新規ストレージノードをストレージノードグループ（例、複製グループ）に自動的に補充するために、グループ通信を使用することができる。
【００３０】
検索可能なデータサービスの実施形態において、ｅＩＤストア内に、ｅＩＤ及びエンティティの関連属性（｛名前、値｝の１組として明示される）を保存するキー値１組ストレージを使用することができる。ｅＩＤ自体が、関連エンティティの属性の１つと考えられ、キー値１組としてｅＩＤに保存することができるということを考慮する。一実施形態において、キー値１組ストレージは、ｅＩＤ及びその他関連属性を保存するために、関連辞書データベースアーキテクチャに従って実装することができる。実施形態の属性を保存するために使用される関連辞書は、読み込みの場合は特に、高いスループットを比較的少量のＣＰＵコストで提供することが可能である。関連辞書は、シンプルであり、使いやすさ及び柔軟性における信頼性の維持を支援する場合がある。さらに、関連辞書は、関連データベースなどの代替物と比較した際、低価格である場合がある。
【００３１】
一実施形態において、ｅＩＤストアは、Ｂｅｒｋｅｌｅｙ  Ｄａｔａｂａｓｅに従い実施することができる。Ｂｅｒｋｅｌｅｙ  Ｄａｔａｂａｓｅは、キー値１組を使用し、テーブル及びその他のデータ構造にインデックスを作製するために使用されるデータベースシステムに搭載されているオープンソースである。関連データベースとは違い、Ｂｅｒｋｅｌｅｙ  ＤａｔａｂａｓｅはＳＱＬクエリをサポートしない。すべてのクエリ及びデータ分析は、代わりに、Ｂｅｒｋｅｌｅｙ  Ｄａｔａｂａｓｅアプリケーションプログラミングインターフェース（ＡＰＩ）を通じたアプリケーションにより実施される。その他の実施形態は、ｅＩＤストアのその他のデータベース構造を使用できる。
【００３２】
検索可能なデータサービスの実施形態は、ウェブサービスを使用して、検索可能なインデックスをウェブ上で使用可能にする。実施形態は、開発者が検索能力をアプリケーションに容易に追加できるようにする。データストアに保存されるデータオブジェクトにアクセスする必要があるアプリケーションの開発者は、アプリケーションがいくつかの属性の１つ、又は属性の組み合わせに基づくデータオブジェクトを取り出せるようにすることを必要、又は所望する。関連辞書を検索インデックスと統合し、検索インデックスをウェブサービスインターフェースを通して使用可能にすることで、検索可能なデータサービスの実施形態により、開発者は、１つの属性又は属性の組み合わせに基づきデータストアに保存されたデータオブジェクトのロケータを取り出すための多数のアプリケーションに必要又は所望される速度及びクエリ電力源を提供するアプリケーションの検索可能なインデックスフロントエンドを低価格及び容易に実装するために、検索可能なデータサービスを調達することができる。
【００３３】
本明細書に記載される種々の機構、サブシステム、及び検索可能なデータサービスのコンポーネントを含む検索可能なデータサービスの実装は、クライアント／開発者に透過的であってもよいことを考慮する。クライアント及び／又は開発者は、ウェブサービスインターフェースを通して提供される、検索可能なデータサービスに対し、最少かつ外部に公開されるインターフェースのみを認識すればよいため、クライアント及び／又は開発者は、検索可能なインデックス（ドメイン）を構築及び更新、並びに検索可能なインデックスからｅＩＤの検索可能なデータサービスをクエリすることができる。
【００３４】
図２は、一実施形態に従い、クライアント及び検索可能なデータサービス間の関係及びデータフローを例示している。データストア３３２は、ロケータと介してアクセス可能なデータエンティティを含んでもよい。検索可能なデータサービス３４０の実装は、ウェブサービスインターフェース３５０を介してＡＰＩを公開してもよい。クライアント３３０は、ウェブサービスインターフェースを介して、検索可能なデータサービス３４０の機能へのアクセスを有してもよい。アプリケーションの開発者（例、クライアント３３０）は、ウェブサービスインターフェース３５０により提供されるコールを介して、検索可能なデータサービス３４０を調達し、データストア３３２にフロントエンド検索サービスを提供する。
【００３５】
クライアント３３０は、ウェブサービスインターフェース３５０を介して、データストア３３２にある少なくとも一部のエンティティのロケータ（ｅＩＤｓ）及び関連属性（｛名前、値｝の組み合わせで明示される）を検索可能なデータサービス３４０に提供できる。検索可能なデータサービス３４０は、上述の通り、ｅＩＤ及び関連属性をバケット内に保存し、検索可能なインデックス３４２を生成するために、属性のインデックスを構築することができる。クライアント３３０はその後、ウェブサービスインターフェース３５０を介して、検索可能なデータサービス３４０をクエリしてもよい。検索可能なデータサービス３４０は、クエリを満たすｅＩＤを捜すために、検索可能なインデックス３４２に対するクエリを実行する。検索可能なデータサービス３４０は、クエリを満たすｅＩＤリストを含むクエリ結果をクライアント３３０に返すことができる。
【００３６】
以下は、検索可能なデータサービスの実施形態の局面を説明するために本明細書で使用される一部の用語の定義である。
・エンティティ：エンティティとは、ある種のデータストア３３２に保存され、開発者が属性を関連付けることを希望する、任意のデータオブジェクト又はエンティティを指す
・識別子（ｅＩＤ）：開発者が、アプリケーションでエンティティを個別に識別するために使用する文字列（例、ＵＴＦ−８などのコード化文字列）ｅＩＤはロケータとも称される。一部の場合、ｅＩＤはブロブ様エンティティを捜すために使用されてもよい。一実施形態において、検索可能なデータサービスは、開発者によって使用されるストレージソリューションに対し不透過的であってもよい。一実施形態において、ＵＴＦ−８コード化は、ｅＩＤの序列を必要とする機構を支援するために、ｅＩＤに使用することもできる。一実施形態において、ｅＩＤは、バイトの任意配列（しかし、ドメイン又はバケット内では固有である）であってもよい
・属性：文字列で明示され、ｅＩＤに関連し、ｅＩＤのインデックス化及びクエリが基づく｛名前、値｝の１組を指す。一実施形態において、属性はＵＴＦ−８コード化文字列であるため、属性はＵＴＦ−８コード化クエリ式文字列で容易に使用することができる
・インデックス：ｅＩＤに関連する各エンティティは、クエリ式を満たすｅＩＤリストを取り出すためにクエリされるインデックスを有する、又は提供することができる
・配列ＩＤ：最新要求の受信を認識し、最新情報の状態を追跡する、検索可能なデータサービス生成固有識別子。一実施形態において、配列ＩＤは最新要求の一貫性の順列及び維持に使用することができ、高い配列ＩＤを有する要求は世界的に、低い配列ＩＤを有する要求に優先する。一実施形態において、配列ＩＤはクライアントに公開されないことを留意されたい。
・クライアント（例、図２のクライアント３３０）：用語クライアントは、検索可能なデータサービスシステムの使用を希望する検索可能なデータサービス加入者によって開発された、アプリケーション、スクリプト、ソフトウェアなどを表すために使用することができる
・加入者：検索可能なデータサービス加入者は、請求、計測、及び可能性のあるその他の目的のために、加入者識別子によって固有に識別されてもよい。各検索可能なデータサービス加入者は、同一の加入者識別子を使用して、検索可能なデータサービス内のデータにアクセスする１つ以上のクライアントを有してもよい。加入者識別子は、検索可能なデータサービスに保存されている加入者のｅＩＤデータを捜すために、検索可能なデータサービス内で使用されてもよい。加入者は、１つ以上のバケットの所有者であってもよい。加入者は、顧客とも称される
・検索可能なデータサービス要求：クライアントが、本明細書に記載される１つ以上の検索可能なサービス操作を実施するために、ウェブサービスインターフェースを介して、検索可能なデータサービスに送信するコール（データを含む）を指す
・検索可能なデータサービス応答：クライアントにより送信された検索可能なデータサービス要求を処理した後、検索可能なデータサービスをクライアントに返信する応答を指す
・バケット：加入者が、意味的又はその他の目的のために保持することを希望する検索可能なデータサービスオブジェクト群を指す。クエリは、１つのバケット内で適用される。バケットは、ドメイン又は検索可能なインデックスとも称される。各バケットは、バケット識別子によって識別されてもよい。一実施形態において、各加入者識別子は、１つ以上のバケット識別子に関連され、バケット識別子は単一の加入者識別子と関連付けされてもよい
【００３７】
以下は、加入者、バケット、及びエンティティ識別子（ｅＩＤ）の関係を例示する。
加入者−＞バケット−＞ｅＩＤ
【００３８】
一実施形態において、検索可能なデータサービスは、各加入者バケットのｅＩＤ−＞属性テーブルを論理的に維持する。以下は、例示的ｅＩＤ−＞属性テーブルの説明である。
ｅＩＤ 属性
ｋ１       ｛｛名前、値｝｝、｛｛名前、値｝｝、．．．
ｋ２       ｛｛名前、値｝｝、｛｛名前、値｝｝、．．．
ｋ３       ｛｛名前、値｝｝、｛｛名前、値｝｝、．．．
…            …
【００３９】
一実施形態において、各ｅＩＤはテーブル内（バケット内）で固有であり、従って、ｅＩＤは加入者によって提供されるエンティティキーと見なされる。一実施形態において、ｅＩＤは印刷可能文字から構成されてもよい。
【００４０】
属性及び｛名前、値｝の１組の関係を考慮すると、属性は１つの｛名前、値｝の１組によって典型的に表される。しかしながら、一実施形態において、上記テーブル内のいかなる列に同一名で１つ以上の｛名前、値｝の１組を有することは可能で、該名の多値属性を表示する。例えば、ｅＩＤ−＞属性テーブルの以下の例示的列は、キーワード属性は、ｅＩＤと特定される特別なＵＲＬに対して、多値であることを例示する。
ｅＩＤ 属性
＜ｕｒｌ＞    （名＝“キーワード”、値＝“ｘｘｘ”）、（名＝“キーワード”、値＝“ｙｙｙ”）、．．．
【００４１】
一実施形態において、｛名前、値｝１組のすべての値は、文字列として明示される。文字列の比較演算子を数字と同一の真理値に戻すには、該数字はゼロが詰め込まれてもよい。例えば、“＞”が比較文字列である場合、“２１”＞“１００”は真理であるが、比較数字である場合は誤りである。しかしながら、文字列又は数字を比較する場合、“０２１”及び“１００”は同一の真理値を有する。一実施形態において、ＩＳＯ８６０１などのフォーマットが、日時値を文字列として正確に比較するために使用することができる。
【００４２】
一実施形態において、ｅＩＤ−＞属性テーブルの各列は、検索可能なデータサービスオブジェクトと見なされてもよい。検索可能なデータサービスオブジェクトは、以下の通り明示されてもよい。
加入者−＞バケット−＞ｅＩＤ−＞｛属性リスト｝
【００４３】
検索可能なデータサービスオブジェクトは、加入者が、クライアントアプリケーションによって使用され、エンティティ識別子（ｅＩＤ）によって識別されるデータストア内のエンティティを検索するために使用され得るインデックスの構築を希望する場合、作成することができる。検索可能なデータサービスオブジェクトを作成する場合、加入者は少なくとも以下の入力を提供する。
・加入者ＩＤ
・バケット識別子−ドメインを識別する
・ｅＩＤ
・属性リスト−エンティティに関連する｛名前、値｝の１組のリスト
【００４４】
一実施形態において、検索可能なデータサービスは、検索可能なデータサービスデータオブジェクトに、｛名前、値｝の１組として明示される１つ以上の属性を自動的に提供してもよい。これらのその他の属性は、加入者によって提供される属性リストに加え、インデックス付け及び検索されうる。これらの属性は、基本属性とも称される。一実施形態において、すべてのドメイン内及びすべての加入者の検索可能なデータサービスオブジェクトは、これらの基本属性を含んでもよい。別の実施形態において、１つ以上のこれらの基本属性は、任意であってよい。基本属性は、以下を１つ以上含むが、これらに限定されない。
・作成時間／日付−検索可能なデータサービスオブジェクトが作成された日時を示すタイムスタンプ
・最新修正時間／日付−検索可能なデータサービスオブジェクトが最後に修正された日時を示すタイムスタンプ。初期状態では、作成時間／日付と同一であってよい
・最新アクセス時間／日付−検索可能なデータサービスオブジェクトが最後にアクセスされた日時を示すタイムスタンプ
・作成者−検索可能なデータサービスオブジェクトを作成した特定のユーザ／クライアントを示す
・最新修正者−検索可能なデータサービスオブジェクトを最後に修正した特定のユーザ／クライアントを示す
・サイズ−検索可能なデータサービスオブジェクトのサイズ（例、バイト）を示す
・アクセス権−検索可能なデータサービスオブジェクトへのアクセス権を示す
【００４５】
検索可能なデータサービスオブジェクトは、加入者によって指定される属性すべて、及び基本属性がインデックス付けされ、ｅＩＤが継続して保存されると、作成が滞りなく実行されたと見なされる。検索可能なデータサービスオブジェクトの作成に失敗した場合、エラーコード及びメッセージが加入者に送信され、オブジェクトの作成が失敗した理由を示すことができる。
【００４６】
一実施形態において、加入者は、検索可能なデータサービスオブジェクト及び検索可能なデータサービス内によってオブジェクトに関連する基本属性を読み込むことができる。一実施形態において、検索可能なデータサービスオブジェクトは、加入者識別子、バケット識別子、及び検索可能なデータサービスオブジェクトのｅＩＤを指定することで、検索可能なデータサービスから読み込まれることができる。
【００４７】
一実施形態において、加入者は、更新情報と併せて、加入者識別子、バケット識別子、及び更新される検索可能なデータサービスオブジェクトのｅＩＤを提供することで、検索可能なデータサービスオブジェクトの更新ができる。一実施形態において、加入者は、ｅＩＤの追加又は削除、ｅＩＤの属性の追加又は削除及び既存属性に関連する値の修正ができる。一実施形態において、加入者は、少なくとも一部の基本属性を追加、削除、又は修正することはできない。しかしながら、加入者が、検索可能なデータサービスオブジェクトを修正する場合、オブジェクト修正に関連する１つ以上の基本属性を更新することができる。
【００４８】
一実施形態において、検索可能なデータサービスオブジェクトは、加入者が要求メッセージで指定される通りに修正を希望するすべてのｅＩＤ及び属性すべて、及び属性に関連するインデックスが更新された場合に限り、更新が滞りなく実行されたと見なされる。一実施形態において、部分的更新はできない。例えば、要求が修正する必要のある複数の属性を指定し、修正の１つが実施不可能である場合、全体的な更新要求は、修正が実施されることなく失敗する。検索可能なデータサービスオブジェクトの作成に失敗した場合、エラーコード及びメッセージが加入者に送信され、オブジェクトの作成が失敗した理由を示すことができる。
【００４９】
一実施形態において、加入者は、削除する加入者識別子、バケット識別子、オブジェクトのｅＩＤを提供することで、ドメインから既存検索可能なデータサービスオブジェクトを削除できる。一実施形態において、検索可能なデータサービスオブジェクトは、オブジェクトがオブジェクトに関連するｅＩＤにアクセス可能である保証がない場合、及びオブジェクトが検索可能でない場合に限り、検索可能なサービスオブジェクトは滞りなく削除される。一実施形態において、検索可能なデータサービスオブジェクトの削除後、オブジェクトにアクセスするためにｅＩＤが継続して使用される期間があることもある。さらに、オブジェクトはある期間検索可能にすることが可能である。検索可能なデータサービスオブジェクト及びその関連インデックスが削除不可能である場合、削除要求は失敗し、加入者はエラーコード及びメッセージを介し、失敗の通知を受けることになる。一実施形態において、一度検索可能なデータサービスオブジェクトがドメインから削除されると、ｅＩＤはドメイン内で加入者によって再使用されることもある。
【００５０】
一実施形態において、加入者は、加入者のドメイン（バケット）、インデックス付き属性、検索可能なデータサービスオブジェクト、及びｅＩＤのリストを要求することもある。検索可能なデータサービスオブジェクト及び加入者によって提供される属性と併せて、加入者は、検索可能なデータサービスオブジェクトを列記する場合、検索可能なデータサービスによって提供される基本属性へのアクセスも有することができる。一実施形態において、加入者は以下の列記操作の１つ以上を含むが、これらに限らない操作を実施することができる。
・指定プレフィックスに一致する検索可能なデータサービスオブジェクト及び／又はｅＩＤの列記
・加入者に関連し、固有加入者識別子によって識別されるすべてのドメイン（バケット）の列記
・ドメイン下（バケット内）にインデックス付けされたすべての属性の列記
・ドメイン下のすべての検索可能なデータサービスオブジェクト及び／又はｅＩＤの列記
・指定クライアントによってインデックス付けされたすべての属性の列記
・全ドメイン共通の顧客に対する、すべての検索可能なデータサービスオブジェクト及び／又はｅＩＤの列記
・指定属性を有するすべての検索可能なデータサービスオブジェクト及び／又はｅＩＤの列記
【００５１】
多数のドメイン、属性、検索可能なデータサービスオブジェクト又はロケータが、リスト要求の応答として返される場合、検索可能なデータサービスは、リスト結果にページ番号をつける場合がある。クライアントは複数の要求により、ピース（ページ）のリストを取り出すことができる。
【００５２】
一実施形態において、加入者は、ウェブサービスインターフェースにより使用可能なクエリ要求により、検索可能なデータサービスオブジェクト及びｅＩＤを検索してもよい。加入者は、シングルドメイン（バケット）で、検索可能なデータサービスオブジェクトの１つ以上の属性に対してクエリを実行し、クエリ式を満たすｅＩＤのリストを取得してもよい。一実施形態において、検索可能なデータサービスは、クエリ式の属性に対して、以下の操作の１つ以上をサポートする場合があるが、これだけに限定されない。これらの操作は、併用される場合がある。
・ブーリアン（例えば、ＡＮＤ、ＯＲ、ＮＯＴ）
・算術演算子（例えば、＜、＞、＝、！＝、＜＝、＞＝、＜＞）
・文字列（特定された文字列を含む属性）
・開始文字列（特定された文字列を含む属性）
【００５３】
クエリ操作は、クエリ式を満たす、検索可能なデータサービスオブジェクトのｅＩＤを返す場合がある。一実施形態において、完全な検索可能なデータサービスオブジェクトが任意に返される場合がある。一実施形態において、クエリの結果は、加入者によりクエリメッセージにて提供されるソート仕様に基づき、昇順又は降順のいずれかにソートされる場合がある。クエリの応答に多数のｅＩＤが返される場合、検索可能なデータサービスは、クエリ結果にページ番号をつける場合がある。クライアントは、複数の要求により、ピース（ページ）のリストのｅＩＤを取り出すことができる。一実施形態において、クライアントは、クエリメッセージにページ長の仕様を提供し、多数の入力（ｅＩＤ）をページ上に指定する場合がある。
【００５４】
一実施形態において、所望により、加入者は、ドメイン（バケット）を削除する場合がある。ドメインは、ドメイン及びドメインの検索可能なデータサービスオブジェクトの属性に関係するインデックスのすべてが削除された場合にのみ、正常に削除されたとみなされるであろう。ドメインの検索可能なデータサービスオブジェクト及びその関連インデックスが削除不可能である場合、削除要求は失敗し、加入者はエラーコード及びメッセージを介し、失敗の通知を受けることになる。
【００５５】
一実施形態において、加入者はドメイン内のインデックスを削除する場合がある。インデックスは、インデックス内のすべての属性が正常に削除された場合にのみ、正常に削除されたと見なされるであろう。ドメインのインデックスが削除不可能である場合、削除要求は失敗し、加入者はエラーコード及びメッセージを介し、失敗の通知を受けることになる。
【００５６】
検索可能なデータサービスの一実施形態は、ある機構を提供する場合があり、加入者は、当該機構により、少なくともいくつかのバッチモードのバケットに対して実行する操作を提出する場合がある。バッチモード機構は、例えば、検索可能なデータサービスにアップロードしたい、大きなデータセットを有する場合がある加入者により、使用される場合がある。例示的なバッチモード機構は、例えば、加入者が、各行が１つの作業、例えば、検索可能なデータサービスオブジェクトに追加するという作業を示すファイルを提出することを可能にする場合がある。そのようなファイルの例示的行は、以下を含んでもよいが、それらだけに限定されない。
・バケット識別子−ドメインを識別する
・作業−実行する作業を示す。例えば、追加、削除、又は修正
・ｅＩＤ
・属性リスト
【００５７】
例示的な検索可能なデータサービスＡＰＩ
このセクションは一実施形態に従い、ウェブサービスインターフェース３５０を介して、ウェブサービスとして開発者及びクライアントに公開される場合がある、検索可能なデータサービス３４０のための例示的なＡＰＩを記載する。一実施形態において、ＡＰＩは、ＴＨＨＰ／ＴＨＨＰＳ上の完全に表現可能な状態の転送（Ｆｕｌｌｙ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）（ＲＥＳＴ）及び／又はシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）を介して、ウェブサービスプラットフォームを通じ、開発者及びクライアントに提供される場合がある。その他の実施形態は、その他のプロトコルを使用する場合がある。提供されるウェブサービスインターフェース３５０は、アプリケーションアグノスティックである場合がある。
【００５８】
以下に、クライアントにより、一実施形態によるウェブサービスインターフェース３５０を介して、検索可能なデータサービスに対して作成される例示的な要求を記載する。これらの説明は、例示的であり、これらに限定されないことに留意されたい。その他の実施形態は、その他の要求を含む場合があり、及び／又は記載の要求の変化形を含む場合がある。
【００５９】
一実施形態において、検索可能なデータサービスにおいて、以下のクライアント作業の種類が可能である場合がある。これらの作業は、ウェブサービスインターフェースを介して、クライアントに公開される。
・更新：ｅＩＤ属性バケットを更新する作業。例えば、追加、置換、及び削除作業
・リスト属性：ｅＩＤ及びバケット識別子の場合、この作業はｅＩＤの属性をリストする。これは、上記テーブルの左から右に進むに従って、視覚化される場合があり、例えば、引数として「ｋ１」が与えられる場合、「ｋ１」の右のすべての｛名前、値｝の１組が返される
・クエリｅＩＤ：クエリ式の場合、式を満たすバケットから、すべてのｅＩＤを返す。これは、上記テーブルの右から左に進むに従って、視覚化される場合がある。一実施形態において、クエリ式は、ブーリアン演算子（例えば、ＮＯＴ、ＡＮＤ、ＯＲ）を使用して組み合わせた前提の集合である。前提は、属性リストの名前及び／又は値フィールドが、必ず真の状態を保持していなければいけないことを示す
【００６０】
更新作業
これらの検索可能なデータサービス作業は、加入者のｅＩＤ属性バケットを更新するために、クライアントによりウェブサービスインターフェースを介して呼び出される場合がある。
【００６１】
一実施形態において、置換作業は、属性が存在しない場合、属性を作成する場合がある。置換作業の後続呼び出しは、値を修正（更新）し、その属性に対して、常に１つの値しかないようにする場合がある。固有の値を有する属性の更新は、この作業を行わなければいけない。一実施形態において、クライアントの置換作業の呼び出し要求は、１つ以上の、以下の情報を含むが、これらだけに限定されない。
・バケット識別子：加入者のバケットを識別する文字列。バケットが存在しない場合は、１つ作成される場合がある
・ｅＩＤ：クライアントがデータストアのエンティティを捜すために使用する場合がある文字列
・名前：属性の名前を示す文字列
・値：属性の値を示す文字列
・加入者識別子：検索可能なデータサービス加入者を識別し、加入者に請求及び加入者を認証するために使用される場合がある。一実施形態において、加入者の証明書も含まれている場合がある
【００６２】
一実施形態において、追加作業は、属性が存在しない場合、属性を作成する場合がある。同一名で異なる値による追加作業の後続呼び出しは、属性にその他の値を追加し、従って、多値属性の作成を可能にする場合がある。一実施形態において、クライアントの追加作業の呼び出し要求は、１つ以上の、以下の情報を含むが、これらだけに限定されない。
・バケット識別子：加入者のバケットを識別する文字列。バケットが存在しない場合は、１つ作成される場合がある
・ｅＩＤ：クライアントがデータストアのエンティティを捜すために使用する場合がある文字列
・名前：属性の名前を示す文字列
・値：属性の値を示す文字列
・加入者識別子：検索可能なデータサービス加入者を識別し、加入者に請求及び加入者を認証するために使用される場合がある。一実施形態において、加入者の証明書も含まれている場合がある
【００６３】
一実施形態において、削除作業は、任意の名前及び／又は｛名前、値｝の１組が指定されているかにより、以下の１つの操作を呼び出す場合がある。
・特定の名前又は値のいずれかがない場合、削除作業は、与えられたｅＩＤに関するすべての属性を削除する場合がある。一実施形態において、ｅＩＤは、追加又は置換作業により、新しい属性が取り込まれない場合、一定時間経過後、ゴミ収集対象となる。一実施形態において、ｅＩＤを持たないバケットは、ゴミ収集対象となる。一実施形態において、属性は、削除済みとしてマークされる場合があり、アクティブなゴミ収集は実行されない
・名前のみを有し特定の値を有さない場合、削除作業は、その名前を有し、与えられたｅＩＤに関する属性を削除する場合がある。属性は、固有値を有するか、又は多値であるかのいずれかである
・特定の名前及び値を有する場合、削除作業は、与えられたｅＩＤに関する｛名前、値｝の１組を削除する。これは、クライアントが多値属性の１つの特定の値を削除することを可能にする
【００６４】
一実施形態において、クライアントの削除作業の呼び出し要求は、１つ以上の、以下の情報を含むが、これらだけに限定されない。
・バケット識別子：加入者のバケットを識別する文字列
・ｅＩＤ：クライアントがデータストアのエンティティを捜すために使用する場合がある文字列
・名前：属性の名前を示す文字列
・値：属性の値を示す文字列
・加入者識別子：検索可能なデータサービス加入者を識別し、加入者に請求及び加入者を認証するために使用される場合がある。一実施形態において、加入者の証明書も含まれている場合がある
【００６５】
上記に記載の各ｅＩＤ属性バケット更新作業は、更新結果を含むクライアントへの更新応答を生成する。一実施形態において、更新応答は、検索可能なデータサービスへのウェブサービスインターフェースを介して、クライアントに転送される場合がある。一実施形態において、更新応答は、正常に終了した更新作業に対して、クライアントに更新作業が正常に終了したことを通知する、及び更新作業が何かの理由で実行できなかった場合に、クライアントに更新作業に失敗したことを通知するために、クライアントに更新結果を報告するため、クライアントに、送信される場合がある。一実施形態において、上記に記載の各更新作業は、よく似た応答構造を使用する場合がある。以下は、更新作業要求に対する、例示的応答に含まれている場合がある情報を説明する。これは、例示的であり、これらに限定されないことに留意されたい。
・状態：「ＯＫ」又は「エラー」のいずれか。更新が正確に形成され、適応される場合、状態はＯＫとなり、そうでなければ、応答は、エラーメッセージ内に問題を説明する
・エラーメッセージ：更新作業要求が直面したいずれかの問題について、さらに説明する情報。例えば、「要求は、不適切です」
【００６６】
バッチ処理更新要求
一実施形態は、バッチ処理、又はバッチ作業として提出される場合がある更新要求を介して、機構を提供する場合がある。バッチ処理更新要求は、上記に記載の２つ以上の連続更新要求を含む場合があり、バッチ処理更新要求に対する応答は、バッチ処理更新要求に対応する更新状態の連続を含む場合がある。一実施形態において、バッチ処理更新要求に指定される更新作業を、リアルタイムで連続して処理するために、単独のバッチ更新要求に提出される場合のある、更新作業の数に制限がある場合がある。又は、バッチ処理更新要求の更新は、非同期的に実行される場合がある。
【００６７】
リスト属性作業
一実施形態は、ウェブサービスインターフェースを介して、クライアントにより呼び出される場合のある、リスト属性作業を提供する場合がある。リスト属性作業は、特定のｅＩＤに関連する属性のリストを返す場合がある。以下は、更新作業要求に対する、例示的なリスト属性作業要求に含まれている場合がある情報を説明する。これは、例示的であり、これらに限定されないことに留意されたい。
・バケット識別子：加入者のバケットを識別する文字列
・ｅＩＤ：クライアントがデータストアのエンティティを捜すために使用する場合がある文字列
・フィルタ式：ｅＩＤに対して返される属性をフィルタするために使用される場合がある、文字列式。フィルタ式が指定されていない場合、ｅＩＤに関連するすべての属性が返される。フィルタの構文は、以下に記載の「クエリｅＩＤ」に使用されるものに従う。このパラメータは任意である場合がある
・加入者識別子：検索可能なデータサービス加入者を識別し、加入者に請求及び加入者を認証するために使用される場合がある。一実施形態において、加入者の証明書も含まれている場合がある
【００６８】
以下は、更新作業要求に対する、クライアントへの例示的なリスト属性作業応答に含まれている場合がある情報を説明する。
・属性リスト：もしあれば、フィルタ式と一致する｛名前、値｝の１組のリスト要求に対して、フィルタ式が与えられていない場合は、特定のｅＩＤのすべての属性が返される。エラーがない場合、これが予測される返答である
・エラーメッセージ：リスト属性作業要求が直面したいずれの問題について、さらに説明する情報。例えば、「未知のエンティティ識別子」、「未知のバケット」、又は「フィルタ式は、不正な構文」
【００６９】
クエリｅＩＤ作業
一実施形態は、ウェブサービスインターフェースを介して、クライアントにより呼び出される場合のある、クエリｅＩＤ作業、又は単にクエリ作業を提供する場合がある。クエリｅＩＤ作業は、クエリ式により指定される条件と一致する、ｅＩＤのリストを返す。クエリ式は、文字列であり、タイトルが「クエリ構文及び検索式」である以下のセクションで与えられるルール一式に従う場合がある。検索可能なデータサービスの一部の実施形態では、いずれにせよ、暗黙の構文を有する非正規化検索式を受け入れ、１つ異常の正規化ルール（タイトルが「非正規化検索式」のセクションを参照）を使用する標準形に対するメッセージを削減する場合がある。クエリｅＩＤ作業要求は、本明細書でクエリ、クエリ要求、又はクエリノード要求といわれる場合があることに留意されたい。
【００７０】
以下は、更新作業要求に対する、例示的なクエリｅＩＤ作業要求に含まれている場合がある情報を説明する。これらに限定されないことに留意されたい。
・バケット識別子：加入者のバケットを識別する文字列
・クエリ式：文字列式であり、それに従い、ｅＩＤのリストが捜し出される、又は返される場合がある
・ＭｏｒｅＴｏｋｅｎ：不透過的なオブジェクト（例、クッキー）であり、以前のクエリｅＩＤ作業要求でクライアントに返されている場合がある。トークンが先のクエリｅＩＤ作業から返される場合、トークンは、返された以前のクエリｅＩＤ作業要求の応答にて捜し出されたｅＩＤのリストの次のページを要求するために、後続のクエリｅＩＤ作業要求に提供される場合がある。この任意のパラメータである
・加入者識別子：検索可能なデータサービス加入者を識別し、加入者に請求及び加入者を認証するために使用される場合がある。一実施形態において、加入者の証明書も含まれている場合がある
【００７１】
以下は、更新作業要求に対する、クライアントへの例示的なクエリｅＩＤ作業応答に含まれている場合がある情報を説明する。
・エンティティ識別子リスト：クエリ要求に指定される検索条件に一致するｅＩＤのリスト。これは、１つ以上のエラーメッセージが返される場合があるエラーがない限り、予測される返答である
・ＭｏｒｅＴｏｋｅｎ：文字列であり、一実施形態において、ＭｏｒｅＴｏｋｅｎは、クライアントから不透過的である。クエリ要求を満たすｅＩＤのリストが、１つの応答に返すには大きすぎる場合、リストはページで返される場合がある。ＭｏｒｅＴｏｋｅｎ「クッキー」は、「最新表示ページ」を示す場合がある。ＭｏｒｅＴｏｋｅｎクッキーは、ｅＩＤの次のページを取り出すための後続のクエリ要求に含まれる場合がある
・エラーメッセージ：クエリｅＩＤ作業要求が直面したいずれの問題について、さらに説明する情報。例えば、「未知のバケット」、「クエリ式は、正しい構文を持たない」、又は「無効なＭｏｒｅＴｏｋｅｎ」
【００７２】
検索可能なデータサービスアーキテクチャ
以前のセクションは、検索可能なデータサービスの実施形態の開発者／クライアントに公開される例示的なウェブサービスＡＰＩを記載した。以下のセクションでは、検索可能なデータサービス、及び検索可能なデータサービスの実装に含まれている場合がある様々なサブシステム並びにコンポーネントの例示的なアーキテクチャを記載する。
【００７３】
図３は、一実施形態に従い、検索可能なデータサービスの例示的な高位機能構造を例示している。一実施形態において、検索可能なデータサービスは、以下の主なコンポーネント及びサブシステム、ウェブサービスプラットフォーム２００、要求ルーター２０２、クエリサブシステム２０４、及びストレージサブシステム２０６の１つ以上を含む場合があるが、それだけに限定されない。その他の実施形態は、このアーキテクチャレベルにおいて、その他のコンポーネント及び／又はサブシステム、又は数々のコンポーネント及び／又はサブシステムの組み合わせを有する場合があることに留意されたい。
【００７４】
ウェブサービスプラットフォーム２００は、検索可能なデータサービスのフロンドエンドとしての役割を果たす、１つ以上のウェブサーバを含む場合がある。ウェブサービスプラットフォーム２００は、以下の機能の１つ以上を含む場合があるが、それだけに限定されない。
・要求インターセプタを通じて、ウェブサーバは、測定、請求、認証、及び検索可能なデータサービスへのアクセス権のために、１つ以上のその他のサービスと情報のやり取りを行う場合がある
・ウェブサーバは、１つ以上の完全に表現可能な状態の転送（Ｆｕｌｌｙ  ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）（ＲＥＳＴ）及び／又はシンプルオブジェクトアクセスプロトコル（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）（ＳＯＡＰ）ＡＰＩを提供する場合があり、検索可能なデータサービスへのデータの提出する、又は検索可能なデータサービスからのデータの取り出す際、開発者及びクライアントに公開される。その他の実施形態において、１つ以上のその他のプロトコル又はプロトコルの組み合わせが試用される場合があることに留意されたい。これらのＡＰＩは、エンティティロケータ（ｅＩＤ）、及びエンティティＩＤ（ｅＩＤ）ストアのエンティティに関連する属性の受信及び保存を可能にする。属性のインデックスは、ｅＩＤストアから構築される場合がある。一実施形態において、ＡＰＩは、ｅＩＤ及び属性（ストレージノード要求又はストレージ要求と称される場合がある）に対応する以上の１つ以上のＡＰＩコールを提供する場合があるが、それだけに限定されない
・追加−属性（｛名前、値｝の１組）をエンティティに追加する。２つ以上の値を有する場合がある「キーワード」のような属性など、複数の値を有する属性として使用される。
・削除−属性を削除する
・置換−既存の属性を置換する。最初に、１つの値を有する属性とともに使用される場合がある
・リスト属性−エンティティのすべての｛名前、値｝の１組をリストする
・ウェブサーバは、クエリ要求を検索可能なデータサービスに提出するために、１つ以上のＲＥＳＴ及び／又はＳＯＡＰ  ＡＰＩを提供する場合がある。その他の実施形態において、１つ以上のその他のプロトコル又はプロトコルの組み合わせが試用される場合があることに留意されたい。一実施形態において、１つのクエリＡＰＩコール（クエリｅＩＤ）がある場合がある。クエリ要求は、クエリノード要求とも称される
【００７５】
要求ルーター２０２は、以下の機能の１つ以上を実行する場合があるが、それだけに限定されない。
・要求ルーター２０２は、ウェブサービスプラットフォーム２００からサービス要求を受け取り、サービス要求がストレージノード要求（例えば、１つ以上のｅＩＤ及び関連属性の追加、削除、又は置換要求）であるか、又はクエリノード要求（１つ以上の保存されたｅＩＤ及び／又は関連属性を取り出す要求）であるかを判断する場合がある
・サービス要求がストレージノード要求の場合、要求ルーター２０２は、ストレージノードロケータに、要求に指定のｅＩＤ及びバケットを、適切なストレージノードまでマップするように要求する。一実施形態において、検索可能なデータサービスインデックス付けデータは、バケットに分離される場合がある。バケットは、シングルクエリに入ると考えられるデータのリミットを定義する
・サービス要求がクエリノード要求の場合、要求ルーター２０２は、クエリノードロケータに、バケット及びクエリ式を、適切なクエリノードまでマップするように要求する
・要求ルーター２０２は、サービス要求を適切なノードへ送り、結果を回収し、結果をウェブサービスプラットフォーム２００に返す
【００７６】
要求ルーター２０４（クエリサービスと称される場合もある）は、以下の機能の１つ以上を実行する場合があるが、それだけに限定されない。
・クエリの処理する
・可能であれば、クエリサブシステム２０４により保持されるクエリキャッシュからのクエリを提供する
・クエリキャッシュからの満たしていないクエリを実行するために、ストレージサブシステム２０６上の１つ以上のストレージノードに送る小ドメイン（バケット）において、クエリは、一般的に単一ストレージノード上で実行される。より大きなバケットは、複数のストレージノードに渡り分割され、各パーティションの１つのストレージノード上でクエリを実行することを要求する場合がある。要求ルーター２０２と同様に、クエリサブシステム２０４は、適切なストレージノードを検出するために、ストレージノードロケータのローカルインスタンスを使用する場合がある
・２つ以上のストレージノードから受け取ったクエリ結果を集約し、必要に応じて、クエリ結果をソートする
・ウェブサービスプラットフォーム２００に提供されるウェブサービスインターフェースを介して、クエリを実行したクライアントにクエリ結果を返す。一実施形態において、必要に応じて、結果にページ番号をつける
【００７７】
ストレージサブシステム２０６は、１つ以上のストレージノードを含む場合がある。ストレージノードは、１つ以上のデータセンタに位置する場合がある。ストレージノードは、以下の機能の１つ以上を実行する場合があるが、それだけに限定されない。
・ストレージノード上で、ローカルｅＩＤストアは、ｅＩＤ及びそれらの属性に対する権限のあるストアとしての役割を果たす場合がある
・インデックスは、ｅＩＤストアから構築され、ローカルストレージノード上のｅＩＤのすべての属性にインデックスを作成する場合がある
・ローカルクエリプロセッサは、ローカルｅＩＤストアに対してクエリを実行する場合がある
・ｅＩＤ更新サービスは、ストレージノード要求（追加、置換、削除など）をローカルｅＩＤストアに適用する場合がある
・ローカルパーティションマネージャーは、各ストレージノードのローカルリソース（ディスクスペース、ＣＰＵ負荷、ネットワークバンド幅など）の使用を監視し、それに応じてバケットのパーティションを管理する場合があり、パーティションを移動するために、共同してその他のストレージノードと通信を行う場合がある。パーティションは、例えば、ストレージノード上のコンフォートゾーン内のストレージ空き容量を維持するため、及び／又は負荷バランシングを提供するために、移動可能である
・例えば、データの冗長性を提供するために、ストレージノードを渡るパーティションを複製するため、その他のストレージノードと共同して通信する場合がある。
【００７８】
一実施形態において、ウェブサービスプラットフォーム２００は、クライアントが検索可能なデータサービスに対してＡＰＩコールを生成した際の、コンタクトの第１ポイントである。ウェブサービスプラットフォーム２００は、例えば、認証、アクセス制御、ロギング、計測、及び請求サービスを提供する場合がある。ウェブサービスプラットフォーム２００により提供される検索可能なデータサービスＡＰＩサービス要求に対するクライアントからのサービス要求は、２つのカテゴリに分類される場合がある。本明細書では、ストレージノード要求又はストレージ要求と称される場合もある、ストレージサブシステム２０６への書き込み要求、及び本明細書では、クエリノード要求、クエリ要求、又は単にクエリとも称される、クエリサブシステム２０４への読込み要求ストレージノード要求は、ストレージサブシステム２０６のバケットのロケータ（ｅＩＤ）及びそれらの関連属性の追加、置換、又は削除要求を含む場合がある。さらに、一実施形態は、クライアントが、ｅＩＤ及び関連属性が追加されうる新しいドメイン（バケット）の作成を要求できるようにする構築ＡＰＩコールを提供する場合がある。クエリノード要求は、クエリノード要求のクエリ式に従い、ストレージサブシステム２０６のバケットからロケータ（ｅＩＤ）のリストを取得するためのクエリである。
【００７９】
ウェブサービスプラットフォーム２００は、クライアントから入力される要求を、要求ルーター２０２に転送し、一実施形態においては、検索可能なデータサービスのコーディネータノード上で、インスタンス化されている場合がある。一実施形態において、単一障害点を防ぐことによって、負荷を分散し、冗長性を提供するために、２つ以上のコーディネータノード及び／又は要求ルーター２０２が存在する場合がある。１つ以上のコーディネータノード上に存在する場合がある要求ルーター２０２、及び１つ以上のその他の関連するコンポーネントは、調整サブシステム又は調整サービスを構成する場合がある。要求ルーター２０２は、要求がストレージノード要求であるか、又はクエリノード要求であるかを判断するために、入力サービス要求を調べ、要求の受け取りに適切なノード（例えば、ストレージノード又はクエリノード）を決定し、検索可能なデータサービス実装内の決定したノードに、要求を転送する。
【００８０】
要求がストレージノード要求の場合、クライアントは、バケット内に保存されたインデックス付け情報に対して、書き込み作業（例えば、追加、削除、又は置換）を要求している。ストレージノード要求は、リスト属性要求である場合もあることに留意されたい。バケットは、シングルクエリに入ると考えられるデータのリミットを定義する。一実施形態において、バケットは１つ以上のパーティションに分割され、異なるストレージノード上に保存される場合がある。しかし、ストレージノードは、１つ以上のパーティションを保存する場合があることに留意されたい。分割により、検索可能なデータサービスのクライアントは、単一ストレージノードに適合するものより大きな検索可能なインデックスを保存及び維持できるようになる場合がある。従って、バケットの異なるパーティションは、異なるストレージノード上に存在する場合がある。パーティションは、ストレージノードに渡り、複製される場合がある。ストレージノードに渡る（及び場合によってはデータセンタに渡る）パーティションの複製は、検索可能なデータサービスにおける、データの冗長性、従って、クライアントの検索可能なインデックスの耐性、信頼性、及び可用性を提供する場合がある。検索可能なデータサービスのパーティション及び複製機構は、本文献の後でさらに記載する。
【００８１】
一実施形態において、要求がストレージノード要求の場合、要求ルーター２０２は、ローカルストレージノードロケータに、ストレージノード要求に指定されるバケット及びｅＩＤを、ストレージサブシステム２０６の特定のストレージノードまでをマップするように問い合わせる場合がある。また要求ルーター２０２は、ストレージノードロケータに、指定されたバケットが１つのパーティションを有するのか、又は２つ以上のパーティションを有するのかを判断するように問い合わせる場合もある。ストレージノードロケータから受け取った情報から、要求ルーター２０２は、ストレージサブシステム２０６の特定のストレージノードを決定し、そして決定したストレージノードに、ストレージノード要求を転送する。ストレージサブシステム２０６において、ストレージノードは、そのローカルｅＩＤストアに対するストレージノード要求に指定される作業を実行する。ストレージノードは、そして必要に応じて、バケットのパーティションの複製を保存すストレージサブシステム２０６のその他のストレージノードに、ストレージノード要求を伝播する。
【００８２】
要求がクエリノード要求の場合、クライアントは、バケット内に保存されたインデックス付け情報に対して、読み取り作業又は問い合わせを要求している。一実施形態において、要求がクエリノード要求の場合、要求ルーター２０２は、ローカルクエリノードロケータに、要求により指定されるバケット及びクエリ式を、クエリサブシステム２０４の適したクエリノードまでをマップするように問い合わせる場合がある。要求ルーター２０２は、そしてクエリノード要求を、クエリサブシステム２０４の決定されたクエリノードに転送する。
【００８３】
クエリサブシステム２０４のクエリノードにおいて、クエリ要求のいくつかの前処理（例えば、正規化）、例えば、クエリ要求に指定されるクエリ式の正規化が実行される場合がある。一実施形態において、ローカルクエリキャッシュは、クエリキャッシュから、クエリを満たすことができるかどうかを判断するために、調べられる場合がある。ローカルクエリキャッシュから、クエリが満たされる場合、クエリサブシステム２０４は、クエリキャッシュからのクエリ結果を、ウェブサービスプラットフォーム２００を介してクライアントに返す。クエリキャッシュからクエリが満たされない場合は、ストレージノードロケータのローカルインスタンスは、クエリが転送されるストレージサブシステム２０６の１つ以上のストレージノードを捜すように問い合わせられる場合がある。
【００８４】
小ドメイン（バケット）において、クエリは、単一ストレージノード上で実行される場合がある。より大きなドメイン（バケット）は、複数のストレージノードに渡り分割される場合があり、各パーティションに対して１つのストレージノード上でクエリを実行するように要求する場合がある。ストレージノードは、クエリサブシステム２０４のクエリノードに結果（ｅＩＤのリスト）を返す。一実施形態において、クエリサブシステム２０４のクエリノード上のクエリアグリゲータは、クエリノード要求の指定に従い、２つ以上のストレージノードから受け取った結果を集約する場合がある。クエリサブシステム２０４は、そしてストレージノードから受け取ったクエリ結果を、ウェブサービスプラットフォーム２００を介して、クライアントに返す。一実施形態において、クエリサブシステム２０４は、必要に応じて、又は所望により、クエリ結果にページ番号を付ける。クエリノードにおいて、ストレージサブシステム２０６から受け取ったクエリ結果は、ローカルクエリキャッシュに書き込まれる場合がある。
【００８５】
上記に記載のように、要求ルーター２０２は、ローカルストレージノードロケータ及びローカルクエリノードロケータに対して、ストレージノード要求を受け取るストレージノード、及びクエリノード要求を受け取るクエリノードを捜すように問い合わせる場合がある。さらに、クエリノード上のローカルストレージノードロケータは、クエリ要求を受け取るストレージノードを捜すように問い合わせられる場合がある。ストレージノードロケータは、どのストレージノードがストレージサブシステム２０６に存在するか追跡し、クエリノードロケータは、どのクエリノードがクエリサブシステム２０４に存在するかを追跡する。両ノードロケータは、それぞれの追跡中のノード上に情報を記録するために、テーブル又はデータベースを使用する場合がある。一実施形態において、このテーブルは、バークレーデータベースに従い構築される場合がある。一実施形態において、ストレージサブシステム２０６に変更、例えば、バケットが再分割される、パーティションが複製される、新しいストレージノードが追加される、新しい入力がバケットに追加される、などがある場合、変更は、様々なノードロケータに伝達される。クエリノードの追加又は削除などのクエリサブシステム２０６への変更は、クエリノードロケータに伝達される場合がある。一実施形態において、１つのローカルノードロケータは、変更を受けて、最初に更新される場合があり、変更はそして、ゴシッププロトコルに従い、ノードロケータからその他のノード上のその他のノードロケータに伝播される場合がある。
【００８６】
検索可能なデータサービスは、様々なノード及びコンポーネント間の通信機構を含む場合があり、それにより、例えばストレージ及びクエリノードロケータは、検索可能なデータサービス実装（例えば、追加又は削除されたノード、置換、パーティション、ストレージサブシステム２０６への書き込みなど）における変更を監視し、従って、伝達された更新情報に従い、それらのそれぞれのテーブルに保存された情報を更新することが可能になる。一実施形態において、通信機構は、ゴシップ又はエピデミックプロトコルに従い、実装される場合がある。この通信機構は、１つのノード上の変更を、情報を要求する場合がある、検索可能なデータサービス実装すべてのノード及びコンポーネントに変更を伝播することを可能にする場合がある。一実施形態において、通信機構は、一貫性の低い更新を提供し、通信機構は情報を伝播し、従って、すべてのノードに対する即時更新を提供しない。しかし、通信システムは、情報を追跡している場合がある、様々なノード及びコンポーネント間の低一貫性を維持するために十分な速度の更新を伝播する場合がある。一実施形態において、通信機構は、伝達情報がシステムの通信バンド幅に負担をかけすぎないように更新情報を伝播する。一実施形態において、これは、その他の内部コンポーネント又は内部ノード通信上の少なくともいくつかの更新情報をピギーバッキングすることによって達成される場合がある。
【００８７】
一実施形態において、ストレージサブシステム２０６のエンティティＩＤ（ｅＩＤ）ストアは、エンティティロケータ（ｅＩＤ）のテーブルとして実装される場合があり、各ｅＩＤの｛名前、値｝の１組として表される属性のセットは、エンティティと関連する。ｅＩＤストアは、検索可能なデータサービスの情報の権限を有するストアである。検索可能なデータサービスのクライアントアプリケーションが、ウェブサービスプラットフォーム２００により提供されるウェブサービスインターフェースに対するストレージノード要求を介して、検索可能なデータサービスに情報を書き込む場合、ストレージノード要求は、要求ルーター２０２により、ストレージサブシステム２０６内の特定のストレージノードへ送られ、ストレージノード上で、情報はローカルｅＩＤストアに書き込まれる。情報は、特定のアプリケーションに関連する特定のバケットに書き込まれる場合があり、バケット情報は、ストレージノード要求に提供される場合があることに留意されたい。従って、異なるクライアントアプリケーションの情報は、異なるバケットに書き込まれる場合がある。一実施形態において、検索可能なデータサービスの加入者は、特定のアプリケーションの検索可能なインデックスの作成を開始する場合、加入者は、検索可能なインデックス（バケット）にバケット識別子を提供する場合がある。検索可能なインデックスに対して、要求（例えば、クエリ）が作成された場合、要求は、検索可能なインデックスのバケット識別子を参照する。加入者は、検索可能なデータサービスの複数の加入者を識別するために使用される場合がある、固有の加入者識別子が提供される場合があることに留意されたい。一実施形態において、ウェブサービスプラットフォームは、加入者に加入者識別子を割り当てる場合がある。特定の加入者は、１つ以上の検索可能なインデックスを有する場合があり、それぞれにバケットが割り当てられ、バケット識別子が与えられる。従って、特定の加入者識別子及び特定のバケット識別子は、検索可能なデータサービスのドメインを特定する。バケットは、２つ以上の異なるストレージノード上の２つ以上のローカルｅＩＤストアに渡って分散されることがあることに留意されたい。ストレージノード要求又はクエリノード要求が送られる特定のストレージノードｅＩＤストアは、要求内に指定される加入者識別子、バケット識別子、及びｅＩＤにより決定される場合がある。
【００８８】
一度情報がｅＩＤストアに追加されると、ｅＩＤストアのインデックスが構築される場合がある。上記に記載のように、ｅＩＤストアの各ｅＩＤは、｛名前、値｝の１組で保存される関連する属性のセットを有する。各名前は、インデックスに対応し、各インデックスは、｛名前、値｝の１組の特定の名前に対応する。一実施形態において、インデックス（インデックスの各行）は、名前に関連する値によりソートされている場合がある。一実施形態において、インデックスは、ローカルｅＩＤストアに関連するローカルクエリインデックスストアに保存されている場合がある。インデックスは、特定のバケットに特有であることに留意されたい。一実施形態において、しかしながら、インデックスは小さなバケットがたくさんある場合は、多くの小さなデータ構造を有することを避けるために、バケットを渡って連結されている場合がある。
【００８９】
例として、ｅＩＤストア及び関連インデックスは、販売商品項目の情報データベース（データストア）、例えば、本を販売するオンライン商業ウェブサイトの本などに対して構築される場合がある。項目の１つの属性は、項目の販売価格である場合がある。従って、データベースの項目の情報のｅＩＤは、ｅＩＤストアに提供され、追加される場合がある。各ｅＩＤは、関連する｛名前、値｝の１組のセットを有し、関連項目の様々な属性の名前及び値を示す。例えば、項目のこれら｛名前、値｝の１組の１つは、「販売価格−＜金額＞」である場合がある。従って、インデックスは、属性名「販売価格」に対して作成される。このインデックスは、「販売価格」の値でソートされてもよい。クライアントは、クライアントは、特定の「販売価格」、指定金額未満の「販売価格」、などを有するｅＩＤを要求していることを示すクエリ式を含む、クエリ要求を提出する場合がある。インデックスは、そしてクエリ式を満たす「販売価格」値を有するデータストア内の項目を捜すために使用される場合がある。クエリを満たす「販売価格」値を有するデータストアの項目のすべてのｅＩＤは、クエリ結果で、問い合わせているクライアントに返される場合がある。
【００９０】
一実施形態において、ストレージサブシステム２０６は、バケットを１つのパーティションとして初期化する場合がある。バケットに情報が追加されるに従い、バケットは、最終的に１つのストレージノードに適合するには大きすぎる、又はその付近点まで成長する場合がある。ストレージノードの空きストレージ容量が非常に少なくなる、ある程度前に（すなわち、ストレージノードの空きストレージ容量がコンフォートゾーンである間に）、バケットを、２つ（又はそれ以上）のパーティションに再分割し、パーティションの１つ（又はそれ以上）は、別のストレージノードに移動し、バケットが継続して成長できるようにする場合がある。このバケットの再分割は、クライアントアプリケーションからは透過的に実行される場合がある。分割は、その他の理由、例えば、サービス要求に負荷バランシングを提供するために実行される場合もあることに留意されたい。検索可能なデータサービスの分割機構は、本文献の後にさらに記載する。
【００９１】
検索可能なデータサービスの実施形態は、クライアントが、以前にバケットに追加された入力を削除することを可能にするインターフェースを提供する場合がある。一実施形態において、これらの入力は、ｅＩＤストアで削除済みとしてマークされるが、ディスクから削除されていない。別の実施形態において、これらの入力は削除対象としてマークされ、検索可能なデータサービスは、定期的又は不定期的にゴミ収集し、削除対象としてマークされた、いずれの入力を削除する機構を提供する場合がある。一実施形態において、バケットが、２つ以上のパーティションを作成するために、以前に再分割され、結果的に入力がバケットから削除されている場合は、検索可能なデータサービスは、ストレージノード上に単一の結合されたパーティションを保存するために十分なディスク容量がある場合は、２つ以上のパーティションを１つのパーティションに結合する機構を提供する場合がある。
【００９２】
バケットの再分割は、バケット（又はバケットのパーティション）が単一ストレージノードに適合するには大きすぎる、又はその付近点である場合に、実行される場合がある。従って、本明細書に記載のバケットの再分割は、バケットが、クライアントのストレージ要求の成長とともに、バケットが成長できるようにする場合がある。一方、例えば、ストレージノード及び／又はデータセンタに渡って冗長性、データ耐性、データ可用性、及び負荷分散を提供するために、２つ以上のストレージノードに渡るパーティションの置換が実行される場合がある。１つのデータセンタ内、又はデータセンタに渡る２つ以上のストレージノードへのパーティションの置換は、１つのパーティションしか有さないバケットに対しても実行される場合がある。
【００９３】
一実施形態において、検索可能なデータサービスは、物理的に２つ以上のデータセンタに存在するノード又はホスト上に実装される場合があるということに留意されたい。各データセンタは、検索可能なデータサービスの実装に関与する２つ以上のノードを含む場合がある。データセンタの検索可能なデータサービスノードは、１つ以上のコーディネータノード（要求ルーター２０２のインスタンスを受け入れるノード）、１つ以上のクエリノード、及び１つ以上のストレージノードを含む場合があるが、それらだけに限定されない。データセンタ内のストレージノード上のパーティションは、データセンタ内の１つ以上のその他のストレージノードに複製される場合があり、及び／又は１つ以上のその他のデータセンタ内の１つ以上のストレージノードに複製される場合があるデータセンタ内での複製は、データセンタ内でのノード障害を防グ場合があり、データセンタ内のノードに負荷バランシングを提供する場合がある。データセンタを渡る複製は、データセンタレベルでの障害を防ぎ、データセンタに渡る負荷バランシングを提供する場合がある。
【００９４】
一実施形態において、検索可能なデータサービスが２つ以上のデータセンタに渡って実装されている場合、単一パーティションを有するバケットは、少なくとも４つのパーティションの複製を有する場合がある。このバケットが存在する、いずれの特定のデータセンタにおいて、パーティションは、少なくとも２つのストレージノードに複製される場合があり、また少なくとも１つのその他のデータセンタにも複製される場合がある。その他のデータセンタにおいて、パーティションは、データセンタ内の少なくとも２つのストレージノードに複製される場合がある。バケットが１つ以上のパーティションを有する場合、各パーティションは、データセンタ内のストレージノードに渡って同様に複製される場合があり、及び／又はデータセンタに渡るストレージノードに複製される場合もある。
【００９５】
一実施形態において、遅延複製機構は、パーティションの複製に使用される場合がある。一実施形態において、パーティションを複製する際、２つの種類の通信がノード間で実行される場合がある。一実施形態において、パーティションの複製は、データセンタ内及びデータセンタに渡る検索可能なデータサービスノード、並びにコンポーネント間で、少なくとも部分的にゴシッププロトコル系の通信機構とアンチエントロピー系の通信機構を併用して実行される場合がある。アンチエントロピープロトコルは、ゴシッププロトコルより高速な通信を提供する場合がある。初期の一貫性を確実にするために、アンチエントロピープロトコルを使用し、パーティションのデータ構造全体を、その他のストレージノードに複製する場合がある。とはいうものの、それまでの間に、更新が受け取られ、元のパーティションに適用される場合がある。従って、アンチエントロピー複製の実行中に、元のストレージノード上で受け取った元のパーティションへの更新は、ゴシッププロトコルを使用し、その他のストレージノードの新しい複製に伝播される場合がある。アンチエントロピーを介して複製されるパーティションの複製は、時間の経過とともに、徐々に古くなっていく。しかし、受け取られたいずれの更新は、新しい複製に伝達される。パーティションのアンチエントロピー複製が完了し、新しい複製がオンラインになる準備が整うと、新しい複製は、伝達された更新により、最新である場合がある。
【００９６】
一実施形態において、検索可能なデータサービスは、２４／７にできる限り近い、検索可能なインデックスの可用性及び信頼性をクライアントに提供するよう試みる場合があり、ストレージノード又はデータセンタ全体までもが、何かの理由で使用負荷になった場合でも、確実に検索可能なインデックスが使用可能であり、いずれの追加又は修正を含む最新であるようにする機構を提供する場合がある。データセンタ内及びデータセンタを渡る両方のストレージノードを渡るパーティションの複製は、本機構の一部である。使用可能な複製が確実に最新であることを助長するために、一実施形態において、データストアのエンティティへの入力が、ローカルｅＩＤストアに追加された、又はローカルｅＩＤストアで修正された場合、ストレージノード上のローカルｅＩＤストアに対して行われた変更は、ストレージサブシステム２０６の更新サービスにより、その他のストレージノード上のその他のｅＩＤストアの１つ以上に対しても行われる場合がある。一実施形態において、各ストレージノード上のｅＩＤ更新管理コンポーネントのインスタンスは、更新サービス機能をストレージノードに実装する場合がある。一実施形態において、更新サービスは、各更新が、その他のストレージノード上の複製の２つ以上に確実に適用されるようにするが、必ずしもすべての複製に対してではない。ストレージノード間のゴシッププロトコルは、そして更新をすべての複製に伝播するために使用される場合がある。
【００９７】
一実施形態において、データセンタのストレージノード上のローカルｅＩＤストアに更新が行われ、更新が正常に行われた事を示す応答がクライアントに返る前、ストレージサブシステム２０６の更新サービスは、データセンタのストレージノードのその他のｅＩＤストアの少なくとも１つ、及びその他のデータセンタのストレージノードのその他のローカルｅＩＤストアの少なくとも１つに確実に更新が行われるように動作する場合がある。一実施形態において、データセンタ内のストレージノード上のローカルｅＩＤに最初の更新が行われた場合、ストレージサブシステム２０６の更新サービスは、更新が正常におこなわれたという応答をクライアントに送信する前に、他のデータセンタの少なくとも２つのローカルストレージノード、及び少なくとも１つのストレージノードに対して更新が正常に行われたという確認を待つ。従って、何らかの理由により、元のストレージノード又はデータセンタ全体までもがオフラインに成る場合、最新の複製は、同一データセンタの他のストレージノード、又は異なるデータセンタに存在する他のストレージノードから入手可能である場合がある。更新は、クライアントは、パーティションの複製を受け入れるすべてのストレージノードに更新が伝播される前に、更新が正常に行われたと通知されたとしても、パーティションのすべての複製は、ゴシッププロトコルを使用する更新サービスにより、一貫性が低く維持されるように他のストレージノードに伝播される場合があることに留意されたい。
【００９８】
特定のパーティション又はバケットのパーティションを複製するストレージノードは、複製グループと考えてもよい。複製グループのストレージノードは、パーティションの同一、又はほぼ同一のコピー又は複製である。一実施形態において、パーティションに対する更新は、ゴシッププロトコルを使用し、複製グループ内のストレージノードに伝播される場合がある。従って、「同一」は、低い一貫性を提供するゴシッププロトコルの制限を受けやすい場合がある。ある時点において、複製グループ内のパーティションは、必ずしも同一である必要はないが、ゴシッププロトコルを介して更新が伝播されると同時に、同一になるよう収束しなければいけない。
【００９９】
一実施形態において、複製グループ内に維持されるパーティションの複製の数は、データセンタのハードウェアの監視される可用性及び信頼性の統計による場合がある。検索可能なデータサービスがハードウェアはあまり信頼性又は可用性がないと認める場合、複製グループ内により多くの複製が作成される場合がある。より信頼性があり、可用性があるハードウェアは、より少ない複製を維持することを可能にする。一実施形態において、複製グループ内に、少なくとも４つから、最高６つまでのパーティションの複製が存在する場合がある。これは、データの耐性、信頼性、及び可用性を提供するために作成され、維持される複製に関連することに留意されたい。一実施形態において、複製グループ内で維持されるパーティションの複製の数は、２つ以上のデータセンタに渡るハードウェアの監視される可用性及び信頼性の統計による場合がある。一実施形態において、複製グループ内に維持されるパーティションの複製の数は、少なくともネットワークの操作特性の機能の一部でもある場合がある。本実施形態において、例えば、ネットワークの障害モード、ネットワークの応答時間、ネットワーク上でのデータ取り出しのエラー率、又は１つ以上のその他の要素又はその組み合わせの１つ以上を含む場合があるが、それらだけに限定されない要素に基づき、データの耐性が向上される場合がある。
【０１００】
一実施形態において、パーティションの複製は、検索可能なデータサービスのグループメンバーシップ及びヘルスコンポーネントにより、特定のパーティション又はパーティションの特定の複製の読み取りが非常に盛んであり、パーティション又は複製グループ内の特定の複製がたくさんの読み取り（クエリメッセージ）を受け取っていることが検出される状況において、実行される場合もある。検索可能なデータサービスは、パーティション又は複製が、読み込みのコンフォートゾーンを越えそうな限界のクエリを受信しているということの検出に伴い、より多くの複製に渡ってクエリを分散し、従って、追加ストレージノードに渡る読み取り（クエリ）負荷の負荷バランシングを提供するために、パーティションの追加複製を１つ以上作成する場合がある。
【０１０１】
バケットに対する高書き込み負荷（例えば、クライアントからバケットへの追加又は更新入力メッセージ）が検出された場合、パーティション又はバケット内のパーティションの追加複製を作成することは、役に立たない場合がある。変わりに、追加複製の作成は、更新は、ゴシッププロトコルを使用して複製に伝播され、より多くの複製がより多くのゴシップを複製グループ内に生成する傾向にあることから、逆効果を生じる場合がある。従って、一実施形態において、検索可能なデータサービスにより、バケットが書き込みが盛んであり、少なくとも一部のストレージノードがそれらのコンフォートゾーンの境界線に接近している場合があることが検出された場合、検索可能なデータサービスは、より多くのパーティションの複製を作成するよりは、バケット内のデータがより多くのストレージノードを渡り分散されるようにバケットを再分割する場合があり、従って、書き込み負荷はより多くのストレージノードに渡って負荷バランシングされる場合がある。
【０１０２】
一実施形態において、複製が必要なパーティションを有するストレージノードは、この情報を１つ以上のその他のストレージノードに、例えばゴシッププロトコルを使用して伝達する場合がある。データセンタ内又は別のデータセンタのその他のストレージノードの１つ以上は、パーティションの複製を進んで受け入れる場合がある。別のストレージノードへの実際の複製における情報は、検索可能なデータサービスのドメイン内（バケット内）の複製の状態のトラックできるようにするために、検索可能なデータサービスのノード上のその他のコンポーネント（例えば、コーディネータノード及びクエリノード上のストレージノードロケータ）に伝達される場合がある。
【０１０３】
ストレージノード上のパーティションの再分割に関する情報は、検索可能なデータサービスのドメイン内のパーティションの状態がトラックできるように、同様に、その他のノードのその他のコンポーネントに伝達される場合がある。パーティションをあるストレージノードから別のストレージノードに移動する必要がある場合、この情報は、１つ以上のその他のストレージノードに伝達される場合があり、この情報を受け取るストレージノードは、そして進んでこのパーティションを受け入れる場合がある。パーティションを移動する必要のあるストレージノードは、そしてパーティションを受け取るために最適なストレージノード候補を選択する。検索可能なデータサービスシステムの一実施形態におけるストレージノード上のディスク負荷を管理するためのストレス管理アルゴリズムを実装し、パーティションを受け取るために最適なストレージノード候補を２つ以上のストレージノード候補から選択するために使用される場合がある、例示的なストレス管理機構を、本文献の後部、表題「ストレス管理」のセクションに記載する。
【０１０４】
問題又は危機状態に対する反動応答としてパーティションを再分割又は複製する代わりに、検索可能なデータサービスは、ノードが、ストレージサブシステム２０６内のストレージノード上のストレージリソースを含むノード上の様々なリソースの使用及びヘルスを監視し、ヘルス情報を検索可能なデータサービス内のノード間で共有し、検索可能なデータサービス内の様々なリソースの潜在的高ストレス又は負荷を避けるように積極的に働くことを可能にする、１つ以上の機構を提供する場合がある。一実施形態において、コンフォートゾーンは、検索可能なデータサービス内の様々なリソースに対して定義され、検索可能なデータサービスは、リソースが、それらの個々のコンフォートゾーンを越えないように積極的に働く場合がある。
【０１０５】
検索可能なデータサービスは、リソースがそのコンフォートゾーンの境界に近づきつつあることを検出した場合、特定のアクションを実行する場合がある。ストレージサブシステム２０６のストレージノードに対するこれらのアクションは、複製及び再分割を含むが、それらだけに限定されない。検索可能なデータサービスは、ストレージノードの使用及びヘルス、並びにクエリノード及びコーディネータノードなどのその他の種類のリソースを監視する場合があり、潜在的危機に先立ち（いわゆる、リソースがまだコンフォートゾーンにある間に）、リソースが既にストレス下になるまで待たずに、アクション（例えば、ストレージノードの再分割又は複製）の実行を試みる場合がある。システムが、リソースが既にストレスを受けるようになるまで、ストレスを開放するための、再分割又は複製などのいくつかのアクションの実行を試みることを待つとすると、リソースは既に内部及び外部要求により過剰状態となる場合があり、アクションの実行がさらに困難になる。従って、検索可能なデータサービスは、システム内のリソースの可用性及び信頼性をサポートするヘルス管理に対して、反応性アプローチとは反対である、先を見越したアプローチを提供する。
【０１０６】
一実施形態において、検索可能なデータサービスの各ノードは、ノードのコントロール及びモニタリングエージェントとしての役割を果たす、ノードマネージャーコンポーネントのインスタンスを含む場合がある。ノードマネージャーコンポーネントは、ノード上の様々なリソースのヘルス情報を監視する自己モニタリングエージェントとしての役割を果たす場合があり、リソースは、ディスク使用量、バンド幅使用量、ＣＰＵ使用量、読み取り及び／又は書き込み負荷などを含む場合があるが、それだけに限定されない。
【０１０７】
一実施形態において、検索可能なデータサービスの各ノード上のストレス管理コンポーネントは、ノードマネージャーにより収集されたノードのリソースのヘルス評価指数がそのコンフォートゾーンの限界である、又は限界に近いかどうかを検出する場合があり、検出の応答として、適切なアクションを開始する場合がある。ストレスマネージャーは、リソースがそのコンフォートゾーンの限界である、又は近い場合に、実行すべきアクションを決定するために使用される、１つ以上のアルゴリズムを実装する場合がある。例えば、ストレージノード上のストレージ空き容量がそのコンフォートゾーンの境界に近づいている場合、ストレスマネージャーは、新しく作成されたパーティションは、別のストレージノードに移動されるようにノード上で再分割を開始する場合があり、従って、ストレージノードのディスク容量を開放する。再分割は、実際にはローカルパーティションマネージャーの管理化で実行されることに留意されたい。
【０１０８】
ノードマネージャーコンポーネントは、ノードが検索可能なデータサービス実装の全体的なヘルスモニタリング及び維持に関与することを可能にする場合がある。ノードマネージャーコンポーネントは、特定のノード上のリソースヘルスを監視する。一実施形態において、別のコンポーネントは、ノードヘルスを、その他のノードと比較するために、ローカル周辺又はノードグループのその他のノードヘルスを監視する場合がある。
【０１０９】
一実施形態において、検索可能なデータサービスの各ノードは、グループメンバーシップ及びヘルスコンポーネントのインスタンスを有する場合がある。一実施形態において、様々なノード上のグループメンバーシップ及びヘルスコンポーネントは、局所で収集されたノードのヘルス情報を、検索可能なデータサービスのローカル周辺又はノードグループ内のその他のノードに伝達することを可能にする。一実施形態において、グループメンバーシップ及びヘルスコンポーネントは、検索可能なデータサービスのその他のコンポーネントが、監視されるノードのセットを識別し、自動更新されるそれらのノードに関するヘルス情報に問い合わせることを可能にする。グループメンバーシップ及びヘルスコンポーネントは、例えば、障害検出機構としての役割を果たす場合がある。グループメンバーシップ及びヘルスコンポーネントは、ノードがそのローカルヘルスを、周辺又はグループ内のその他のノードと比較することを可能にする。
【０１１０】
一実施形態において、検索可能なデータサービスの各ノードは、グループメンバーシップ及びヘルス機構により、その周辺又はノードグループ内のその他のノードから受け取る、そのローカルリソースのヘルス及びヘルスメッセージに基づき、局所決定を行う場合がある。これは、中央制御装置に頼らずに、ローカルノード及びノードグループに渡る検索可能なデータサービスのヘルスモニタリング並びにリソースの管理を供給する場合がある。従って、一実施形態において、検索可能なデータサービス実装全体のヘルスを監視し、リソースの最適化を試みる中央制御が存在せず、従って、単一障害点がない場合がある。ヘルスモニタリング及び維持は、中央制御装置による代わりに、ノード上で局所的に、及びノードグループ内で共同して実行されるため、ヘルス情報の全体リストを維持する必要がなく、より少ないヘルス情報を、検索可能なデータサービス実装に渡り、全体に伝達すればよい。
【０１１１】
ローカルノードマネージャーにより、各ノードはそれ自身のリソース使用量及びヘルスを監視する。各ノードは、ローカル周辺又はグループ内のその他のノードも監視する場合がある。ローカルストレスマネージャーは、ノードマネージャーにより収集されるリソース使用量及びヘルス情報にアクセスする。ストレージノード上のストレスマネージャーが、ノードは、そのデータを再分割する必要があると判断する場合、ストレージノードは、別のストレージノード上に新しく作成されたパーティションを受け入れるように強制しない。代わりに、この情報は、例えばグループメンバーシップ及びヘルス機構により、その他のローカルストレージノードと共有される。ディスク空き容量を有するその他のローカルストレージノード（この場合もやはり、ノードマネージャーにより局所的に監視される）は、グループメンバーシップ及びヘルス機構を介して共有されるヘルス情報の再分割が必要なその他のストレージノードを捜す場合がある。空き容量を有するストレージノードが、パーティションの移動を必要とする別のストレージノードを検出する場合、進んでパーティションを受け入れるように決定する場合がある。
【０１１２】
従って、特定のグループ内のストレージノードは、それら自身の間で、データの再分割に関して同意する場合がある。これは、すべてのノードが関連するグループの決定として実行する必要がない場合がある。代わりに、２つのストレージノードが共同してデータを再分割することに同意し、その１つのノードは進んで新しいパーティションを受け入れる。このグループ通信及び連携は、特定のデータセンタ内のノード間で生じる場合もあるが、データセンタを渡るノード間でも生じる場合があることに留意されたい。
【０１１３】
最初、バケットが作成されたとき、バケットは１つのパーティションを含む。パーティションは、複製グループを形成する２つ以上のストレージノードに渡って複製される場合がある。２つ以上の新しいパーティションを形成するために、複製されたパーティションが再分割される際、それぞれの新しいパーティションは、複製グループになる。最初、新しく作成されたパーティションは、同一ストレージノード上に存在する。従って、各ストレージノードは、１つ以上の複製グループの構成員である場合がある。パーティションの再分割は、複製グループ内のすべてのストレージノード上で実行され、まだ１つのバケットが存在し、最初、すべてのデータは同位置に存在する。データの半分は、しかしながら、パーティションＡに存在し、もう半分は、パーティションＢに存在する。複製はまだ同一ストレージノード上に存在するため、いずれにせよ、いずれのストレージノードの潜在的ストレージ容量問題は再分割により解決されていない。各ストレージノードは、そのストレージ空き容量がコンフォートゾーンの限界に近づいている場合、可能であれば、パーティションを別のストレージノードに移動することを決定する場合がある。一実施形態において、別のストレージノードは、一実施形態において、ゴシッププロトコルを介して捜し出される場合、進んでパーティションを受け入れる決定をする場合がある。パーティションをその他のストレージノードにコピーすることは、いずれの更新をパーティションの複製に適用するために使用されるゴシッププロトコルとともに、パーティションの複製のためのアンチエントロピー機構を使用して実行される場合がある。このパーティションの移動は、危機状態の回避を助長するために、ストレージの空き容量がコンフォートゾーンである間に、進んで実行される場合がある。
【０１１４】
上記に記載のように、ノードグループの１種類は、複製グループである。複製グループ内の各ストレージノードは、特定のパーティションの複製を保存する。パーティションが成長するにつれ、複製グループ内のストレージノードのいずれかは、ノード上のストレージ空き容量がそのコンフォートゾーンの限界に近づいていることを検出する場合があり、従ってローカル複製を分割する必要がある場合がある。一実施形態において、パーティションが複製グループ内のストレージノードのいずれかにとって大きすぎるようになりつつある場合、パーティションは、その他のストレージノードにはディスク空き容量があるとしても、すべてのストレージノード上で再分割される場合がある。新しく作成されたパーティションは、最初はすべてのパーティションが同一のストレージノードのセットに存在するとしても、それぞれ独立した複製グループを構成する場合がある。従って、複製されたパーティションの再分割は、以前は１つの複製グループしか存在していなかった所に、２つの複製グループも生成する。ストレージ空き容量がコンフォートゾーンの限界又は限界付近であるストレージノードの１つは、そしてその新しく作成されたパーティションの１つの複製を、進んでパーティションを受け入れる別のストレージノードに移動する場合がある。例えば、別のノードは、複製グループに結合又は追加される場合があり、進んでパーティションを受け入れる場合がある。複製グループ内のその他のストレージノードは、十分なディスク容量を有する場合があり、従って、パーティションを移動しない場合がある。
【０１１５】
図４は、一実施形態に従い、検索可能なデータサービスの例示的なネットワークアーキテクチャを例示している。検索可能なデータサービス実装は、ウェブサービスプラットフォーム２００、１つ以上のコーディネータノード３５０、クエリＴＳＡＲ（Ｔｏｐ  Ｓｅａｒｃｈ  ＡｇｇｒｅｇａｔｏＲ）ノードと称される１つ以上のクエリノード３６０、及び１つ以上のストレージノード３７０を含む場合があるが、それだけに限定されない。各コーディネータノード３５０は、要求ルーター２０２の少なくとも１つのインスタンスを含む場合があるが、それだけに限定されない。
【０１１６】
図３に記載の高位機能クエリサブシステム２０４及びストレージサブシステム２０６は、必ずではないが、クエリＴＳＡＲノード３６０及びストレージノード３７０上のそれぞれに直接マップする場合があることに留意されたい。各サブシステムは、図６を参照してさらに下記に記載される、いくつかのコンポーネントを含む場合がある。一実施形態において、クエリサブシステム２０４のコンポーネントは、クエリＴＳＡＲノード３６０上に存在し、ストレージサブシステム２０６のコンポーネントは、ストレージノード３７０上にマップする。又は、機能的にサブシステムの１つの部分と考えられる場合がある特定のコンポーネントは、物理的にコーディネータノード３５０、クエリＴＳＡＲノード３６０、又はストレージノード３７０上に存在する場合がある。例えば、各ストレージノード３７０は、図６のローカルクエリプロセッサ２２８のインスタンスを含む場合があり、機能的にクエリサブシステム２０４の一部と考えられる場合があるが、必ずというわけではない。さらに、図６に描かれる検索可能なデータサービスのいくつかのコンポーネントは、ノードの異なるもの上にローカルインスタンスを有する場合がある。例えば、一実施形態において、各コーディネータノード３５０上及び各クエリＴＳＡＲノード３６０上の、ストレージノードロケータ２１６のローカルインスタンスが存在する場合がある。
【０１１７】
データストア３３２は、データ（エンティティ）のユニットが保存される場合がある、データストレージシステムを示す。データストア３３２は、エンティティを捜し、取り出すために、ロケータが使用される場合がある、いずれの種類のストレージシステムに従って実装される場合がある。クライアントシステム３３０上に、バックエンドデータストア３３２に対する検索フロントエンドとして検索可能なデータサービスを活用するアプリケーションが実装される場合がある。一実施形態において、アプリケーションは、バックエンドデータストア３３２のデータを検索、及び取り出すためのウェブサービスプラットフォーム２００のウェブサービスインターフェースに従い、検索可能なデータサービスの機能性にアクセスするように設定されている場合がある。
【０１１８】
検索可能なデータサービスを、バックエンドデータストア３３２に対する検索フロントエンドとして活用するアプリケーションは、検索可能なデータサービスの加入者と称される場合がある。検索可能なデータサービス実装は、２以上の加入者を有する場合があることに留意されたい。すなわち、検索可能なデータサービス実装は、検索可能なインデックスを２つ以上のバックエンドデータストアに提供する場合がある。またアプリケーションは、２つ以上のバックエンドデータストア３３２に対する検索フロントエンドとして、検索可能なデータサービス実装を活用する場合があることにも留意されたい。２つ以上のバックエンドデータストア３３２に対する検索フロントエンドとして、検索可能なデータサービス実装を活用し、そのため、従って検索可能なデータサービス実装に、２つ以上の検索可能なインデックスが実装されるアプリケーションは、各検索可能なインデックスの加入者として別々に、及び一意的に識別される場合がある。固有の加入者識別子は、検索可能なデータサービスへの各加入に割り当てられる場合があり、加入者識別子は、特定のデータストア３３２に対して、特定の検索可能なインデックスを一意的に識別するために使用される場合がある。２つ以上のクライアントシステム３３０は、関連固有加入者識別子を使用し、検索可能なデータサービス実装の特定の検索可能なインデックスにアクセスする場合があることに留意されたい。
【０１１９】
一実施形態において、クライアントシステム３３０は、インターネット３３４を介して、ウェブサービスプラットフォームのウェブサービスインターフェースに従い、検索可能なデータサービスに、サービス要求（クエリノード要求及び／又はストレージノード要求）を提出する場合がある。ウェブサービスプラットフォーム２００は、サービス要求をコーディネータノード３５０まで送る場合がある。コーディネータノード３５０は、サービス要求を適切なノードまで送り、結果を回収し、結果をウェブサービスプラットフォーム２００に送り返す。コーディネータノード３５０上の要求ルーターは、ウェブサービスプラットフォーム２００からサービス要求を受け取り、各サービス要求がストレージノード要求か、又はクエリノード要求かを判断する場合がある。サービス要求がストレージノード要求の場合、要求ルーターは、ストレージノードロケータに、要求に指定されるｅＩＤ及びバケットから適切なストレージノード３７０までをマップするように問い合わせる。サービス要求がクエリノード要求の場合、要求ルーターはクエリノードロケータに、要求に指定されるバケット及びクエリ式から適切なクエリＴＳＡＲノード３６０までをマップするように問い合わせる。一実施形態において、ストレージノードロケータ及びクエリノードロケータは、各コーディネータノード３５０上に位置するインスタンスを有する検索可能なデータサービスのコンポーネントである場合がある。
【０１２０】
コーディネータノード３５０からのクエリノード要求を受信次第、クエリＴＳＡＲノード３６０は、クエリを１つ以上のストレージノード３７０に転送する前に、クエリの処理を実行する場合がある。クエリＴＳＡＲノード３６０は、クエリを実行するために、クエリを適切なストレージノード３７０に転送する場合がある。小さなドメインに対して、クエリは一般的に単一ストレージノード３７０上で実行される場合がある。より大きなドメインは、複数のストレージノード３７０を渡り分割され、クエリが１つのストレージノード３７０バケットは、複数のストレージノードに渡り分割され、各パーティションの１つのストレージノード上でクエリを実行することを要求する場合がある。分割は、本文献の後でさらに記載する。クエリＴＳＡＲノード３６０は、クエリの適切なストレージノード３７０を捜すために、ストレージノードロケータのローカルインスタンスを使用する場合がある。クエリＴＳＡＲノード３６０は、ストレージノード３７０から受け取ったクエリの結果を集約し、ソートする場合がある。クエリＴＳＡＲノード３６０は、そしてクエリの結果をコーディネータノード３５０に返す場合がある。一実施形態において、クエリＴＳＡＲノード３６０は、必要に応じて、又は所望により、ページ番号を付ける場合がある。
【０１２１】
ストレージノード３７０上で、ｅＩＤストアは、ｅＩＤ及びそれらの属性に対する権限ストアとしての役割を果たす場合がある。ローカルストレージノード３７０上のｅＩＤのすべての属性にインデックスをつける場合がある、ｅＩＤストアからインデックスが構築される場合がある。ローカルクエリプロセッサは、クエリＴＳＡＲノード３６０から受信したクエリを、ストレージノード３７０上のインデックスに対して実行する場合がある。ｅＩＤ更新サービスは、コーディネータノード３５０からストレージノード要求を受け取り、それに応じてｅＩＤストアを更新する場合がある。ローカルパーティションマネージャーは、ストレージノード３７０のローカルリソース（ディスクスペース、ＣＰＵ負荷、ネットワークバンド幅など）の使用を監視する場合があり、必要に応じて、パーティションを再分散するために、その他のストレージノード３７０上のその他のパーティションマネージャーと通信し、それに応じてバケットのパーティションを管理する場合があり、パーティションを移動するために、共同してその他のストレージノードと通信を行う場合がある。
【０１２２】
図５Ａ及び５Ｂは、一実施形態に従い、検索可能なインデックスの検索可能なデータサービスオブジェクトを保存し、検索可能なインデックスのデータストアにあるエンティティの識別子（ｅＩＤｓ）を捜すサービス要求を処理する検索可能なデータサービスを実装する方法を例示している。各検索可能なデータサービスオブジェクトは、データストアの特定のエンティティの２つ以上の属性を指定する場合がある。各属性は、｛名前、値｝の１組で表示される場合があり、属性は、データストアの特定のエンティティを位置付けるための固有のエンティティ識別子（ｅＩＤ）を含む場合がある。
【０１２３】
検索可能なデータサービスシステムは、複数のノード上に実装される場合がある。ノードは、１つのデータセンタ内に位置する場合、又は２つ以上のデータセンタに分散されている場合がある。データセンタは、地理的に分散している場合がある。一実施形態において、検索可能なデータサービスは、少なくとも調整サブシステム、クエリサブシステム、及びストレージサブシステムを含んでいる場合がある。一実施形態において、複数のノードは、調整サブシステムを実装する１つ以上のコーディネータノード、クエリサブシステムを実装する１つ以上のクエリノード（クエリＴＳＡＲノードとも称される）、及びストレージサブシステムを実装するストレージノードを含んでいる場合がある。一実施形態において、ウェブサービスプラットフォームは、検索可能なデータサービスのクライアントアプリケーションに対して１つ以上のインターフェースコールを提供する、検索可能なデータサービスに対してウェブサービスインターフェースを提供する場合がある。
【０１２４】
図５Ａにおいて、ウェブサービスプラットフォームは、１０００で示されるように、検索可能なデータサービスのウェブサービスインターフェースに従い、クライアントアプリケーションからサービス要求を受け取る場合がある。ウェブサービスプラットフォームは、１００２で示されるように、そして検索可能なデータサービスのコーディネータノードにサービス要求を転送する場合がある。一実施形態において、ウェブサービスプラットフォームは、検索可能なデータサービスの計測、請求、認証、及び加入者のアクセス制御を実行する１つ以上のその他のサービスを提供する場合がある。
【０１２５】
１００４で示されるように、コーディネータノードは、サービス要求がクエリノード要求（検索可能なインデックスの読み取り作業）であるか、又はストレージノード要求（検索可能なインデックスへの書き込み作業、又はリスト属性要求）であるかを判断する場合がある。一実施形態において、検索可能なデータサービスの要求ルーターコンポーネントは、当該判断を実行する場合がある。１００４において、サービス要求がストレージ要求である場合、１００６に示されるように、コーディネータノードは、ストレージノード要求を受け取るストレージノードを捜す場合がある。一実施形態において、検索可能なデータサービスの要求ルーターコンポーネントは、ストレージノード要求を受信するストレージノードを位置付けるために、検索可能なデータサービスのローカルストレージノードロケータコンポーネントを調べる場合がある。１００８に示されるように、コーディネータノードは、そしてストレージノード要求を決定されたストレージノードに転送する場合がある。
【０１２６】
ストレージノード要求を受信次第、ストレージノードは、１０１０に示されるように、検索可能なインデックスのパーティションを、ストレージノード要求に従い修正する場合がある。一実施形態において、ストレージノードは、以下を実行する場合がある。
・ストレージ要求に指定の検索可能なデータサービスオブジェクトを検索可能なインデックスに追加する
・検索可能なインデックスに保存されている検索可能なデータサービスオブジェクトをストレージ要求に指定されるように修正する
・検索可能なインデックスから、検索可能なデータサービスオブジェクトを、ストレージ要求に指定されるように削除する、又は
・ストレージノード要求がリスト属性要求の場合、エンティティのすべての｛名前、値｝の１組のリストをコンパイルし、返す。リスト属性要求は、パーティションの修正を生じない場合があることに留意されたい
【０１２７】
１０１２に示されるように、パーティションの変更は、修正されたパーティションの複製を保存する、その他のストレージノードの１つ以上に伝播される場合がある。一実施形態において、ゴシッププロトコルに従い、その他のストレージノードに伝播される場合がある。一実施形態において、アンチエントロピープロトコルも、パーティションのその他の複製に変更を伝播するために使用される場合がある。１０１４に示されるように、ウェブサービスインターフェースに従い、ストレージノード要求の成功又は失敗を示す応答が、クライアントアプリケーションに返される場合がある。
【０１２８】
１００４において、サービス要求がクエリノード要求である場合、コーディネータノードは、１０１６に示されるように、クエリノード要求を受信するクエリノードを位置付ける場合がある。一実施形態において、検索可能なデータサービスの要求ルーターコンポーネントは、クエリノード要求を受け取るクエリノードを捜すために、検索可能なデータサービスのローカルクエリノードロケータコンポーネントを調べる場合がある。１０１８に示されるように、コーディネータノードは、そしてクエリノード要求を決定されたストレージノードに転送する場合がある。アイテム１０２０は、フローチャートが図５Ｂに続いていることを示す。
【０１２９】
図５Ｂにおいて、クエリノードは、コーディネータノードからクエリノード要求を受け取り、クエリノード要求を処理する。一実施形態において、クエリノードは、クエリノード要求のいくつかの処理、例えば、クエリノード要求に指定される非正規化クエリ式の正規化を実行する。１０２２に示されるように、クエリノードは、クエリノード要求に指定されるクエリ式が、以前のクエリノード要求の結果をキャッシュに保存するローカルクエリキャッシュにより満たされるかどうかを判断する場合がある。１０２４において、クエリノードがローカルクエリキャッシュから満たされる場合は、１０２６に示されるように、クエリノードは、ローカルクエリキャッシュから取り出したクエリ結果を、ウェブサービスインターフェースに従い、クライアントアプリケーションに返す場合がある。
【０１３０】
１０２４において、クエリノード要求が、ローカルクエリキャッシュから満たされない場合は、１０２８に示されるように、クエリノードは、クエリノード要求を受け取り、処理するために適した１つ以上のストレージノードを捜す場合がある。一実施形態において、クエリノードは、検索可能なデータサービスのローカルストレージノードロケータコンポーネントを調べ、ストレージノード要求を受け取る１つ以上のストレージノードを捜す場合がある。１０３０に示されるように、クエリノードは、そしてクエリノード要求を決定されたストレージノードに転送する場合がある。
【０１３１】
１０３２に示されるように、クエリノードからクエリノード要求を受け取る各ストレージノードは、検索可能なインデックスのローカルパーティションを検索し、クエリノード要求により指定されるクエリ式を満たす検索可能なデータサービスオブジェクトを捜す場合がある。１０３４に示されるように、それぞれのストレージノードは、そしてクエリ式を満たすクエリ結果を、クエリノードに返す場合がある。一実施形態において、クエリ結果は、１０３６に示されるように、ローカルクエリキャッシュに保存される場合がある。クエリノードは、１０３８に示されるように、必要に応じて、又は所望により、クエリ結果の結合、ソート、及び／又はページ番号付けを実行する場合がある。１つ以上のストレージノードからクエリ結果を受け取る場合、クエリ結果を結合する必要がある場合がある。クエリ結果がページ限度を超過する場合、クエリ結果はページ番号を付けられ、２つ以上の応答メッセージにてクライアントアプリケーションに返される場合がある。一実施形態において、クエリ結果は、クリエノード要求に指定されるソート条件に従って、ソートされる場合がある。一実施形態において、クエリ結果は、少なくとも、検索可能なインデックス中の、クエリノード要求に指定されるクエリ式を満たす各検索可能なデータサービスオブジェクトからのエンティティ識別子（ｅＩＤ）を含む場合がる。１０４０に示されるように、クエリノードは、ストレージノードから受け取ったクエリ結果を、ウェブサービスインターフェースに従い、クライアントアプリケーションに返す場合がある。
【０１３２】
図６は、一実施形態に従い、検索可能なデータサービスの例示的な下位モジュラーアーキテクチャを例示している。この図は、検索可能なデータサービスの様々なモジュール、又はコンポーネントを通るデータフローを示す。本実施形態において、検索可能なデータサービスは、示されるコンポーネントの１つ以上を含む場合があるが、それだけに限定されない。検索可能なデータサービスの実装は、少なくとも、いくつかの記載のコンポーネントの２つ以上を含む場合があることに留意されたい。
【０１３３】
以下に、ウェブサービスプラットフォーム２００により提供されるウェブサービスＡＰＩに対する追加要求（ストレージノード要求の一種）を使用して、検索可能なデータサービスに新しい情報が提出された場合の、検索可能なデータサービスの実施形態における、例示的なデータフローを記載する。ＲＥＳＴ又はＳＯＡＰ要求がウェブサービスプラットフォーム２００に届くと、認証され、タイムスタンプを押され、要求ルーター２０２に渡される。要求ルーター２０２は、ストレージノードロケータ２１６に、データを保存している場合がある１つ以上のストレージノード２７０のリストを要求し、データをリスト上の１つのノードに送る。ストレージノード２７０上のエンティティＩＤ更新マネージャー２３０は、データを受け取り、データを自身のローカルエンティティＩＤストア２３６に保存し、データを少なくとも別のローカルストレージノード２７０、及び別のデータセンタに存在する２つのストレージノード２７０に送る。すべてのこれらのストレージノードがデータを保存後、ＲＥＳＴ又はＳＯＡＰコールは、「成功」結果を返す。
【０１３４】
以下に、クエリノード要求又はクエリを処理する際の、検索可能なデータサービスの実施形態における、例示的なデータフローを記載する。ＲＥＳＴ又はＳＯＡＰ要求がウェブサービスプラットフォーム２００に届き、認証され、要求ルーター２０２に渡される。要求ルーター２０２は、クエリノードロケータ２２０に、クエリを処理可能なクエリＴＳＡＲ（Ｔｏｐ  Ｓｅａｒｃｈ  ＡｇｇｒｅｇａｔｏＲｓ）２１２のリストを要求し、そのリスト上の１つのノード（クエリＴＳＡＲ２１２）にクエリを送る。クエリＴＳＡＲ２１２は、最初にクエリがクエリキャッシュ２１４により満たされるかどうかを判断する。満たされる場合、クエリ応答をウェブサービスプラットフォーム２００に送り返す要求ルーター２０２に返し、そこからクエリ応答は、ウェブサービスインターフェースに従い、クエリを起動したクライアントアプリケーションに返される場合がある。
【０１３５】
クエリが、クエリキャッシュ２１４から回答を得られない場合、クエリＴＳＡＲ２１２は、ローカルストレージノードロケータ２１６に、バケットのパーティション、及びこれらのパーティションの複製を保存するストレージノードホストのセットを要求する。クエリＴＳＡＲ２１２は、そして各パーティションから１つのストレージノードホストのローカルクエリプロセッサ２２８にクエリを送る場合がある。ローカルクエリプロセッサ２２８は、クエリを満たすすべてのｅＩＤを捜す場合がある。これらのリストは、そしてクエリＴＳＡＲ２１２に返され、リストは集約される。集約されたリストは、ソートされ、問い合わせているクライアントに返される場合がある。
【０１３６】
検索可能なデータサービスの実施形態は、高可用性及び信頼性要件を有する大きな分散型システム上で実行される場合がある。これらの環境において、検索可能なデータサービスの実施形態は、高可用性及び信頼性要件を満たすために、システムリソースを監視及び管理する場合がある。一実施形態において、グループメンバーシップ及びヘルスコンポーネント２２６は、各ノード上で実行される場合があり、１つ以上のその他のノードのＣＰＵ、ディスク、メモリ、ネットワーク稼働率、及びその他のローカルシステム計測に関するローカルヘルス情報と情報をやり取りする場合がある。グループヘルス２２６コンポーネントは、複製グループのメンバーシップを追跡記録し、ノードが検索可能なデータサービスシステム環境に出入りする際にも追跡記録する場合がある。
【０１３７】
パーティションマネージャー２３２は、複製グループへのストレージノードホストの割り当て、及びバケットの複数のパーティションへの分割を担当する。これは、ディスク容量が少ない中で実行されているノードが、データセットを分割することを可能にし、いくつかのデータは、別のノードに移動される場合がある。いつ、どのようにデータを分割し、移動するかを決定するための例示的なアルゴリズムを、以下の本文献に記載する。
【０１３８】
一実施形態において、すべての検索可能なデータサービスノードは、その他の検索可能なデータサービスノードと情報をやり取りするために、グループ通信コンポーネント２２２を使用する場合がある。一実施形態において、グループ通信コンポーネント２２２は、エピデミック（ゴシップ）及びアンチエントロピー内部ノード通信を提供する場合がある。
【０１３９】
検索可能なデータサービスの一実施形態において、データストアの更新を要求する場合、各更新要求に対して、要求ルーター２０２は、連続トークンを生成する場合がある。連続トークンは、順序ＩＤ及びおそらくその他のシステム情報を獲得する場合がある。クライアントは、所望により、順序ＩＤを連続トークンから抽出する場合がある。一実施形態において、検索可能なデータサービスは、要求を、この順序ＩＤにより与えられる順序に従い、適用する場合がある。その他の実施形態は、その他の方法を使用して更新に順番をつける場合があることに留意されたい。
【０１４０】
一実施形態において、順序ＩＤは、そのローカルＮＴＰ同期時間に基づき、要求ルーター２０２により生成される場合がある。その他の実施形態は、順序ＩＤを生成するために、その他の基準を使用する場合がある。ＮＴＰ同期時間は、不完全な同期システムであり、クロックスキューにより、更新の準が反転している場合があることに留意されたい。しかし、順序ＩＤを生成するための基準としてＮＴＰ同期時間を使用する一実施形態において、クライアントは、この順序に同意しない場合、更新が適用される、及び更新を再提出する順序を決定する場合がある。
【０１４１】
一実施形態において、クライアントは、次の検索可能なデータサービスの要求と一緒に、受け取った最後の連続トークンを送るように要求される場合がある。一実施形態において、検索可能なデータサービスは、受け取った最後の連続トークンを使用し、クロックスキュー及び順序に関するデータを収集する場合がある。一実施形態において、検索可能なデータサービスは、必要に応じて、収集されたデータにより決定されるように、更新の順序に影響を与えるために、クライアントにより供給される最後の連続トークンを使用する場合がある。
【０１４２】
データ区分及び複製
検索可能なデータサービスの実施形態は、ストレージサブシステム２０６におけるインデキシングデータの、データ区分及び複製のための１つ以上の機構を提供することができる。データ区分は、検索可能なデータサービスのクライアントが、もしそうでなければ単一のストレージノード上に納まることができる以上に大きい検索可能なインデックスを保存、及び維持することを可能にすることができる。データ複製は、保存、及び検索可能なデータサービスを介してクライアントアプリケーションからのクエリにアクセス可能とされた加入者のデータストアに対して、検索可能なインデックスの持続性、信頼性、及び可用性のための検索可能なインデックスにおける冗長性を提供することができる。
【０１４３】
検索可能なデータサービスの実施形態におけるデータ区分、及びデータ複製の一側面は、データ区分、及びデータ複製を制御するセントラルコントローラがないことである。その代わりに、データ区分、及びデータ複製のタスクを、検索可能なデータサービスシステムにおける様々なノード、及びコンポーネント間で分配することができる。
【０１４４】
図７は、一実施形態に従い、検索可能なデータサービスシステムの検索可能なインデックスを区分する方法を例示している。検索可能なデータサービスシステムは、複数のノード上に実装することができる。ノードは１つのデータセンタに位置付けられてもよく、又は２つ以上のデータセンタに分散されてもよい。データセンタは、地理的に分散することができる。一実施形態では、検索可能なデータサービスは、少なくとも１つのコーディネーションサブシステム、クエリサブシステム、及びストレージサブシステムを含むことがある。一実施形態では、複数のノードは、コーディネーションサブシステムを実装する１つ以上のコーディネータノード、クエリサブシステムを実装する１つ以上のクエリノード（クエリＴＳＡＲノードとも呼ばれる）、及びストレージサブシステムを実装する１つ以上のストレージノードを含むことがある。一実施形態では、ウェブサービスプラットフォームは、１つ以上のインタフェースコールを、検索可能なデータサービスのクライアントアプリケーションに提供する検索可能なデータサービスに、ウェブサービスインタフェースを提供することがある。
【０１４５】
１０５０に示すように、検索可能なデータサービスは、単一のストレージノード上に保存される単一のパーティションとして、データストアに対する検索可能なインデックスを初期化することが可能である。１０５２に示すように、時間とともにパーティションは増大することが可能である。例えば、検索可能なデータサービスオブジェクトを検索可能なインデックスに追加するように、クライアントアプリケーションからストレージ要求が受信されると、パーティションは増大することが可能である。ある時点で、検索可能なデータサービスは、ストレージノード上の利用可能なディスクスペースが、ストレージノード上の利用可能なディスクスペースに対するコンフォートゾーンの限度にある、又は限度に近いことを検出することが可能である。
【０１４６】
検索可能なインデックスが増大し続けることを可能にするために、１０５４に示すように、２つ以上の新しいパーティションを生成するよう、パーティションは再区分されることが可能である。新しいパーティションのそれぞれは、検索可能なインデックスにおいて、検索可能なデータサービスオブジェクトの異なるサブセットを含むことが可能である。次に、新しいパーティションの１つ以上は、１つ以上の他のストレージノードに移動され、したがって１０５６に示すように、ストレージノード上のストレージ空間を使用可能にすることができる。一実施形態では、別のノードが協力して、自ら新しいパーティションを取り出し保存することが可能である。一実地形態では、パーティションを移動する必要があるストレージノードは、ストレージノードがパーティションを移動する必要があることを示すストレージノードのグループ内で、メッセージを送信することが可能である。次に、メッセージを受信するストレージノードの１つ以上は、自らパーティションを保存することが可能である。次に、ストレージノードは、パーティションを保存するボランティアから、最適なストレージノードを選択するすることが可能であり、次に、選択されたストレージノードと協力して、パーティションを他のストレージノードへ移動することが可能である。ここで留意すべきは、２つのノード上で保存される異なるパーティションは増大し続けることが可能であり、したがって、必要に応じて次に他のストレージノードへ移動されることがある、新しいパーティションを生成するために、再区分されることが可能であるということである。したがって、他のストレージノードへのパーティションの再区分及び移動は、検索可能なインデックスのパーティションが、単一のストレージノードのストレージリミットを越えて増大することを可能にする。検索可能なデータサービスシステムの一実施形態において、ストレージノード上でディスク負荷を管理するためのストレス管理アルゴリズムを実装し、パーティションを受信する２つ以上のボランティアストレージノードのうちで、最適なストレージノードを選択するために使用されることが可能である、例示的ストレス管理機構は、本文書において、ストレス管理という題名の項において後述される。
【０１４７】
ここで留意すべきは、２つ以上の新しいパーティションを作成するためのパーティションの再区分、及びストレージノードから１つ以上の他のストレージノードへの、１つ以上のパーティションの移動はまた、検索可能なインデックスへの書き込み負荷を負荷分散するために行われることが可能であるということである。ストレージノードが、パーティションへの書き込み負荷がストレージノードへの書き込みに対するコンフォートゾーンの限度にある、又は限度に近いことを検出する場合、ストレージノードはパーティションを再区分し、書き込み負荷の一部を他のストレージノードへ移動するために、上述のように、新しいパーティションの少なくとも１つを別のストレージノードへ、協力して移動することが可能である。
【０１４８】
図８は、一実施形態に従い、検索可能なデータサービスシステムの検索可能なインデックスのパーティションを複製する方法を例示している。データ複製は、検索可能なインデックスの持続性、信頼性、及び可用性のための検索可能なインデックスにおける冗長性を提供することができる。パーティションの複製はまた、ストレージノードの供給源に対する１つ以上の使用評価指標を負荷分散するために行われることが可能である。一実施形態では、ストレージノードが、パーティションへの読み込み負荷がストレージノードへの読み込みに対するコンフォートゾーンの限度にある、又は限度に近いことを検出する場合、パーティションの複製は、パーティションへの読み込み負荷を負荷分散するために行われることが可能である。一実施形態では、ストレージノードが、ストレージノード上のＣＰＵ負荷がストレージノードへのＣＰＵ負荷に対するコンフォートゾーンの限度にある、又は限度に近いことを検出する場合、パーティションの複製は、ストレージノード上のＣＰＵ負荷を負荷分散するために行われることが可能である。
【０１４９】
ストレージノードによって保存されるパーティションを複製するために、ストレージノードは、１１００に示すように、パーティションの複製を受信するよう別のストレージノードを位置付けることができる。一実施形態では、他のノードは協力して、自ら複製を受信及び保存する。一実施形態では、パーティションを複製したいストレージノードは、ストレージノードが複製を受信するボランティアを探していることを示すストレージノードのグループ内で、メッセージを送信することが可能である。次に、メッセージを受信するストレージノードの１つ以上は、自ら複製を保存することが可能である。次に、ストレージノードは、複製を保存するボランティアから、最適なストレージノードを選択するすることが可能であり、選択されたストレージノードと協力して、パーティションを他のストレージノードへ複製することが可能である。
【０１５０】
次に、１１０２に示すように、ストレージノードは協力して、アンチエントロピープロトコルを使用して、パーティションを他のストレージノードへ複製することが可能である。ここで留意すべきは、検索可能なインデックスに関するストレージノード要求が受信及び処理されると、パーティションは複製の間に潜在的に更新されることが可能であるということである。一実施形態では、パーティション及び複製間の一致性を得るために、１１０４に示すように、他のストレージノードへ更新を伝えるためのゴシッププロトコルを使用して、複製は、パーティションへ受信された更新と共に更新されることが可能である。ここで留意すべきは、ゴシッププロトコルは、パーティションの複製間の弱一致性をもたらす場合があることである。また、ここで留意すべきは、パーティションの複製の更新は、ゴシッププロトコルを使用して実行され続け、したがって複製間の弱一致性を維持する場合があることである。
【０１５１】
パーティションが複製されるストレージノードは、パーティションを保存するストレージノードと同じデータセンタ内にあることが可能であるか、又は別のストレージセンタにあることが可能である。一実施形態では、検索可能なデータサービスは、データセンタ内でパーティションの少なくとも２つの複製、及び少なくとも１つの他のデータセンタ内でパーティションの少なくとも２つの複製を作成、及び維持することができる。
【０１５２】
データ区分
図９Ａ及び９Ｂは、検索可能なデータサービスの一実施形態に従い、加入者の検索可能なインデックス、各加入者２５０のデータのバケットへの分離、及びバケットの区分を例示している。各加入者２５０に対して、検索可能なデータサービスデータはバケットに分離され、それは単一のクエリにおいて考慮されることが可能であるデータの限度を定義する。図９Ａでは、検索可能なデータサービスクライアント（又は加入者）が、加入者２５０Ａによって識別される検索可能なインデックスにデータを追加するとき、クライアントは、属性を有するロケータ（ｅＬＤ）をバケット２５２に提出する。各バケット２５２は、初めは単一のストレージノード上にある。データセットが無制限に増大することが可能であるため、パーティションは、ストレージノード上のディスクの物理的容量を超えることがある。一実施形態では、この可能性を考慮するために、図９Ｂに図解するように、バケット内のデータを２つ以上のパーティション２５４にわたって分割することができる。図９Ｂでは、パーティション２５４を形成するするために、図９Ａのバケット２５２が分割されていることが示される。例えば、バケット２５２Ａは、パーティション２５４Ａ、２５４Ｂ、及び２５４Ｃに分割されている。ここで留意すべきは、一実施形態において、各パーティション２５４が、単一のストレージノード上にあることである。しかしながら、２つ以上のパーティション２５４が、単一のストレージノード上にあってもよい。
【０１５３】
パーティション２５４が増大すると、ディスクはスペースがなくなり、１つ以上のパーティション２５４を、別のストレージノードに移動させる必要がある場合がある。一実施形態では、検索可能なデータサービスのストレスマネージャーコンポーネントは、ストレージノード間のパーティション２５４の移動を管理するタスクの、少なくとも一部を行うことができる。検索可能なデータサービスの実施形態におけるデータ区分は、パーティションマネージャー２３２のコンポーネント、及びストレスマネージャーコンポーネントに関連して、以下でさらに説明される。
【０１５４】
データ複製
図９Ｃは、一実施形態に従い、パーティションの複製を介するデータ複製を例示している。一実施形態では、データ持続性及びフォルトトレランスに関して、データセット（バケットパーティション２５４）は、いくつかのストレージノードにわたって複製されてもよい。図９Ｃでは、複製グループ２５６を形成するために、図９Ｂのパーティション２５４は複製されている。例えば、図９Ｃでは、複製グループ２５６Ａ、２５６Ｂ、及び２５６Ｃを形成するために、バケット２５２Ａのパーティション２５４Ａ、２５４Ｂ、及び２５４Ｃは複製されている。複製は、検索可能なデータサービスの実施形態が、複製グループ２５６にわたってクエリ負荷を分散することを可能することができ、したがって、検索可能なデータサービス上の持続的な「読み込みストレス」への対応として必要な、又は望ましい場合がある。さらに、１つ以上のストレージノードが機能しなくなると、検索可能なデータサービスの実施形態は、複製グループ２５６を密集の状態に保つために、新しいストレージノードを支給することができる。複製グループの形成の詳細は、グループメンバーシップ及びヘルスコンポーネントに関連して、以下でさらに説明される。
【０１５５】
パーティションマネージャー
一実施形態では、検索可能なデータサービスのパーティションマネージャー２３２のコンポーネントは、ディスク（ストレージ）スペースの不足の結果として、及び／又は高いプロセス負荷から生じることがあるホットスポットを軽減するために、検索可能なデータサービスシステムを再構成するための決定を下し、アクションを実行する責任を有する。パーティションマネージャー２３２のコンポーネントは、検索可能なデータサービスシステムにおけるホスト、又はノード上のストレスの平衡を保つ傾向がある分散型演算処理（ホスト、又はノードにわたって分配される）として機能することができる。
【０１５６】
一実施形態では、パーティションマネージャー２３２は、以下の行動の１つ以上を実行するがそれらに限定されない。
・ホスト（ストレージノード）は、複製グループ２５６に追加されてもよい。
・ホスト（ストレージノード）は、複製グループ２５６から取り除かれてもよい。
・パーティション２５４は、分割されてもよい。
・パーティション２５４は、別のパーティションとマージされてもよい。
【０１５７】
一実施形態では、パーティションマネージャー２３２は、グループメンバーシップ及びヘルスコンポーネント２２６によって回収され、受信されたグループヘルス情報に従って、これらの行動を実行する。
【０１５８】
パーティション
一実施形態では、パーティション２５４は、エンティティＩＤ（ｅＩＤ）のハッシュに基づいて形成することができる。以下は、プロバイドｅＩＤが特定のパーティション内にあるかどうか示す、ブーリアン（真又は偽）を返信する例示的な関数である。
bool inPartition(String eID, int mask, int value)
{
int h = hash(eID);
return (h & mask) == value;
}
【０１５９】
様々なハッシュ関数のいずれも、様々な実施形態において使用することができる。一実施形態では、ハッシュ関数は、検索可能なデータサービスのクロスプラットフォーム実装をサポートするために、明確に特定することができる。例示的な一実施形態では、ＩＳＯ３３０９に定義されるように、ＣＲＣ３２は、パーティションを決定するためのハッシュ関数として使用することができる。ＣＲＣ３２は、意図的な悪意のある入力を除いて、ほとんど何に対しても円滑な分配を生成することができる。一実施形態では、より大きい演算処理の費用と交換に、暗号安全ハッシュを使用することによって、悪意のある入力の可能性を回避することが可能である。
【０１６０】
パーティションの分割及びマージ
検索可能なデータサービスデータはバケット２５２に分離され、それは単一のクエリにおいて考慮されることが可能であるデータの限度を定義する。一実施形態では、任意量のクエリ処理能力をバケット２５２に追加することができるように、クエリされるバケット２５２は、フォルトトレランスに必要とされる最小数を超えて複製されることが可能である。しかしながら、バケット２５２は、検索可能なデータサービスシステム内のホスト上に保存されるには、あまりにも大きくなる場合があり、及び／又はクライアントシステムから過剰な数の更新を受信する場合がある。バケット２５２の複製は、これらの潜在的状況から生じる可能性がある問題に対応しない場合がある。一実施形態では、これらの潜在的状況に対応するために、バケット２５２は、データの分かれたパーティション２５４に分割することができる。
【０１６１】
一実施形態では、データストアの更新は、更新されるエンティティを含むパーティション２５４のメンバにのみ送信される必要がある。しかしながら、クエリは、バケット２５２におけるすべてのパーティション２５４に対して行われ、次に、クエリの結果は、クエリサブシステム２０４において、クエリアグリゲータによってマージされる。したがって、パーティション２５４の数は、バケット２５２のストレージ要求によって決定されてもよく、一方で、各複製グループ２５６におけるホストの数は、バケット２５２に対するクエリの数によって決定することができる。
【０１６２】
検索可能なデータサービスの実施形態は、単一で、潜在的に異種のホストを複製グループ２５６に追加することによって、バケット２５２の増分スケーリングを可能にする、拡張可能ハッシングと同様の機構を提供することができる。この機構は、検索可能なデータサービスシステムが、異種のマシンをうまく利用することを可能にすることができ、また他の利点もあるが、バケット２５２に対する区分が、動的に変化することを可能にすることができる。一実施形態では、検索可能なデータサービスエンティティを区分するためのアルゴリズムは、エンティティ識別子（ｅＩＤ）が整数にハッシュされる場合に用いられてもよく、その整数の最下位ビットは、パーティション２５４を決定するために調査される。一実施形態では、調査される上位ビットの数は、パーティション２５４間で異なることがある。
【０１６３】
図１０は、一実施形態に従い、複製グループのパーティションの分割を例示している。本実施形態では、バケット２５４におけるパーティション２５４の数は、複製グループ２５６におけるパーティション２５４の分割によって、増加することができる。所定のハッシュのサフィックスに対する複製グループ２５６は、もう１ビットをサフィックスに追加することによって形成されることが可能な２つのサフィックスに対応する、２つのパーティション（２つの複製グループ）になる。図１０に図解される例では、ハッシュのサフィックス＿１０の複製グループ２５６Ｎは、サフィックス＿０１０及び＿１１０によって識別される、２つのパーティション（複製グループ２５６Ｎ＿０、及び複製グループ２５６Ｎ＿１）に分割されている。
【０１６４】
この機構を使用して、２つの新しい複製グループ２５６Ｎ＿０、及び２５６Ｎ＿１の初期メンバーシップは、分割された複製グループ２５６Ｎのメンバーシップと全く同じであることが可能である。データの移動は最初は起こらず、クエリ及び更新は、分割前と同様に分配することができる。しかしながら、新しいストレージノードが、分割された複製グループ２５６（この例では、複製グループ２５６Ｎ＿０）の１つに追加されるとき、複製グループは、必要とされる数以上のメンバを有する。次に、ストレスが加えられたホストは、（複製グループ２５６Ｎ＿１にとどまっている一方で）この場合、そのデータの半分（複製グループ２５６Ｎ＿０内の半分）を削除することによって、複製グループ２５６Ｎ＿０から離れ、したがって、ホスト上のストレスを軽減することができる。したがって、単一ノードのバケット２５２への追加は、ストレージサブシステム上の少なくとも一部のストレスを軽減することができる。
【０１６５】
ここで留意すべきは、すべてのホストが同量のディスクスペースを有する（すなわち、ディスクスペースに関して同種である）場合、また、データがパーティション２５４間でほぼ均等に分割されている場合、バケット２５２におけるすべてのホストは、ほぼ同時にスペースがなくなる傾向があることがあり、それはバケットが再区分する必要があるたびに、バケット２５２におけるホストの数を２倍にする必要があり得ることである。
【０１６６】
同種ホストを使用するとき、バケットがパーティションを区分する必要があるたびに、バケット２５２におけるホストを２倍にする必要性を回避するために、検索可能なデータサービスの実施形態は、ストレスが加えられた複製グループ２５６に追加されるホストの確率は、その複製グループ２５６上の測定されたストレスに比例して増加するが、ほぼ無作為にホストを追加することが可能である１つ以上の機構を使用することができる。これらの機構を使用して、複製グループ２５６の分割は、複製グループ上のストレージストレスが危機的になる前に、実行されることが可能である。測定されたストレスレベルが増大すると、新しいホストはより頻繁に追加されるが、ストレスが低いとき、１つ以上の新しいホストは、分割された複製グループ２５６に早期に追加されることが可能である。
【０１６７】
パーティションマネージャーインターフェース
一実施形態では、パーティションマネージャー２３２は、ＡＰＩに従って、ｅＩＤ更新マネージャー２３０と相互作用することができる。以下は、パーティションマネージャー２３２によって使用することができ、また、記載された例示的なコール、及びコールバックの１つ以上を含むことができるがそれらに限定されない、例示的なＡＰＩである。
setpartitions(Subscriber, Bucket, AcceptPartitionList, DropPartitionList)
【０１６８】
ＡｃｃｅｐｔＰａｒｔｉｔｉｏｎＬｉｓｔ、及びＤｒｏｐＰａｒｔｉｔｉｏｎＬｉｓｔは、各文字列がパーティションマスクを示す、一連の文字列である。ｅＩＤ更新マネージャー２３０は、新しいパーティションリストを記憶し、受信操作をフィルターにかけるために、リストを使用する。次に、ｅＩＤ更新マネージャー２３０は、ハッシュされたｅＩＤが、ドロップパーティションリストにおけるパターンと一致するアイテムを取り除くために、データストアを移動することができる。アクセプトパーティションリスト、又はドロップパーティションリストの一方は、空であってもよい。ストレージノードを起動するとき、そのアクセプトパーティションリストは空であってもよく、またパーティションマネージャー２３２からのこのコールを使用して、初期化されてもよい。
empty(subscriber identifier, bucket identifier)
【０１６９】
このコールバックは、特定のバケットがローカルに空になったこと、また、したがって、パーティションマネージャー２３２がそれをマージ、又は削除することを考慮すべきであることを示す。
hint(subscriber identifier, bucket identifier, mask)
【０１７０】
このピアツーピアのコールは、別のストレージノードが、指定されたパーティションに加わることを考慮すべきであることの暗示である。
【０１７１】
一実施形態では、パーティションマネージャー２３２は、ＡＰＩを介した、グループメンバーシップ及びヘルス２２６のコンポーネントへの、複製グループ内のノードの負荷を決定するための、グループヘルス２２６のコンポーネントのクライアントであることが可能である。一実施形態では、パーティションマネージャー２３２はまた、十分に活用されていないストレージノードを探すために、ストレージノードロケータ２１６をクエリすることができる。 
【０１７２】
一実施形態では、パーティションの分割及びマージは、ディスクストレージ上のストレスによってのみ、決定されることが可能である。特に、いったんローカルディスクの使用が特定の閾値を超えると、ローカルホストのパーティションは分割することができる。他の実施形態は、一連の利用可能なホスト間でエンティティを分割するための他のアーキテクチャ、及び機構を使用することができる。例えば、一実施形態では、コンシステントハッシュ法（又は分散ハッシュテーブル（ＤＨＴ））は、エンティティ複製を半無作為に、利用可能なホスト間に広げるために、使用されることが可能である。本実施形態は、システムにおけるホストの追加、又は削除を比較的容易にすることができるが、クエリがバケットを供給するほとんどすべてのホストに送信される必要があると、クエリングを非効率的にする傾向がある場合がある。したがって、バケットに対するクエリ処理能力のスケーリングは、本実施形態では困難であろう。別の例示的な実施形態では、エンティティは、それらの属性に基づいて分配されることが可能であるが、ここで留意すべきは、本実施形態は、クエリの計画及び実行をより複雑にする場合があることである。本実施形態はまた、ホストの追加及び削除の複雑性を増大させ、変化するデータ分配への反応をより困難にすることがある。
【０１７３】
ストレージノード
図１１は、一実施形態に従い、例示的ストレージノード及びそのコンポーネントを例示している。ここで留意すべきは、パーティションマネージャー２３２、及び関連コンポーネントは、パーティションマネージャーという題名の項において上述され、ローカルクエリプロセッサ２２８は、クエリサービスという題名の項において、以下でさらに説明されることである。図１１の次の説明は、ｅＩＤストア２３６、及びその関連コンポーネント：ｅＩＤストア２３６上にコンパイルされるｅＩＤ更新マネージャー２７６、及びクエリインデックス２３４に重点を置く。また、ここで留意すべきは、一実施形態において、図解されるコンポーネントのインスタンスは、検索可能なデータサービス実装において、すべてのストレージノード２７０上にあることが可能であるということことである。
【０１７４】
一実施形態では、ローカルｅＩＤストア２３６、及びローカルｅＩＤ更新マネージャー２３０は共に機能して、以下の機能性の１つ以上を提供することができるが、それらに限定されない。
・リスト属性ＡＰＩをサポートする：クライアントが更新を提出した後、クライアントがｅＩＤに関連する属性をリードバックすることができる
・クエリインデックス２３４の作成、及び再作成をサポートする：ｅＩＤストア２３６は、クエリインデックス２７４の作成のための、信頼すべきストアとして使用することができる。これらのインデックス２３４が損失した場合、それらはローカルｅＩＤストア２３６を使用して、再生することができる
・チャンク要求に対するクエリサブシステム２０４の要求をサポートし、それによってｅＩＤのリストが提出され、それに対して、それぞれに対する属性が返信することができる
【０１７５】
一実施形態では、検索可能なデータサービス実装内における、様々なストレージノード２７０上のｅＩＤストア２３６のインスタンスは、以下の機能性の１つ以上を集合的に提供することができるが、それらに限定されない。
・永続性：クライアントが、更新が受け入れられたことを伝えられるとき、クライアントは、複製されたｅＩＤストア２３６がデータを損失しない、高水準の信頼を要求することができる
・一致性：複製は、顧客との特定のサービス内容合意書（ＳＬＡ）内で、最終的な一致性を示す
・信頼性、可能性、拡張性：検索可能なデータサービス実装は、全体のシステムが特定のＳＬＡに応じることを可能にするために、随時、これらをサポートするよう要求することができる
【０１７６】
一実施形態では、永続性及び一致性の機能性を提供するために、ｅＩＤストア２３６のインスタンスは、本文書においてさらに後述されるように、ゴシップ機構を使用して通信することができる。グループヘルス２２６のコンポーネント、及びストレスマネージャーコンポーネントとの相互作用を介するパーティションマネージャー２３２は、動的区分を介して、ｅＩＤストア２３６のディスク使用を、またノードが機能しなくなったときの新しい複製の作成を介して、ｅＩＤストア２３６の永続性を管理することができる。
【０１７７】
ｅＩＤ更新マネージャー
一実施形態では、ｅＩＤ更新マネージャー２３０は、特定のポート上で、例えばＴＣＰを介して、更新及びリスト属性要求を受信することができる。また、ｅＩＤ更新マネージャー２３０は、問題や状態を報告するために、また、ｅＩＤ更新マネージャー２３０はどのバケットパーティション２５４を維持すべきか、また、もしあれば、どちらを削除すべきかについての指示を受信するために、そのローカルパーティションマネージャー２３２と通信することができる。
【０１７８】
ここで留意すべきは、ストレージノード２７０は、１つ以上のバケットパーティション２５４を含んでもよいことである。一実施形態では、区分の決定は、ｅＩＤ更新マネージャー２３０の範囲外にある。しかしながら、ｅＩＤ更新マネージャー２３０は区分の決定を伝えられ、それらに従う。
【０１７９】
ｅＩＤストア
一実施形態では、ｅＩＤストア２３６は、Ｂｅｒｋｅｌｅｙデータベース（ＢＤＢ）として実装することができる。ここで留意すべきは、他の実施形態は、ｅＩＤストア２３６を実装するために、他の機構を使用することができることである。ＢＤＢは、その中の加入者識別子、バケット識別子、及びエンティティ識別子（ｅＩＤ）が与えられるすべての属性を見つけるための容量を提供する。ＢＤＢは、キー値の１組として情報を保存し、キーは、ここでＢＤＢキーと呼ばれることがあり、値はＢＤＢ値と呼ばれることがある。一実施形態では、ＢＤＢキー、及びＢＤＢ値は以下のように形成することができる。
・BDB-key = Key( subscriber identifier, bucket identifier, eID )
・BDB-value = { updates-for-the-eID-above }
【０１８０】
Ｋｅｙ（ｓｕｂｓｃｒｉｂｅｒ  ｉｄｅｎｔｉｆｉｅｒ，  ｂｕｃｋｅｔ  ｉｄｅｎｔｉｆｉｅｒ，  ｅＩＤ  ）は、特定の引数を使用して固有のキーを形成する関数である。例えば、一実施形態では、この関数は加入者識別子、バケット識別子、及びｅＩＤ文字列を結合することによって、ＢＤＢキーを形成することができる。例を引き続き述べると、バケット識別子が与えられるすべてのｅＩＤをリストアップするために、関数は、いくつかの範囲が定められた情報を有する、結合された加入者識別子、バケット識別子、及びｅＩＤ文字列にプレフィックスを付けることができる。例えば、ＢＤＢキーは、「ｐ１２＿ｃｌｉｅｎｔ１ｂｕｃｋｅｔ１／ｐｈｏｔｏｓ／ｘｙ．ｊｐｇ」として形成されてもよく、それは加入者のバケットの１つ（「ｂｕｃｋｅｔ１」）と結合される加入者識別子（「ｃｌｉｅｎｔ１」）が、１２文字の長さであり、１２文字の後に続くものは何でも、ｅＩＤ文字列「／ｐｈｏｔｏｓ／ｘｙ．ｊｐｇ」であることを示す。どのルックアップ関数（加入者識別子、バケット識別子、及びｅＩＤの等価ルックアップ、値域を含まない加入者識別子及びバケットの等価ルックアップ、及びｅＩＤに対する等価ルックアップなど）が望ましいかによって、Ｋｅｙ（．．．）は、実施形態における様々な方法で実行することができる。
【０１８１】
一実施形態では、ＢＤＢ値は、更新操作（例えば、置換、追加、及び／又は削除）、及びＢＤＢキーにおけるｅＩＤの属性を作成するのに役立つ、更新操作に対応するシーケンスＩＤの集合体を含むことができる。一実施形態では、属性の新しい更新操作は、そのシーケンスＩＤのがより高い場合、ｅＩＤストアにおける既存の更新操作に優先する。例えば、ｅＩＤが与えられると、ｅＩＤストア２３６内のその属性の置換より、高いシーケンスＩＤを有する属性の置換操作は、ｅＩＤストア２３６から後者を取り除く。別の例として、特定のシーケンスＩＤを有する全削除操作は、無関係のより低いシーケンスＩＤを有するすべての更新操作を行う。
【０１８２】
上記のことを説明するために、特定のｅＩＤにおける、以下の例示的なＢＤＢ値を検討する。
{ (op=replace, name=n1, value=v1, ts=t1), (op=replace, name=n2, value=v2, ts=t2), (op=add,name=n2,value=v3,ts=t3) }
ここで、ｏｐは操作を示し、ｔｓはシーケンスＩＤを示す。この例に関して、ｔ４＞ｔ３＞ｔ２＞ｔ１と仮定する。例における「現時点」では、ＢＤＢ値によって含意される属性は、
{(n1,v1),(n2,v2),(n2,v3)}
であり、ここでｎ２は多値である。ここで、同じｅＩＤにおける、以下の例示的なシナリオの１つを介する更新を検討する。
【０１８３】
第１シナリオ
(op=replace, name=n2, value=v4, ts=t4)
これは、ＢＤＢ値に、
{ (op=replace, name=n1, value=v1, ts=t1), (op=replace, name=n2, value=v4, ts=t4) }
を含ませる。
したがって、
(op=replace, name=n2, value=v2, ts=t2), (op=add,name=n2,value=v3,ts=t3)
は、新しい更新に取って代わられるため、更新のリストから除外される。
第２シナリオ
(op=delete, ts=t4) 
これは、ＢＤＢ値に、
{(op=delete, ts=t4)}
のみを含ませる。
他の操作のすべては、この新しい操作にすべて取って代わられるため、取り除かれる。
第３シナリオ
(op=add, name=n1, value=v5, ts=t4) 
これは、ＢＤＢ値に、
{ (op=replace, name=n1, value=v1, ts=t1), (op=add, name=n1, value=v5, ts=t4), (op=replace, name=n2, value=v2, ts=t2), (op=add,name=n2,value=v3,ts=t3) } 
を含ませる。
このシナリオでは、どの更新も外される２つの属性、ｎ１及びｎ２は多値である。
【０１８４】
クエリインデックス
一実施形態では、クエリインデックス２３４は、Ｂｅｒｋｅｌｅｙデータベース（ＢＤＢ）として実装することができる。ここで留意すべきは、他の実施形態は、クエリインデックス２３４を実装するために、他の機構を使用することができることである。一実施形態では、バケット２５２が与えられると、クエリインデックス２３４は、｛名前、値｝の１組からｅＩＤへのマッピングを可能にする。したがって、クエリインデックス２３４に対して、
BDB-key = Key( subscriber identifier, bucket identifier, name, value )
BDB-value = { all-eIDs-with-{name, value}-above }
【０１８５】
一実施形態は、加入者識別子、バケット識別子及び名前による等価ルックアップ、並びに値による等価及び値域ルックアップを実行することができる。一実施形態では、クエリインデックス２３４に対するＫｅｙ（  ｓｕｂｓｃｒｉｂｅｒ  ｉｄｅｎｔｉｆｉｅｒ，  ｂｕｃｋｅｔ  ｉｄｅｎｔｉｆｉｅｒ，  ｎａｍｅ，  ｖａｌｕｅ  ）関数は、例示的なクエリ、
@name = "some-name", @value > "string1" AND @value < "string2"
を与えられると、以下の変換を可能にすることによって、クエリをサポートすることができる。
BDB-Key > Key ( subscriber identifier, bucket identifier, "some-name", "string1" ) AND BDB-Key < Key ( subscriber identifier, bucket identifier, "some-name", "string2" )
【０１８６】
関数Ｋｅｙ（．．．）を実行するための一部の例示的な方法は、上記のｅＩＤストアという題名の項で論じられ、ここにおいても適用するよう意図されている。
【０１８７】
一実施形態では、クエリインデックス２３４に対するＢＤＢ値は、ＢＤＢキーにおける｛名前、値｝の１組を有する、一連の１つ以上のｅＩＤと結合するシーケンスＩＤに加えて、一連の更新操作（例えば、追加及び／又は置換）である。ここで留意すべきは、ｅＩＤストア２３６のすべての新しい更新は、１つ以上の以前の更新を無関係にする可能性があることである。クエリインデックス２３４は、それが取って代わるすべての更新に加えて、新しい更新を受信する必要がある。
【０１８８】
ストレージノード使用事例
以下は、一実施形態に従って、一部の例示的な検索可能なデータサービス ストレージノードの使用事例を説明する。初めの２つの使用事例（更新要求の処理、及びリスト属性要求の処理）は、外部的事象の処理を説明する。残りは、内部的事象の処理を説明する。
【０１８９】
以下は、一実施形態に従って、更新要求の処理を説明する。要求ルーター２０２からの更新要求を受信すると、ｅＩＤ更新マネージャー２３０が、更新が現在維持しているバケットに対するものではないと決定した場合、エラーが返される。ｅＩＤ更新マネージャー２３０が、今後、Ｔ（例えば、５〜１０まで）秒を超えるシーケンスＩＤを有する要求ルーター２０２によって、更新がマークされると決定した場合、ｅＩＤ更新マネージャー２３０はエラーを返す。一実施形態では、ｅＩＤ更新マネージャー２３０はまた、そのＮＴＰ同期化の状態をチェックし、必要であれば警告を発することができる。
【０１９０】
一実施形態では、ｅＩＤ更新マネージャー２３０は、グループ通信２２２のコンポーネントを使用して、更新を「ｇｃａｓｔ」することができる。ネットワークを通じて送信されるバイト数は、概算されることが可能であり（さらなる詳細に関しては、グループ通信の項を参照）、通常、バイト数は、Ｎが永続性に必要とされる複製の数である場合には、更新メッセージのバイトサイズのＮ倍であることが可能である。ｇｃａｓｔは、更新が永続性に対して書き込まれるノードセットを返すことができるか、又はタイムアウトすることができる。
【０１９１】
ｅＩＤ更新マネージャー２３０は、更新のあるｅＩＤストア２３６のリードモディファイライトを実行する。これによって、いくつかの更新が取って代わられたり、新しい更新が入力されることがある。ｅＩＤ更新マネージャー２３０が、更新が取って代わられたため、適用できないことを検出すると、メッセージが遅いという表示が返される。ｅＩＤ更新マネージャー２３０は、永続的なログにおいて、新しい更新、及び取って代わられた更新をログする。ｅＩＤ更新マネージャー２３０がうまくｇｃａｓｔし、ｅＩＤストア２３６を更新し、そのログへ書き込みすると、それは、ｇｃａｓｔから得られるノードセットを返す。そうでなければ、エラーが返される場合がある。
【０１９２】
以下は、一実施形態に従って、リスト属性要求の処理を説明する。ｅＩＤ更新マネージャー２３０は、要求によって特定されるｅＩＤを検出するために、そのローカルｅＩＤストア２３６を読み込む。ｅＩＤが検出されると、その属性は読み込まれ、成功応答が返信される。ｅＩＤが検出されないと、エラーが返される場合がある。
【０１９３】
内部的事象の処理
ｅＩＤストアログが変更する場合、クエリインデックスアップデータは、新しい追加を読み込むことができ、クエリインデックス２３４を更新する。アンチエントロピーデーモンは新しい追加を読み込み、アンチエントロピーに対するそのデータ構造（例えば、Ｍｅｒｋｌｅツリー）を更新する。
【０１９４】
以下は、一実施形態に従って、グループ通信２２２のコンポーネントによって行われる、適用メッセージコールの処理を説明する。ｅＩＤ更新マネージャー２３０が、更新が現在維持しているバケットに対するものではないと決定した場合、エラーが返される。ｅＩＤ更新マネージャー２３０が、今後、Ｔ（例えば、５〜１０まで）秒を超えるシーケンスＩＤを有する要求ルーター２０２によって、更新がマークされると決定した場合、更新は受け入れられ、ｅＩＤ更新マネージャー２３０は、そのＮＴＰ同期化の状態をチェックし、必要であれば警告を発する。
【０１９５】
ｅＩＤ更新マネージャー２３０は、更新メッセージのあるｅＩＤストア２３６のリードモディファイライトを実行する。これによって、いくつかの更新が取って代わられたり、新しい更新が入力されることがある。ｅＩＤ更新マネージャー２３０が、更新が取って代わられたため、適用できないことを検出すると、メッセージが遅いという表示が返される。ｅＩＤ更新マネージャー２３０が、更新がすでに適用されていることを検出した場合、メッセージが二重であるという表示が返される。ｅＩＤ更新マネージャー２３０は、永続的なログにおいて、新しい更新、及び取って代わられた更新をログする。ｅＩＤ更新マネージャー２３０が、うまくｅＩＤストア２３６を更新し、そのログへ書き込みすると、それはＯＫ（成功）を返す。そうでなければ、エラーが返される場合がある。
【０１９６】
以下は、一実施形態に従って、グループ通信２２２のコンポーネントによって行われる、アンチエントロピーコールの処理を説明する。コールに応えて、アンチエントロピーデーモンは表示されたホストに接続し、ホストと共にアンチエントロピーセッションを実行する。アンチエントロピーは、本文書の他でさらに論じられる。
【０１９７】
以下は、一実施形態に従って、パーティションマネージャー２３２によって行われる、セットパーティションコールの処理を説明する。ｅＩＤ更新マネージャー２３０は、新しいアクセプトリスト、及びドロップリストによってそのログを書き込む。ｅＩＤ更新マネージャー２３０は、もはや責任を持たないｅＩＤのそれ自体を取り除くために、ドロップリストによってクリーナースレッドを開始する。クエリインデックス２３４は、ログされた事象を読み込むとき、それ自体のクリーナースレッドを開始する。アンチエントロピーデーモンもまた、ログされた事象を読み込むとき、それ自体のクリーナースレッドを開始する。
【０１９８】
ｅＩＤ更新マネージャーインターフェース
以下は、一実施形態に応じて、ｅＩＤ更新マネージャー２３０によって公開される、又は要求することができる、例示的なインターフェースを説明する。ここで留意すべきは、これらのインターフェースは例示的なものであり、限定することを意図していないことである。
【０１９９】
ｅＩＤ更新マネージャー２３０は、以下のインターフェースの１つ以上を、要求ルーター２０２に公開することができるが、それらに限定されない。
replace ( bucket identifier, eID, name, value, prev-seq-ID) OR
add     ( bucket identifier, eID, name, value, prev-seq-ID) OR
delete  ( bucket identifier, eID, name, value, prev-seq-ID)
【０２００】
ｅＩＤ更新マネージャー２３０は、以下のインターフェースの１つ以上を、ローカルグループ通信２２２のコンポーネントに公開することができるが、それらに限定されない。
apply(Group, Msg) --> ok|dup|late|error 
antientropy(Group, Host, Cookie) --> Status
【０２０１】
ｅＩＤ更新マネージャー２３０は、以下のインターフェースをローカルパーティションマネージャー２３２に公開することができるが、それに限定されない。
setpartitions(Subscriber, Bucket, AcceptPartitionList, DropPartitionList) 
ここで留意すべきは、アクセプトパーティションリスト、及びドロップパーティションリストは、｛マスク、値｝の１組のリストであることである。
【０２０２】
ｅＩＤ更新マネージャー２３０は、以下のインターフェースの１つ以上を、ローカルグループ通信２２２のコンポーネントから要求することができるが、それらに限定されない。
gcast(Group, Msg) --> {ok, Hosts, Cookie} | error 
gsync(Cookie, Timeout)--> true|false 
【０２０３】
ｅＩＤ更新マネージャー２３０は、以下のインターフェースを、ローカルパーティションマネージャー２３２から公開することができるが、それに限定されない。 
empty(Subscriber, Bucket)
【０２０４】
クエリサービス
一実施形態では、検索可能なデータサービスシステムのクエリサブシステム２０４、又はクエリサービスは、クライアントクエリを解析し、データを取り出し、クエリ結果のセットを相互に関連付けるための、１つ以上のインターフェースを提供することができる。一実施形態では、クエリサービスは、図６に図解するように、１つ以上のクエリＴＳＡＲ２１２、クエリキャッシュ２１４、クエリノードロケータ２２０、及び各ストレージノード２７０上に、ローカルクエリプロセッサ２２８、ローカルクエリインデックスストア２３４、及びエンティティＩＤ（ｅＩＤ）ストア２３６を含むがそれらに限定されない、検索可能なデータサービスのいくつかのコンポーネントを関係させる、又は含むことができる。ここで留意すべきは、これらのコンポーネントは、以下の図において、異なる番号を使用して言及される場合があることである。
【０２０５】
図１２は、検索可能なデータサービスのクライアントからのクエリサービスを実施するクエリサブシステムを構成又は相互作用する検索可能なデータサービスの種々のコンポーネントを例示し、さらに、一実施形態に従い、コンポーネント間のデータフローをさらに例示している。クエリサブシステムは、関連エンティティＩＤ（ｅＩＤ）（特定のバケットに属する）を含み、それぞれのストレージノード３７０からの結果を収集し、各所定のクエリを満たすｅＩＤセットをキャッシュする検索可能なデータサービスにおいて、すべてのストレージノード３７０に対して、クライアント提出のクエリの効率的な実行を提供することができる。一実施形態では、クエリの処理を実行するために、クエリサブシステムは、以下のコンポーネントを含むことができるが、それらに限定されない。
・クエリノードロケータ３５４は、各特定のクエリに対して、ルーティング決定を行うことができる。一実施形態では、クエリキャッシュ３６４の利点を最大限にするために、繰り返されるクライアントクエリは、クエリシステムを介して同じパスを送ることを推奨されてもよい。
・クエリＴＳＡＲ（Ｔｏｐ  Ｓｅａｒｃｈ  ＡｇｇｒｅｇａｔｏＲ）３６０は、所定のバケットに対する適切な一連のストレージノード３７０にクエリを分配し、また結果及びクエリキャッシングを収集する
・各ストレージノード３７０上のローカルクエリ実行エンジン３７６は、ストレージノード３７０のそれぞれでローカルにクエリを実行する責任を有する
【０２０６】
一実施形態では、クエリＴＳＡＲ３６０は、本質的に対等に扱われる。各クエリＴＳＡＲ３６０は、いかなるクライアントクエリにも応答することができる。これは、個々のノードの追加、及び削除を単純化するのに役立つことが可能である。しかしながら、クエリ結果は、個々のノード上のクエリキャッシュ３６４においてキャッシュされることがあるため、一実施形態では、できる限り頻繁に、同じクエリＴＳＡＲ３６０を介して、同じストレージドメインに対する同一クエリを送るよう試みる場合がある。クエリＴＳＡＲ３６０を介してクエリを送るのに役立つために、要求ルーター３５２は、特定のバケットに対するクエリノードのリストを得るために、クエリノードロケータ３５４にアクセスすることができる。
【０２０７】
上述のサービス及びコンポーネントに加えて、１つ以上の他のコンポーネント、又はサービスが、クエリサービスによってアクセス可能である。例えば、ストレージノードロケータサービス３６９は、所定のバケットに対する適切なストレージノード３７０の１組、又はリストを位置付けるために、アクセス可能である。別の例として、クエリサービスは、全体のシステムノードヘルスサービス（図６における、グループメンバーシップ及びヘルス２２６）を活用、又はそれに参加することができ、それは、システムへ参加、及びシステムを終了する様々なノードを監視することができ、システムにおける他のノードへ、そのヘルス情報を伝えることができる。
【０２０８】
クエリノードロケータ
クエリキャッシングが有益なヒット率を提供するために、一実施形態は、可能であれば、同じクライアントクエリが、コーディネーションサービス（要求ルーター３５２）によって、同じクエリＴＳＡＲ３６０のノードに送られることを確実にするよう、試みることが可能である。一実施形態では、クエリノードロケータ３５４は、その１つが、各コーディネータノード３５０においてインスタンス化されることが可能であるが、そのルーティングを提供するためのロジックをカプセル化することができる。一実施形態では、クエリノードロケータ３５４は、参加ノードの１組上の受信クエリの無作為分配を可能にする、一貫したハッシングスキームを実装することができる。他の実施形態は、クエリを分配するための他の無作為、又は非無作為機構を実装することができる。
【０２０９】
一実施形態では、クエリノードロケータ３５４は、ＳＨＡ−１のようなベースハッシュ関数を使用して、各ノード及びキーにｍ−ｂｉｔの識別子を指定するための、一貫したハッシュ関数を実行する。一実施形態では、ノードの識別子は、ノードのＩＰアドレスをハッシュすることによって選択されてもよく、一方で、キーの識別子は、ドメイン及び正規化クエリ文字列の組み合わせをハッシュすることによって、生成することができる。用語「キー」は、用語が使用される文脈から意味が明らかであるため、オリジナルキー、及びハッシュ関数下でのその形の両方を意味するために、使用することができる。同様に、用語「ノード」は、ノード、及びハッシュ関数下でのその識別子の両方を意味するために、使用することができる。一実施形態では、識別子の長さは、２つのノード又はキーが、同じ識別子に対してハッシュする可能性をごくわずかにするに十分、大きいことが可能である。
【０２１０】
一実施形態では、クエリノードロケータ３５４によって使用されるハッシュマップ構造は、以下のフィールドの１つ以上を含むことができるが、それらに限定されない。
・キー−組み合わされたドメイン（バケット）名、及びクエリ文字列式のハッシュ
・値−所定のバケットに対するクエリ式を満たす一連のｅＩＤ
・コスト−最初にクエリ式を実行するためにかかった時間。例えば、ガーベジコレクション、及び置換アルゴリズムに使用することができる
・タイムスタンプ−入力がキャッシュに入れられたときのローカル時間。例えば、ガーベジコレクション、及び検証アルゴリズムに使用することができる
【０２１１】
一貫したハッシングは、次のように、ノードにキーを指定することができる。識別子は、２mを法とした識別子サークルで順序付けられる。キーｋは、識別子空間において、識別子が（識別子の）ｋに同等な、又は続く最初のノードに指定される。このノードは、キーｋの後続ノードと呼ばれ、ｓｕｃｃｅｓｓｏｒ（ｋ）で示される。識別子が、０から２m‐１の数のサークルとして表される場合、ｓｕｃｃｅｓｓｏｒ（ｋ）は、ｋから時計回り方向の最初のノードである。
【０２１２】
図１３は、ｍ＝３の識別子サークルを図解する。サークルは、３つのノード：０、１、及び３を有する。識別子１の後続はノード１であり、したがって、キー１は、ノード１に位置付けられることになる。同様に、キー２はノード３に、キー６はノード０に位置付けられることになる。
【０２１３】
一貫したハッシングは、最小限の中断で、ノードが検索可能なデータサービスを開始、及び終了することを可能にすることができる。ノードｎがネットワークに参加するとき、一貫したハッシングマッピングを維持するために、ノードｎの後続にすでに指定された特定のキーは、ここでノードｎに指定されるようになる。ノードｎがネットワークを終了するとき、その指定されたキーのすべては、ノードｎの後続に指定される。ノードに対するキーの指定における他の変更が、発生する必要はない。図１３において示される例では、ノードが識別子７で参加するとすれば、それは、識別子０を有するノードから、識別子６を有するキーをとらえる。
【０２１４】
クエリＴＳＡＲ（Ｔｏｐ  Ｓｅａｒｃｈ  ＡｇｇｒｅｇａｔｏＲ）
一実施形態では、クエリプロセッサ３６２は、クエリメッセージにおいて、クライアント３３０によって提供されるクエリ式を取り扱う、検索可能なデータサービスシステムの第１のコンポーネントである。クエリプロセッサ３６２は、クエリ式を前処理することができる。クエリ言語における、非正規化構文を可能にする実施形態では、クエリプロセッサ３６２が行う最初のステップは、クエリをその標準的な、正規化形に変換することである。一実施形態では、クエリプロセッサ３６２はまた、意味的に同一のクエリが同じに見えるように、クエリ式における述語を並べ替え、それらを正規化することができる。例えば、クエリ式：
[predicate1] AND [predicate2] AND [predicate3]
は、クエリ式と同じ正規化クエリ式によって表されるべきである。：
[predicate3] AND [predicate1] AND [predicate2]
例えば、クエリ式における述語の正規化は、システムが、より高いクエリキャッシュ３６４のヒット率を実現するのに役立つことが可能である。
【０２１５】
クエリ式の処理に続いて、クエリプロセッサ３６２は、クエリキャッシュ３６４が、所定の（場合によって正規化された）クエリ式を満たすための、必要な結果セットを含んでいるか決定するために、そのローカルクエリキャッシュ３６４を調査することができる。クエリキャッシュ３６４が結果セットを含む場合、結果セットはクエリキャッシュ３６４から取り出され、コーディネータノード３５０を介してクライアント３３０に返される。そうでなければ、クエリ式はクエリアグリゲータ３６６に送られ、それは、対応するストレージノード３７０からの結果セットを取り出す責任を有する。結果セットがストレージノード３７０から取り出された後、それはローカルクエリキャッシュ３６４においてキャッシュされ、コーディネータノード３５０を介してクライアント３３０に返される。
【０２１６】
クエリキャッシュ３６４におけるクエリキャッシングの効率性は、検索可能なデータサービスシステムの全体的性能に影響を与える、性能パラメータである。システムの全体的性能は、結果セットを取り出すために個々のストレージノード３７０に行く必要なく、クエリキャッシュ３６４に対してホットクエリを解決することによって、改善することができる。 
【０２１７】
クエリアグリゲータ
一実施形態では、現在のクエリが実行されているバケットに対するｅＩＤを含む、一連のストレージノード３７０を位置付けるために、クエリアグリゲータ３６６は、ストレージノードロケータ３６８のサービスを使用することができる。一連のストレージノード３７０が決定された後、クエリアグリゲータ３６６は、クエリ要求を、ストレージノード３７０上のそれぞれにある、ローカルクエリ実行エンジン３７６に送信することができ、必要であれば再試行する。クエリに参加しているすべてのストレージノード３７０から、結果セットが受信されると、結果セットは、必要であればソート属性に基づいて、単一のセットにマージすることができる。
【０２１８】
ローカルクエリ実行エンジン
図１４は、一実施形態に従い、単一ストレージノード３７０の例示的アーキテクチャを例示している。ローカルクエリ実行エンジン３７６は、ストレージノード３７０のｅＩＤストア３８０、及びローカルクエリインデックスストア３７８と、密接に関連することができる。ローカルクエリ実行エンジン３７６は、この特定のストレージノード３７０上に保存される、ｅＩＤのセットに対して、ローカルにクエリを実行する。ｅＩＤに関するすべての情報がローカルに存在するため、ローカルクエリ実行エンジン３７６は、ローカルに（すなわち、このストレージノード３７０内で）、提供されたクエリ３９０を実行し、結果をソートし、クエリ結果セット３９０を（ソート属性と共に）、クエリＴＳＡＲ３６０に返すことができる。一実施形態では、受信クエリ３９０は、ローカルクエリ実行エンジン３７６によって、ｅＩＤストア３８０に対して実行される前に、パーサ３７２によってローカルに解析され、クエリオプティマイザ３７４によって最適化することができる。一実施形態では、パーサ３７２、クエリオプティマイザ３７４、及びローカルクエリ実行エンジン３７６は、図６に図解するように、ローカルクエリプロセッサ２２８のコンポーネントであってもよい。
【０２１９】
クエリ構文及び検索式
実施形態では、例示的なクエリメッセージは、以下のフィールドの１つ以上を含むことができるが、それらに限定されない。
・加入者識別子−特定のクライアント、又は検索可能なデータサービスのクライアントに対する識別子
・バケット識別子−クエリにおいて考慮され得る、データの限度を定義するバケットを識別する
・ノードＩＤ−ノード識別子
・クエリ式−このクエリに対して適用される検索式
・「Ｍｏｒｅ  Ｔｏｋｅｎｓ」−クエリ式を満たすｅＩＤの数が、ページ付けの限度を超えるとき、不透明なｍｏｒｅＴｏｋｅｎオブジェクトは、クライアントに返すことができる。このトークンは、結果の次のセット（ｅＩＤ）を取り出すために、同じクエリで再実行することができる
・シーケンストークン
【０２２０】
実施形態では、クエリサービスは、サービスのクライアントによる検索可能なデータサービスへのクエリに対する、以下の種類の演算の１つ以上をサポートすることができるが、それらに限定されない。
・ブーリアン演算（例えば、ＡＮＤ、ＯＲ、ＮＯＴなど）
・算術演算（例えば、＜、＞、＜＝、＞＝、＜＞、＝、！＝）
・文字列比較演算（例えば、プレフィックス「ｃｏｎｔａｉｎｓ」など）
・クライアント指定の属性に基づく、エンティティの結果セットのソート。一実施形態では、ソートを、単一の属性上のみで許可することができる。他の実施形態は、２つ以上の属性上でのソートを許可することができる
・結果セットのページ付け
【０２２１】
一実施形態では、検索可能なデータサービスにおける検索式は、Ｘｐａｔｈのサブセット、Ｗ３Ｃ推奨を表すことができる。ここで留意すべきは、他の実施形態が、検索式に対する他のプロトコルを使用することが可能であるということである。一実施形態では、属性が（名前、値）の１組のリストであり、マークアップ言語（例えば、ＸＭＬ）文書における、複数のレベルが許可されなければ、Ｘｐａｔｈ構文の比較的小さいサブセットは、使用されることが可能である。ここで留意すべきは、他の実施形態は、マークアップ言語文書において、複数のレベルを許可することができることである。また、ここで留意すべきは、他の実施形態は、Ｘｐａｔｈ構文の比較的大きいサブセットを使用することができることである。したがって、検索可能なデータサービスの少なくとも一部の実施形態で使用されるクエリ構文は、Ｘｐａｔ定義のプレディケートテスト式に関連する。
【０２２２】
一部の実施形態では、Ｘｐａｔｈクエリ構文に加えて、検索式に対する１つ以上の非正規化形―１つ以上の正規化ルールに従って、標準形に変換され得る、暗黙的構文を有する式―が、許可されてもよい。検索式に対する非正規化形の許可は、検索可能なデータサービスを活用する開発者に対して、テスト及び実行における柔軟性を提供するのに役立つことができる。
【０２２３】
実施形態では、検索式は、オブジェクトの属性リストに影響を与える。つまり、真理値は、オブジェクトの属性の１つ以上、又はすべてを使用して計算されてもよく、真である場合は、オブジェクトを選択することができる。
【０２２４】
以下は、一実施形態に従った、検索式の一部の例であり、限定することは意図しない。
[@name = "xxxxxx" starts-with (@value = "yyyyyy")] 
【０２２５】
この式は、属性リストのすべての｛名前、値｝の１組に適用される、テストを意味する。角括弧「［］」は、個々の要素テストを指定する。このテストの適用後、式と一致する｛名前、値｝の１組の小さなセットは、残される。このセットは、ＸＰａｔｈによって、「ノードセット」と呼ばれる。オブジェクトに対する非ヌルのノードセットが得られた場合、そのキーは選択される。
[ @name = "prefix" @value = "keyword"] AND [@name = "glassy" starts-with (@value = "tasty") ] 
【０２２６】
この例では、２つのノードが組み合わせられている。ＸＰａｔｈで示されるように、ノードセットは、それがヌル集合ではないとき、かつそのときに限り、真と評価する。上記の例では、２つのノードセットは、オブジェクトの属性リストによって別々に計算され、それらの真理値は、ＡＮＤを使用して組み合わせられる。
【０２２７】
ここで留意すべきは、［＠ｖａｌｕｅ＝”ｆｏｏ”］は、ＮＯＴ［＠ｖａｌｕｅ！＝”ｆｏｏ”］と同じことを意味しないことである。前者は、ある属性が、文字列値「ｆｏｏ」のある値を有するとき、かつそのときに限り真であり、後者は、すべての属性が、文字列値「ｆｏｏ」のある値を有するとき、かつそのときに限り真である。
【０２２８】
以下は、一実施形態における、検索式で許可される例示的なクエリ構文の要約である。ここで留意すべきは、他の実施形態は、この構文の少なくとも一部を含まないことが可能である、及び／又は他の構文を含むことが可能であることである。
query expression <- (predicate expression)? 
predicate expression <- predicate | NOT predicate expression | predicate expression AND predicate expression | predicate expression OR predicate expression | predicate expression sort expression 
sort expression <- 'SORTBY[' attribute name ']' | 'SORTBY[' attribute name ' ASC]' | 'SORTBY[' attribute name ' DESC]' 
predicate <- '[' attribute name ']' | '[' attribute name _value test expression_ ']' 
attribute name <- '@name =' attribute 
上記において、ａｔｔｒｉｂｕｔｅは、システムにおける所定の属性の文字列名である。
value test expression <- value test | NOT value test expression | value test expression AND value test expression | value test expression OR value test expression 
value test <- '@value =' test value 
上記において、値は、ｔｅｓｔ  ｖａｌｕｅと等しくなければならない。
value test <- '@value !=' test value 
上記において、値は、ｔｅｓｔ  ｖａｌｕｅと等しくあってはならない。
value test <- '@value >' test value 
上記において、値は、ｔｅｓｔ  ｖａｌｕｅより大きくなければならない。
value test <- '@value >=' test value 
上記において、値は、ｔｅｓｔ  ｖａｌｕｅより大きいか、等しくなくてはならない。
value test <- '@value <' test value 
上記において、値は、ｔｅｓｔ  ｖａｌｕｅより小さくなくてはならない。
value test <- '@value <=' test value 
上記において、値は、ｔｅｓｔ  ｖａｌｕｅより小さいか、等しくなくてはならない。
value test <- 'startsWith(@value =' test value ')' 
上記において、値は、ｔｅｓｔ  ｖａｌｕｅから始まらなくてはならない。
value test <- 'contains(@value =' test value ')' 
上記において、値は、従属文字列として、ｔｅｓｔ  ｖａｌｕｅを含まなければならない。
【０２２９】
以下は、一実施形態における、検索式に対する例示的なクエリ構文ルールの要約である。ここで留意すべきは、他の実施形態は、これらの構文ルールの少なくとも一部を含まないことが可能である、及び／又は他の構文ルール、又はこれらのルールの修正を含むことが可能であることである。
・オブジェクトの属性リストの、すべての｛名前、値｝の１組上で実行されるブーリアンテストは、角括弧［…］内に入る
・角括弧内では、｛名前、値｝の１組の名前、及び値の部分は、左側の「＠ｎａｍｅ」及び「＠ｖａｌｕｅ」使用して、言及される
・式の最初の部分は、「＠ｎａｍｅ＝」の形をとった属性の名前でなければならず、後にゼロ、又は属性値のより多くのブーリアンテストが続くことができる。
・演算子「＞＞＝＜＜＝＝！＝」は、右側の文字列との、比較演算子として使用することができる
・Ｘｐａｔｈからの文字列関数「ｓｔａｒｔｓ−ｗｉｔｈ」及び「ｃｏｎｔａｉｎｓ」は、文字列値の属性に対して使用することができる
・属性のすべての＠ｎａｍｅ部分は、文字列と見なされ、＠ｖａｌｕｅ部分も文字列と見なされる
・ブーリアン演算子は、ＡＮＤ、ＯＲ、及びＮＯＴである。これらは、｛名前、値｝の１組上で、テストを組み合わせるために使用することができる
・［．．］内のテストを使用して得られた属性セットは、ＸＰａｔｈによって与えられるような真理値を有し（ノードセットのブーリアン関数）、したがって、ブーリアン演算子を使用して組み合わせられることができる
・任意のＳＯＲＴＢＹ式は、結果セットがソートされるべき属性を指定することができる。ＳＯＲＴＢＹ式は、ソート順序を示すために、ＡＳＣ（昇順）及びＤＥＳＣ（降順）指定子を含むことができる。ＡＳＣ（昇順）は、デフォルトのソート順序である
【０２３０】
以下は、上記のように、例示的な標準的検索式の構文に従った、例示的な検索式である。
[@name = "lastName" starts-with (@value = “Adams”)] AND [@name = "firstName" @value = "John"] AND [@name = "age" @value > "25" AND @value < "60"] SORTBY[@name = "year" DESC] 
【０２３１】
非正規化検索式
上記は、検索可能なデータサービスの実施形態において使用することができるＸｐａｔｈ構文を使用した、例示的な標準的検索式の構文を説明する。しかしながら、検索可能なデータサービスの一部の実施形態は、暗黙的構文を有する非正規化検索式を受け入れ、１つ以上の正規化ルールを使用して、ステートメントを標準形に変換することができる。以下は、非正規化検索式、及び暗黙的構文を標準形に変換するための、対応する例示的な関連正規化ルールの例を示す。ここで留意すべきは、
“unnormalized expression” => [normalized expression]
にあるように、非正規化式は左側に、正規化式は右側に示されることである。
【０２３２】
後に比較演算子「＞＞＝＜＜＝：！＝」が続く文字列は、後に文字列、又は数が続かなければならない。式は、比較テストを形成する。
“index > 5” => [@name = "index" @value > "5" ] 
“title:‘foo’” => [@name = "title" @value = "foo"] 
【０２３３】
否定テストは、その前に「ＮＯＴ」を有するテストである。
"NOT keyword:'xxxxxx'" => [ @name = "keyword" NOT(@value = "xxxxxx")] 
【０２３４】
要素テストは、上記で定義されるようなテスト、又は否定テストのいずれかである。要素テストは、ブーリアン演算子ＡＮＤ又はＯＲによって接続される級数として、リストアップすることができる。ブーリアン演算子が欠けている場合、それはＡＮＤと仮定される。括弧は、ブーリアン演算子が適用することができる順序を示すために、使用することができる。
"title:‘foo’ NOT prefix:‘keyword’" => [ @name = "title" @value = "foo"] AND [ @name = "prefix" NOT (@value = "keyword") ] 
【０２３５】
同じ属性上のテストのシーケンスは、同じ述語に属するとして扱われることができる。
"price > 5 AND price < 20 AND available:'yes'" => [ @name = "price" @value > "5" AND @value < "20" ] AND [ @name = "available" @value = "yes" ] 
【０２３６】
ソート順序は、クエリ文字列の終わりに「ｓｏｒｔｂｙ」式を含むことによって、指定されてもよく、後に、結果セットがソートされるべき属性名が続く。追加の修飾子（「ａｓｃ」又は「ｄｅｓｃ」）は、ソート順序を指定するために、後に続くことができる。
"year < 2010 AND author:'John Doe' sortby price desc" => [@name = "year" @value < "2010"] AND [@name = "author" @value = "John Doe"] SORTBY[@name = "price" DESC] 
【０２３７】
クエリ結果セット
一実施形態では、検索可能なデータサービスに提出されるクエリは、ここに記載されるように、検索可能なデータサービスのクエリサービスによって処理され、以下の１つ以上を、返された検索結果データの一部として生成することができるが、それらに限定されない。
・クエリ式を満たす１つ以上のエンティティＩＤ（ｅＩＤ）のセット。一実施形態では、返されるｅＩＤの数は、所定のページ付けの限度を超えることはできない。
・ｍｏｒｅＴｏｋｅｎ：クエリ式を満たすｅＩＤの数が、ページ付けの限度を超えるとき、クライアントに返される不透明なオブジェクト。このトークンは、結果の次のセット（ｅＩＤ）を取り出すために、同じクエリで再実行することができる。
【０２３８】
クエリサービス使用事例
以下は、一実施形態に応じて、一部の例示的な検索可能なデータサービスのクエリサービス使用事例を説明する。ここで留意すべきは、これらの使用事例は、図１２に図解するように、例示的なクエリサブシステムのアーキテクチャを意味することができることである。
【０２３９】
以下は、一実施形態に応じて、すべてのノードが利用可能であり、クエリがキャッシュされておらず、どのシーケンストークンも提供されていない場合の、クエリサービスによる例示的なクエリ要求の処理を説明する。クライアント３３０からクエリを受信した後、コーディネータノード３５０上の要求ルーター３５２は、クエリ要求、又はクエリ要求からのクエリ情報を、ローカルクエリノードロケータ３５４に提出する。クエリノードロケータ３５４は、１つ以上のクエリＴＳＡＲノード３６０のリストを返すことによって、応答することができる。一実施形態では、リスト内で返され得るクエリＴＳＡＲノード３６０の数には、所定の限度があってもよい（例えば、限度は３つであってもよい）。一実施形態では、クエリＴＳＡＲノード３６０のリストは、１つ以上の基準に従って、ランク付け、又はソートされてもよい。
【０２４０】
次に、要求ルーター３５２は、クエリ要求を、クエリノードロケータ３５４から受信するリスト上の、少なくとも１つのクエリＴＳＡＲノード３６０に提出する。要求ルーター３５２からクエリ要求を受信するクエリＴＳＡＲノード３６０では、ローカルクエリプロセッサ３６２は、ローカルクエリキャッシュ３６４へ、クエリ要求を提出することができる。クエリキャッシュ３６４が、ネガティブキャッシュのヒット結果を返す場合、クエリＴＳＡＲノード３６０は、ローカルストレージノードロケータ３６８に、クエリ要求を提出する。ストレージノードロケータ３６８は、クエリ要求において指定されるバケットを含む、ストレージノード３７０のセット、又はリストを返す。
【０２４１】
次に、クエリＴＳＡＲ３６０は、ストレージノードロケータ３６８によって返されるリストからの、ストレージノード３７０の１つ以上に、クエリ要求を提出することができる。一実施形態では、クエリ要求は、必要とされるストレージノード３７０の最小限のセットに提出することができる。クエリ要求を受信する各ストレージノード３７０上のローカルクエリプロセッサは、ローカルｅＩＤストアに対してクエリ要求を処理し、エンティティＩＤ（ｅＩＤ）のセットを返すことができる。一実施形態では、ｅＩＤのセットは、ページサイズ（例えば、１００エンティティ）によって制限されてもよい。「ｍｏｒｅ  ｔｏｋｅｎ」インジケータは、クエリ要求を満たすために利用可能な、より多くのｅＩＤがあることを示すために、必要であれば返されてもよい。
【０２４２】
クエリＴＳＡＲ３６０は、必要であれば、１つ以上のストレージノードから受信するｅＩＤのセットをマージし、結果を保存するために、クエリ要求を、ローカルクエリキャッシュ３６４に提出する。次に、クエリＴＳＡＲ３６０は、クエリ結果を要求ルーター３５２に返す。次に、要求ルーター３５２は、クエリ結果を、要求しているクライアント３３０に返す。
【０２４３】
以下は、一実施形態に応じて、すべてのノードが利用可能であり、クエリがキャッシュされ、どのシーケンストークンも提供されていない場合の、クエリサービスによる例示的なクエリ要求の処理を説明する。クライアント３３０からクエリを受信した後、コーディネータノード３５０上の要求ルーター３５２は、クエリ要求、又はクエリ要求からのクエリ情報を、ローカルクエリノードロケータ３５４に提出する。クエリノードロケータ３５４は、１つ以上のクエリＴＳＡＲノード３６０のリストを返すことによって、応答する。一実施形態では、リスト内で返されてもよいクエリＴＳＡＲノード３６０の数には、所定の限度があってもよい（例えば、３）。一実施形態では、クエリＴＳＡＲノード３６０のリストは、１つ以上の基準に従って、ランク付け、又はソートされてもよい。
【０２４４】
次に、要求ルーター３５２は、クエリ要求を、クエリノードロケータ３５４から受信するリスト上の、少なくとも１つのクエリＴＳＡＲノード３６０に提出する。要求ルーター３５２からクエリ要求を受信するクエリＴＳＡＲノード３６０では、ローカルクエリプロセッサ３６２は、ローカルクエリキャッシュ３６４へ、クエリ要求を提出する。クエリキャッシュ３６４が、ポジティブキャッシュのヒット結果を返す場合、クエリＴＳＡＲ３６０は、クエリキャッシュ３６４から回復されるｅＩＤのページを、要求ルーター３５２に返す。次に、要求ルーター３５２は、クエリ結果を、要求しているクライアント３３０に返す。
【０２４５】
以下は、一実施形態に応じて、すべてのノードが利用可能であり、シーケンストークンがクライアントによって提供されている場合の、クエリサービスによる例示的なクエリ要求の処理を説明する。シーケンストークンは、検索可能なデータサービスが、シーケンストークンのノードセットにおいて指定される、それらのストレージノード３７０を支持することを確実にするのに役立つために、クエリ要求が与えられる。更新の直後に、クエリ要求においてシーケンストークンを提供することによって、クライアント３３０は、クエリ結果セットに反映される更新を見る機会を、著しく増加することができる。上述の例示的な使用事例からの２つの大きな違いは、クエリキャッシュ３６４がバイパスされること、また、クエリ要求を実行するために、ストレージノード３７０を選択するプロセスは、シーケンストークンによって示される、それらのストレージノード３７０を支持することである。
【０２４６】
クライアント３３０からクエリを受信した後、コーディネータノード３５０上の要求ルーター３５２は、クエリ要求、又はクエリ要求からのクエリ情報を、ローカルクエリノードロケータ３５４に提出する。クエリノードロケータ３５４は、１つ以上のクエリＴＳＡＲノード３６０のリストを返すことによって、応答する。一実施形態では、リスト内で返することができるクエリＴＳＡＲノード３６０の数には、所定の限度があってもよい（例えば、３）。一実施形態では、クエリＴＳＡＲノード３６０のリストは、１つ以上の基準に従って、ランク付け、又はソートされてもよい。
【０２４７】
次に、要求ルーター３５２は、クエリ要求を、クエリノードロケータ３５４から受信するリスト上の、少なくとも１つのクエリＴＳＡＲノード３６０に提出する。クエリＴＳＡＲ３６０は、要求を、ローカルストレージノードロケータ３６８に提出する。ストレージノードロケータ３６８は、クエリ要求において指定されるバケットを含む、ストレージノード３７０のセット、又はリストを返す。クエリＴＳＡＲ３６０は、クエリ要求が提出されてもよい、１つ以上のストレージノード３７０のセットを決定するために、シーケンストークンにおいて指定される、ストレージノード３７０のセット、及びストレージノードロケータ３６８によって返される、ストレージノード３７０のリストを使用し、次に、決定されたストレージノード３７０に、クエリ要求を提出する。クエリ要求を受信する各ストレージノード３７０上のローカルクエリプロセッサは、ローカルｅＩＤストアに対してクエリ要求を処理し、エンティティＩＤ（ｅＩＤ）のセットを返す。クエリＴＳＡＲ３６０は、必要であれば、ストレージノード３７０から受信するｅＩＤのセットをマージし、結果を保存するために、クエリ要求を、ローカルクエリキャッシュ３６４に提出する。次に、クエリＴＳＡＲ３６０は、クエリ結果を要求ルーター３５２に返す。次に、要求ルーター３５２は、クエリ結果を、要求しているクライアント３３０に返す。
【０２４８】
クエリサービスインターフェース
以下は、一実施形態に応じて、クエリサービスのコンポーネントによって、公開又は要求されてもよい、例示的なインターフェースを説明する。ここで留意すべきは、これらのインターフェースは例示的なものであり、制限することを意図しないことである。
【０２４９】
以下は、クエリサービスのコンポーネントの、例示的な公開されるインターフェースである。
【０２５０】
クエリノードロケータ３５４は、クエリＴＳＡＲ３６０のホストの、ランク付けされたリストを見つけるために、使用することができる。クエリノードロケータ３５４は、少なくとも以下の例示的なインターフェースで公開してもよい。
GetQueryNodes ( subscriber identifier, bucket identifier, query-expression ) 
【０２５１】
ＧｅｔＱｕｅｒｙＮｏｄｅｓは、加入者識別子、バケット識別子、及びクエリ式を受け入れ、提供された情報に対応するホストのリストを返す。
【０２５２】
クエリＴＳＡＲ３６０は、少なくとも以下の、例示的なクエリインターフェースを公開してもよい。
Query ( queryID, subscriber identifier, bucket identifier, query-expression, more-token, update-cookie) 
【０２５３】
Ｑｕｅｒｙは、クエリＩＤ、加入者識別子、バケット識別子、クエリ式、ｍｏｒｅ−ｔｏｋｅｎオブジェクト、及び更新クッキを受け入れる。Ｑｕｅｒｙは、クエリＩＤ、ｅＩＤリスト、ｍｏｒｅ−ｔｏｋｅｎオブジェクト、及び／又は適切な場合、エラーメッセージを返す。
【０２５４】
各ストレージノード３７０上のローカルクエリプロセッサは、少なくとも以下の、例示的なクエリインターフェースを公開してもよい。
Query ( queryID, subscriber identifier, bucket identifier, query-expression, more-token, update-cookie)
【０２５５】
Ｑｕｅｒｙは、クエリＩＤ、加入者識別子、バケット識別子、クエリ式、ｍｏｒｅ−ｔｏｋｅｎオブジェクト、及び更新クッキを受け入れる。Ｑｕｅｒｙは、クエリＩＤ、ｅＩＤリスト、ｍｏｒｅ−ｔｏｋｅｎオブジェクト、及び／又は適切な場合、エラーメッセージを返す。
【０２５６】
以下は、クエリサービスのコンポーネントの、例示的な要求されるインターフェースである。
【０２５７】
ストレージノードロケータ３６８は、書き込み、及びリスト属性操作に対する、ストレージホストのランク付けされたリストを見つけるために使用することができる、インターフェースを公開してもよい。
GetStorageNodes ( subscriber identifier, bucket identifier) 
【０２５８】
ＧｅｔＳｔｏｒａｇｅＮｏｄｅｓは、加入者識別子及びバケット識別子を受け入れ、１つ以上のストレージノード３７０のリストを返す。
【０２５９】
グループヘルス２２６のコンポーネントは、利用可能なクエリＴＳＡＲノード３６０を位置付けるために、クエリノードロケータ３５４によって使用することができる、１つ以上のインターフェースを公開してもよい。
Status (group)
【０２６０】
Ｓｔａｔｕｓは、特定のグループ内のノードに関する状態情報を返す。グループ内のノードに関する状態が、１つも既知ではない場合、ゼロの状態（又は、「ｓｔａｔｕｓ  ｕｎｋｎｏｗｎ」）が返される。一実施形態では、状態は、各ノードに対する質のベクトル：｛ｓｔａｔｕｓ，  ［｛Ｑｕａｌｉｔｙ，  Ｌｅｖｅｌ｝，  ｛｝．．．］として、返すことができる。状態情報は、ディスクスペース、「温度」の読み込み、活性などの１つ以上を含むことができるが、それらに限定されない。
Monitor (group, callback) 
【０２６１】
Ｍｏｎｉｔｏｒは、非同期コールバックを介して、グループ状態の変更を返す。
【０２６２】
ストレス管理
検索可能なデータサービスの実施形態は、分散型、非集中的、自動化ストレス管理機構を実装することができる。実施形態では、検索可能なデータサービスにおける各ノードは、できる限りそれ自体のリソースを管理することができる。ノードは、それらのリソース使用を監視することができ、それらのリソース使用について、他のノードの限定されたセットと通信することができる。リソース使用がノード上であまりに高く、コンフォートゾーンから外れる場合、リソースは、ホット状態と見なされ得る。十分に使用されていないリソースは、コールド状態と見なされ得る。各ノードは、そのリソース使用をコンフォートゾーン内にとどめるために実行することができる、アクションを有することができる。
【０２６３】
一実施形態では、ストレス管理は、実行されるモニタリング、分析／決定、及び行動を制御する別のプロセスを有し、モジュール式であることが可能である。一実施形態では、ディスクスペースは、自動化ストレス管理機構によって、アクティブに管理することができる。他の実施形態は、通信帯域、読み込み負荷、書き込み負荷、及び／又はＣＰＵ使用又は負荷、又はそれらの組み合わせの１つ以上を含むが、それらに限定されない、他のシステムリソースをアクティブに管理することができる。
【０２６４】
ストレス管理機構の実施形態は、重要なリソースの自動化モニタリング、リソース使用の分析、及びリソース使用をコンフォートゾーンにとどめるためのアクションの決定、及び実行を含むがそれらに限定されない、機能性を提供することができる。ストレス管理機構によって実行されるアクションは、全体のシステムの性能、可用性、及び／又は信頼性に影響を与える可能性のある、システム負荷を生成しないように、実行することができる。
【０２６５】
実施形態では、検索可能なデータサービスノードによって監視することができる、リソースに対する使用評価指標は、以下の１つ以上を含むことができるが、それらに限定されない。
・ストレージ（例えば、ディスク）空間：一部の実施形態は、利用可能なストレージ空間が、コンフォートゾーン内にあるか決定するため目的で、ストレージノード上の利用可能な、及び／又は使用されているストレージ空間の割合を監視することができる
・ＣＰＵ（プロセッサ）負荷：一部の実施形態は、ＣＰＵ（プロセッサ）使用を監視することができる。一実施形態は、キューの深さ、及び／又は１つ以上の他のＣＰＵ使用評価指標を監視することができる。使用されているノードの潜在的スループットの割合は、ＣＰＵ使用がコンフォートゾーン内にあるか決定する目的で、監視することができる
・読み込み負荷：一部の実施形態は、ディスク読み込みの数を監視することができる。読み込みは、主としてクエリによって、副次的に「リスト属性」コールによって、決定することができる。実施形態は、これらのコールが静かに損失していないこと、またコールが実行不可能な場合、コールがエラーを返すことを確実にすることができる
・書き込み負荷：一部の実施形態は、ディスク書き込みの数を監視することができる。ホスト／ディスクがあまりに多くの書き込み負荷を有するとき、ｅＩＤ属性の更新は、速度を落とすことができる。実施形態は、書き込みが静かに損失していないこと、またコールが実行不可能な場合、更新がエラーを返すことを確実にすることができる
【０２６６】
一実施形態では、リソース負荷ログは、最近のアクティビティを示す移動ウィンドウ平均を有する、各ノード上に維持することができる。例えば、ディスクスペースが、ストレージノードのコンフォートゾーンに対してあまりにホットであるとき、データはストレージノードから、１つ以上の他のストレージノードへ移動することができる。一実施形態では、ストレス管理機構は、リソースが極めて低い状態に達する前に、ノード上のディスクスペース（又は別のリソース）を増大することができる。
【０２６７】
一実施形態では、ディスクがストレージノード上で、あまりにいっぱいになるとき（すなわち、ストレージノード上のディスクスペースのリソース使用が、あまりにホットであり、したがって、ストレージノードに対するコンフォートゾーンから外れる、又は外れようとしているとき）、データは、ディスクから移動されてもよい。一実施形態では、これは、データ移動を最小限に抑えて実行されてもよい。
【０２６８】
図１５は、一実施形態に従い、検索可能なデータサービスシステムのためのストレス管理方法のフローチャートである。検索可能なデータサービスシステムは、複数のノード上で実装することができる。ノードは、１つのデータセンタに位置付けられることができるか、又は、２つ以上のデータセンタにわたって分散することができる。データセンタは、地理的に分散されてもよい。一実施形態では、検索可能なデータサービスは、少なくとも１つのコーディネーションサブシステム、クエリサブシステム、及びストレージサブシステムを含むことができる。一実施形態では、複数のノードは、コーディネーションサブシステムを実装する１つ以上のコーディネータノード、クエリサブシステムを実装する１つ以上のクエリノード（クエリＴＳＡＲノードとも呼ばれる）、及びストレージサブシステムを実装する１つ以上のストレージノードを含むことができる。一実施形態では、ウェブサービスプラットフォームは、１つ以上のインタフェースコールを、検索可能なデータサービスのクライアントアプリケーションに提供する検索可能なデータサービスに、Ｗｅｂサービスインターフェースを提供することができる。
【０２６９】
一実施形態では、複数のノードは、それぞれ複数のノードのサブセットを含む、２つ以上のノードグループへ自己組織化することができる。一実施形態では、ノードグループは、それぞれストレージノードのサブセットを含む、１つ以上のストレージノードグループ、それぞれクエリノードのサブセットを含む、１つ以上のクエリノードグループ、及び、それぞれコーディネータノードのサブセットを含む、１つ以上のコーディネータノードグループを含むことができる。一実施形態では、各クエリノード、及び各コーディネータノードは、サービス要求を受信するために、適切なストレージノードを位置付けるよう構成される検索可能なデータサービスの、ストレージノードロケータのコンポーネントのインスタンスを含むことができ、ノードグループは、それぞれクエリノード、及びコーディネータノードのサブセットを含む、１つ以上のストレージノードロケータグループを含むことができる。他の実施形態は、他の種類のノードグループを含むことができる。
【０２７０】
１２００に示すように、ノードグループ内の各ノードは、ノード上の検索可能なデータサービスの性能をサポートするのに使用される、ノードの１つ以上のローカルリソースのそれぞれに対する、１つ以上の使用評価指標を監視することができる。一実施形態では、ノードグループ内のノードは、ゴシッププロトコルに従って、ローカルリソースに対する使用評価指標を、ノードグループ内の他のノードに伝えることができる。１２０２に示すように、ノードグループ内のノードの１つは、ノードのローカルリソースの１つに対する、監視された使用評価指標が、使用評価指標に対する、特定のコンフォートゾーンの限界を超えていることを検出することができる。１２０４に示すように、ノードは、ノード上のローカルリソースに対するリソース使用の少なくとも一部を、同様のリソースを含むノードグループ内の別のノードに移動するために、ノードグループ内の少なくとも１つの他のノードと通信することができる。一実施形態では、ゴシッププロトコル、及び／又はアンチエントロピープロトコルは、少なくとも１つの他のノードと通信するために、使用することができる。ここで留意すべきは、ローカルリソースに対するリソース使用の少なくとも一部を、ノードグループ内の別のノードに移動するによって、ノード上のローカルリソースに対する監視された使用評価指標を、ノード上の使用評価指標に対する特定のコンフォートゾーン内に、移動することが可能であるということである。
【０２７１】
以下は、一実施形態に応じて、検索可能なデータサービスシステム内のストレス管理機構によって実行可能なディスク負荷を管理するための、例示的なストレス管理アルゴリズムである。ここで留意すべきは、アルゴリズムは、必要な場合に、新しいホストを検索可能なデータサービスシステムに追加すること、及び必要な場合に、個々のホスト（ストレージノード）上のディスクスペースを増大することの、両方を行うことである。個々のホストは、ディスクスペース使用をローカルに管理するために、このアルゴリズムの関連部分の実装を使用することができる。ここで留意すべきは、他の実施形態は、他のアルゴリズム、又はこのアルゴリズムの修正を使用することができることである。
定義：
Ｄa＝すべてのストレージノードにわたる、ディスク使用の平均割合
Ｄth＝ディスク使用閾値。コンフォートゾーンの上限
Ｄc＝コンフォートゾーンの下限
Ｄi＝ホストＨi上のディスク使用の割合
Ｐi＝Ｈi上のパーティション
例示的なアルゴリズム：
Ｄa＞Ｄthである場合、ホストを追加する。
Ｄi＞Ｄthである場合、Ｈiが移動しようと提示するパーティションのリストを公開する。リストは、Ｈiのパーティションの１つ以上、又はすべてをも含むことができる。
Ｄa＜Ｄcであるときのホストは、それらがＤthを超えることなく、受け入れることができるリストからのパーティションをビッドすることができる。
Ｈiは、
Ｄc＜Ｄi（新）＜Ｄth
移動コストは低い
パーティションは、ほとんどが空き容量のディスクに行くのような１つ以上のビッドを受け入れることができる。
その後、Ｈiが、Ｄth未満にさせるビッドを受信しない場合、Ｈi上のパーティション（一実施形態では、最小のパーティション）を分割し、パーティションの更新されたリストを再提示する。
【０２７２】
一実施形態では、新しいパーティションは、同一、又は同様の機構を使用して、提示することができる。デフォルトサイズは、新しいパーティションに対して、実数（ゼロに近い）の初期サイズの代わりに、使用することができる。
【０２７３】
一実施形態では、より大きなパーティションに対するディスク上の大きな空き容量を確保するために、上記のアルゴリズムは、その移動がディスクをコンフォートゾーンに入れることができる場合、パーティションがディスクへ移動される可能性が高くなるように、修正してもよい。本実施形態では、コンフォートゾーン内のホストは、パーティション上でビットすることができない。この修正は、大量の空き容量を有するディスクへ、より小さいパーティションを移動させることを防ぐのに役立つことができ、したがって、より大きいパーティションに対する空き容量を確保することができる。
【０２７４】
他の実施形態は、ディスクスペースのストレス管理アルゴリズムの実行に適用されてもよい、パーティションの移動に関する１つ以上の他のルールを実行することができる。例えば、一実施形態は、最近ほとんど増大していないパーティションによる、ディスクの充填（Ｄth、及び／又はコンフォートゾーンの幅の増大）を可能にするルールを実行することができる。別の例として、一実施形態は、最近大幅に増大し、低活動期にＤthに近づいているディスクからの、パーティションを移動を可能にするルールを実行することができる。
【０２７５】
グループ通信
グループ通信２２２のコンポーネントは、例えば、検索可能なデータサービスの他のコンポーネントが、インデックス情報の弱一致性の複製データベースを維持することを可能にするために、使用することができる。グループ通信２２２は、更新を、以下の種類の複製データセットの１つ以上に「運ぶ」ことができるが、それらに限定されない。
・独立したストレージ／インデックス／クエリサブシステムにおける、検索可能なデータサービスのエンティティ
・バケットの区分情報、及び独立したストレージホストの複製グループディレクトリ
・クエリサブシステムのホスト、及び要求ルーター２０２のホストに関する、グループメンバーシップ情報
【０２７６】
弱一致性は、複製データの読み込みが、複製グループのほかの場所で適用された、最も最近の書き込みによって行われた変更を反映できないことを意味する。さらなる変更がない場合、例えば、ネットワークパーティション、及び／又はノード再起動によって、収束が遅延しても、すべての複製は、同一値に収束するべきである。
【０２７７】
一実施形態では、グループ通信は、２つの方法：ゴシップ及びアンチエントロピーに依存することができる。ゴシップ（又は「ｒｕｍｏｒ  ｍｏｎｇｅｒｉｎｇ」は、確率的なフラッディングの間は、信頼できないマルチキャストである。アンチエントロピーは、無作為ピアホストを選択し、選択されたホスト上のピアデータベース、及び他のホスト上のピアデータベース間のいかなる違いも検索し、解決するプロセスである。一実施形態では、高レベル、及び低レベルのアンチエントロピーが実行されてもよい。
【０２７８】
高レベルのアンチエントロピーは、メッセージの確率的なフラッディングが、ホストを失った可能性のある場合を処理するために、ゴシップされた更新のピアのログを比較することができる。高レベルのアンチエントロピーは、基礎データベースに関係なく、実行されてもよい。低レベルのアンチエントロピーは、データベースを比較し（又は、一実施形態では、チェックサムのような、データベースの統計値を合計し）、ノードが再起動した、そうでなければ、そのメッセージログを失った場合、又はノードが複製グループに加わり、データベースのコピーを冪等的に得るために、低レベルのアンチエントロピーを使用する場合を、処理することができる。
【０２７９】
一実施形態では、グループ通信２２２のコンポーネントは、基礎データベースの実行の知識をまったく有していなくてもよい。グループ通信２２２のコンポーネントは、データベースに、更新を広めるというコールを提供し、受信された更新を処理、及び低レベルのアンチエントロピーを実行するためのコールバックを提供するために、データベースに依存する。
【０２８０】
グループ通信２２２のコンポーネントは、グループヘルス２２６のコンポーネントと、頻繁な相互作用を有することができる。一実施形態では、２つのコンポーネントは、別々のプロセスにおいて実装されてもよい。別の実施形態では、これらのコンポーネントの両方は、２つのコンポーネントがデータ構造を共有することができるように、同一のプロセス内で実装されてもよい。
【０２８１】
複製グループのライフサイクル
図１６は、一実施形態に従い、検索可能なデータサービスにある複製グループ３００のライフサイクルを例示している。新しいホスト３１０は、複製グループ３００に追加されてもよく、既存ホスト３１０は、複製グループ３００から取り除かれるか、それを中止することができる。新しいホスト３１０（例えば、ホスト３１０Ｊ）は、３２０それら自体をプレッジ３０４として宣言、又は誓約することによって、複製グループ３００に追加することができる。誓約されたホスト３１０（例えば、ホスト３１０Ｇ、及び３１０Ｈ）は、複製されたデータセットへのゴシップされた更新を受信することができる。次に、誓約されたホスト３１０は、既存複製グループ３００のメンバ（例えば、ホスト３１０Ｆ）を選択し、低レベルのアンチエントロピーを実行することができる。誓約されたホスト３１０はまた、すべての更新を受信することができるため、アンチエントロピーが終了するとき、誓約されたホスト３１０は、いかなる他の複製グループ３００のメンバと同じくらい最新であることが可能であり、したがって、３２２それら自体を、複製グループ３００へと先導することができる。
【０２８２】
ホスト３１０（例えば、ホスト３１０Ｋ）は、例えば、失敗又は放棄によって、複製グループ３００を脱退することがある。脱退は、あまりに多くの同時の脱退が、複製グループ３００に、その最小限のメンバーシップ要求を下回らせる可能性があるため、同期化を要求することができる。
【０２８３】
一実施形態では、グループメンバーシップの変更は、近親グループ３０２として知られる、ホストの１つ以上の他のグループに、送信されてもよい。複製グループに対しては、近親グループは、ストレージノードロケータグループである。ストレージノードロケータグループに対しては、近親グループは、すべての複製グループである。複製グループは、特定のパーティションの複製を保存する、ストレージノードのグループである。ここで留意すべきは、複製グループは、図９Ｃ、及び図１０において、複製グループ２５６として図解されることである。ストレージノードロケータグループは、それぞれがストレージノードロケータ２１６のインスタンスを含む、検索可能なデータサービスにおけるノード（ホスト）のグループである。
【０２８４】
検索可能なデータサービスの実施形態は、ホスト、又はノードの以下のタイプのグループの１つ以上を含むことができるが、それらに限定されない。ここで留意すべきは、名前が、各タイプのグループに対して提供されることである。これらの名前は例示的なものであり、限定することを意図しないことである。
・ｓｎｌ＿ｈｏｓｔｓ：ストレージノードロケータ（ｓｎｌ）を実装するいくつかの、又はすべてのノードを含む。一実施形態では、すべてのコーディネーション、及びクエリ集約サブシステムのノード
・ｑｔｓａｒ＿ｈｏｓｔｓ：クエリサブシステム内のいくつかの、又はすべてのノードを含む。これは、クエリノードグループとも呼ばれることができる
・ｃｏｏｒｄ＿ｄａｔａｃｅｎｔｅｒ＿ｈｏｓｔｓ：所定のデータセンタ内のすべてのコーディネータノード。これは、コーディネータノードグループとも呼ばれることができる
・ｓｎ＿ｓｕｂｓｃｒｉｂｅｒ＿ｂｕｃｋｅｔ＿ｍａｓｋ＿ｖａｌｕｅ＿ｈｏｓｔｓ：名前付けされたパーティションに対する、複製グループ。「ｓｎ」は、「ストレージノード」を表す。これは、他でパーティショングループと呼ばれるものであるが、ストレージノードグループとも呼ばれることができる
【０２８５】
グループ通信インターフェース
以下は、一実施形態に応じて、検索可能なデータサービスのグループ通信２２２のコンポーネントによって公開、又は要求することができる、例示的なインターフェース（例えば、コール及びコールバック、内部的及び外部的の両方（ピアツーピア））を説明する。ここで留意すべきは、これらのインターフェースは例示的なものであり、限定することを意図しないということである。他の実施形態は、他のインターフェースを含むことができるか、又はこれらのインターフェースの１つ以上を含まなくてもよい。
コール
constructor(argument(s))
【０２８６】
一実施形態は、新しい複製グループ３００を構築するために、コンストラクタコールを提供することができる。このコンストラクタは、ｇｃａｓｔコールを介して受信される初期更新をうまく認識し、提供するために必要とされる最小数のグループメンバを含むが、それに限定されない引数として、１つ以上のパラメータを受け入れることができる（以下参照）。
gcast(Group, Msg)
【０２８７】
ｇｃａｓｔは、ゴシップされたメッセージを、グループ内へ先導する。Ｇｒｏｕｐは、グループを名前付ける文字列である。Ｍｓｇは、グループへ送信されるメッセージを特定する値である。これは、ｍｓｇ引数として、他のグループメンバに対するａｐｐｌｙコールバックに与えられる。
【０２８８】
一実施形態では、ｇｃａｓｔコールの結果は、以下の要素の１つ以上を含むが、それらに限定されないオブジェクトである。
・ホスト：今までのところ更新を認識してきたストレージノードをリストアップする、文字列の配列
・耐久性：メッセージが、最小数のグループメンバに初期に伝えられたかどうか示すブーリアン。システムは、偽が返されても、メッセージを伝達するよう試み続ける
・クッキー：メッセージが、すべてのグループメンバによって認識されたか見るために、後にｇｓｙｎｃに与えられる値
【０２８９】
一実施形態では、ｇｃａｓｔコールは、以下のエラーの１つ以上を生成することがあるが、それらに限定されない。
・無効のグループタイプ
・無効のグループ名
gsync(Cookie) 
【０２９０】
ｇｓｙｎｃは、ゴシップされたメッセージがすべての非失敗グループメンバに届いたかどうか示す、ブーリアンを返す。Ｃｏｏｋｉｅは、成功したｇｃａｓｔコールによって返された値である。ｇｓｙｎｃコールの結果は、すべてのグループメンバがメッセージを認識したかどうか示すブーリアンである。一実施形態では、ｇｓｙｎｃコールは、無効のクッキーエラーを生成することがあるが、それに限定されない。
コールバック
apply(Group, Msg)
【０２９１】
ａｐｐｌｙコールバックは、所定のメッセージによって説明される変更を、複製データセットに適用する。Ｇｒｏｕｐは、グループ名を示す文字列である。Ｍｓｇは、適用されるメッセージを示す値である。
【０２９２】
一実施形態では、ｇｃａｓｔコールの結果は、以下のうちの１つ以上を含むことができるが、それらに限定されない。
・ＯＫ：より最近指示された変更によって、おそらくは全部ではないが、変更がうまく適用された
・ＤＵＰ：又は「ｄｕｐｌｉｃａｔｅ」。特定の変更が、すでに受信されている
・ＬＡＴＥ：特定の変更が、より最近指示された変更によって、廃棄されている
・Ｅｒｒｏｒ：エラー理由を与える文字列。Ｅｒｒｏｒによって特定される理由により、変更は適用されることができない。結果として、一実施形態では、低レベルのアンチエントロピーセッションは、自己修復を実行するために、ピアと共に要求することができる
antientropy(Group, Host)
【０２９３】
ａｎｔｉｅｎｔｒｏｐｙコールバックは、名前付けされたグループに関連するデータに対する、特定のピアホストを有する、アンチエントロピーセッションを開始する。Ｇｒｏｕｐは、グループの名前を示す文字列である。Ｈｏｓｔは、アンチエントロピーを実行するための、ピアホストの名前を示す文字列である。ａｎｔｉｅｎｔｒｏｐｙは、全体のデータセットがトラバースされたかどうか示す、ブーリアンを示すことができる。偽である場合、同一グループに対する別のアンチエントロピーセッションが、好ましくは異なるピアホストで、開始することができる。一実施形態では、ａｎｔｉｅｎｔｒｏｐｙコールバックは、グループ無効、又はホスト無効エラーを生成することがあるが、それに限定されない。
【０２９４】
ピアツーピアコール
ピアツーピアコールは、検索可能なデータサービスの実装に内部的である。これらのコールは、特定のグループのメンバ間で、又はメンバに行われる。
rumor(Group, Originator, Seqno, OrigVtime, Msg)
【０２９５】
ｒｕｍｏｒピアツーピアコールは、ｒｕｍｏｒ−ｍｏｎｇｅｒｉｎｇによって、グループ内に更新を広める。Ｇｒｏｕｐは、更新が広められるグループの名前を示す文字列である。Ｏｒｉｇｉｎａｔｏｒは、送信元ホストの名前を示す文字列である。Ｓｅｑｎｏは、更新に対する送信元のシーケンス番号を示す。ＯｒｉｇＶｔｉｍｅは、更新に対する送信元の仮想時間を示す。Ｍｓｇは、ａｐｐｌｙコールバックを介して、離れたデータベースに適用される、広められている更新を示す。ｒｕｍｏｒコールの結果は、ｒｕｍｏｒがうまく受信されているかどうか示す、ブーリアンであることが可能である。一実施形態では、ｒｕｍｏｒコールは、グループ無効エラーを生成することがあるが、それに限定されない。
request_membership(Group, Mode, Generation, Seqno)
【０２９６】
ｒｅｑｕｅｓｔ＿ｍｅｍｂｅｒｓｈｉｐピアツーピアコールは、自発的なメンバーシップ変更が、受信側のグループメンバーシップビューにおいて、送信側に対して行われることを要求する。Ｇｒｏｕｐは、グループの名前を示す文字列である。Ｍｏｄｅは、メンバーシップ変更の種類を示す。一実施形態では、これは、「誓約」、「開始」、及び「脱退」の１つであってもよい。Ｇｅｎｅｒａｔｉｏｎは送信側の世代番号を示し、それは、再起動後増分すると保証され得る。Ｓｅｑｎｏは、認識ベクトル（以下参照）が、すべてのグループメンバが操作を確かめたときを示すために、使用することができるように、操作に対する送信元のシーケンス番号を示す。ｒｅｑｕｅｓｔ＿ｍｅｍｂｅｒｓｈｉｐコールの結果は、受信者が、要求されたグループメンバーシップの変更を行ったかどうか示す、ブーリアンである。一実施形態では、ｒｅｑｕｅｓｔ＿ｍｅｍｂｅｒｓｈｉｐコールは、グループ無効エラーを生成することがあるが、それに限定されない。
【０２９７】
一実施形態では、受信されたｒｅｑｕｅｓｔ＿ｍｅｍｂｅｒｓｈｉｐコールは、受信側によって、１人以上の他のグループメンバに転送されてもよい。一実施形態では、受信側は、ｒｅｑｕｅｓｔ＿ｍｅｍｂｅｒｓｈｉｐコールが転送されている他のグループメンバのリストを、送信側に返すことができる。
failure(Group, Host, Generation)
【０２９８】
ｆａｉｌｕｒｅピアツーピアコールは、グループメンバが、失敗したと確認されたことを発表する。Ｇｒｏｕｐは、グループの名前を示す文字列である。Ｈｏｓｔは、失敗したホストを識別する。Ｇｅｎｅｒａｔｉｏｎは、失敗時の、失敗したホストの世代を示す。
fast_anti_entropy(Group, View, SummaryVec, AcknowledgementVec)
【０２９９】
ｆａｓｔ＿ａｎｔｉ＿ｅｎｔｒｏｐｙピアツーピアコールは、ｒｕｍｏｒ−ｍｏｎｇｅｒｉｎｇによって見逃されたおそれのある更新を交換するために、アンチエントロピーの速い、又は高レベルのフェーズを開始する。これらの操作の交換は、ｓｙｎｃに２つのホストを運ぶために、いかなる必要なルーモア機能も後に続くことができる。Ｇｒｏｕｐは、グループの名前を示す文字列である。Ｖｉｅｗは、グループメンバーシップビューを表すオブジェクトである。ＳｕｍｍａｒｙＶｅｃは、要約ベクトルを表すオブジェクトである。ＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔＶｅｃは、認識ベクトルを表すオブジェクトである。ｆａｓｔ＿ａｎｔｉ＿ｅｎｔｒｏｐｙコールの結果は、２つのホストがすべての利用可能なメッセージを交換するまで、相互コール、及びルーモア操作の交換が後に続くように、情報の成功した処理を示すブーリアンであることが可能である。一実施形態では、ｆａｓｔ＿ａｎｔｉ＿ｅｎｔｒｏｐｙコールは、グループ無効エラーを生成することがあるが、それに限定されない。
【０３００】
一実施形態では、受信されたｆａｓｔ＿ａｎｔｉ＿ｅｎｔｒｏｐｙコールは、受信側によって、１人以上の他のグループメンバに転送されてもよい。一実施形態では、受信側は、ｆａｓｔ＿ａｎｔｉ＿ｅｎｔｒｏｐｙコールが転送された他のグループメンバのリストを、送信側に返すことができる。
【０３０１】
グループメンバーシップ及びヘルス
一実施形態では、グループヘルス２２６のコンポーネントは、検索可能なデータサービスの１つ以上の他のコンポーネントが、コンポーネントが監視可能なノードのセットを識別することを可能にすることができる。次に、グループヘルス２２６のコンポーネントは、それらのノードに関する自動的にリフレッシュされたヘルス情報に対して、他のコンポーネントによってクエリされてもよい。一実施形態では、グループヘルス２２６のコンポーネントはまた、失敗検出機構として機能することができる。
【０３０２】
検索可能なデータサービスの実施形態では、ホスト（ノード）は、グループヘルス２２６のコンポーネント、及びグループ通信２２２のコンポーネントを介して、それら自体、及び他のノードに関するヘルス情報を交換することができる。一実施形態では、検索可能なデータサービスのノードが、他のノードと通信していない場合、ノード失敗、ネットワーク失敗、又は何らかの他の理由によるものであっても、ノードの情報の停滞は、他のノードによって通知されてもよく、タイマーは、サイレントノードが失敗したと最終的に宣言するために、使用することができる。この時間のカプセル化は、コンポーネントが非同期的に機能することを可能にすることによって、他のコンポーネントを単純化するのに役立つことができ、ノードＡが、ノードＢからの応答を待っている場合、ノードＡは、最終的にノードＢからの応答受信するか、ノードＢの失敗を通知することができる。一実施形態では、別のノードは、グループヘルスメッセージが、最後に受信されたグループヘルスメッセージの後の事前指定されたタイムアウト期間と等しい、又はより大きい期間に、（直接、又はゴシップを介して）そのノードから受信されない場合、失敗した、又はオフラインになったと決定することができる。
【０３０３】
一実施形態では、分散型負荷平均化は、グループメンバーシップ、及びヘルス２２６のコンポーネントを介して、少なくとも部分的に、制御されてもよい。例えば、一実施形態では、グループヘルス２２６のコンポーネントは、現在の負荷平均及び距離を考慮に入れて、複製グループから最適なメンバノードを選択するための機構を提供することができる。
【０３０４】
一実施形態では、検索可能なデータサービス内の各ノード上に、グループヘルス２２６のコンポーネントのインスタンスがあってもよい。一実施形態では、他のノードがノードの失敗を検出することを可能にするために、各ノード上のグループヘルス２２６のコンポーネントは、ハートビートメッセージとも呼ばれるグループヘルスメッセージを、１つ以上の隣接ノードに定期的に送信することができる。ハートビートメッセージは、ノードに対する現在のローカルヘルス統計値を含むことができる。これらの統計値は、以下のノードヘルス情報の評価指標の１つ以上を含むことができるが、それらに限定されない。
・プロセッサの使用評価指標−例えば、ＣＰＵ（プロセッサ）負荷平均／実行キューの深さなど
・ストレージ、及び／又はメモリリソースの使用評価指標−例えば、ディスクＩ／Ｏ、ディスク空き容量、ページング／スワッピング評価指標など
・ネットワーク／帯域リソースの使用評価指標−例えば、ネットワーク通信リソースに対する、ネットワークトラフィック評価指標
【０３０５】
統計値は、例えば、１分にわたる、又は５分にわたるなどの期間にわたる（又は、評価指標の異なるものに対して異なる期間にわたる）、平均であってもよい。一実施形態では、ノードのヘルス情報の評価指標に対する平均は、操作における増加又は減少を伴う負荷におけるわずかな変化の推定値を確立するために、操作カウントに対して相関性があってもよい。一実施形態では、グループヘルス２２６のコンポーネントは、平均化に対する最後の期間において、操作のバケットごとの内訳を得るために、必要に応じて、１つ以上の他のローカルコンポーネントをクエリすることができる。統計値は、例えば、「１秒ごとに追加の１５０クエリが受け入れられる場合、ディスクＩ／Ｏのストレスはどのようなものになるのか」、などの操作の数における変化に応えて実現することができる、ＣＰＵ負荷（又は帯域、又はストレージなど）における変化の予測により、増大することができる。例えば、これは、ストレージノード上のパーティションマネージャー２３２のコンポーネントが、構成に対して１つ以上の提案された変更が行われる場合、負荷がどのようなものになり得るか予測することを、可能にすることができる。
【０３０６】
一実施形態では、ハートビートメッセージは、エピデミック、又はゴシックプロトコルを介して、検索可能なデータサービスシステム全体の、又は、検索可能なデータサービスシステム内のノードのグループ内のノード上のコンポーネントに、伝えられることができる。一実施形態では、通信は、上述のように、検索可能なデータサービスのグループ通信２２２のコンポーネントを介して、実行することができる。一実施形態では、グループヘルス情報は、他の検索可能なデータサービスのノード間、又はコンポーネント間メッセージ上で、ピギーバックすることができる。
【０３０７】
ノードが、特定の閾値、又は期間（例えば、５分）を超える期間、別のノードに対するハートビートメッセージを受信していない場合、ノードは、他のノードが失敗したと予測することができる。ノードが、期間中、いかなる他のノードからもいかなるハートビートを受信しない場合、ノードは、そのネットワーク接続が失敗したと予測することができる。
【０３０８】
一実施形態では、ノードがハートビートメッセージを受信するとき、ノードは、これが、ノードが見る、送信元ノードからの最も最近のハートビートメッセージであるかどうか調べるために、内部テーブルをチェックすることができる。そうではない場合、ハートビートメッセージは廃棄される。それが、送信元ノードからの最も最近のハートビートメッセージである場合、内部テーブルは更新され、次に、ハートビートメッセージは、１つ以上の他の隣接ノードに送信されてもよい。一実施形態では、隣接ノードは、無作為に選択されてもよい。一実施形態では、隣接ノードは、ハートビートがＷＡＮリンク上で送信される回数を減らすために、より近い隣接ノードに重点を置いて、選択されてもよい。しかしながら、ネットワーク上で遠隔ノードにハートビートメッセージをうまく送信する（また、ハートビートメッセージを受信する遠隔ノードの）確率は、ハートビートが、検索可能なデータサービスシステム内のすべての他のデータセンタに、最終的に達するという望ましいレベルの確実さを実現するために、十分高くあるべきである。
【０３０９】
一実施形態では、ハートビートメッセージが転送される隣接ノードは、監視されるグループごとに選択されてもよい。例えば、ノードＡのグループヘルス２２６のコンポーネントが、ノードＡがそれぞれメンバであるグループＧ１、Ｇ２、及びＧ３を監視しており、また、ノードＡがメンバーではないグループＧ４、Ｇ５、及びＧ６も監視している場合、ノードＡのハートビートメッセージは、６つのグループのそれぞれにおけるＮホストに送信されてもよい。一実施形態は、重複メンバーシップを有するグループに対するハートビートメッセージが転送される、ノードの選択を最適化することができる。例えば、グループＧ２におけるノードＢが、ノードＡからのハートビートメッセージを受信するために選択され、また、ノードＢがグループＧ４及びＧ６のメンバでもある場合、ノードＢは、それらの他のグループに対するハートビートメッセージを受信するためにも、選択されてもよい。
【０３１０】
ノードが、例えば５分の期間、監視されるノードからのヘルス更新を見ていない場合、ノードは、異なるノードでヘルスアンチエントロピーを実行することができ、それは、一実施形態では、ノードからの距離を減少させる確率に応じて、選択されてもよい。他の実施形態は、ヘルスアンチエントロピーが実行可能な異なるノードを選択するために、他の方法、若しくは評価指標、又はそれらの組み合わせを使用することができる。例えば、一実施形態では、異なるノードは、効果的なネットワーク、及びノード利用コストを減少する確率に応じて、選択されてもよい。アンチエントロピーが監視されるノードに対する更新をもたらさない場合、監視されるノードは、監視しているノード上のローカルコンポーネントに対して、故障、又は使用不可と識別されてもよい。
【０３１１】
一実施形態では、１つ以上の、ゴシップ、又はエピデミックプロトコルは、ヘルス情報の更新の弱一致性のマルチキャスティングに対して、使用されてもよい。一実施形態では、グループ通信２２２のコンポーネントが、グループメンバーシップ、及びヘルス２２６のコンポーネントに依存しているため、グループヘルス２２６のコンポーネントは、グループ通信２２２のコンポーネントの常連のクライアントとして、見なされることができない。
【０３１２】
グループヘルス２２６のコンポーネントは、グループ通信２２２のコンポーネントと頻繁な相互作用を有することができる。一実施形態では、２つのコンポーネントは、別々のプロセスで実装されてもよい。別の実施形態では、これらのコンポーネントの両方は、２つのコンポーネントがデータ構造を共有することができるように、同一のプロセス内で実装されてもよい。
【０３１３】
ヘルス更新を実行するために必要とされるネットワークトラフィックの量は、ノードの潜在的に大きいグループにより、検索可能なデータサービスをスケーリングするための制限因子であってもよい。したがって、一実施形態では、検索可能なデータサービス内のノードのグループは、グループの階層として組織化されてもよく、したがって、ノードのいかなる単一のグループのサイズを制限する一方で、大きいデータセットが対処されることを可能にする。
【０３１４】
図１７は、一実施形態に応じて、検索可能なデータサービスシステムにおいて、グループヘルスを監視するための方法を図解する。検索可能なデータサービスシステムは、複数のノード上で実装されてもよい。ノードは１つのデータセンタに位置付けられてもよく、又は２つ以上のデータセンタに分散されてもよい。データセンタは、地理的に分散することができる。一実施形態では、検索可能なデータサービスは、少なくとも１つのコーディネーションサブシステム、クエリサブシステム、及びストレージサブシステムを含むことができる。一実施形態では、複数のノードは、コーディネーションサブシステムを実装する１つ以上のコーディネータノード、クエリサブシステムを実装する１つ以上のクエリノード（クエリＴＳＡＲノードとも呼ばれる）、及びストレージサブシステムを実装する１つ以上のストレージノードを含むことができる。一実施形態では、ウェブサービスプラットフォームは、１つ以上のインタフェースコールを、検索可能なデータサービスのクライアントアプリケーションに提供する検索可能なデータサービスに、ウェブサービスインタフェースを提供することができる。
【０３１５】
一実施形態では、複数のノードは、それぞれ複数のノードのサブセットを含む、２つ以上のノードグループへ自己組織化することができる。一実施形態では、ノードグループは、それぞれストレージノードのサブセットを含む、１つ以上のストレージノードグループ、それぞれクエリノードのサブセットを含む、１つ以上のクエリノードグループ、及び、それぞれコーディネータノードのサブセットを含む、１つ以上のコーディネータノードグループを含むことができる。一実施形態では、各クエリノード、及び各コーディネータノードは、サービス要求を受信するために、適切なストレージノードを位置付けるよう構成される検索可能なデータサービスの、ストレージノードロケータのコンポーネントのインスタンスを含むことができ、ノードグループは、それぞれクエリノード、及びコーディネータノードのサブセットを含む、１つ以上のストレージノードロケータグループを含むことができる。他の実施形態は、他の種類のノードグループを含むことができる。
【０３１６】
１３００に示すように、ノードグループ内の各ノードは、ノードに対するローカルヘルス情報を収集することができる。１３０２に示すように、ノードグループ内の各ノードは、ノードに対する収集されたローカルヘルス情報を含むメッセージを、ノードグループ内の少なくとも１つの他のノードに、周期的に、又は非周期的に送信することができる。１３０４に示すように、ノードグループ内の各ノードは、ノードグループ内の１つの他のノードから送信され、他のノードに対する収集されたローカルヘルス情報を含むメッセージを、周期的に、又は非周期的に受信することができる。一実施形態では、ノードに対するローカルヘルス情報は、ローカルストレージリソースに対する、１つ以上のストレージリソース使用評価指標、ローカルプロセッサリソースに対する、１つ以上のプロセッサ使用評価指標 、及びネットワーク通信リソースに対する、１つ以上のネットワーク使用評価指標の１つ以上を含むことができるが、それらに限定されない。
【０３１７】
一実施形態では、ノードグループ内のノードは、ゴシッププロトコルに従って、ノードグループ内にメッセージを伝えるように構成されてもよい。一実施形態では、ノードグループ内のノードは、他の検索可能なデータサービスのメッセージに関するヘルス情報を、ノードグループ内の他のノードへ、ピギーバックすることができる。
【０３１８】
一実施形態では、ヘルスメッセージは、ノードグループ内の別のノードがオフラインになったか検出するために、ハートビートメッセージとして使用されてもよい。本実施形態では、１３０６に示すように、ノードグループ内のノードの１つは、他のノードに対する収集されたローカルヘルス情報を含む新しいメッセージが、特定の期間内に受信されないと、ノードグループ内の別のノードがオフラインになったことを決定することができる。
【０３１９】
一実施形態では、別の他のノードに対する収集されたローカルヘルス情報を含む新しいメッセージが、特定の期間内に、ノードグループ内の特定のノードから受信されなかったことを検出すると、ノードは、ノードグループ内のノードに対する更新されたヘルス情報を得るために、ノードグループ内の１つ以上の他のノードによって、アンチエントロピー操作を実行することができる。アンチエントロピー操作が、特定のノードに対する更新されたヘルス情報をもたらさない場合、ノードは、特定のノードがオフラインになったことを決定することができる。
【０３２０】
一実施形態では、ノードグループ内のノードは、ノードに対する収集されたローカルヘルス情報を、他のノードからのメッセージ内で受信される、ノードグループ内の他のノードの少なくとも１つに対する、ローカルヘルス情報と比較することができる。ノードは、ノードに対するローカルノードヘルスの決定に、比較を使用することができる。
【０３２１】
グループメンバーシップ、及びヘルスインターフェース
以下は、一実施形態に応じて、検索可能なデータサービスのグループヘルス２２６のコンポーネントによって公開、又は要求されてもよい、例示的なインターフェース（例えば、コール及びコールバック、内部的及び外部的の両方（ピアツーピア））を説明する。ここで留意すべきは、これらのインターフェースは例示的なものであり、限定することを意図しないということである。他の実施形態は、他のインターフェースを含むことができるか、又はこれらのインターフェースの１つ以上を含まなくてもよい。
コール
add(Group, Host)
【０３２２】
ａｄｄコールは、特定のホスト（ノード）を特定のグループに追加する。このコールは、まだ存在していない場合、グループの作成をもたらすことができる。
del(Group, Host)
【０３２３】
ｄｅｌコールは、特定のホスト（ノード）を特定のグループから削除する。このコールは、削除されたホストが、グループ内の唯一のホストであった場合、特定のグループそれ自体の削除をもたらすことができる。
gdel(Group)
【０３２４】
ｇｄｅｌコールは、特定のグループを削除する。
status(Group)
【０３２５】
ｓｔａｔｕｓコールは、特定のグループ内のすべてのノードに対する状態情報を返す。ｓｔａｔｕｓは、グループ内のノード名、及び名前付けされたノードのそれぞれに関する状態情報を含む、オブジェクト内で返される。状態情報は、各ノードに対して、ノードが知られているかどうか、すなわち、ノードが、名前付けされたノードに関して受信される以前の情報を介して、要求側に知られているかどうかについての表示を含むことができる。ノードが知られていない場合、その特定のノードに関する他の状態情報は、有効でないことがある。ノードが知られている場合、ノードに対する状態情報は、ノードが現在使用可能であるかの表示を含むことができ、また、ノードに関する他の情報も含むことができる。
monitor(Group)
【０３２６】
ｍｏｎｉｔｏｒコールは、１つ以上の非同期コールバックを介して、特定のグループに対するグループ状態変更を返す。
unmonitor(Group)
【０３２７】
ｕｎｍｏｎｉｔｏｒコールは、特定のグループに対する非同期コールバックをオフにする。このコールは、特定のグループに対するｍｏｎｉｔｏｒコールを取り消すことができる。
【０３２８】
コールバック
update(Group, Host, Status)
【０３２９】
ｕｐｄａｔｅコールバックは、特定の監視されるグループ内の特定のホスト（ノード）に対する、状態変更の即時通知を提供する。
【０３３０】
ピアツーピアコール
heartbeat(Originator, OrigVtime, StatVec)
【０３３１】
ｈｅａｒｔｂｅａｔピアツーピアコールは、ハートビートのルーモアを伝える。Ｏｒｉｇｉｎａｔｏｒは、ハートビートを送信するホストを示す。ＯｒｉｇＶｔｉｍｅは、ハートビートの仮想時間を示す。ＳｔａｔＶｅｃは、１つ以上の評価指標上の統計値、及び統計値に対する値の配列を含む、オブジェクトであり、ここで、第１の要素は、正規化ストレスであり、第２の要素は、ストレスにおける予測される操作ごとの変化である。統計値が含まれることができる、例示的な評価指標は、以下の１つ以上を含むことができるが、それらに限定されない。
・ｃｐｕ：期間（例えば、１分間）のＣＰＵ負荷平均、又は実行キューの深さ
・ｄｉｓｋｓｐａｃｅ：ディスクスペース利用率及び使用法（例えば、ギガバイトで）
・ｄｉｓｋｉｏ：ディスクＩ／Ｏ操作
・ｎｅｔ：ネットワークＩ／Ｏ操作
・ｍｅｍｐａｇｅ：メモリページング
【０３３２】
管理コンソール
検索可能なデータサービスの一実施形態は、アドミニストレータが、検索可能なデータサービスシステムの動作を監視することを可能にすることができる、管理コンソールを提供することができる。図１８は、一実施形態に従い、検索可能なデータサービスシステムの管理コンソールの高レベルアーキテクチャを例示している。管理コンソール４００は、検索可能なデータサービスシステム内のホスト４１０から、情報を収集することができる。検索可能なデータサービスシステムの実装において、単一の事象（例えば、クエリ、又は追加）は、互いに通信するシステム内の多くのホストをもたらすことがある。事象に関する情報、及び事象に続くことができるシステム内の活動（例えば、メッセージ）の結果のカスケードを監視、記録、分析、要約、及び表示することができる管理コンソール４００を提供することは、検索可能なデータサービスシステムの様々なフェーズの間、システムモニタリング、最適化、及びトラブルシューティングに有用であることが可能である。
【０３３３】
管理コンソール４００は、例えば、システム動作を理解し、デバッグし、最適化を必要とし得る領域を検出するために、検索可能なデータサービスシステムの開発フェーズの間、使用されてもよい。生産フェーズの間、管理コンソール４００は、例えば、システムのヘルスを監視し、問題を識別するため、また、課題が危機的になる前に、予測及び対処するために、使用されてもよい。
【０３３４】
図１８に図解される実施形態では、検索可能なデータサービスの管理は、２つ以上のホスト上にある分散型管理システムのコンポーネントで、分散型アーキテクチャにおいて実行されてもよい。遠隔管理４０２のアプリケーションは、ホストシステム（管理コンソール４００）上にあることが可能である。検索可能なデータサービスシステム内のホスト４１０の１つ以上は、それぞれ、検索可能なデータサービスの活動に関する情報、ヘルス情報、並びに、そのホスト上のコンポーネント４１４間の、及び異なるホスト４１０上のコンポーネント４１４間のコンポーネント間通信を含む、そのホスト４１０内の検索可能なデータサービスコンポーネント４１４の通信を監視、及び収集するローカル管理４１２のモジュールを含むことができる。
【０３３５】
一実施形態では、遠隔管理４０２のアプリケーションは、特定の検索可能なデータサービスノード（ホスト４１０）におけるローカル管理４１２のモジュールで、通信チャネル（例えば、ＲＰＣ（遠隔手続呼び出し）、又はＨＴＴＰ通信チャネル）を確立することができ、１つ以上の検索可能なデータサービスコンポーネント４１４を監視するよう要求する。次に、各ローカル管理４１２のモジュールは、要求された検索可能なデータサービスコンポーネント４１４との接続を確立することができ、それらの検索可能なデータサービスコンポーネント４１４が、モニタリングのためのメッセージを、ローカル管理４１２のモジュールに送信し始めるよう要求する。ローカル管理４１２のモジュールは、これらのメッセージを、遠隔管理４０２のアプリケーションに転送する。
【０３３６】
一実施形態では、遠隔管理４０２のアプリケーションは、例えばアドミニストレータである人間のクライアントに、対話型クライアントインターフェースを提供することができる。クライアントは、クライアントインターフェースを介して、遠隔管理４０２のアプリケーションに、特定（又はすべて）のローカル管理４１２のモジュールに接続するよう命令することができ、ローカル管理４１２のモジュールに、遠隔管理４０２のアプリケーションを介して、特定の検索可能なデータサービスコンポーネント４１４のモニタリングを、可能／不可能にするよう命令することができる。
【０３３７】
管理コンソール４００は、クライアント（例えば、システムアドミニストレータ）に対する収集された情報、及び／又は収集された情報の要約を記録、ログ／保存、分析実行、並びにグラフィック／テキストで表示することができる。一実施形態では、管理コンソール４００は、以下の活動の１つ以上を可能に、又は実行することができるが、それらに限定されない（図６に図解されるコンポーネントを参照する）。
・検索可能なデータサービスホスト間のメッセージを記録、ログ、及び表示する。これらのメッセージは、要求ルーター２０２間のメッセージ、ストレージノードロケータ２１６間のメッセージ、クエリノードロケータ２２０間のメッセージ、ｅＩＤ更新マネージャー２３０間のメッセージ、要求ルーター２０２、及びクエリＴＳＡＲ２１２間のメッセージ、要求ルーター２０２、及びｅＩＤ更新マネージャー２３０間のメッセージ、クエリＴＳＡＲ２１２、及びクエリプロセッサ２２８間のメッセージ、パーティションマネージャー２３２、及びストレージノードロケータ２１６間のメッセージ、パーティションマネージャー２３２間のメッセージを含むことができるが、それらに限定されない
・検索可能なデータサービスホスト内のモジュール、又はコンポーネント間のメッセージ（例えば、ＲＰＣメッセージ）を記録、ログ、及び表示する。これらのメッセージは、要求ルーター２０２−クエリノードロケータ２２０のメッセージ、要求ルーター２０２−ストレージノードロケータ２１６のメッセージ、パーティションマネージャー２３２−ｅＩＤ更新マネージャー２３０のメッセージ、クエリＴＳＡＲ２１２−ストレージノードロケータ２１６のメッセージ、ストレージノードロケータ２１６−グループメンバーシップ及びヘルス２２６のメッセージ、クエリノードロケータ２２０−グループメンバーシップ及びヘルス２２６のメッセージ、パーティションマネージャー２３２−グループメンバーシップ及びヘルス２２６のメッセージ、ストレージノードロケータ２１６−グループ通信２２２のメッセージ、及びクエリノードロケータ２２０−グループ通信２２２のメッセージを含むことができるが、それらに限定されない
・ｅＩＤストア２３６、及びクエリインデックスストア２３４の内容を記録、及び表示する
・グループメンバーシップ情報（例えば、ｓｎｌ＿ｈｏｓｔｓ、ｑｔｓａｒ＿ｈｏｓｔｓなど）を監視、及び表示する
・ストレージノードロケータ２１６の状況を見る：ホスト、及びパーティション複製間のマッピング
・クエリノードロケータ２２０の状況を見る：クエリＴＳＡＲの一貫したハッシングリング
・クエリＴＳＡＲのクエリキャッシュ２１４の内容を表示する
・要求ルーター２０２の状況を見る
・パーティションマネージャー２３２の状況を見る
・グループメンバーシップのリストを変更する
・２つのノード間のアンチエントロピーを開始する
・システムからのリソースを追加、又は除外する
・１つ以上のノードを、一時的に、又は永久的に停止する
【０３３８】
図１８をもう一度参照すると、一実施形態では、遠隔管理４０２のアプリケーションは、以下のインターフェースの１つ以上を提供することができるが、それらに限定されない。ここで留意すべきは、これらのインターフェースは例示的なものであり、限定することを意図しないということである。
readMsg(String msg)
【０３３９】
ｒｅａｄＭｓｇは、ローカル管理４１２のモジュールからメッセージを受信する。
startMon(String host, int port)
【０３４０】
ｓｔａｒｔＭｏｎは、特定のホスト：ポートにおいて、ローカル管理４１２のモジュールに接続し、このローカル管理４１２のモジュールに対して監視される、すべてのコンポーネント４１４を有効にする。
stopMon(String host, int port)
【０３４１】
ｓｔｏｐＭｏｎは、すべてのコンポーネント４１４のモニタリングを停止し、特定のホスト：ポートにおいて、ローカル管理４１２のモジュールから切断する。
stopAllMon()
【０３４２】
ｓｔｏｐＡｌｌＭｏｎは、べてのコンポーネント４１４のモニタリングを停止し、すべての現在接続されている、ローカル管理４１２のモジュールから切断する。
enableComp(String componentName)
【０３４３】
ｅｎａｂｌｅＣｏｍｐは、ｃｏｍｐｏｎｅｎｔＮａｍｅによって識別される、すべての接続されたホストのコンポーネント４１４のモニタリングを開始する。
enableAllComp()
【０３４４】
ｅｎａｂｌｅＡｌｌＣｏｍｐは、静的入力ファイル内で見られる、すべてのコンポーネント４１４上のモニタリングを有効にする。
disableComp(String componentName)
【０３４５】
ｄｉｓａｂｌｅＣｏｍｐは、ｃｏｍｐｏｎｅｎｔＮａｍｅによって識別される、すべての接続されたホストのコンポーネント４１４のモニタリングを停止する。
disableAllComp()
【０３４６】
ｄｉｓａｂｌｅＡｌｌＣｏｍｐは、すべてのコンポーネント４１４のモニタリングを停止するが、現在接続されているローカル管理４１２のモジュールから切断しない。
【０３４７】
ローカル管理モジュール
検索可能なデータサービスのホスト４１０上のローカル管理４１２のモジュールは、遠隔管理４０２のアプリケーション、及びローカルコンポーネント４１４間の仲介としての機能を果たす。ローカル管理４１２のモジュールは、遠隔管理４０２の接続を待ち、一度遠隔管理４０２のアプリケーションに接続されると、その遠隔管理４０２のアプリケーションからの有効／無効コンポーネント４１４の要求を処理する。また、ローカル管理４１２のモジュールは、ローカルコンポーネント４１４の間の検索可能なデータサービスメッセージ上の情報を、遠隔管理４０２のアプリケーションに転送することができる。
【０３４８】
以下は、ローカル管理４１２のモジュールからの、遠隔管理４０２のアプリケーションへのメッセージを監視する、検索可能なデータサービスの例示的なメッセージのフォーマットであり、限定することを意図しない。
<host/hostname/nodeID>: <Component> <sent/received> on <to/from who> <timestamp>: <msg>
【０３４９】
一実施形態では、ローカル管理４１２のモジュールは、以下のインターフェースの１つ以上を提供することができるが、それらに限定されない。ここで留意すべきは、これらのインターフェースは例示的なものであり、限定することを意図しないということである。
monMsg(String msg)
【０３５０】
ｍｏｎＭｓｇは、コンポーネント４１４がメッセージを送信／受信するとき、コンポーネント４１４によってコールされる。
monBegin(String componentName)
【０３５１】
ｍｏｎＢｅｇｉｎは、静的ファイル中の名前付けされたコンポーネント４１４のポートを調べ、ローカルホスト：ポートに接続し、コンポーネント４１４に対するｍｏｎＥｎａｂｌｅ（）をコールする。
monBeginAll()
【０３５２】
ｍｏｎＢｅｇｉｎＡｌｌは、コンポーネント４１４、及びコンポーネントのポートのリストを含む、静的入力ファイルを読み込み、ファイル内にリストアップされるコンポーネント４１４に接続し、コンポーネント４１４のそれぞれに対する、ｍｏｎＥｎａｂｌｅ（）をコールする。
monStop(String componentName)
【０３５３】
ｍｏｎＳｔｏｐは、名前付けされたコンポーネント４１４のモニタリングを停止する。
monStopAll()
【０３５４】
ｍｏｎＳｔｏｐＡｌｌは、すべての現在のコンポーネント４１４のモニタリング活動を停止する。
【０３５５】
ローカルコンポーネント
ローカルコンポーネント４１４は、ローカル管理４１２の接続を待つ。一度、ローカル管理４１２のモジュールに接続されると、ローカルコンポーネント４１４は、ローカル管理４１２のモジュールからの有効要求を受信するとき、モニタリングに対するメッセージを、ローカル管理４１２のモジュールに送信し始めることができる（それは、ローカル管理４１２のモジュールが、遠隔管理４０２のアプリケーションからの有効要求を受信するときも、同様に生じる）。ローカルコンポーネント４１４は、ローカル管理４１２のモジュールからの無効要求を受信するとき、モニタリングに対するメッセージの送信を停止することができる。
【０３５６】
以下は、ローカルコンポーネント４１４からの、ローカル管理４１２のモジュールへのメッセージを監視する、検索可能なデータサービスの例示的なメッセージのフォーマットであり、限定することを意図しない。
<Component> <sent/received> on <to/from who> <timestamp>: <msg>
【０３５７】
一実施形態では、ローカルコンポーネント４１４は、以下のインターフェースの１つ以上を提供することができるが、それらに限定されない。ここで留意すべきは、これらのインターフェースは例示的なものであり、限定することを意図しないということである。
monEnable()
【０３５８】
ｍｏｎＥｎａｂｌｅは、ｓｅｎｄＭｓｇＴｏＭｏｎを呼び出すことによって、いかなる送信／受信されたメッセージを、ローカル管理４１２のモジュールに送信し始める。
monDisable()
【０３５９】
ｍｏｎＤｉｓａｂｌｅは、ローカル管理４１２のモジュールへのメッセージの送信を停止する。
sendMsgToMon(String msg)
【０３６０】
モニタリングが有効であるとき、ｓｅｎｄＭｓｇＴｏＭｏｎは、ｍｏｎＭｓｇ（Ｓｔｒｉｎｇ  ｍｓｇ）を呼び出すことによって、いかなる送信／受信されたメッセージを、ローカル管理４１２のモジュールに送信する。
【０３６１】
検索可能なデータサービスシステム−物理的実装
図１９は、一実施形態に従い、ネットワーク環境にある検索可能なデータサービスの実装を例示している。ネットワーク７００は、例えば、ワールドワイドウェブ、又はインターネットを表すことができる。又は、ネットワーク７００は、ローカルエリアネットワーク（ＬＡＮ）、又はワイドエリアネットワーク（ＷＡＮ）を表すことができる。検索可能なデータサービス７２０は、１つ以上のデータセンタ７１０（例えば、データセンタ７１０Ａ、及び７１０Ｂ）にわたって実装されてもよい。データセンタ７１０は、コンピュータデバイスのローカルコレクションを表し、それは、サーバシステム、及びストレージデバイスを含むことができるが、それらに限定されない。データセンタ７１０は、地理的に分散されてもよい。ここで留意すべきは、データセンタ７１０内のすべてのコンピュータデバイスが、検索可能なデータサービス７２０に参加可能とは限らないことである。
【０３６２】
データセンタ７１０Ａ、及び７１０Ｂそれぞれにおける、検索可能なデータサービスホスト７２２Ａ、及び７２２Ｂは、図４に図解するように、コーディネータノード３４０、クエリＴＳＡＲノード３５０、及びストレージノード３６０などの、検索可能なデータサービスノードのインスタンスをホストする、個々のコンピュータシステム（例えば、サーバシステム）を示す。一実施形態では、各検索可能なデータサービスホスト７２２は、唯一の検索可能なデータサービスノードをホストすることができる。本実施形態では、各検索可能なデータサービスホスト７２２は、明確な検索可能なデータサービスノードを示す。各コーディネータノード３４０、クエリＴＳＡＲノード３５０、及びストレージノード３６０は、別々のコンピュータシステム上でインスタンス化される。
【０３６３】
別の実施形態では、検索可能なデータサービスホスト７２２は、１つ以上の検索可能なデータサービスノードをホストすることができる。例えば、データセンタ内の１つの検索可能なデータサービスホスト７２２は、コーディネータノード３４０のインスタンスをホストすることができ、別のホスト７２２は、クエリＴＳＡＲノード３５０、及びストレージノード３６０のインスタンスをホストすることができる。
【０３６４】
一実施形態では、検索可能なデータサービスノードのコンポーネントは、２つ以上の検索可能なデータサービスホスト７２２にわたって、インスタンス化されてもよい。本実施形態では、２つ以上のコンピュータシステムが、１つの検索可能なデータサービスノードを構成することができる。
【０３６５】
検索可能なデータサービスストア７２４は、図６に図解するように、ｅＩＤストア２３６、クエリインデックスストア２３４、要求ログ２１０、メンバーシップマップ２１８、及びメッセージログ２２４などの検索可能なデータサービスによって、持続的に保存され得る様々なデータを表す。ここで留意すべきは、図１２が、ホスト７２２の外部としてストア７２４を示す一方で、一実施形態では、検索可能なデータサービスストア７２４の少なくとも一部は、ホスト７２２内のストレージ上に位置付けられることが可能であるということである。様々な実施形態では、検索可能なデータサービスストア７２４は、ホスト７２２内、データセンタ７１０内、ネットワーク７００上の他の離れたところに位置付けられた、又は上記のある組み合わせの、いかなるタイプの永続的なストレージデバイス、又はストレージシステム上に保存されてもよい。ここで留意すべきは、ストレージノード３６０は、論理的に、検索可能なデータサービスホスト７２２上でインスタンス化されるコンポーネントに加えて、少なくとも、ローカルｅＩＤストア２３６、及びクエリインデックスストア２３４を含む。同様に、コーディネータノード３４０、及びクエリＴＳＡＲノード３５０は、論理的に、検索可能なデータサービスストア７２４内に保存される、少なくとも一部のデータを含むことができる。
【０３６６】
クライアントシステム７３０は、いかなる有線、又は無線ネットワーク接続機構を介して、ネットワーク７００に結合されてもよい。クライアントシステム７３０は、データストア７４０内で保存されるデータに対する、検索可能なインデックスを作成及び更新するために、及び／又は、データストア７４０に保存されるエンティティに対するロケータを得るための、検索可能なインデックスをクエリするために、上述のように、ウェブサービスインターフェースを介して、検索可能なデータサービス７２０にアクセスすることができる。クライアントシステム７３０、及びデータストア７４０を保存するストレージデバイスは、ネットワーク７００上のどこにでも位置付けられることができる。ウェブサービスインターフェースは、ネットワーク７００に結合される１つ以上のサーバシステム上でインスタンス化される、ウェブサービスプラットフォーム（例えば、図６のウェブサービスプラットフォーム２００を参照）によって、提供されてもよく、それは、他の検索可能なデータサービス７２０のハードウェアコンポーネントを含むデータセンタ７１０に存在することが可能、又は不可能である。ここで留意すべきは、ウェブサービスプラットフォームは、ウェブサービスプラットフォームが、検索可能なデータサービス７２０に対する故障の単一点ではないように、ハードウェア、及びソフトウェアにおいて冗長性を提供することが可能であるということである。
【０３６７】
ここで留意すべきは、クライアントシステム７３０、及びデータストア７４０に対するサーチフロントエンドとして、検索可能なデータサービス７２０を活用するために、クライアントシステム７３０上でインスタンス化されるクライアントアプリケーションの開発者にとって、基礎的なアーキテクチュア、実装、及び検索可能なデータサービス７２０の操作は、不透明であることである。開発者は、検索可能なデータサービスに対して公開されるウェブサービスインターフェースに従って、クライアントアプリケーションに対するサーチフロントエンドをプログラミングすることができる。
【０３６８】
検索可能なデータサービス７２０は、大量のデータを保存するためにスケーリングすることができる。特別な構成は、検索可能なデータサービス７２０をスケーリングするために必要とされない。異種のマシンがシステムに追加されてもよく、また、マシンは自動的に検出され、検索可能なデータサービス７２０に追加されてもよい。スケーリングは、単により大きなサーバを追加することによってではなく、追加のホスト７２２、及びストレージデバイスを、データセンタ７１０に追加することによって、及び／又は新しいデータセンタ７１０を、検索可能なデータサービス７２０に追加することによって、実現されてもよい。
【０３６９】
検索可能なデータサービス７２０は、以下の１つ以上を扱うために、追加のハードウェアを追加することによって、スケーリングされてもよいが、それらに限定されない。
・検索可能なデータサービスクライアントの数
・検索可能なデータサービス加入者に対する、特定の検索可能なインデックスドメインのサイズ、及び／又は、すべての加入者に対するすべてのドメインの全体のサイズ
・各検索可能なデータサービスオブジェクト内の、属性のサイズ及び数
・処理される要求の数（読み込み／書き込みスループット）
・ノードの数（追加のコーディネータノード３４０は、例えば、負荷バランシングに対して追加されてもよい）
・冗長性要件（いくつのパーティションの複製が必要とされるか）
・可用性、一致性、及び性能全般。全体のシステムの可用性、一致性、及び性能を改善するために、追加のノードは、データセンタ７１０に追加されてもよく、及び／又は、追加のデータセンタ７１０は、検索可能なデータサービス７２０に追加されてもよい。より具体的な例として、データセンタ内の追加のストレージノード３６０に、又は別の新しく追加されたデータセンタ内のストレージノード３６０に対して、パーティションを複製することは、さらなる冗長性を提供し、可用性を増大し、負荷バランシングを改善することができる。
【０３７０】
潜在的に高価なハードウェア（例えば、サーバシステム）の特定のモデル、又は、特定のベンダからのハードウェア／ソフトウェアのサーバソリューションを必要とせずに、検索可能なデータサービス７２０は、データセンタ７１０内の１人以上のベンダからの、比較的安価な、異種のコモディティハードウェア上で実装されてもよい。異なるベンダからの異なるタイプのシステムは、システムが概して、データセンタ７１０内の他のシステムと互換性がある限り、異なるディスクサイズ、及びパフォーマンス機能、異なるＣＰＵ機能、ＲＡＭ機能などで、検索可能なデータサービスのインフラストラクチャにおいて、ホスト７２２として使用されてもよい。一実施形態では、ホスト７２２に対する１つ以上の最低要件が確立されてもよいが、最低要件を満たすいかなる互換性のあるシステムも、ホスト７２２としての機能を果たすことができる。
【０３７１】
実施形態は、ツータッチのデータセンタメンテナンスモデルをサポートすることができ、それによって、ホスト７２２は一度故障すると、修理されなくてもよいが、代わりに置換されてもよい。比較的安価な、異種のハードウェアを使用することによって、検索可能なデータサービス７２０は、安価に、また迅速にスケーリングされてもよい。
【０３７２】
クライアントの視点から見ると、検索可能なデータサービス７２０の機能性、及び性能は、ホスト７２２、ネットワーク、又はデータセンタ７１０までもの故障など、システム故障によって影響されるべきではない。ここに記載されるように、検索可能なデータサービス７２０の論理的、及び物理的アーキテクチュアは、故障の単一点を有していない。検索可能なデータサービス７２０は、クライアントの機能性に影響を与えることなく、データセンタ７１０、若しくは全体のデータセンタ７１０においてさえ、マシンの一時的、又は永久的損失に耐えることができる。検索可能なデータサービス７２０は、クライアント７３０への重大な影響なしで、ホスト７２２、ネットワークハードウェア、又は全体のデータセンタ７１０さえの偶発故障にも、耐えることができる。検索可能なデータサービス７２０は、検索可能なデータサービス７２０の全体の操作に重大な影響を及ぼすことなく、単一のデータセンタ７１０内の１つ以上のホスト７２２の、意図的シャットダウンに耐えることができ、それは、例えば、データセンタ７１０内のホスト７２２のフリートが、必要とされる、又は希望される場合、アップグレードされることを可能にする。
【０３７３】
一実施形態では、検索可能なデータサービス７２０は、ネットワーク７００上で、グローバルなアクセス可能性を提供することができる。グローバルなアクセス可能性を提供することによって、検索可能なデータサービス７２０は、クライアントシステム７３０の地理的位置にかかわらず、同様の待ち時間、及びスループット性能を、クライアントシステム７３０に提供することができる。ここで留意すべきは、クライアントシステム７３０は、いかなる有線、又は無線ネットワーク接続機構を介して、ネットワーク７００に結合されることが可能であるということである。クライアントシステム７３０の位置にかかわらず、クライアントシステム７３０に対して、同様の性能経験によって、グローバルなアクセス可能性を提供することを支援をするために、検索可能なデータサービス７２０は、地理的に広く分散されているデータセンタ７１０にわたって、実装されてもよい。次に、グローバルなアクセス可能性を必要とし得る加入者の検索可能なインデックス（ドメイン）は、地理的に分散され、離れたデータセンタ７１０にわたって、複製されてもよい。ここで留意すべきは、地理的に分散されたドメインは、データセンタ７３０にわたるデータの同期化のとき、待ち時間の微増をもたらす場合があることである。
【０３７４】
例示的なシステム
一実施形態では、ここに記載されるように、検索可能なデータサービスの１つ以上のコンポーネントを実装するホストシステムは、図２０に図解されるホストシステム９００などの、１つ以上のコンピュータアクセス可能な媒体を含む、又はそれにアクセスするよう構成される、汎用コンピュータシステムを含むことができる。図解される実施形態では、ホストシステム９００は、入力／出力（Ｉ／Ｏ）インターフェース９３０を介して、システムメモリ９２０に結合される、１つ以上のプロセッサ９１０を含む。コンピュータシステム９００は、Ｉ／Ｏインターフェース９３０に結合される、ネットワークインターフェース９４０をさらに含む。
【０３７５】
様々な実施形態では、コンピュータシステム９００は、１つのプロセッサ９１０を含む、ユニプロセッサシステム、又はいくつかのプロセッサ９１０（例えば、２つ、４つ、８つ、又は別の適切な数）を含むマルチプロセッサシステムであってもよい。プロセッサ９１０は、インストラクションを実行する能力があるいかなる適切なプロセッサであってもよい。例えば、様々な実施形態では、プロセッサ９１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、又はＭＩＰＳ  ＩＳＡなどの様々なインストラクションセットアーキテクチュア（ＩＳＡ）、又はいかなる他の適切なＩＳＡを実装する、汎用、又は組み込みプロセッサであってもよい。マルチプロセッサシステムにおいて、プロセッサ９１０のそれぞれは、必ずしもというわけではないが、一般に、同一のＩＳＡを実装することができる。
【０３７６】
システムメモリ９２０は、プロセッサ９１０によってアクセス可能なインストラクション、及びデータを保存するよう構成されてもよい。様々な実施形態では、システムメモリ９２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、同期ダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ型メモリ、又はいかなる他のタイプのメモリなどの、いかなる適切なメモリ技術を使用して、実装されてもよい。図解される実施形態では、検索可能なデータサービスの様々なノードに対する、上述のそれらの方法及び技術などの望ましい機能を実装する、プログラムインストラクション、及びデータは、コード９２５として、システムメモリ９２０内に保存されることが示される。さらに、検索可能なデータサービスストア７２４Ｃは、図６に図解される、ｅＩＤストア２３６、クエリインデックスストア２３４、要求ログ２１０、メンバーシップマップ２１８、及びメッセージログ２２４などの、検索可能なデータサービスによって持続的に保存されてもよい、様々なデータを表し、それは、一実施形態では、ホスト９００のシステムメモリ９２０の少なくとも一部に、保存されてもよい。
【０３７７】
一実施形態では、Ｉ／Ｏインターフェース９３０は、プロセッサ９１０、システムメモリ９２０、及びネットワークインターフェース９４０、又は他の周辺装置インターフェースを含む、デバイス内のいかなる周辺装置デバイス間の、Ｉ／Ｏトラフィックをコーディネートするよう構成されてもよい。一部の実施形態では、Ｉ／Ｏインターフェース９３０は、１つのコンポーネント（例えば、システムメモリ９２０）からのデータ信号を、別のコンポーネント（例えば、プロセッサ９１０）による使用に適したフォーマットへと変換するために、いかなる必要なプロトコル、タイミング、又は他のデータの変換を実行することができる。一部の実施形態では、Ｉ／Ｏインターフェース９３０は、例えば、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）バス標準、又はユニバーサルシリアルバス（ＵＳＢ）標準の改良型など、様々な種類の周辺装置バスを介して付属されるデバイスのための、サポートを含むことができる。一部の実施形態では、Ｉ／Ｏインターフェース９３０の機能は、例えば、ノースブリッジ、及びサウスブリッジなどの、２つ以上の別々のコンポーネントに分割されてもよい。また、一部の実施形態では、システムメモリ９２０に対するインターフェースなどの、Ｉ／Ｏインターフェース９３０の機能性の一部、又はすべては、プロセッサ９１０に直接組み込まれることができる。
【０３７８】
ネットワークインターフェース９４０は、検索可能なデータサービスストア７２４Ｄの少なくとも一部を保存するために使用可能な、他の検索可能なデータサービスノード、及びストレージデバイス又はシステムをホストする、他のホストシステム９００などの、ネットワークに付属される検索可能なデータサービスノード、及び他のデバイスをホストするホストシステム９００間で、データが交換されることを可能にするよう構成されてもよい。特に、ネットワークインターフェース９４０は、ネットワーク７００を介して、検索可能なデータサービスに対するウェブサービスインターフェースを、クライアントシステム７３０に提供するウェブサービスプラットフォーム８４０をホストする、ネットワーク７００上のホストシステム９００、及び他のコンピュータシステム間の通信を可能にするよう構成されてもよい。ネットワークインターフェース９４０は、一般に、１つ以上の有線、又は無線ネットワークプロトコル（例えば、Ｗｉ−Ｆｉ／ＩＥＥＥ  ８０２．１１、又は別の無線ネットワーク標準）をサポートすることができる。様々な実施形態では、ネットワークインターフェース９４０は、例えば、他のタイプのイーサネット（登録商標）ネットワークなどの、いかなる適切な有線、又は無線の一般データネットワークを介して、通信をサポートすることができる。さらに、ネットワークインターフェース９４０は、アナログ音声ネットワーク、又はデジタルファイバ通信ネットワークなどの、電気通信／電話ネットワークを介して、ファイバーチャネルＳＡＮなどの、ストレージエリアネットワークを介して、又は、いかなる他の適切なタイプのネットワーク、及び／又はプロトコルを介して、通信をサポートすることができる。
【０３７９】
一部の実施形態では、システムメモリ９２０は、上述のような、検索可能なデータサービスの１つ以上のコンポーネントを実装するための、上述のようなプログラムインストラクション、及びデータを保存するよう構成される、コンピュータアクセス可能ストレージ媒体の一実施形態であってもよい。しかしながら、他の実施形態では、プログラムインストラクション、及び／又はデータは、異なるタイプのコンピュータアクセス可能媒体上で、受信、送信、又は保存されてもよい。一般的に言えば、コンピュータアクセス可能ストレージ媒体は、Ｉ／Ｏインターフェース９３０を介してコンピュータシステム９００に結合されるディスク、又はＤＶＤ／ＣＤなどの、磁気又は光媒体などのストレージ媒体、又はメモリ媒体を含むことができる。また、コンピュータアクセス可能ストレージ媒体は、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ  ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどのいかなる揮発性、又は不揮発性媒体を含むことができ、それらは、システムメモリ９２０、又は別のタイプのメモリとして、コンピュータシステム９００の一部の実施形態に含まれることができる。さらに、コンピュータアクセス可能ストレージ媒体は、ネットワークインターフェース９４０を介して実装されてもよいような、ネットワーク、及び／又は無線リンクなどの通信媒体を介して送られる、電気、電磁、又はデジタル信号などの、伝送媒体又は信号を含むことができる。
【０３８０】
結論
様々な実施形態は、コンピュータアクセス可能ストレージ媒体に関する前述の説明に従って実装される、インストラクション、及び／又はデータを受信、送信、又は保存するステップを、さらに含むことができる。一般的に言えば、コンピュータアクセス可能ストレージ媒体は、例えば、ディスク、又はＤＶＤ／ＣＤ−ＲＯＭなどの磁気、又は光媒体、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの揮発性、又は不揮発性媒体などの、ストレージ媒体、又はメモリ媒体を含むことができる。ネットワーク、及び／又は無線リンクなどの通信媒体を介して送られる、電気、電磁、又はデジタル信号などの、伝送媒体又は信号も同様である。
【０３８１】
図において図解され、本書に記載されるような様々な方法は、方法の例示的な実施形態を示す。方法は、ソフトウェア、ハードウェア、又はそれらの組み合わせにおいて実行されてもよい。方法の順序は変更されてもよく、様々な要素が、追加、並べ替え、組み合わせ、省略、修正などされてもよい。
【０３８２】
本開示の利益を得る当業者には明らかであるように、様々な修正及び変更がなされてもよい。本発明が、すべてのかかる修正及び変更を包含し、したがって、上記の説明は例示目的であり、制限を目的とするのもではない。
【図面の簡単な説明】
【０３８３】
【図１】ウェブサービスインターフェースを提供する例示的システム構造を例示するブロック図であり、ウェブサービスクライアント及びウェブサービスプロバイダー間の情報のやり取りを示している。
【図２】一実施形態に従い、クライアント及び検索可能なデータサービス間の関係及びデータフローを例示している。
【図３】一実施形態に従い、検索可能なデータサービスの例示的な高水準機能構造を例示している。
【図４】一実施形態に従い、検索可能なデータサービスの例示的なネットワークアーキテクチャを例示している。
【図５Ａ】一実施形態に従い、検索可能なインデックスの検索可能なデータサービスオブジェクトを保存し、検索可能なインデックスのデータストアにあるエンティティの識別子（ｅＩＤｓ）を捜すサービス要求を処理する検索可能なデータサービスを実装する方法を例示している。
【図５Ｂ】一実施形態に従い、検索可能なインデックスの検索可能なデータサービスオブジェクトを保存し、検索可能なインデックスのデータストアにあるエンティティの識別子（ｅＩＤｓ）を捜すサービス要求を処理する検索可能なデータサービスを実装する方法を例示している。
【図６】一実施形態に従い、検索可能なデータサービスの例示的な低レベルモジュラーアーキテクチャを例示している。
【図７】一実施形態に従い、検索可能なデータサービスシステムの検索可能なインデックスを区分する方法を例示している。
【図８】一実施形態に従い、検索可能なデータサービスシステムの検索可能なインデックスのパーティションを複製する方法を例示している。
【図９Ａ】検索可能なデータサービスの一実施形態に従い、加入者の検索可能なインデックス、各加入者データのバケットへの保管、及びバケットの区分を例示している。
【図９Ｂ】検索可能なデータサービスの一実施形態に従い、加入者の検索可能なインデックス、各加入者データのバケットへの保管、及びバケットの区分を例示している。
【図９Ｃ】一実施形態に従い、パーティションの複製を介するデータ複製を例示している。
【図１０】一実施形態に従い、複製グループのパーティションの分割を例示している。
【図１１】一実施形態に従い、例示的ストレージノード及びそのコンポーネントを例示している。
【図１２】検索可能なデータサービスのクライアントからのクエリサービスを実施するクエリサブシステムを構成又は相互作用する検索可能なデータサービスの様々なコンポーネントを例示し、さらに、一実施形態に従い、コンポーネント間のデータフローをさらに例示している。
【図１３】一実施形態に従い、識別子サークルを例示している。
【図１４】一実施形態に従い、単一ストレージノードの例示的アーキテクチャを例示している。
【図１５】一実施形態に従い、検索可能なデータサービスシステムのためのストレス管理方法のフローチャートである。
【図１６】一実施形態に従い、検索可能なデータサービスにある複製グループのライフサイクルを例示している。
【図１７】一実施形態に従い、検索可能なデータサービスシステムのグループメンバーシップ及びヘルスをモニタリングする方法を例示している。
【図１８】一実施形態に従い、検索可能なデータサービスシステムの管理コンソールの高水準アーキテクチャを例示している。
【図１９】一実施形態に従い、ネットワーク環境にある検索可能なデータサービスの実装を例示している。
【図２０】実施形態を実装することができる、コンピュータシステム上の例示的実施形態を例示するブロック図である。
【図１】
2009522660.tif 000003
【図２】
2009522660.tif 000004
【図３】
2009522660.tif 000005
【図４】
2009522660.tif 000006
【図５Ａ】
2009522660.tif 000007
【図５Ｂ】
2009522660.tif 000008
【図６】
2009522660.tif 000009
【図７】
2009522660.tif 000010
【図８】
2009522660.tif 000011
【図９Ａ】
2009522660.tif 000012
【図９Ｂ】
2009522660.tif 000013
【図９Ｃ】
2009522660.tif 000014
【図１０】
2009522660.tif 000015
【図１１】
2009522660.tif 000016
【図１２】
2009522660.tif 000017
【図１３】
2009522660.tif 000018
【図１４】
2009522660.tif 000019
【図１５】
2009522660.tif 000020
【図１６】
2009522660.tif 000021
【図１７】
2009522660.tif 000022
【図１８】
2009522660.tif 000023
【図１９】
2009522660.tif 000024
【図２０】
2009522660.tif 000025
【国際調査報告】
2009522660.tif 000026
2009522660.tif 000027
2009522660.tif 000028
2009522660.tif 000029