JP2021529379A - 検索サーバの集中型ストレージ - Google Patents

Abstract

複数の検索サーバ間の共有ストレージに格納されたインデックス情報に基づき検索要求を処理することに関する技術が開示される。幾つかの実施形態では、第１検索サーバは、受信した検索要求を処理するために使用可能なインデックス情報を含むローカルキャッシュを維持し、ローカルキャッシュを共有ストレージと同期させる。同期させるステップは、共有ストレージから、共有ストレージの中のインデックス情報を示すメタデータを読み出すステップと、メタデータに基づき、ローカルキャッシュの中のインデックス情報が共有ストレージと異なるか否かを決定するステップと、を含む。ローカルキャッシュの中のインデックス情報が共有ストレージの中のインデックス情報と異なると決定することに応答して、第１検索サーバは、ローカルキャッシュの中のインデックス情報を共有ストレージの中のインデックス情報で更新する。第１検索サーバは、次に、更新されたインデックス情報を用いて決定された１つ以上の検索結果を提供してよい。

Description

本開示は、概して、コンピューティングシステムに関し、より具体的には、検索要求を処理する（service）ことを促進するコンピューティングシステムに関する。

多くの情報を維持するコンピューティングシステムは、ユーザが所望の情報を素早く発見できるために、検索機能を実装することがある。例えば、組織のシステムは、種々の従業員の多数の連絡先レコードを維持し、ユーザが従業員の姓のような１つ以上の項目を提供することにより、特定の１つを検索できるようにしてよい。この機能を実装するために、システムは、ＡｐａｃｈｅＳｏｌｒ（商標）サーバのような検索サーバを使用して、情報を検索するための要求を処理してよい。このようなサーバは、受信した文書をインデックス付けして、インデックスデータ構造を生成してよい。該インデックスデータ構造は、検索要求が受信されると、検索結果を決定するためにアクセスされる。インデックスデータ構造の使用は、検索が受信されるとき種々の項目について各文書をスキャンするより、検索を高速に実行できる。

複数の検索サーバの間の共有ストレージ内にインデックス情報を維持する検索システムの一実施形態を示すブロック図である。

共有ストレージ内のコンテンツの一実施形態を示すブロック図である。

共有ストレージからインデックス情報をプルする検索サーバの一実施形態を示すブロック図である。

共有ストレージへインデックス情報をプッシュする検索サーバの一実施形態を示すブロック図である。

ローカルのストレージ破損を処理する検索システムの実施形態を示すブロック図である。 ローカルのストレージ破損を処理する検索システムの実施形態を示すブロック図である。

検索システムにより実行される方法の実施形態を示すフロー図である。 検索システムにより実行される方法の実施形態を示すフロー図である。 検索システムにより実行される方法の実施形態を示すフロー図である。

例示的なコンピュータシステムの一実施形態を示すブロック図である。

本開示は、「一実施形態」又は「実施形態」への言及を含む。「一実施形態では」又は「実施形態では」の語句の出現は、必ずしも同じ実施形態を表さない。特定の特徴、構造、又は特性は、本開示と矛盾しない任意の適切な方法で結合されてよい。

本開示において、異なるエンティティ（これは、「ユニット」、「回路」、他のコンポーネント、等のように様々に表されてよい）は、１つ以上のタスク又は動作を実行するよう「構成される」と記載され又は請求されてよい。この明確な記述−「１つ以上のタスクを実行する」よう構成される「エンティティ」−は、本願明細書で、構造（つまり、電子回路のような何らかの物理的なもの）を表すために使用される。より具体的には、この明確な記述は、この構造が動作中に１つ以上のタスクを実行するよう配置されることを示すために使用される。構造は、該構造が現在作動中でない場合でも、何らかのタスクを実行する「よう構成される」と言える。「インデックス情報を格納するよう構成されるストレージ」は、例えば、対象のコンピュータシステムが現在使用中でない場合でも（例えば、それに電源が接続されていない）、動作中にこの機能を実行する１つ以上のコンピュータシステムを包含することを意図する。従って、何らかのタスクを実行する「よう構成される」と記載され又は引用されるエンティティは、装置、回路、タスクを実施するために実行可能なプログラム命令を格納するメモリ、等のような何らかの物理的なものを表す。この語法は、本願明細書で、何らかの無形物を表すために使用されない。従って、「〜よう構成される」構成は、本願明細書では、アプリケーションプログラミングインタフェース（application programming interface(API)）のようなソフトウェアエンティティを表すために使用されない。

用語「〜よう構成される（configured to）」は、「構成可能である（configurable to」を意味しない。未設定ＦＰＧＡは、例えば、何らかの特定の機能を実行するよう「構成される」と考えられない。しかしながら、未設定ＦＰＧＡは、該機能を実行するよう「構成可能」であってよく、設定（プログラミング）後に該機能を実行するよう「構成され」てよい。

添付の特許請求の範囲における、構造が１つ以上のタスクを実行するよう「構成される」という記載は、その請求項の要素について３５U.S.C.§１１２（ｆ）を含まないことが明確に意図される。従って、提出される本願の請求項のいずれも、手段及び機能の要素を有するものとして解釈されることが意図される。出願人が審査中に§１１２（ｆ）を含むことを意図する場合には、［機能を実行するための］「手段」の構成を用いて請求項の要素を記載する。

本願明細書で使用されるとき、用語「第１」、「第２」、等は、それらが先行する名詞のラベルとして使用され、特に断りの無い限り、いかなる種類の順序（例えば、空間的、時間的、論理的、等）も意味しない。例えば、複数の検索サーバを有するコンピュータクラスタでは、用語「第１」及び「第２」検索サーバは、検索サーバのうちの任意の２つを表すために使用できる。言い換えると、「第１」及び「第２」検索サーバは、例えばクラスタに参加する最初のサーバに限定されない。

本願明細書で使用されるとき、用語「に基づき」は、決定に影響する１つ以上の要素を記述するために使用される。この用語は、追加要素が決定に影響し得る可能性を排除しない。つまり、決定は、特定の要素に単独で基づいて、又は特定の要素及び他の指定されていない要素に基づいてよい。句「Ｂに基づきＡを決定する」について検討する。この句は、ＢがＡを決定するために使用される因子であること、又はＡの決定に影響を与えることを示す。この句は、Ａの決定が何からの他の因子、例えばＣに基づいてもよいことを排除しない。この句は、ＡがＢのみに基づき決定される一実施形態を包含することも意図する。本願明細書で使用されるとき、語法「に基づき」は、従って、「に少なくとも部分的に基づき」と同義である。

コンピューティングシステムが膨大な検索クエリを断続的に受信するとき、クエリの処理を分散するために、複数の検索サーバが使用されてよい。この分散型処理を促進するために、所与のサーバは、インデックスの少なくとも一部を維持することを担ってよい。該インデックスは、ローカルに又は該サーバに専用のストレージ内に格納される。このストレージ方式は、しかしながら、幾つかの欠点を有する。個々のサーバは、クラッシュの影響を受けやすく、クラッシュは、サーバがインデックスの一部を維持することを担っているので、インデックス情報の損失をもたらし得る。新たに追加された検索サーバは現在のインデックス情報のコピーを取得するために他のサーバに負担をかけることがあるので、需要に基づき検索サーバの数をスケーリングすることも、面倒になり得る。この起こり得る性能損失を軽減するために、追加の検索サーバはプロビジョニングされてよいが、それらは需要の急増が希な場合は、十分に活用されない可能性がある。さらに、インデックス情報更新を膨大な数の検索サーバに渡り分配することは、各更新を分配するためにサーバが他のサーバに連絡しようとするので、ネットワーク帯域幅を消費し、サーバの性能を浪費し得る。

本開示は、代わりに、複数の検索サーバのインデックス情報がサーバ間で共有されるストレージの中に維持される実施形態を記載する。種々の実施形態で以下に更に詳述されるように、検索サーバは、インデックス情報を、共有ストレージと周期的に同期されるローカルキャッシュ内に維持できる。従って、サーバは、検索要求を受信した場合、ローカルキャッシュに格納されたインデックス情報を用いて要求を処理できる。サーバは、項目（アイテム、item）をインデックス付けする要求を受信した場合、自身のローカルキャッシュを更新し、更新したインデックス情報を共有ストレージへとプッシュできる。ここで、他の検索サーバは、更新されたインデックス情報を取得し、それらそれぞれのキャッシュを更新できる。新しいサーバが追加された場合、該新しいサーバは、共有ストレージから直接に、自身のローカルキャッシュをプロビジョニングできる。

この方法でインデックス情報を格納することは、有意な利点を提供できる。第１に、インデックス情報の更新を分配するサーバは、更新された情報を直接提供するために各サーバに面倒な連絡をするのではなく、単に、更新した情報を共有ストレージに書き込むだけである。第２に、インデックス情報が共有ストレージ内に維持されるなら、それらのサーバにより維持される任意の状態は共有ストレージ内に既に維持されているので、個々のサーバの損失は無視できる。更に、幾つかの実施形態では、共有ストレージが高い可用性及び／又は災害からの回復、つまりローカルストレージにより実装できない技術を実装し得るので、追加の信頼性が達成され得る。第３に、新しいサーバは、他のサーバを煩わすのではなく、自身のローカルキャッシュを共有ストレージから直接にプロビジョニングするので、需要に基づくスケーリングは、より迅速に及び／又は頻繁に生じることが可能である。

図１を参照すると、検索システム１０のブロック図が示される。図示の実施形態では、システム１０は、相互接続１５０により一緒に接続される、アプリケーションサーバ１１０、検索サーバ１２０及びローカルキャッシュ１３０を含む仮想マシン１０２、並びに共有ストレージ１４０を含む。幾つかの実施形態では、検索システム１０は、図と異なる方法で実装されてよい。例えば、アプリケーションサーバ１１０は、システム１０の部分でなくてよく、共有ストレージ１４０の複数のインスタンスが使用されてよい、等である。

アプリケーションサーバ１１０は、図示の実施形態では、検索機能を有するユーザインタフェースを提供するアプリケーションを提示するよう動作する。従って、アプリケーションは、ユーザが検索されるべき１つ以上のアイテムを入力できるようにする入力フィールドを提示し、検索から決定された１つ以上の結果を表示するインタフェースを提示してよい。このアプリケーションは、任意の適切なアプリケーションに対応してよい。例えば、幾つかの実施形態では、アプリケーションは顧客関係管理（customer relationship management(CRM)）を促進し、種々のＣＲＭデータをデータベースシステム内に維持してよい。このようなアプリケーションは、例えば、ユーザがこのＣＲＭデータを検索できるようにする、例えば種々の連絡先情報、製品情報、等を検索できるようにするユーザインタフェースを提示してよい。別の例では、アプリケーションは、ユーザのアクセス可能な文書のデータベースのためのインタフェースを提示し、ユーザが文書のうちの特定のものを検索できるようにしてよい。種々の実施形態では、サーバ１１０は、ウェブページをクライアント装置に提供することによりアプリケーションコンテンツを提示するウェブサーバである。サーバ１１０として記載されるが、コンポーネント１１０は、アプリケーションをローカルで実行しユーザと直接インタフェースするクライアント装置であってもよい。図１に示すように、アプリケーションサーバ１１０は、検索要求１１２及びインデックス要求１１４をサーバ１２０へ送信してよい。

検索サーバ１２０は、図示の実施形態では、検索要求１１２を受信することに応答して、検索を実行するために実行可能である。図示のように、各サーバ１２０は、それぞれのマシン１０２により実行されてよい。幾つかの実施形態では、マシン１０２は、個別の物理マシン１０２であり、従って、サーバ１２０は、異なるそれぞれのハードウェアを用いて実行する。他の実施形態では、マシン１０２は、図１に示されるような仮想マシン、又はＨｅｒｏｋｕ（登録商標）Ｄｙｎｏｓ、Ｌｉｎｕｘ（登録商標）コンテナ（ＬＸＣ）、Ｄｏｃｋｅｒ（登録商標）コンテナ、制御グループ（Ｃｇｒｏｕｐｓ）、名前空間、等のような何らかの他の形式のコンテナである。このような一実施形態では、コンテナ内の検索サーバ１２０のプロビジョニングは、同じハードウェアが複数のコンテナにより共有可能なので、基礎にあるハードウェアのより高い利用率を可能できる。サーバ１２０は、幾つかの場合には、追加サーバ１２０が新しいハードウェアをもたらすのではなく、既存の基礎にあるハードウェア上に展開できるので、より迅速に展開することもできる。また更に、幾つかの実施形態では、マシン１０２は、コンテナを実行するために、クラウドに基づくプラットフォームを実装するコンピュータクラスタ上でインスタンス化されてよい。

上述のように、種々の実施形態で、検索サーバ１２０は、マシン１０２のそれぞれのローカルキャッシュ１３０内に維持されるインデックス情報１３２に基づき検索要求を処理する。このインデックス情報１３２は、サーバ１２０により、所与の要求１１２の中で指定された項目に基づき検索結果を決定するために使用される１つ以上のインデックスデータ構造を定義してよい。例えば、サーバ１２０が文書検索をサポートする場合、インデックス情報１３２は、著者名を特定の文書にマッピングするインデックスデータ構造を定義してよい。従って、受信した検索要求１１２が名前「Ｓｍｉｔｈ」を指定する場合、サーバ１２０は、インデックスデータ構造を参照して、「Ｓｍｉｔｈ」により著された文書を決定してよい。種々の実施形態で、検索サーバ１２０は、１つ以上の項目をインデックス付けするためのインデックス要求１１４を受信することに応答して、インデックス情報を生成してよい。例えば、サーバ１２０は、「Ｓｍｉｔｈ」により著された新しい文書をインデックス付けするための要求１１４を受信してよく、インデックス情報１３２をインデックスデータ構造に追加して、該新しい文書が「Ｓｍｉｔｈ」についての検索に応答して識別されるようにしてよい。種々の実施形態で、検索サーバ１２０は、図３及び４を参照して以下に詳述するように、プル動作１３４及び／又はプッシュ動作１３６を実行することにより、それらそれぞれのローカルキャッシュ１３０に格納されたインデックス情報１３２を、共有ストレージ１４０に格納されたインデックス情報１４２と同期させる。

共有ストレージ１４０は、図示の実施形態では、インデックス情報を維持する１次記憶として検索サーバ１２０にサービスするよう構成される。ストレージ１４０は、ネットワーク接続ストレージ（network attached storage(NAS)）、ストレージエリアネットワーク（storage area network(SAN)）等のような任意の適切な形式のネットワークストレージに対応してよい。幾つかの実施形態では、ストレージ１４０は、広域ネットワークを介してサーバ１２０に提供され得る（ＡｍａｚｏｎのＳｉｍｐｌｅＳｔｏｒａｇｅＳｅｒｖｉｃｅ（商標）のような）クラウドストレージを実装するコンピュータクラスタにより提供されるサービスである。幾つかの実施形態では、ストレージ１４０は、インデックス情報１４２を更に守るために、高い可用性（high availability (HA)）及び災害回復性（disaster recovery (DR)）を実装する。種々の実施形態で、ストレージ１４０は共有されて、インデックス情報１４２に並列にアクセス可能にするために、複数の検索サーバ１２０により同時にアクセスされるようにする。図２に関して以下に詳述するように、ストレージ１４０の中のインデックス情報１４２は、複数のセグメントファイルに構成されてもよい。ストレージ１４０は、ストレージ１４０からインデックス情報１４２をプルすること、及びストレージ１４０へインデックス情報１３２をプッシュすることを促進するために種々のメタデータも維持してよい。

図２を参照すると、共有ストレージ１４０の中のコンテンツのブロック図が示される。図示の実施形態では、共有ストレージ１４０は、複数のセグメントファイル２１０Ａ〜Ｎ及びメタデータファイル２２０を含む。メタデータファイル２２０は、コミットポイント情報２２２、マッピング２２４、サイズ及びチェックサム２２６、並びに削除ファイルリスト２２８を更に含む。幾つかの実施形態では、ストレージ１４０は、図示のものと異なるように実装されてよい。例えば、ストレージ１４０は、異なるインデックスに対応するインデックス情報１４２の複数のインスタンスを含んでよく、メタデータファイル２２０は図示のものより多くの（又は少ない）情報を含んでよい、等である。

セグメントファイル２１０は、図示の実施形態では、検索を実行するとき、検索サーバ１２０により参照されるインデックスデータ構造を定義するインデックス情報１４２の部分を含む。幾つかの実施形態では、ファイル２１０は、インデックス要求１１４により要求されると、新しい情報１４２が追加され、更新され、又は削除される度に新しいファイル２１０が書き込まれるコピーオンライト（copy−on−write）記憶方式を用いて書き込まれる。例えば、ファイル２１０Ｂ内の値が更新される場合、新しいファイル２１０は新しい値により書き込まれるが、ファイル２１０Ｂは不変のままである。このような方式は、ファイル２１０に記録されたデータを保護するために実行されてよく、ファイル２１０内のデータが存在する場所で更新され又は削除されるライトインプレイス（write−in−place）記憶方式とは対照的である。（他の実施形態では、ファイル２１０は、ライトインプレイス記憶方式を用いて記録されてよい。）ファイルが書き込まれる順序を識別するために（及び従ってどんな情報１４２が現在関連しているかを決定するために）、セグメントファイル２１０は、ファイル２１０がストレージ１４０に書き込まれる順序を示すシーケンス番号（例えば、増大するカウンタ値）を割り当てられてよい。（幾つかの実施形態では、ファイル２１０はストレージ１４０にプッシュされる前にキャッシュ１３０に書き込まれ得るので、この順序は、ファイル２１０が最初にローカルキャッシュ１３０に書き込まれた順序を反映してよい。）

一実施形態では、ファイル２１０は、それらに割り当てられたシーケンス番号を用いて命名されてよい。幾つかの例では、しかしながら、この命名方式の使用は、ファイル２１０が上書きされる可能性がある。例えば、２つのサーバ１２０が同じシーケンス番号を用いてファイル２１０を書き込もうとする場合、これらのファイルは同じ名前を有し、衝突を生じるだろう。サーバ１２０は、現在のシーケンス番号に関して誤っている可能性があり、該シーケンス番号を有する既存のファイル２１０を上書きしてしまうかも知れない。幾つかの実施形態におけるこの潜在的問題に対応するために、ファイル２１０は、それらのシーケンス番号と独立であってよいユニークな名前を割り当てられてよい。従って、図示の実施形態では、起こり得るファイル名衝突の可能性を低減するために、ファイル２１０は、各名前の少なくとも一部がランダムに生成された数値を含むユニーク識別子（unique identifier (UID)）名２１２を割り当てられる。

メタデータファイル２２０は、図示の実施形態では、ローカルキャッシュ１３０の共有ストレージ１４０との同期を促進するために、検索サーバ１２０により使用される種々のメタデータを含む。種々の実施形態で、サーバ１２０による読み出しを容易にするために、ファイル２２０は、検索サーバ１２０に渡り知られている、ストレージ１４０内で一貫した一に書き込まれる（例えば、一貫したファイル名を有し、一貫したディレクトリパスに存在する）。幾つかの実施形態では、ファイル２２０は、複数のファイル２２０のうちの１つである。各ファイル２２０は、インデックス情報１４２により定義されるそれぞれのインデックスデータ構造に関連付けられる。他の実施形態では、しかしながら、メタデータファイル２２０は、インデックス情報１４２により定義される複数のインデックスデータ構造のメタデータを含むことができる。

コミットポイント情報２２２は、図示の実施形態では、インデックスデータ構造を定義するインデックス情報１４２の最新バージョン（つまり、現在のバージョン）を構成するファイル２１０を識別する。幾つかの実施形態では、ファイル２１０は、新鮮でない／古いインデックス情報１４２を有することになると、メタデータ２２２から削除されてよい。他の実施形態では、新鮮でないインデックス情報１４２を有するファイル２１０は、情報２２２の中で依然として識別されてよいが、インデックス情報１４２の最新バージョンを構成したいとして示される。幾つかの実施形態では、情報２２２は、ファイル２１０それぞれのシーケンス番号に基づきファイル２１０識別する。情報２２２は、ストレージ１４０が更新されたときを識別するタイムスタンプ情報も含んでよい。図３に関して説明するように、検索サーバ１２０のローカルキャッシュ１３０との同期の最中に情報１４２をプルしようとする検索サーバ１２０は、（マッピング２２４と一緒に）情報２２２を読み出して、どのセグメントファイル２１０が異なり（例えば、任意の前の同期に対して新しいか）及びストレージ１４０から読み出されるべきかを決定してよい。図４に関して説明するように、同期の最中に情報１３２をプッシュしようとする検索サーバ１２０は、同様に、情報２２２を読み出して、どのセグメントファイル２１０が自身のキャッシュ１３０からストレージ１４０に書き込まれるべきかを決定してよい。

シーケンス番号のＵＩＤへのマッピング２２４は、図示の実施形態では、シーケンス番号のファイル２１０のファイル名へのマッピングである。従って、最新ファイル２１０をプルしようとする検索サーバ１２０は、最初に情報２２２を読み出して、それらのシーケンス番号を決定し、次にマッピング２２４を参照して、プルすべきファイル２２０の特定のファイル名を決定してよい。ＵＩＤ名２１２が使用されない実施形態では、マッピング２２４は、異なる命名方式を反映するために異なる方法で実装されてよい（又は命名方式に依存して実装されなくてよい）。

サイズ及びチェックサム２２６は、図示の実施形態では、セグメントファイル２１０について生成されたファイルサイズ及びチェックサムのリストである。このメタデータ２２６は、検索サーバ１２０がセグメントファイル２１０をストレージ１４０に書き込むとき、ストレージ１４０内に記録されてよく、該ファイル２１０（及びより一般的な情報１４２）が後に破損したかどうかを決定するために使用されてよい。図５Ａに関して後述するように、検索サーバ１２０は、自身のキャッシュ１３０の中のインデックス情報１３２が破損していると決定し、それをストレージ１４０からの情報で置き換えようとしてよい。情報１４２が破損していると決定された場合（例えば、メタデータ２２６に基づき決定される）、図５Ｂに関して後述するように、検索サーバ１２０は、別のサーバ１２０がインデックス情報１４２を自身のキャッシュ１３０からのインデックス情報１３２で置き換えることを要求してよい。

削除ファイルリスト２２８は、図示の実施形態では、削除のためにスケジューリングされているが未だ削除されていなくてよいファイル２１０のリストである。幾つかの実施形態では、サーバ１２０は、特定のファイル２１０が（もはや現在の情報を含まないので）削除されるべきであると決定し、該ファイル２１０の指示及びタイムスタンプをリスト２２８に格納してよく、そのときにファイル２１０を削除しない。後の時点で、自身のローカルキャッシュ１３０を共有ストレージ１４０と同期させようとするサーバ１２０（同じサーバ１２０又は異なるサーバ１２０であってよい）は、リスト２２８に格納されたタイムスタンプと一緒にリスト２２８を読み出してよい。タイムスタンプのうちの任意のものが時間閾値を満たす場合、サーバ１２０は、それらの古いタイムスタンプに対応するファイル２１０を削除してよい。このような削除方式は、削除情報に対して決定が行われた後に、インデックス情報が（例えば復元目的で）一時的に保存されることを可能にできる。

図３を参照すると、ローカルキャッシュ１３０を共有ストレージ１４０と同期させるプル動作１３４のブロック図が示される。上述のように、この動作１３４は、検索サーバ１２０がサーバ１２０のクラスタに追加された後に、例えば仮想マシン１０２が追加されたサーバ１２０によりインスタンス化されることに応答して、実行されてよい。種々の実施形態で、検索サーバ１２０は、それらのキャッシュ１３０がストレージ１４０と同期化されることを保証するために、定期的間隔でプル動作１３４を実行してもよい。幾つかの実施形態では、ストレージ１４０を更新する検索サーバ１２０は、ＡｐａｃｈｅＺｏｏＫｅｅｐｅｒ（商標）のような分散型連携アプリケーションを使用して、他のサーバにプル動作１３４を実行させるために、更新が生じたときに他のサーバ１２０に通知してよい。幾つかの実施形態では、サーバ１２０が、自身のローカルキャッシュ１３０に格納されたセグメントファイル２１０により未だ定義されていないインデックスデータ構造を用いて検索を実行するための検索要求１１２を受信した場合に、プル動作１３４が開始されてもよい。

図示のように、同期が既に実行されたとすると、検索サーバ１２０は、メタデータ３１０、及び１つ以上のセグメントファイル２１０を含んでよい幾つかのインデックス情報１３２を既に含んでよい。図示の実施形態では、ローカルメタデータ３１０は、ローカルキャッシュ１３０に格納されたセグメントファイル２１０を識別し、メタデータファイル２２０に関して上述したメタデータ２２２〜２２８のうちの任意のものを含んでよい。例えば、幾つかの実施形態では、ローカルメタデータ３１０は、どのファイル２１０がキャッシュ１３０に格納されるかを識別するシーケンス番号セットを含んでよい。

種々の実施形態で、プル動作１３４は、検索サーバ１２０がメタデータファイル２２０を読み出すことで開始し、キャッシュ１３０内のインデックス情報１３２が共有ストレージ１４０内のインデックス情報１４２と異なるか否かを決定してよい。幾つかの実施形態では、この決定は、ローカルメタデータ３１０内のシーケンス番号をメタデータファイル２２０（具体的には、上述のコミットポイント情報２２２）内のシーケンス番号と比較して、ストレージ１４０内のどのセグメントファイル２１０がキャッシュ１３０内に存在しないかを決定することを含んでよい。一実施形態では、この比較は、最初に、メタデータ３１０の中に示される最近格納されたセグメントファイル２１０のシーケンス番号を、メタデータファイル２２０内で示される最近格納されたセグメントファイル２１０のシーケンス番号と比較することを含んでよい。これらの番号が同じ場合、検索サーバ１２０は、キャッシュ１３０がストレージ１４０と同期されていることを決定し、更なる動作を行わなくてよい。それらが異なる場合、キャッシュ１３０及びストレージ１４０が同期されていないことを意味し、検索サーバ１２０は、メタデータ３１０及びメタデータファイル２２０の中のシーケンス番号の各々を比較して、異なるセグメントファイル２１０を識別してよい。

検索サーバ１２０が自身のインデックス情報１３２と異なるインデックス情報１４２を識別すると、検索サーバ１２０は、該異なるインデックス情報１４２を自身のローカルキャッシュ１３０へとプルしてよい。幾つかの実施形態では、これは、情報１３２と異なると決定された任意の情報１４２をプルすることを含んでよい。他の実施形態では、しかしながら、これは、検索サーバ１２０により使用されているインデックスデータ構造のセグメントファイル２１０のみをプルすることを含んでよい。例えば、検索サーバ１２０がインデックスＸＹＺを定義するセグメントファイル２１０を格納し、インデックスＡＢＣを用いる検索を実行するための検索要求１１２を受信した場合、検索サーバ１２０は、インデックスデータ構造ＸＹＺ及びＡＢＣのセグメントファイル２１０をプルしてよいが、該サーバ１２０により使用されていないインデックスＤＥＦのセグメントファイル２１０をプルしない。

図４を参照すると、共有ストレージ１４０をローカルキャッシュ１３０と同期させるプッシュ動作１３６のブロック図が示される。上述のように、検索サーバ１２０は、インデックス情報１３２及び１４２により定義されるインデックスデータ構造の中で参照されるアイテムを追加し、変更し又は削除するためのインデックス要求１１４を受信してよい。インデックス要求１１４を受信することに応答して、検索サーバ１２０は、新しいセグメントファイル２１０を生成し、該ファイル２１０の第１インスタンスを自身のローカルキャッシュ１３０に格納してよい。幾つかの実施形態では、新しいセグメントファイル２１０は、複数のファイル２１０からのインデックス情報を単一のファイル２１０へとマージすることにより、生成されてもよい。新しいファイル２１０がローカルキャッシュ１３０に格納されると、検索サーバ１２０は、他のサーバ１２０への自身の配信を促進するために、プッシュ１３６を実行して、新しいセグメントファイル２１０の第２インスタンスをストレージ１４０に格納してよい。

プル動作１３４と同様に、プッシュ動作１３６は、検索サーバ１２０がメタデータファイル２２０を読み出して、キャッシュ１３０内のどのセグメントファイル２１０が共有ストレージ１４０内のセグメントファイル２１０に対して新しいかを決定することで開始してよい。ファイル２１０のうちの任意のものが異なる場合、検索サーバ１２０は、異なるファイル２１０のリストを構築し、該異なるファイル２１０を自身のローカルキャッシュ１３０から共有ストレージ１４０へとプッシュしてよい。（幾つかの実施形態では、検索サーバ１２０は、ローカルキャッシュ１３０に無いと決定されたファイル２１０を共有ストレージ１４０からプルしてもよい。）新しいセグメントファイル２１０をストレージ１４０へプッシュすることに成功すると、検索サーバ１２０は、メタデータファイル２２０を更新して、新しいファイル２１０が共有ストレージ１４０にコミットされたことを反映してよい。幾つかの実施形態では、検索サーバ１２０は、更新されたインデックス情報１４２を他のサーバ１２０に通知してもよい。しかしながら、他の実施形態では、他のサーバ１２０は、それらが最終的にプル１３４を実行するとき、更新されたインデックス情報１４２を知ってよい。

幾つかの実施形態では、プッシュ動作１３６は、同期的に実行される。つまり、ローカルキャッシュ１３０にセグメントファイル２１０の第１インスタンスを格納すると、プッシュ動作１３６が実行されて、セグメントファイル２１０の第２インスタンスを共有ストレージ１４０に格納する。他の実施形態では、プッシュ動作１３６は、非同期的に実行される。例えば、インデックス付けを実行する検索サーバ１２０は、プッシュ動作１３６を定期的間隔で開始して、キャッシュ１３０内の任意の新しく生成されたセグメントファイル２１０をストレージ１４０へとプッシュしてよい。代替として、検索サーバ１２０は、自身がキャッシュ１３０内に閾数の新しいセグメントファイル２１０を生成するまで待機し、次に、新しいファイル２１０のセットをストレージ１４０へプッシュするバッチ同期を実行してよい。

図５Ａを参照すると、ローカルの破損５００Ａを修復するブロック図が示される。上述のように、検索サーバ１２０は、自身のローカルキャッシュ１３０内のインデックス情報１３２が破損していると決定してよい。インデックス情報１３２が破損していると決定することに応答して、検索サーバ１２０は、プル１３４を実行して、インデックス情報１３２を、共有ストレージ１４０からの破損していないインデックス情報１４２で置き換えてよい。しかしながら、共有ストレージ１４０内のインデックス情報１４２が破損していると決定された場合、検索サーバ１２０は、図５Ｂにより次に議論されるように進行してよい。

図５Ｂを参照すると、ストレージの破損５００Ｂを修復するブロック図が示される。上述のように、幾つかの例では、検索サーバ１２０は、共有ストレージ１４０内の情報１４２が破損していると決定してよい。検索サーバ１２０の自身のキャッシュ１３０内のインデックス情報１３２が破損していない場合、検索サーバ１２０は、自身の情報１３２のプッシュ１３６を実行して、インデックス情報１４２を置き換えてよい。しかしながら、自身のインデックス情報１３２が破損している場合（図５Ｂの場合）、検索サーバ１２０は、共有ストレージ１４０を介して、破損に関する通知を他のサーバ１２０へ送信してよい。従って、図示の実施形態では、検索サーバ１２０Ａは、別のサーバ１２０Ｂに決定した破損に関して通知するために、破損フラグ５１０を設定する。フラグ５１０を読み出すことに応答して、検索サーバ１２０Ｂは、自身のローカルインデックス情報１３２が破損していない場合、自身のローカルインデックス情報１３２を自身のキャッシュ１３０からプッシュすることにより、共有ストレージ１４０内のインデックス情報１４２を置き換えてよい。他の実施形態では、しかしながら、検索サーバ１２０は、互いに直接連絡するような他の技術を用いて、破損を互いに通知してよい。

図６Ａを参照すると、複数の検索サーバの間の共有ストレージに格納されたインデックス情報に基づき検索要求を処理する方法６００のフローチャートが示される。方法６００は、検索サーバ１２０のような１つ以上の検索サーバ１２０により実行される方法の一実施形態である。幾つかの例では、方法６００の実行は、より高い信頼性及び／又は拡張性を提供し得る。

ステップ６０５で、第１検索サーバは受信した検索要求（例えば、検索要求１１２）を処理するために使用可能なインデックス情報（例えばインデックス情報１３２）を含むローカルキャッシュ（例えば、ローカルキャッシュ１３０）を維持する。種々の実施形態で、方法６００は、第１検索サーバを含むコンテナ（例えば、仮想マシン１０２Ａ）をインスタンス化するステップと、コンテナ内で第１検索サーバを実行するステップと、を含む。幾つかの実施形態では、方法６００は、複数の検索サーバにより経験されている負荷を決定するステップと、共有ストレージからインデックス情報を読み出し及び検索要求を処理するために実行可能な別の検索サーバを含む別のコンテナ（例えば、仮想マシン１０２Ｎ）をインスタンス化するステップと、を含む。

ステップ６１０で、第１検索サーバは、ローカルキャッシュを共有ストレージ（例えば、共有ストレージ１４０）と同期させる。種々の実施形態で、同期させるステップは、共有ストレージから、共有ストレージ内のインデックス情報を示すメタデータ（例えば、メタデータファイル２２０）を読み出すステップと、メタデータに基づき、ローカルキャッシュ内のインデックス情報が共有ストレージと異なるか否かを決定するステップと、ローカルキャッシュ内のインデックス情報が共有ストレージ内のインデックス情報と異なると決定することに応答して、ローカルキャッシュ内のインデックス情報を共有ストレージ内のインデックス情報で更新するステップと、を含む。幾つかの実施形態では、ローカルキャッシュ内のインデックス情報は、第１セグメントファイルセット（例えばセグメントファイル２１０）の間で分散される。このような一実施形態では、読み出したメタデータは、共有ストレージ内の（例えば、コミットポイント情報２２２内の）第２セグメントファイルセットを識別し、決定するステップは、第１セグメントファイルセットを第２セグメントファイルセットと比較して、共有ストレージ内の、ローカルキャッシュに含まれないセグメントファイルを識別するステップを含む。

ステップ６１５で、第１検索サーバは、検索を行うための検索要求を受信する。

ステップ６２０で、第１検索サーバは、検索要求に応答して、更新されたインデックス情報を用いて決定された１つ以上の結果を提供する。幾つかの実施形態では、方法６００は、第１検索サーバにより、１つ以上のアイテムをインデックス付けするための要求に応答して、インデックス情報を生成するステップと、生成されたインデックス情報の第１インスタンスをローカルキャッシュに格納するステップと（生成されたインデックス情報の第１インスタンスは、１つ以上のアイテムに対する検索要求を処理するために第１検索サーバにより使用可能である）、生成されたインデックス情報の第２インスタンスを共有ストレージに格納するステップと（生成されたインデックス情報の第２インスタンスは、複数の検索サーバのうちの第２検索サーバにより、１つ以上のアイテムに対する検索要求を処理するために使用可能である）、を含む。幾つかの実施形態では、方法６００は、第１検索サーバにより、ローカルキャッシュ内のインデックス情報が破損していると決定するステップと、ローカルキャッシュ内のインデックス情報が破損していると決定することに応答して、ローカルキャッシュ内のインデックス情報を共有ストレージ内のインデックス情報で置き換えようとするステップと、を更に含む。幾つかの実施形態では、方法６００は、第１検索サーバが、共有ストレージ内のインデックス情報が破損していると決定するステップと、共有ストレージに、共有ストレージ内のインデックス情報が破損していることを示す通知（例えば、破損フラグ５１０）を格納するステップと、を更に含む。このような一実施形態では、通知は、複数の検索サーバのうちの第２検索サーバに、共有ストレージ内のインデックス情報を、第２検索サーバにより維持されるローカルキャッシュからのインデックス情報により置き換えさせる。幾つかの実施形態では、方法６００は、第１検索サーバにより、共有ストレージ内のインデックス情報を格納する１つ以上のセグメントファイルを削除することを決定するステップと、共有ストレージに、１つ以上のセグメントファイルが削除されるべきであるという指示（例えば、削除ファイルリスト２２８）を格納するステップと、を更に含む。このような一実施形態では、第２検索サーバは、指示を格納してから閾時間量が経過したと決定することに応答して、１つ以上のセグメントファイルを削除する。

図６Ｂを参照すると、複数の検索サーバの間の共有ストレージにインデックス情報を配信する方法６３０のフローチャートが示される。方法６３０は、検索サーバ１２０のような検索サーバにより実行される方法の別の実施形態である。幾つかの例では、方法６３０の実行は、より高い信頼性及び／又は拡張性を提供し得る。

ステップ６３５で、検索サーバは、１つ以上のアイテムをインデックス付けするための要求（例えば、インデックス要求１１４）を受信する。その結果、１つ以上のアイテムが実行された検索に応答して検索結果として識別可能になる。

ステップ６４０で、検索サーバは、要求に応答して、１つ以上のアイテムに基づきインデックス情報を生成する。

ステップ６４５で、検索サーバは、生成されたインデックス情報の第１インスタンスを、第１検索サーバによりアクセス可能なローカルキャッシュ（例えばローカルキャッシュ１３０）に格納されたインデックス情報（例えば、インデックス情報１３２）に追加する。

ステップ６５０で、検索サーバは、生成されたインデックス情報の第２インスタンスを、共有ストレージ（例えば共有ストレージ１４０）に格納されたインデックス情報（例えば、インデックス情報１４２）に追加して、生成されたインデックス情報を複数の検索サーバによりアクセス可能にする。幾つかの実施形態では、第２インスタンスを追加するステップは、
共有ストレージに、共有ストレージに格納された他のインデックス情報に対して、生成されたインデックス情報の第２インスタンスが格納される順序を識別するシーケンスメタデータ（例えば、コミットポイント情報２２２）を格納するステップであって、識別された順序は、複数の検索サーバのうちの検索サーバにより、生成されたインデックス情報の第２インスタンスを読み出すか否かを決定するために使用可能である、ステップを含む。幾つかの実施形態では、生成されたインデックス情報の第２インスタンスを追加するステップは、共有ストレージに、生成されたインデックス情報の第２インスタンスを含むセグメントファイル（例えば、セグメントファイル２１０）を格納するステップと、セグメントファイルに、ランダムに生成された値を含むファイル名（例えば、ＵＩＤ名２１２）を割り当てるステップと、を含む。幾つかの実施形態では、生成されたインデックス情報の第２インスタンスを追加するステップは、共有ストレージに、生成されたインデックス情報の第２インスタンスを含むセグメントファイルを格納するステップと、共有ストレージに、セグメントファイルを検証するために使用可能なチェックサム（例えば、サイズ及びチェックサム２２６）を格納するステップと、を含む。幾つかの実施形態では、生成されたインデックス情報の第２インスタンスを追加するステップは、生成されたインデックス情報の第２インスタンスを、共有ストレージに非同期プッシュするステップを含む。

ステップ６５５で、検索サーバは、ローカルキャッシュに格納された生成されたインデックス情報の第１インスタンスに基づき決定された検索結果として、１つ以上のアイテムのうちの１つを識別するステップを含む検索を実行する。幾つかの実施形態では、方法６３０は、検索サーバが、ローカルキャッシュを共有ストレージと同期させるステップを更に含む。該同期させるステップは、共有ストレージから、インデックス情報が共有ストレージに格納される順序を識別するシーケンス情報（例えば、コミットポイント情報２２２）を読み出すステップと、順序に基づき、ローカルキャッシュ内のインデックス情報が共有ストレージと異なるか否かを決定するステップと、決定に応答して、ローカルキャッシュ内のインデックス情報を共有ストレージ内のインデックス情報により更新するステップと、を含む。幾つかの実施形態では、方法６３０は、検索サーバが、共有ストレージは複数の検索サーバのうちの別の検索サーバからの、共有ストレージ内のインデックス情報が破損していることを示す通知（例えば、破損フラグ５１０）を含むと決定するステップと、通知に応答して、ローカルキャッシュからのインデックス情報を共有ストレージに格納するステップと、を更に含む。幾つかの実施形態では、方法６３０は、検索サーバが、共有ストレージは複数の検索サーバのうちの別の検索サーバからの共有ストレージ内のセグメントファイルが削除されるべきであることを示す（例えば、削除ファイルリスト２２８内の）通知を含むと決定するステップと、通知に応答して、通知が共有ストレージに格納されて以来の時間量を決定するステップと、時間量が閾値を満たすことに応答して、セグメントファイルを削除するステップと、を更に含む。

図６Ｃを参照すると、検索要求を処理する方法６６０のフローチャートが示される。方法６６０は、検索サーバ１２０のような検索サーバにより実行される方法の別の実施形態である。幾つかの例では、方法６６０の実行は、より高い信頼性及び／又は拡張性を提供し得る。

ステップ６６５で、検索サーバは受信した検索要求（例えば、要求１１２）を処理するためにインデックス情報（例えばインデックス情報１３２）をローカルキャッシュ（例えば、ローカルキャッシュ１３０）に格納する。

ステップ６７０で、検索サーバは、ローカルキャッシュ内のインデックス情報を、共有ストレージ（例えば、共有ストレージ１４０）内のインデックス情報（例えば、インデックス情報１４２）と同期させる。種々の実施形態で、同期させるステップは、共有ストレージから、共有ストレージ内のインデックス情報を示すメタデータ（例えば、メタデータファイル２２０）を読み出すステップと、メタデータに基づき、ローカルキャッシュ内のインデックス情報と異なる、共有ストレージ内のインデックス情報を識別するステップと、ローカルキャッシュ内のインデックス情報を共有ストレージ内のインデックス情報で更新するステップと、を含む。種々の実施形態で、識別するステップは、メタデータに基づき、ローカルキャッシュに格納された第１セグメントファイルセットを、共有ストレージに格納された第２ファイルセットと比較するステップを含む。幾つかの実施形態では、メタデータは、共有ストレージの中で最近格納されたセグメントファイルのシーケンス番号（例えば、コミットポイント情報２２２）を指定するステップを含み、該識別するステップは、シーケンス番号を、ローカルキャッシュの中の最近格納されたセグメントファイルのシーケンス番号と比較するステップを含む。

ステップ６７５で、検索要求に応答して、検索サーバは、更新されたインデックス情報（例えば、異なるインデックス情報１４２）を用いて決定された１つ以上の結果を提供する。幾つかの実施形態では、方法６６０は、１つ以上のアイテムをインデックス付けして、検索において１つ以上のアイテムを識別するために使用可能なインデックス情報を生成するステップと、生成されたインデックス情報をローカルキャッシュに格納して、検索サーバによる後の検索を促進するステップと、生成されたインデックス情報を（例えば、新子セグメントファイル２１０として）共有ストレージに格納して、複数の検索サーバのうちの他の検索サーバによる後の検索を促進するステップと、を更に含む。幾つかの実施形態では、方法６６０は、共有ストレージの中のインデックス情報が破損している決定するステップと、決定に応答して、複数の検索サーバのうちの別の検索サーバに共有ストレージの中のインデックス情報を他の検索サーバのローカルキャッシュ（例えば、ローカルキャッシュ１３０Ｂ）からのインデックス情報で置き換えさせる破損フラグ（例えば、破損フラグ５１０）を設定するステップと、を更に含む。

＜例示的なコンピュータシステム＞
図７を参照すると、例示的なコンピュータシステム７００のブロック図が示され、１つ以上の要素１０２〜１０４の機能を実装してよい。コンピュータシステム７００は、相互接続７６０（例えば、システムバス）を介してシステムメモリ７２０及びＩ／Ｏインタフェース７４０に結合されるプロセッササブシステム７８０を含む。Ｉ／Ｏインタフェース７４０は、１つ以上の装置７５０に結合される。コンピュータシステム７００は、限定ではないが、サーバシステム、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ又はノードブックコンピュータ、メインフレームコンピュータシステム、タブレットコンピュータ、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、携帯電話機、音楽プレイヤ又はＰＤＡ（personal data assistant）のような消費者装置を含む、種々の種類の装置のうちのいずれであってもよい。便宜上単一のコンピュータシステム７００が図７に示されるが、システム７００は、一緒に動作する２つ以上のコンピュータシステムとして実装されてもよい。

プロセッササブシステム７８０は、１つ以上のプロセッサ又は処理ユニットを含んでよい。コンピュータシステム７００の種々の実施形態では、プロセッササブシステム７８０の複数のインスタンスが相互接続７６０に結合されてよい。種々の実施形態では、プロセッササブシステム７８０（又は７８０内の各処理ユニット）は、キャッシュ又は他の形式のオンボードメモリを含んでよい。

システムメモリ７２０は、プロセッササブシステム７８０により実行可能なプログラム命令を格納し、システム７００に本願明細書に記載の種々の動作を実行させるために使用可能である。システムメモリ７２０は、異なる物理メモリ媒体、例えばハードディスク記憶装置、フロッピーディスク記憶装置、取り外し可能ディスク記憶装置、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ、ＳＲＡＭ、ＥＤＯＲＡＭ、ＳＤＲＡＭ、ＤＤＲ、ＳＤＲＡＭ、ＲＡＭＢＵＳＲＡＭ、等）、読み出し専用メモリ（ＰＲＯＭ、ＥＥＰＲＯＭ、等）、等を用いて実装されてよい。コンピュータシステム７００内のメモリは、メモリ７２０のような主記憶装置に限定されない。むしろ、コンピュータシステム７００は、プロセッササブシステム７８０内のキャッシュメモリ及びＩ／Ｏ装置７５０上の２次記憶（例えば、ハードドライブ、ストレージアレイ、等）のような他の形式の記憶装置を含んでもよい。幾つかの実施形態では、これらの他の形式の記憶装置は、プロセッササブシステム７８０により実行可能なプログラム命令を格納してもよい。幾つかの実施形態では、メモリ７２０は、要素１０２〜１４０のうちの１つ以上のためのプログラム命令を含んでよい。

Ｉ／Ｏインタフェース７４０は、種々の実施形態に従い他の装置と結合され通信するよう構成される種々の種類のインタフェースのうちのいずれであってもよい。一実施形態では、Ｉ／Ｏインタフェース７４０は、フロントサイドから１つ以上のバックサイドバスへのブリッジチップ（例えば、Ｓｏｕｔｈｂｒｉｇｄｇｅ）である。Ｉ／Ｏインタフェース７４０は、１つ以上の対応するバス又は他のインタフェースを介して１つ以上のＩ／Ｏ装置７５０に結合されてよい。Ｉ／Ｏ装置７５０の例は、記憶装置（ハードドライブ、光ドライブ、取り外し可能フラッシュドライブ、記憶アレイ、ＳＡＮ、又はそれらの関連する制御部）、（例えば、ローカル又はワイドエリアネットワークへの）ネットワークインタフェース装置、又は他の装置（例えば、グラフィック、ユーザインタフェース装置、等）を含む。一実施形態では、コンピュータシステム７００は、（例えば、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、Ｅｔｈｅｒｎｅｔ、等を介して通信するよう構成される）ネットワークインタフェース７５０を介してネットワークに結合される。

特定の実施形態が上述されたが、これらの実施形態は、単一の実施形態のみが特定の特徴に関して記載されたとしても、本開示の範囲を限定することを意図しない。本開示で提供される特徴の例は、特に断りの無い限り、限定ではなく説明を意図している。上述の説明は、本開示の利益を享受する当業者に明らかなように、このような代替、変更、及び均等物をカバーすることを意図している。

本開示の範囲は、本願明細書で解決される問題のうちのいずれか又は全部を軽減するか否かにかかわらず、本願明細書に開示した任意の特徴又は特徴の結合（明示的又は暗示的のいずれも）、又はそれらの任意の一般化を含む。従って、新規な請求項が、任意のこのような特徴の組み合わせに対して、本願（又は本願に基づく優先権を主張する出願）の審査中に形成され得る。特に、添付の請求項を参照して、従属請求項による特徴は、独立請求項の特徴と結合されてよく、それぞれの独立請求項の特徴は、添付の請求の範囲に列挙されない特定の組み合わせではなく、任意の適切な方法で結合されてよい。

Claims (20)

1. 複数の検索サーバの間の共有ストレージに格納されたインデックス情報に基づき検索要求を処理する方法であって、
   前記複数の検索サーバのうちの第１検索サーバにより、受信した検索要求を処理するために使用可能なインデックス情報を含むローカルキャッシュを維持するステップと、
   前記第１検索サーバにより、前記ローカルキャッシュを前記共有ストレージと同期させるステップであって、
   前記共有ストレージから、前記共有ストレージの中の前記インデックス情報を示すメタデータを読み出すステップと、
   前記メタデータに基づき、前記ローカルキャッシュの中の前記インデックス情報が前記共有ストレージと異なるか否かを決定するステップと、
   前記ローカルキャッシュの中の前記インデックス情報が前記共有ストレージの中の前記インデックス情報と異なると決定することに応答して、前記ローカルキャッシュの中の前記インデックス情報を、前記共有ストレージの中の前記インデックス情報により更新するステップと、
   を含むステップと、
   前記第１検索サーバにより、検索を行うための検索要求を受信するステップと、
   前記検索要求に応答して、前記第１検索サーバにより、前記更新されたインデックス情報を用いて決定された１つ以上の結果を提供するステップと、
   を含む方法。
2. 前記ローカルキャッシュの中の前記インデックス情報は、第１セグメントファイルセットの間で分散され、
   前記読み出したメタデータは、前記共有ストレージの中の第２セグメントファイルセットを識別し、
   前記決定するステップは、前記第１セグメントファイルセットを前記第２セグメントファイルセットと比較して、前記共有ストレージの中の、前記ローカルキャッシュに含まれないセグメントファイルを識別するステップを含む、請求項１に記載の方法。
3. 前記第１検索サーバにより、１つ以上のアイテムをインデックス付けするための要求に応答して、インデックス情報を生成するステップと、
   前記第１検索サーバにより、前記生成されたインデックス情報の第１インスタンスを前記ローカルキャッシュに格納するステップであって、前記生成されたインデックス情報の前記第１インスタンスは、前記第１検索サーバにより、前記１つ以上のアイテムに対する検索要求を処理するために使用可能である、ステップと、
   前記第１検索サーバにより、前記生成されたインデックス情報の第２インスタンスを前記共有ストレージに格納するステップであって、前記生成されたインデックス情報の前記第２インスタンスは、前記複数の検索サーバのうちの第２検索サーバにより、前記１つ以上のアイテムに対する検索要求を処理するために使用可能である、ステップと、
   を含む請求項１に記載の方法。
4. 前記第１検索サーバにより、前記ローカルキャッシュの中の前記インデックス情報が破損していると決定するステップと、
   前記ローカルキャッシュの中の前記インデックス情報が破損していると決定することに応答して、前記第１検索サーバが、前記ローカルキャッシュの中の前記インデックス情報を前記共有ストレージの中の前記インデックス情報で置き換えようとするステップと、
   を更に含む請求項１に記載の方法。
5. 前記第１検索サーバにより、前記共有ストレージの中の前記インデックス情報が破損していると決定するステップと、
   前記第１検索サーバにより、前記共有ストレージに、前記共有ストレージの中の前記インデックス情報が破損していることを示す通知を格納するステップであって、前記通知は、前記複数の検索サーバのうちの第２検索サーバに、前記共有ストレージの中の前記インデックス情報を前記第２検索サーバにより維持されているローカルキャッシュからのインデックス情報で置き換えさせる、ステップと、
   を更に含む請求項４に記載の方法。
6. 前記第１検索サーバにより、前記共有ストレージにインデックス情報を格納する１つ以上のセグメントファイルを削除するよう決定するステップと、
   前記第１検索サーバにより、前記共有ストレージに、前記１つ以上のセグメントファイルが削除されるべきであるという指示を格納するステップと、
   前記複数の検索サーバのうちの第２検索サーバにより、前記指示の格納から閾時間量が経過したと決定することに応答して、前記１つ以上のセグメントファイルを削除するステップと、
   を更に含む請求項１に記載の方法。
7. 前記第１検索サーバを含むコンテナをインスタンス化するステップと、
   前記第１検索サーバを前記コンテナ内で実行するステップと、
   を更に含む請求項１に記載の方法。
8. 前記複数の検索サーバにより経験されている負荷を決定するステップと、
   前記共有ストレージからインデックス情報を読み出し及び検索要求を処理するために実行可能な別の検索サーバを含む別のコンテナをインスタンス化するステップと、
   を更に含む請求項７に記載の方法。
9. 格納されたプログラム命令を有する非一時的コンピュータ可読媒体であって、前記プログラム命令は、複数の検索サーバのうちの第１検索サーバに、前記複数の検索サーバの間の共有ストレージにインデックス情報を配信する動作を実施させることが可能であり、前記動作は、
   １つ以上のアイテムをインデックス付けするための要求を受信するステップであって、前記１つ以上のアイテムは、実行された検索に応答して検索結果として識別可能になる、ステップと、
   前記要求に応答して、前記１つ以上のアイテムに基づきインデックス情報を生成するステップと、
   前記生成されたインデックス情報の第１インスタンスを、前記第１検索サーバによりアクセス可能なローカルキャッシュに格納されたインデックス情報に追加するステップと、
   前記生成されたインデックス情報の第２インスタンスを、前記共有ストレージに格納されたインデックス情報に追加するステップであって、前記生成されたインデックス情報が前記複数の検索サーバによりアクセス可能になるようにする、ステップと、
   検索を実行するステップであって、前記１つ以上のアイテムのうちの１つを、前記ローカルキャッシュに格納された生成されたインデックス情報の前記第１インスタンスに基づき決定された検索結果として識別するステップを含む、ステップと、
   を含む、コンピュータ可読媒体。
10. 前記第２インスタンスを追加するステップは、
    前記共有ストレージに、前記共有ストレージに格納された他のインデックス情報に対して、生成されたインデックス情報の前記第２インスタンスが格納される順序を識別するシーケンスメタデータを格納するステップであって、前記識別された順序は、前記複数の検索サーバのうちの検索サーバにより、生成されたインデックス情報の前記第２インスタンスを読み出すか否かを決定するために使用可能である、ステップを含む、請求項９に記載のコンピュータ可読媒体。
11. 生成されたインデックス情報の前記第２インスタンスを追加するステップは、
    前記共有ストレージに、生成されたインデックス情報の前記第２インスタンスを含むセグメントファイルを格納するステップを含み、前記格納するステップは、前記セグメントファイルに、ランダムに生成された値を含むファイル名を割り当てるステップを含む、請求項９に記載のコンピュータ可読媒体。
12. 生成されたインデックス情報の前記第２インスタンスを追加するステップは、
    前記共有ストレージに、生成されたインデックス情報の前記第２インスタンスを含むセグメントファイルを格納するステップと、
    前記共有ストレージに、前記セグメントファイルを検証するために使用可能なチェックサムを格納するステップと、
    を含む、請求項９に記載のコンピュータ可読媒体。
13. 生成されたインデックス情報の前記第２インスタンスを追加するステップは、
    前記生成されたインデックス情報の前記第２インスタンスを、前記共有ストレージに非同期プッシュするステップを含む、請求項９に記載のコンピュータ可読媒体。
14. 前記動作は、
    前記ローカルキャッシュを前記共有ストレージと同期させるステップであって、前記同期させるステップは、
    前記共有ストレージから、インデックス情報が前記共有ストレージに格納される順序を識別するシーケンス情報を読み出すステップと、
    前記順序に基づき、前記ローカルキャッシュの中の前記インデックス情報が前記共有ストレージと異なるか否かを決定するステップと、
    前記決定に応答して、前記ローカルキャッシュの中の前記インデックス情報を共有ストレージの中の前記インデックス情報により更新するステップと、
    を含むステップ、を更に含む、請求項９に記載のコンピュータ可読媒体。
15. 前記動作は、
    前記共有ストレージが、前記複数の検索サーバのうちの別の検索サーバからの前記共有ストレージの中のインデックス情報が破損していることを示す通知を含むと決定するステップと、
    前記通知に応答して、前記ローカルキャッシュからのインデックス情報を前記共有ストレージに格納するステップと、
    を更に含む、請求項９に記載のコンピュータ可読媒体。
16. 前記動作は、
    前記共有ストレージが、前記複数の検索サーバのうちの別の検索サーバからの前記共有ストレージの中のセグメントファイルが削除されるべきであることを示す通知を含むと決定するステップと、
    前記通知に応答して、前記通知が前記共有ストレージに格納されて以来の時間量を決定するステップと、
    前記時間量が閾値を満たすことに応答して、前記セグメントファイルを削除するステップと、
    を更に含む、請求項９に記載のコンピュータ可読媒体。
17. 格納されたプログラム命令を有する非一時的コンピュータ可読媒体であって、前記プログラム命令は、検索サーバに、複数の検索サーバの間の共有ストレージに格納されたインデックス情報に基づき検索要求を処理する動作を実施させることが可能であり、前記動作は、
    ローカルキャッシュに、受信した検索要求を処理するためのインデックス情報を格納するステップと、
    前記ローカルキャッシュの中のインデックス情報を前記共有ストレージの中の前記インデックス情報と同期させるステップであって、前記同期させるステップは、
    前記共有ストレージから、前記共有ストレージの中の前記インデックス情報を示すメタデータを読み出すステップと、
    前記メタデータに基づき、前記共有ストレージの中の、前記ローカルキャッシュの中の前記インデックス情報と異なるインデックス情報を識別するステップと、
    前記ローカルキャッシュの中の前記インデックス情報を、共有ストレージの中の前記識別されたインデックス情報により更新するステップと、を含むステップと、
    検索要求に応答して、前記更新されたインデックス情報を用いて決定された１つ以上の結果を提供するステップと、
    を含む、コンピュータ可読媒体。
18. 前記メタデータは、前記共有ストレージの中で最近格納されたセグメントファイルのシーケンス番号を指定し、前記セグメントファイルはインデックス情報を含み、
    前記識別するステップは、前記シーケンス番号を、前記ローカルキャッシュの中の最近格納されたセグメントファイルのシーケンス番号と比較するステップを含む、請求項１７に記載のコンピュータ可読媒体。
19. 前記動作は、
    １つ以上のアイテムをインデックス付けして、検索において前記１つ以上のアイテムを識別するために使用可能なインデックス情報を生成するステップと、
    前記生成されたインデックス情報を前記ローカルキャッシュに格納して、前記検索サーバによる後の検索を促進するステップと、
    前記生成されたインデックス情報を前記共有ストレージに格納して、前記複数の検索サーバのうちの他の検索サーバによる後の検索を促進するステップと、
    を更に含む、請求項１７に記載のコンピュータ可読媒体。
20. 前記動作は、
    前記共有ストレージの中のインデックス情報が破損している決定するステップと、
    前記決定に応答して、前記複数の検索サーバのうちの別の検索サーバに前記共有ストレージの中のインデックス情報を前記別の検索サーバのローカルキャッシュからのインデックス情報で置き換えさせる破損フラグを設定するステップと、
    を更に含む、請求項１７に記載のコンピュータ可読媒体。

Images