(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-03-10
(45)【発行日】2022-03-18
(54)【発明の名称】検索サーバの集中型ストレージ
(51)【国際特許分類】
G06F 16/22 20190101AFI20220311BHJP
G06F 16/27 20190101ALI20220311BHJP
G06F 16/901 20190101ALI20220311BHJP
【FI】
G06F16/22
G06F16/27
G06F16/901
(21)【出願番号】P 2020571440
(86)(22)【出願日】2018-06-22
(86)【国際出願番号】 IB2018000937
(87)【国際公開番号】W WO2019243859
(87)【国際公開日】2019-12-26
【審査請求日】2020-12-21
(73)【特許権者】
【識別番号】506332063
【氏名又は名称】セールスフォース ドット コム インコーポレイティッド
(74)【代理人】
【識別番号】100107766
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ギンツブルク,イラン
【審査官】後藤 彰
(56)【参考文献】
【文献】米国特許出願公開第2008/0301087(US,A1)
【文献】国際公開第01/27746(WO,A2)
【文献】米国特許出願公開第2008/0104100(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00-16/958
(57)【特許請求の範囲】
【請求項1】
複数の検索サーバの間の共有ストレージに格納されたインデックス情報に基づき検索要求を処理する方法であって、
前記共有ストレージは、前記インデックス情報へのアクセスを可能にするために、前記複数の検索サーバにより同時にアクセス可能であり、前記方法は、
前記複数の検索サーバのうちの第1検索サーバにより、受信した検索要求を処理するために使用可能なインデックス情報を含むローカルキャッシュを維持するステップと、
前記第1検索サーバにより、前記ローカルキャッシュを前記共有ストレージと同期させるステップであって、
前記第1検索サーバにより、前記共有ストレージから、前記共有ストレージの中の前記インデックス情報を示すメタデータを読み出すステップと、
前記第1検索サーバにより、前記メタデータに基づき、前記ローカルキャッシュの中の前記インデックス情報が前記共有ストレージ
の中のインデックス情報と異なるか否かを決定するステップ
であって、前記メタデータに基づき、前記ローカルキャッシュの中の前記インデックス情報と異なる前記共有ストレージの中のインデックス情報が識別される、ステップと、
前記ローカルキャッシュの中の前記インデックス情報が前記共有ストレージの中の前記インデックス情報と異なると決定することに応答して、前記ローカルキャッシュの中の前記インデックス情報を、前記共有ストレージの中の前記
識別されたインデックス情報により更新するステップと、
を含むステップと、
前記第1検索サーバにより、検索を行うための検索要求を受信するステップと、
前記検索要求に応答して、前記第1検索サーバにより、前記更新されたインデックス情報を用いて決定された1つ以上の結果を提供するステップと、
を含む方法。
【請求項2】
前記ローカルキャッシュの中の前記インデックス情報は、第1セグメントファイルセットの間で分散され、
前記読み出したメタデータは、前記共有ストレージの中の第2セグメントファイルセットを識別し、
前記決定するステップは、前記第1セグメントファイルセットを前記第2セグメントファイルセットと比較して、前記共有ストレージの中の、前記ローカルキャッシュに含まれないセグメントファイルを識別するステップを含む、請求項1に記載の方法。
【請求項3】
前記第1検索サーバにより、1つ以上のアイテムをインデックス付けするための要求に応答して、インデックス情報を生成するステップと、
前記第1検索サーバにより、前記生成されたインデックス情報の第1インスタンスを前記ローカルキャッシュに格納するステップであって、前記生成されたインデックス情報の前記第1インスタンスは、前記第1検索サーバにより、前記1つ以上のアイテムに対する検索要求を処理するために使用可能である、ステップと、
前記第1検索サーバにより、前記生成されたインデックス情報の第2インスタンスを前記共有ストレージに格納するステップであって、前記生成されたインデックス情報の前記第2インスタンスは、前記複数の検索サーバのうちの第2検索サーバにより、前記1つ以上のアイテムに対する検索要求を処理するために使用可能である、ステップと、
を含む請求項1に記載の方法。
【請求項4】
前記第1検索サーバにより、前記ローカルキャッシュの中の前記インデックス情報が破損していると決定するステップと、
前記ローカルキャッシュの中の前記インデックス情報が破損していると決定することに応答して、前記第1検索サーバが、前記ローカルキャッシュの中の前記インデックス情報を前記共有ストレージの中の前記インデックス情報で置き換えようとするステップと、
を更に含む請求項1に記載の方法。
【請求項5】
前記第1検索サーバにより、前記共有ストレージの中の前記インデックス情報が破損していると決定するステップと、
前記第1検索サーバにより、前記共有ストレージに、前記共有ストレージの中の前記インデックス情報が破損していることを示す通知を格納するステップであって、前記通知は、前記複数の検索サーバのうちの第2検索サーバに、前記共有ストレージの中の前記インデックス情報を前記第2検索サーバにより維持されているローカルキャッシュからのインデックス情報で置き換えさせる、ステップと、
を更に含む請求項4に記載の方法。
【請求項6】
前記第1検索サーバにより、前記共有ストレージにインデックス情報を格納する1つ以上のセグメントファイルを削除するよう決定するステップと、
前記第1検索サーバにより、前記共有ストレージに、前記1つ以上のセグメントファイルが削除されるべきであるという指示を格納するステップと、
前記複数の検索サーバのうちの第2検索サーバにより、前記指示の格納から閾時間量が経過したと決定することに応答して、前記1つ以上のセグメントファイルを削除するステップと、
を更に含む請求項1に記載の方法。
【請求項7】
前記第1検索サーバを含むコンテナをインスタンス化するステップと、
前記第1検索サーバを前記コンテナ内で実行するステップと、
を更に含む請求項1に記載の方法。
【請求項8】
前記複数の検索サーバにより経験されている負荷を決定するステップと、
前記共有ストレージからインデックス情報を読み出し及び検索要求を処理するために実行可能な別の検索サーバを含む別のコンテナをインスタンス化するステップと、
を更に含む請求項7に記載の方法。
【請求項9】
格納されたプログラム命令を有する非一時的コンピュータ可読媒体であって、前記プログラム命令は、複数の検索サーバのうちの第1検索サーバに、前記複数の検索サーバの間の共有ストレージにインデックス情報を配信する動作を実施させることが可能であり、
前記共有ストレージは、前記インデックス情報へのアクセスを可能にするために、前記複数の検索サーバにより同時にアクセス可能であり、前記動作は、
1つ以上のアイテムをインデックス付けするための要求を受信するステップであって、前記1つ以上のアイテムは、実行された検索に応答して検索結果として識別可能になる、ステップと、
前記要求に応答して、前記1つ以上のアイテムに基づきインデックス情報を生成するステップと、
前記生成されたインデックス情報の第1インスタンスを、前記第1検索サーバによりアクセス可能なローカルキャッシュに格納されたインデックス情報に追加するステップと、
前記生成されたインデックス情報の第2インスタンスを、前記共有ストレージに格納されたインデックス情報に追加するステップであって、前記生成されたインデックス情報が前記複数の検索サーバによりアクセス可能になるようにする、ステップと、
検索を実行するステップであって、前記1つ以上のアイテムのうちの1つを、前記ローカルキャッシュに格納された生成されたインデックス情報の前記第1インスタンスに基づき決定された検索結果として識別するステップを含む、ステップと、
を含む、コンピュータ可読媒体。
【請求項10】
前記第2インスタンスを追加するステップは、
前記共有ストレージに、前記共有ストレージに格納された他のインデックス情報に対して、生成されたインデックス情報の前記第2インスタンスが格納される順序を識別するシーケンスメタデータを格納するステップであって、前記識別された順序は、前記複数の検索サーバのうちの検索サーバにより、生成されたインデックス情報の前記第2インスタンスを読み出すか否かを決定するために使用可能である、ステップを含む、請求項9に記載のコンピュータ可読媒体。
【請求項11】
生成されたインデックス情報の前記第2インスタンスを追加するステップは、
前記共有ストレージに、生成されたインデックス情報の前記第2インスタンスを含むセグメントファイルを格納するステップを含み、前記格納するステップは、前記セグメントファイルに、ランダムに生成された値を含むファイル名を割り当てるステップを含む、請求項9に記載のコンピュータ可読媒体。
【請求項12】
生成されたインデックス情報の前記第2インスタンスを追加するステップは、
前記共有ストレージに、生成されたインデックス情報の前記第2インスタンスを含むセグメントファイルを格納するステップと、
前記共有ストレージに、前記セグメントファイルを検証するために使用可能なチェックサムを格納するステップと、
を含む、請求項9に記載のコンピュータ可読媒体。
【請求項13】
生成されたインデックス情報の前記第2インスタンスを追加するステップは、
前記生成されたインデックス情報の前記第2インスタンスを、前記共有ストレージに非同期プッシュするステップを含む、請求項9に記載のコンピュータ可読媒体。
【請求項14】
前記動作は、
前記ローカルキャッシュを前記共有ストレージと同期させるステップであって、前記同期させるステップは、
前記共有ストレージから、インデックス情報が前記共有ストレージに格納される順序を識別するシーケンス情報を読み出すステップと、
前記順序に基づき、前記ローカルキャッシュの中の前記インデックス情報が前記共有ストレージと異なるか否かを決定するステップと、
前記決定に応答して、前記ローカルキャッシュの中の前記インデックス情報を共有ストレージの中の前記インデックス情報により更新するステップと、
を含むステップ、を更に含む、請求項9に記載のコンピュータ可読媒体。
【請求項15】
前記動作は、
前記共有ストレージが、前記複数の検索サーバのうちの別の検索サーバからの前記共有ストレージの中のインデックス情報が破損していることを示す通知を含むと決定するステップと、
前記通知に応答して、前記ローカルキャッシュからのインデックス情報を前記共有ストレージに格納するステップと、
を更に含む、請求項9に記載のコンピュータ可読媒体。
【請求項16】
前記動作は、
前記共有ストレージが、前記複数の検索サーバのうちの別の検索サーバからの前記共有ストレージの中のセグメントファイルが削除されるべきであることを示す通知を含むと決定するステップと、
前記通知に応答して、前記通知が前記共有ストレージに格納されて以来の時間量を決定するステップと、
前記時間量が閾値を満たすことに応答して、前記セグメントファイルを削除するステップと、
を更に含む、請求項9に記載のコンピュータ可読媒体。
【請求項17】
格納されたプログラム命令を有する非一時的コンピュータ可読媒体であって、前記プログラム命令は、検索サーバに、複数の検索サーバの間の共有ストレージに格納されたインデックス情報に基づき検索要求を処理する動作を実施させることが可能であり、
前記共有ストレージは、前記インデックス情報へのアクセスを可能にするために、前記複数の検索サーバにより同時にアクセス可能であり、前記動作は、
ローカルキャッシュに、受信した検索要求を処理するためのインデックス情報を格納するステップと、
前記ローカルキャッシュの中のインデックス情報を前記共有ストレージの中の前記インデックス情報と同期させるステップであって、前記同期させるステップは、
前記共有ストレージから、前記共有ストレージの中の前記インデックス情報を示すメタデータを読み出すステップと、
前記メタデータに基づき、前記共有ストレージの中の、前記ローカルキャッシュの中の前記インデックス情報と異なるインデックス情報を識別するステップと、
前記ローカルキャッシュの中の前記インデックス情報を、
前記共有ストレージの中の前記識別されたインデックス情報により更新するステップと、を含むステップと、
検索要求に応答して、前記更新されたインデックス情報を用いて決定された1つ以上の結果を提供するステップと、
を含む、コンピュータ可読媒体。
【請求項18】
前記メタデータは、前記共有ストレージの中で最近格納されたセグメントファイルのシーケンス番号を指定し、前記セグメントファイルはインデックス情報を含み、
前記識別するステップは、前記シーケンス番号を、前記ローカルキャッシュの中の最近格納されたセグメントファイルのシーケンス番号と比較するステップを含む、請求項17に記載のコンピュータ可読媒体。
【請求項19】
前記動作は、
1つ以上のアイテムをインデックス付けして、検索において前記1つ以上のアイテムを識別するために使用可能なインデックス情報を生成するステップと、
前記生成されたインデックス情報を前記ローカルキャッシュに格納して、前記検索サーバによる後の検索を促進するステップと、
前記生成されたインデックス情報を前記共有ストレージに格納して、前記複数の検索サーバのうちの他の検索サーバによる後の検索を促進するステップと、
を更に含む、請求項17に記載のコンピュータ可読媒体。
【請求項20】
前記動作は、
前記共有ストレージの中のインデックス情報が破損している決定するステップと、
前記決定に応答して、前記複数の検索サーバのうちの別の検索サーバに前記共有ストレージの中のインデックス情報を前記別の検索サーバのローカルキャッシュからのインデックス情報で置き換えさせる破損フラグを設定するステップと、
を更に含む、請求項17に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、概して、コンピューティングシステムに関し、より具体的には、検索要求を処理する(service)ことを促進するコンピューティングシステムに関する。
【背景技術】
【0002】
多くの情報を維持するコンピューティングシステムは、ユーザが所望の情報を素早く発見できるために、検索機能を実装することがある。例えば、組織のシステムは、種々の従業員の多数の連絡先レコードを維持し、ユーザが従業員の姓のような1つ以上の項目を提供することにより、特定の1つを検索できるようにしてよい。この機能を実装するために、システムは、ApacheSolr(商標)サーバのような検索サーバを使用して、情報を検索するための要求を処理してよい。このようなサーバは、受信した文書をインデックス付けして、インデックスデータ構造を生成してよい。該インデックスデータ構造は、検索要求が受信されると、検索結果を決定するためにアクセスされる。インデックスデータ構造の使用は、検索が受信されるとき種々の項目について各文書をスキャンするより、検索を高速に実行できる。
【図面の簡単な説明】
【0003】
【
図1】複数の検索サーバの間の共有ストレージ内にインデックス情報を維持する検索システムの一実施形態を示すブロック図である。
【0004】
【
図2】共有ストレージ内のコンテンツの一実施形態を示すブロック図である。
【0005】
【
図3】共有ストレージからインデックス情報をプルする検索サーバの一実施形態を示すブロック図である。
【0006】
【
図4】共有ストレージへインデックス情報をプッシュする検索サーバの一実施形態を示すブロック図である。
【0007】
【
図5A】ローカルのストレージ破損を処理する検索システムの実施形態を示すブロック図である。
【
図5B】ローカルのストレージ破損を処理する検索システムの実施形態を示すブロック図である。
【0008】
【
図6A】検索システムにより実行される方法の実施形態を示すフロー図である。
【
図6B】検索システムにより実行される方法の実施形態を示すフロー図である。
【
図6C】検索システムにより実行される方法の実施形態を示すフロー図である。
【0009】
【
図7】例示的なコンピュータシステムの一実施形態を示すブロック図である。
【発明を実施するための形態】
【0010】
本開示は、「一実施形態」又は「実施形態」への言及を含む。「一実施形態では」又は「実施形態では」の語句の出現は、必ずしも同じ実施形態を表さない。特定の特徴、構造、又は特性は、本開示と矛盾しない任意の適切な方法で結合されてよい。
【0011】
本開示において、異なるエンティティ(これは、「ユニット」、「回路」、他のコンポーネント、等のように様々に表されてよい)は、1つ以上のタスク又は動作を実行するよう「構成される」と記載され又は請求されてよい。この明確な記述-「1つ以上のタスクを実行する」よう構成される「エンティティ」-は、本願明細書で、構造(つまり、電子回路のような何らかの物理的なもの)を表すために使用される。より具体的には、この明確な記述は、この構造が動作中に1つ以上のタスクを実行するよう配置されることを示すために使用される。構造は、該構造が現在作動中でない場合でも、何らかのタスクを実行する「よう構成される」と言える。「インデックス情報を格納するよう構成されるストレージ」は、例えば、対象のコンピュータシステムが現在使用中でない場合でも(例えば、それに電源が接続されていない)、動作中にこの機能を実行する1つ以上のコンピュータシステムを包含することを意図する。従って、何らかのタスクを実行する「よう構成される」と記載され又は引用されるエンティティは、装置、回路、タスクを実施するために実行可能なプログラム命令を格納するメモリ、等のような何らかの物理的なものを表す。この語法は、本願明細書で、何らかの無形物を表すために使用されない。従って、「~よう構成される」構成は、本願明細書では、アプリケーションプログラミングインタフェース(application programming interface(API))のようなソフトウェアエンティティを表すために使用されない。
【0012】
用語「~よう構成される(configured to)」は、「構成可能である(configurable to」を意味しない。未設定FPGAは、例えば、何らかの特定の機能を実行するよう「構成される」と考えられない。しかしながら、未設定FPGAは、該機能を実行するよう「構成可能」であってよく、設定(プログラミング)後に該機能を実行するよう「構成され」てよい。
【0013】
添付の特許請求の範囲における、構造が1つ以上のタスクを実行するよう「構成される」という記載は、その請求項の要素について35U.S.C.§112(f)を含まないことが明確に意図される。従って、提出される本願の請求項のいずれも、手段及び機能の要素を有するものとして解釈されることが意図される。出願人が審査中に§112(f)を含むことを意図する場合には、[機能を実行するための]「手段」の構成を用いて請求項の要素を記載する。
【0014】
本願明細書で使用されるとき、用語「第1」、「第2」、等は、それらが先行する名詞のラベルとして使用され、特に断りの無い限り、いかなる種類の順序(例えば、空間的、時間的、論理的、等)も意味しない。例えば、複数の検索サーバを有するコンピュータクラスタでは、用語「第1」及び「第2」検索サーバは、検索サーバのうちの任意の2つを表すために使用できる。言い換えると、「第1」及び「第2」検索サーバは、例えばクラスタに参加する最初のサーバに限定されない。
【0015】
本願明細書で使用されるとき、用語「に基づき」は、決定に影響する1つ以上の要素を記述するために使用される。この用語は、追加要素が決定に影響し得る可能性を排除しない。つまり、決定は、特定の要素に単独で基づいて、又は特定の要素及び他の指定されていない要素に基づいてよい。句「Bに基づきAを決定する」について検討する。この句は、BがAを決定するために使用される因子であること、又はAの決定に影響を与えることを示す。この句は、Aの決定が何からの他の因子、例えばCに基づいてもよいことを排除しない。この句は、AがBのみに基づき決定される一実施形態を包含することも意図する。本願明細書で使用されるとき、語法「に基づき」は、従って、「に少なくとも部分的に基づき」と同義である。
【0016】
コンピューティングシステムが膨大な検索クエリを断続的に受信するとき、クエリの処理を分散するために、複数の検索サーバが使用されてよい。この分散型処理を促進するために、所与のサーバは、インデックスの少なくとも一部を維持することを担ってよい。該インデックスは、ローカルに又は該サーバに専用のストレージ内に格納される。このストレージ方式は、しかしながら、幾つかの欠点を有する。個々のサーバは、クラッシュの影響を受けやすく、クラッシュは、サーバがインデックスの一部を維持することを担っているので、インデックス情報の損失をもたらし得る。新たに追加された検索サーバは現在のインデックス情報のコピーを取得するために他のサーバに負担をかけることがあるので、需要に基づき検索サーバの数をスケーリングすることも、面倒になり得る。この起こり得る性能損失を軽減するために、追加の検索サーバはプロビジョニングされてよいが、それらは需要の急増が希な場合は、十分に活用されない可能性がある。さらに、インデックス情報更新を膨大な数の検索サーバに渡り分配することは、各更新を分配するためにサーバが他のサーバに連絡しようとするので、ネットワーク帯域幅を消費し、サーバの性能を浪費し得る。
【0017】
本開示は、代わりに、複数の検索サーバのインデックス情報がサーバ間で共有されるストレージの中に維持される実施形態を記載する。種々の実施形態で以下に更に詳述されるように、検索サーバは、インデックス情報を、共有ストレージと周期的に同期されるローカルキャッシュ内に維持できる。従って、サーバは、検索要求を受信した場合、ローカルキャッシュに格納されたインデックス情報を用いて要求を処理できる。サーバは、項目(アイテム、item)をインデックス付けする要求を受信した場合、自身のローカルキャッシュを更新し、更新したインデックス情報を共有ストレージへとプッシュできる。ここで、他の検索サーバは、更新されたインデックス情報を取得し、それらそれぞれのキャッシュを更新できる。新しいサーバが追加された場合、該新しいサーバは、共有ストレージから直接に、自身のローカルキャッシュをプロビジョニングできる。
【0018】
この方法でインデックス情報を格納することは、有意な利点を提供できる。第1に、インデックス情報の更新を分配するサーバは、更新された情報を直接提供するために各サーバに面倒な連絡をするのではなく、単に、更新した情報を共有ストレージに書き込むだけである。第2に、インデックス情報が共有ストレージ内に維持されるなら、それらのサーバにより維持される任意の状態は共有ストレージ内に既に維持されているので、個々のサーバの損失は無視できる。更に、幾つかの実施形態では、共有ストレージが高い可用性及び/又は災害からの回復、つまりローカルストレージにより実装できない技術を実装し得るので、追加の信頼性が達成され得る。第3に、新しいサーバは、他のサーバを煩わすのではなく、自身のローカルキャッシュを共有ストレージから直接にプロビジョニングするので、需要に基づくスケーリングは、より迅速に及び/又は頻繁に生じることが可能である。
【0019】
図1を参照すると、検索システム10のブロック図が示される。図示の実施形態では、システム10は、相互接続150により一緒に接続される、アプリケーションサーバ110、検索サーバ120及びローカルキャッシュ130を含む仮想マシン102、並びに共有ストレージ140を含む。幾つかの実施形態では、検索システム10は、図と異なる方法で実装されてよい。例えば、アプリケーションサーバ110は、システム10の部分でなくてよく、共有ストレージ140の複数のインスタンスが使用されてよい、等である。
【0020】
アプリケーションサーバ110は、図示の実施形態では、検索機能を有するユーザインタフェースを提供するアプリケーションを提示するよう動作する。従って、アプリケーションは、ユーザが検索されるべき1つ以上のアイテムを入力できるようにする入力フィールドを提示し、検索から決定された1つ以上の結果を表示するインタフェースを提示してよい。このアプリケーションは、任意の適切なアプリケーションに対応してよい。例えば、幾つかの実施形態では、アプリケーションは顧客関係管理(customer relationship management(CRM))を促進し、種々のCRMデータをデータベースシステム内に維持してよい。このようなアプリケーションは、例えば、ユーザがこのCRMデータを検索できるようにする、例えば種々の連絡先情報、製品情報、等を検索できるようにするユーザインタフェースを提示してよい。別の例では、アプリケーションは、ユーザのアクセス可能な文書のデータベースのためのインタフェースを提示し、ユーザが文書のうちの特定のものを検索できるようにしてよい。種々の実施形態では、サーバ110は、ウェブページをクライアント装置に提供することによりアプリケーションコンテンツを提示するウェブサーバである。サーバ110として記載されるが、コンポーネント110は、アプリケーションをローカルで実行しユーザと直接インタフェースするクライアント装置であってもよい。
図1に示すように、アプリケーションサーバ110は、検索要求112及びインデックス要求114をサーバ120へ送信してよい。
【0021】
検索サーバ120は、図示の実施形態では、検索要求112を受信することに応答して、検索を実行するために実行可能である。図示のように、各サーバ120は、それぞれのマシン102により実行されてよい。幾つかの実施形態では、マシン102は、個別の物理マシン102であり、従って、サーバ120は、異なるそれぞれのハードウェアを用いて実行する。他の実施形態では、マシン102は、
図1に示されるような仮想マシン、又はHeroku(登録商標)Dynos、Linux(登録商標)コンテナ(LXC)、Docker(登録商標)コンテナ、制御グループ(Cgroups)、名前空間、等のような何らかの他の形式のコンテナである。このような一実施形態では、コンテナ内の検索サーバ120のプロビジョニングは、同じハードウェアが複数のコンテナにより共有可能なので、基礎にあるハードウェアのより高い利用率を可能できる。サーバ120は、幾つかの場合には、追加サーバ120が新しいハードウェアをもたらすのではなく、既存の基礎にあるハードウェア上に展開できるので、より迅速に展開することもできる。また更に、幾つかの実施形態では、マシン102は、コンテナを実行するために、クラウドに基づくプラットフォームを実装するコンピュータクラスタ上でインスタンス化されてよい。
【0022】
上述のように、種々の実施形態で、検索サーバ120は、マシン102のそれぞれのローカルキャッシュ130内に維持されるインデックス情報132に基づき検索要求を処理する。このインデックス情報132は、サーバ120により、所与の要求112の中で指定された項目に基づき検索結果を決定するために使用される1つ以上のインデックスデータ構造を定義してよい。例えば、サーバ120が文書検索をサポートする場合、インデックス情報132は、著者名を特定の文書にマッピングするインデックスデータ構造を定義してよい。従って、受信した検索要求112が名前「Smith」を指定する場合、サーバ120は、インデックスデータ構造を参照して、「Smith」により著された文書を決定してよい。種々の実施形態で、検索サーバ120は、1つ以上の項目をインデックス付けするためのインデックス要求114を受信することに応答して、インデックス情報を生成してよい。例えば、サーバ120は、「Smith」により著された新しい文書をインデックス付けするための要求114を受信してよく、インデックス情報132をインデックスデータ構造に追加して、該新しい文書が「Smith」についての検索に応答して識別されるようにしてよい。種々の実施形態で、検索サーバ120は、
図3及び4を参照して以下に詳述するように、プル動作134及び/又はプッシュ動作136を実行することにより、それらそれぞれのローカルキャッシュ130に格納されたインデックス情報132を、共有ストレージ140に格納されたインデックス情報142と同期させる。
【0023】
共有ストレージ140は、図示の実施形態では、インデックス情報を維持する1次記憶として検索サーバ120にサービスするよう構成される。ストレージ140は、ネットワーク接続ストレージ(network attached storage(NAS))、ストレージエリアネットワーク(storage area network(SAN))等のような任意の適切な形式のネットワークストレージに対応してよい。幾つかの実施形態では、ストレージ140は、広域ネットワークを介してサーバ120に提供され得る(AmazonのSimpleStorageService(商標)のような)クラウドストレージを実装するコンピュータクラスタにより提供されるサービスである。幾つかの実施形態では、ストレージ140は、インデックス情報142を更に守るために、高い可用性(high availability (HA))及び災害回復性(disaster recovery (DR))を実装する。種々の実施形態で、ストレージ140は共有されて、インデックス情報142に並列にアクセス可能にするために、複数の検索サーバ120により同時にアクセスされるようにする。
図2に関して以下に詳述するように、ストレージ140の中のインデックス情報142は、複数のセグメントファイルに構成されてもよい。ストレージ140は、ストレージ140からインデックス情報142をプルすること、及びストレージ140へインデックス情報132をプッシュすることを促進するために種々のメタデータも維持してよい。
【0024】
図2を参照すると、共有ストレージ140の中のコンテンツのブロック図が示される。図示の実施形態では、共有ストレージ140は、複数のセグメントファイル210A~N及びメタデータファイル220を含む。メタデータファイル220は、コミットポイント情報222、マッピング224、サイズ及びチェックサム226、並びに削除ファイルリスト228を更に含む。幾つかの実施形態では、ストレージ140は、図示のものと異なるように実装されてよい。例えば、ストレージ140は、異なるインデックスに対応するインデックス情報142の複数のインスタンスを含んでよく、メタデータファイル220は図示のものより多くの(又は少ない)情報を含んでよい、等である。
【0025】
セグメントファイル210は、図示の実施形態では、検索を実行するとき、検索サーバ120により参照されるインデックスデータ構造を定義するインデックス情報142の部分を含む。幾つかの実施形態では、ファイル210は、インデックス要求114により要求されると、新しい情報142が追加され、更新され、又は削除される度に新しいファイル210が書き込まれるコピーオンライト(copy-on-write)記憶方式を用いて書き込まれる。例えば、ファイル210B内の値が更新される場合、新しいファイル210は新しい値により書き込まれるが、ファイル210Bは不変のままである。このような方式は、ファイル210に記録されたデータを保護するために実行されてよく、ファイル210内のデータが存在する場所で更新され又は削除されるライトインプレイス(write-in-place)記憶方式とは対照的である。(他の実施形態では、ファイル210は、ライトインプレイス記憶方式を用いて記録されてよい。)ファイルが書き込まれる順序を識別するために(及び従ってどんな情報142が現在関連しているかを決定するために)、セグメントファイル210は、ファイル210がストレージ140に書き込まれる順序を示すシーケンス番号(例えば、増大するカウンタ値)を割り当てられてよい。(幾つかの実施形態では、ファイル210はストレージ140にプッシュされる前にキャッシュ130に書き込まれ得るので、この順序は、ファイル210が最初にローカルキャッシュ130に書き込まれた順序を反映してよい。)
【0026】
一実施形態では、ファイル210は、それらに割り当てられたシーケンス番号を用いて命名されてよい。幾つかの例では、しかしながら、この命名方式の使用は、ファイル210が上書きされる可能性がある。例えば、2つのサーバ120が同じシーケンス番号を用いてファイル210を書き込もうとする場合、これらのファイルは同じ名前を有し、衝突を生じるだろう。サーバ120は、現在のシーケンス番号に関して誤っている可能性があり、該シーケンス番号を有する既存のファイル210を上書きしてしまうかも知れない。幾つかの実施形態におけるこの潜在的問題に対応するために、ファイル210は、それらのシーケンス番号と独立であってよいユニークな名前を割り当てられてよい。従って、図示の実施形態では、起こり得るファイル名衝突の可能性を低減するために、ファイル210は、各名前の少なくとも一部がランダムに生成された数値を含むユニーク識別子(unique identifier (UID))名212を割り当てられる。
【0027】
メタデータファイル220は、図示の実施形態では、ローカルキャッシュ130の共有ストレージ140との同期を促進するために、検索サーバ120により使用される種々のメタデータを含む。種々の実施形態で、サーバ120による読み出しを容易にするために、ファイル220は、検索サーバ120に渡り知られている、ストレージ140内で一貫した一に書き込まれる(例えば、一貫したファイル名を有し、一貫したディレクトリパスに存在する)。幾つかの実施形態では、ファイル220は、複数のファイル220のうちの1つである。各ファイル220は、インデックス情報142により定義されるそれぞれのインデックスデータ構造に関連付けられる。他の実施形態では、しかしながら、メタデータファイル220は、インデックス情報142により定義される複数のインデックスデータ構造のメタデータを含むことができる。
【0028】
コミットポイント情報222は、図示の実施形態では、インデックスデータ構造を定義するインデックス情報142の最新バージョン(つまり、現在のバージョン)を構成するファイル210を識別する。幾つかの実施形態では、ファイル210は、新鮮でない/古いインデックス情報142を有することになると、メタデータ222から削除されてよい。他の実施形態では、新鮮でないインデックス情報142を有するファイル210は、情報222の中で依然として識別されてよいが、インデックス情報142の最新バージョンを構成したいとして示される。幾つかの実施形態では、情報222は、ファイル210それぞれのシーケンス番号に基づきファイル210識別する。情報222は、ストレージ140が更新されたときを識別するタイムスタンプ情報も含んでよい。
図3に関して説明するように、検索サーバ120のローカルキャッシュ130との同期の最中に情報142をプルしようとする検索サーバ120は、(マッピング224と一緒に)情報222を読み出して、どのセグメントファイル210が異なり(例えば、任意の前の同期に対して新しいか)及びストレージ140から読み出されるべきかを決定してよい。
図4に関して説明するように、同期の最中に情報132をプッシュしようとする検索サーバ120は、同様に、情報222を読み出して、どのセグメントファイル210が自身のキャッシュ130からストレージ140に書き込まれるべきかを決定してよい。
【0029】
シーケンス番号のUIDへのマッピング224は、図示の実施形態では、シーケンス番号のファイル210のファイル名へのマッピングである。従って、最新ファイル210をプルしようとする検索サーバ120は、最初に情報222を読み出して、それらのシーケンス番号を決定し、次にマッピング224を参照して、プルすべきファイル220の特定のファイル名を決定してよい。UID名212が使用されない実施形態では、マッピング224は、異なる命名方式を反映するために異なる方法で実装されてよい(又は命名方式に依存して実装されなくてよい)。
【0030】
サイズ及びチェックサム226は、図示の実施形態では、セグメントファイル210について生成されたファイルサイズ及びチェックサムのリストである。このメタデータ226は、検索サーバ120がセグメントファイル210をストレージ140に書き込むとき、ストレージ140内に記録されてよく、該ファイル210(及びより一般的な情報142)が後に破損したかどうかを決定するために使用されてよい。
図5Aに関して後述するように、検索サーバ120は、自身のキャッシュ130の中のインデックス情報132が破損していると決定し、それをストレージ140からの情報で置き換えようとしてよい。情報142が破損していると決定された場合(例えば、メタデータ226に基づき決定される)、
図5Bに関して後述するように、検索サーバ120は、別のサーバ120がインデックス情報142を自身のキャッシュ130からのインデックス情報132で置き換えることを要求してよい。
【0031】
削除ファイルリスト228は、図示の実施形態では、削除のためにスケジューリングされているが未だ削除されていなくてよいファイル210のリストである。幾つかの実施形態では、サーバ120は、特定のファイル210が(もはや現在の情報を含まないので)削除されるべきであると決定し、該ファイル210の指示及びタイムスタンプをリスト228に格納してよく、そのときにファイル210を削除しない。後の時点で、自身のローカルキャッシュ130を共有ストレージ140と同期させようとするサーバ120(同じサーバ120又は異なるサーバ120であってよい)は、リスト228に格納されたタイムスタンプと一緒にリスト228を読み出してよい。タイムスタンプのうちの任意のものが時間閾値を満たす場合、サーバ120は、それらの古いタイムスタンプに対応するファイル210を削除してよい。このような削除方式は、削除情報に対して決定が行われた後に、インデックス情報が(例えば復元目的で)一時的に保存されることを可能にできる。
【0032】
図3を参照すると、ローカルキャッシュ130を共有ストレージ140と同期させるプル動作134のブロック図が示される。上述のように、この動作134は、検索サーバ120がサーバ120のクラスタに追加された後に、例えば仮想マシン102が追加されたサーバ120によりインスタンス化されることに応答して、実行されてよい。種々の実施形態で、検索サーバ120は、それらのキャッシュ130がストレージ140と同期化されることを保証するために、定期的間隔でプル動作134を実行してもよい。幾つかの実施形態では、ストレージ140を更新する検索サーバ120は、ApacheZooKeeper(商標)のような分散型連携アプリケーションを使用して、他のサーバにプル動作134を実行させるために、更新が生じたときに他のサーバ120に通知してよい。幾つかの実施形態では、サーバ120が、自身のローカルキャッシュ130に格納されたセグメントファイル210により未だ定義されていないインデックスデータ構造を用いて検索を実行するための検索要求112を受信した場合に、プル動作134が開始されてもよい。
【0033】
図示のように、同期が既に実行されたとすると、検索サーバ120は、メタデータ310、及び1つ以上のセグメントファイル210を含んでよい幾つかのインデックス情報132を既に含んでよい。図示の実施形態では、ローカルメタデータ310は、ローカルキャッシュ130に格納されたセグメントファイル210を識別し、メタデータファイル220に関して上述したメタデータ222~228のうちの任意のものを含んでよい。例えば、幾つかの実施形態では、ローカルメタデータ310は、どのファイル210がキャッシュ130に格納されるかを識別するシーケンス番号セットを含んでよい。
【0034】
種々の実施形態で、プル動作134は、検索サーバ120がメタデータファイル220を読み出すことで開始し、キャッシュ130内のインデックス情報132が共有ストレージ140内のインデックス情報142と異なるか否かを決定してよい。幾つかの実施形態では、この決定は、ローカルメタデータ310内のシーケンス番号をメタデータファイル220(具体的には、上述のコミットポイント情報222)内のシーケンス番号と比較して、ストレージ140内のどのセグメントファイル210がキャッシュ130内に存在しないかを決定することを含んでよい。一実施形態では、この比較は、最初に、メタデータ310の中に示される最近格納されたセグメントファイル210のシーケンス番号を、メタデータファイル220内で示される最近格納されたセグメントファイル210のシーケンス番号と比較することを含んでよい。これらの番号が同じ場合、検索サーバ120は、キャッシュ130がストレージ140と同期されていることを決定し、更なる動作を行わなくてよい。それらが異なる場合、キャッシュ130及びストレージ140が同期されていないことを意味し、検索サーバ120は、メタデータ310及びメタデータファイル220の中のシーケンス番号の各々を比較して、異なるセグメントファイル210を識別してよい。
【0035】
検索サーバ120が自身のインデックス情報132と異なるインデックス情報142を識別すると、検索サーバ120は、該異なるインデックス情報142を自身のローカルキャッシュ130へとプルしてよい。幾つかの実施形態では、これは、情報132と異なると決定された任意の情報142をプルすることを含んでよい。他の実施形態では、しかしながら、これは、検索サーバ120により使用されているインデックスデータ構造のセグメントファイル210のみをプルすることを含んでよい。例えば、検索サーバ120がインデックスXYZを定義するセグメントファイル210を格納し、インデックスABCを用いる検索を実行するための検索要求112を受信した場合、検索サーバ120は、インデックスデータ構造XYZ及びABCのセグメントファイル210をプルしてよいが、該サーバ120により使用されていないインデックスDEFのセグメントファイル210をプルしない。
【0036】
図4を参照すると、共有ストレージ140をローカルキャッシュ130と同期させるプッシュ動作136のブロック図が示される。上述のように、検索サーバ120は、インデックス情報132及び142により定義されるインデックスデータ構造の中で参照されるアイテムを追加し、変更し又は削除するためのインデックス要求114を受信してよい。インデックス要求114を受信することに応答して、検索サーバ120は、新しいセグメントファイル210を生成し、該ファイル210の第1インスタンスを自身のローカルキャッシュ130に格納してよい。幾つかの実施形態では、新しいセグメントファイル210は、複数のファイル210からのインデックス情報を単一のファイル210へとマージすることにより、生成されてもよい。新しいファイル210がローカルキャッシュ130に格納されると、検索サーバ120は、他のサーバ120への自身の配信を促進するために、プッシュ136を実行して、新しいセグメントファイル210の第2インスタンスをストレージ140に格納してよい。
【0037】
プル動作134と同様に、プッシュ動作136は、検索サーバ120がメタデータファイル220を読み出して、キャッシュ130内のどのセグメントファイル210が共有ストレージ140内のセグメントファイル210に対して新しいかを決定することで開始してよい。ファイル210のうちの任意のものが異なる場合、検索サーバ120は、異なるファイル210のリストを構築し、該異なるファイル210を自身のローカルキャッシュ130から共有ストレージ140へとプッシュしてよい。(幾つかの実施形態では、検索サーバ120は、ローカルキャッシュ130に無いと決定されたファイル210を共有ストレージ140からプルしてもよい。)新しいセグメントファイル210をストレージ140へプッシュすることに成功すると、検索サーバ120は、メタデータファイル220を更新して、新しいファイル210が共有ストレージ140にコミットされたことを反映してよい。幾つかの実施形態では、検索サーバ120は、更新されたインデックス情報142を他のサーバ120に通知してもよい。しかしながら、他の実施形態では、他のサーバ120は、それらが最終的にプル134を実行するとき、更新されたインデックス情報142を知ってよい。
【0038】
幾つかの実施形態では、プッシュ動作136は、同期的に実行される。つまり、ローカルキャッシュ130にセグメントファイル210の第1インスタンスを格納すると、プッシュ動作136が実行されて、セグメントファイル210の第2インスタンスを共有ストレージ140に格納する。他の実施形態では、プッシュ動作136は、非同期的に実行される。例えば、インデックス付けを実行する検索サーバ120は、プッシュ動作136を定期的間隔で開始して、キャッシュ130内の任意の新しく生成されたセグメントファイル210をストレージ140へとプッシュしてよい。代替として、検索サーバ120は、自身がキャッシュ130内に閾数の新しいセグメントファイル210を生成するまで待機し、次に、新しいファイル210のセットをストレージ140へプッシュするバッチ同期を実行してよい。
【0039】
図5Aを参照すると、ローカルの破損500Aを修復するブロック図が示される。上述のように、検索サーバ120は、自身のローカルキャッシュ130内のインデックス情報132が破損していると決定してよい。インデックス情報132が破損していると決定することに応答して、検索サーバ120は、プル134を実行して、インデックス情報132を、共有ストレージ140からの破損していないインデックス情報142で置き換えてよい。しかしながら、共有ストレージ140内のインデックス情報142が破損していると決定された場合、検索サーバ120は、
図5Bにより次に議論されるように進行してよい。
【0040】
図5Bを参照すると、ストレージの破損500Bを修復するブロック図が示される。上述のように、幾つかの例では、検索サーバ120は、共有ストレージ140内の情報142が破損していると決定してよい。検索サーバ120の自身のキャッシュ130内のインデックス情報132が破損していない場合、検索サーバ120は、自身の情報132のプッシュ136を実行して、インデックス情報142を置き換えてよい。しかしながら、自身のインデックス情報132が破損している場合(
図5Bの場合)、検索サーバ120は、共有ストレージ140を介して、破損に関する通知を他のサーバ120へ送信してよい。従って、図示の実施形態では、検索サーバ120Aは、別のサーバ120Bに決定した破損に関して通知するために、破損フラグ510を設定する。フラグ510を読み出すことに応答して、検索サーバ120Bは、自身のローカルインデックス情報132が破損していない場合、自身のローカルインデックス情報132を自身のキャッシュ130からプッシュすることにより、共有ストレージ140内のインデックス情報142を置き換えてよい。他の実施形態では、しかしながら、検索サーバ120は、互いに直接連絡するような他の技術を用いて、破損を互いに通知してよい。
【0041】
図6Aを参照すると、複数の検索サーバの間の共有ストレージに格納されたインデックス情報に基づき検索要求を処理する方法600のフローチャートが示される。方法600は、検索サーバ120のような1つ以上の検索サーバ120により実行される方法の一実施形態である。幾つかの例では、方法600の実行は、より高い信頼性及び/又は拡張性を提供し得る。
【0042】
ステップ605で、第1検索サーバは受信した検索要求(例えば、検索要求112)を処理するために使用可能なインデックス情報(例えばインデックス情報132)を含むローカルキャッシュ(例えば、ローカルキャッシュ130)を維持する。種々の実施形態で、方法600は、第1検索サーバを含むコンテナ(例えば、仮想マシン102A)をインスタンス化するステップと、コンテナ内で第1検索サーバを実行するステップと、を含む。幾つかの実施形態では、方法600は、複数の検索サーバにより経験されている負荷を決定するステップと、共有ストレージからインデックス情報を読み出し及び検索要求を処理するために実行可能な別の検索サーバを含む別のコンテナ(例えば、仮想マシン102N)をインスタンス化するステップと、を含む。
【0043】
ステップ610で、第1検索サーバは、ローカルキャッシュを共有ストレージ(例えば、共有ストレージ140)と同期させる。種々の実施形態で、同期させるステップは、共有ストレージから、共有ストレージ内のインデックス情報を示すメタデータ(例えば、メタデータファイル220)を読み出すステップと、メタデータに基づき、ローカルキャッシュ内のインデックス情報が共有ストレージと異なるか否かを決定するステップと、ローカルキャッシュ内のインデックス情報が共有ストレージ内のインデックス情報と異なると決定することに応答して、ローカルキャッシュ内のインデックス情報を共有ストレージ内のインデックス情報で更新するステップと、を含む。幾つかの実施形態では、ローカルキャッシュ内のインデックス情報は、第1セグメントファイルセット(例えばセグメントファイル210)の間で分散される。このような一実施形態では、読み出したメタデータは、共有ストレージ内の(例えば、コミットポイント情報222内の)第2セグメントファイルセットを識別し、決定するステップは、第1セグメントファイルセットを第2セグメントファイルセットと比較して、共有ストレージ内の、ローカルキャッシュに含まれないセグメントファイルを識別するステップを含む。
【0044】
ステップ615で、第1検索サーバは、検索を行うための検索要求を受信する。
【0045】
ステップ620で、第1検索サーバは、検索要求に応答して、更新されたインデックス情報を用いて決定された1つ以上の結果を提供する。幾つかの実施形態では、方法600は、第1検索サーバにより、1つ以上のアイテムをインデックス付けするための要求に応答して、インデックス情報を生成するステップと、生成されたインデックス情報の第1インスタンスをローカルキャッシュに格納するステップと(生成されたインデックス情報の第1インスタンスは、1つ以上のアイテムに対する検索要求を処理するために第1検索サーバにより使用可能である)、生成されたインデックス情報の第2インスタンスを共有ストレージに格納するステップと(生成されたインデックス情報の第2インスタンスは、複数の検索サーバのうちの第2検索サーバにより、1つ以上のアイテムに対する検索要求を処理するために使用可能である)、を含む。幾つかの実施形態では、方法600は、第1検索サーバにより、ローカルキャッシュ内のインデックス情報が破損していると決定するステップと、ローカルキャッシュ内のインデックス情報が破損していると決定することに応答して、ローカルキャッシュ内のインデックス情報を共有ストレージ内のインデックス情報で置き換えようとするステップと、を更に含む。幾つかの実施形態では、方法600は、第1検索サーバが、共有ストレージ内のインデックス情報が破損していると決定するステップと、共有ストレージに、共有ストレージ内のインデックス情報が破損していることを示す通知(例えば、破損フラグ510)を格納するステップと、を更に含む。このような一実施形態では、通知は、複数の検索サーバのうちの第2検索サーバに、共有ストレージ内のインデックス情報を、第2検索サーバにより維持されるローカルキャッシュからのインデックス情報により置き換えさせる。幾つかの実施形態では、方法600は、第1検索サーバにより、共有ストレージ内のインデックス情報を格納する1つ以上のセグメントファイルを削除することを決定するステップと、共有ストレージに、1つ以上のセグメントファイルが削除されるべきであるという指示(例えば、削除ファイルリスト228)を格納するステップと、を更に含む。このような一実施形態では、第2検索サーバは、指示を格納してから閾時間量が経過したと決定することに応答して、1つ以上のセグメントファイルを削除する。
【0046】
図6Bを参照すると、複数の検索サーバの間の共有ストレージにインデックス情報を配信する方法630のフローチャートが示される。方法630は、検索サーバ120のような検索サーバにより実行される方法の別の実施形態である。幾つかの例では、方法630の実行は、より高い信頼性及び/又は拡張性を提供し得る。
【0047】
ステップ635で、検索サーバは、1つ以上のアイテムをインデックス付けするための要求(例えば、インデックス要求114)を受信する。その結果、1つ以上のアイテムが実行された検索に応答して検索結果として識別可能になる。
【0048】
ステップ640で、検索サーバは、要求に応答して、1つ以上のアイテムに基づきインデックス情報を生成する。
【0049】
ステップ645で、検索サーバは、生成されたインデックス情報の第1インスタンスを、第1検索サーバによりアクセス可能なローカルキャッシュ(例えばローカルキャッシュ130)に格納されたインデックス情報(例えば、インデックス情報132)に追加する。
【0050】
ステップ650で、検索サーバは、生成されたインデックス情報の第2インスタンスを、共有ストレージ(例えば共有ストレージ140)に格納されたインデックス情報(例えば、インデックス情報142)に追加して、生成されたインデックス情報を複数の検索サーバによりアクセス可能にする。幾つかの実施形態では、第2インスタンスを追加するステップは、
共有ストレージに、共有ストレージに格納された他のインデックス情報に対して、生成されたインデックス情報の第2インスタンスが格納される順序を識別するシーケンスメタデータ(例えば、コミットポイント情報222)を格納するステップであって、識別された順序は、複数の検索サーバのうちの検索サーバにより、生成されたインデックス情報の第2インスタンスを読み出すか否かを決定するために使用可能である、ステップを含む。幾つかの実施形態では、生成されたインデックス情報の第2インスタンスを追加するステップは、共有ストレージに、生成されたインデックス情報の第2インスタンスを含むセグメントファイル(例えば、セグメントファイル210)を格納するステップと、セグメントファイルに、ランダムに生成された値を含むファイル名(例えば、UID名212)を割り当てるステップと、を含む。幾つかの実施形態では、生成されたインデックス情報の第2インスタンスを追加するステップは、共有ストレージに、生成されたインデックス情報の第2インスタンスを含むセグメントファイルを格納するステップと、共有ストレージに、セグメントファイルを検証するために使用可能なチェックサム(例えば、サイズ及びチェックサム226)を格納するステップと、を含む。幾つかの実施形態では、生成されたインデックス情報の第2インスタンスを追加するステップは、生成されたインデックス情報の第2インスタンスを、共有ストレージに非同期プッシュするステップを含む。
【0051】
ステップ655で、検索サーバは、ローカルキャッシュに格納された生成されたインデックス情報の第1インスタンスに基づき決定された検索結果として、1つ以上のアイテムのうちの1つを識別するステップを含む検索を実行する。幾つかの実施形態では、方法630は、検索サーバが、ローカルキャッシュを共有ストレージと同期させるステップを更に含む。該同期させるステップは、共有ストレージから、インデックス情報が共有ストレージに格納される順序を識別するシーケンス情報(例えば、コミットポイント情報222)を読み出すステップと、順序に基づき、ローカルキャッシュ内のインデックス情報が共有ストレージと異なるか否かを決定するステップと、決定に応答して、ローカルキャッシュ内のインデックス情報を共有ストレージ内のインデックス情報により更新するステップと、を含む。幾つかの実施形態では、方法630は、検索サーバが、共有ストレージは複数の検索サーバのうちの別の検索サーバからの、共有ストレージ内のインデックス情報が破損していることを示す通知(例えば、破損フラグ510)を含むと決定するステップと、通知に応答して、ローカルキャッシュからのインデックス情報を共有ストレージに格納するステップと、を更に含む。幾つかの実施形態では、方法630は、検索サーバが、共有ストレージは複数の検索サーバのうちの別の検索サーバからの共有ストレージ内のセグメントファイルが削除されるべきであることを示す(例えば、削除ファイルリスト228内の)通知を含むと決定するステップと、通知に応答して、通知が共有ストレージに格納されて以来の時間量を決定するステップと、時間量が閾値を満たすことに応答して、セグメントファイルを削除するステップと、を更に含む。
【0052】
図6Cを参照すると、検索要求を処理する方法660のフローチャートが示される。方法660は、検索サーバ120のような検索サーバにより実行される方法の別の実施形態である。幾つかの例では、方法660の実行は、より高い信頼性及び/又は拡張性を提供し得る。
【0053】
ステップ665で、検索サーバは受信した検索要求(例えば、要求112)を処理するためにインデックス情報(例えばインデックス情報132)をローカルキャッシュ(例えば、ローカルキャッシュ130)に格納する。
【0054】
ステップ670で、検索サーバは、ローカルキャッシュ内のインデックス情報を、共有ストレージ(例えば、共有ストレージ140)内のインデックス情報(例えば、インデックス情報142)と同期させる。種々の実施形態で、同期させるステップは、共有ストレージから、共有ストレージ内のインデックス情報を示すメタデータ(例えば、メタデータファイル220)を読み出すステップと、メタデータに基づき、ローカルキャッシュ内のインデックス情報と異なる、共有ストレージ内のインデックス情報を識別するステップと、ローカルキャッシュ内のインデックス情報を共有ストレージ内のインデックス情報で更新するステップと、を含む。種々の実施形態で、識別するステップは、メタデータに基づき、ローカルキャッシュに格納された第1セグメントファイルセットを、共有ストレージに格納された第2ファイルセットと比較するステップを含む。幾つかの実施形態では、メタデータは、共有ストレージの中で最近格納されたセグメントファイルのシーケンス番号(例えば、コミットポイント情報222)を指定するステップを含み、該識別するステップは、シーケンス番号を、ローカルキャッシュの中の最近格納されたセグメントファイルのシーケンス番号と比較するステップを含む。
【0055】
ステップ675で、検索要求に応答して、検索サーバは、更新されたインデックス情報(例えば、異なるインデックス情報142)を用いて決定された1つ以上の結果を提供する。幾つかの実施形態では、方法660は、1つ以上のアイテムをインデックス付けして、検索において1つ以上のアイテムを識別するために使用可能なインデックス情報を生成するステップと、生成されたインデックス情報をローカルキャッシュに格納して、検索サーバによる後の検索を促進するステップと、生成されたインデックス情報を(例えば、新子セグメントファイル210として)共有ストレージに格納して、複数の検索サーバのうちの他の検索サーバによる後の検索を促進するステップと、を更に含む。幾つかの実施形態では、方法660は、共有ストレージの中のインデックス情報が破損している決定するステップと、決定に応答して、複数の検索サーバのうちの別の検索サーバに共有ストレージの中のインデックス情報を他の検索サーバのローカルキャッシュ(例えば、ローカルキャッシュ130B)からのインデックス情報で置き換えさせる破損フラグ(例えば、破損フラグ510)を設定するステップと、を更に含む。
【0056】
<例示的なコンピュータシステム>
図7を参照すると、例示的なコンピュータシステム700のブロック図が示され、1つ以上の要素102~104の機能を実装してよい。コンピュータシステム700は、相互接続760(例えば、システムバス)を介してシステムメモリ720及びI/Oインタフェース740に結合されるプロセッササブシステム780を含む。I/Oインタフェース740は、1つ以上の装置750に結合される。コンピュータシステム700は、限定ではないが、サーバシステム、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ又はノードブックコンピュータ、メインフレームコンピュータシステム、タブレットコンピュータ、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、携帯電話機、音楽プレイヤ又はPDA(personal data assistant)のような消費者装置を含む、種々の種類の装置のうちのいずれであってもよい。便宜上単一のコンピュータシステム700が
図7に示されるが、システム700は、一緒に動作する2つ以上のコンピュータシステムとして実装されてもよい。
【0057】
プロセッササブシステム780は、1つ以上のプロセッサ又は処理ユニットを含んでよい。コンピュータシステム700の種々の実施形態では、プロセッササブシステム780の複数のインスタンスが相互接続760に結合されてよい。種々の実施形態では、プロセッササブシステム780(又は780内の各処理ユニット)は、キャッシュ又は他の形式のオンボードメモリを含んでよい。
【0058】
システムメモリ720は、プロセッササブシステム780により実行可能なプログラム命令を格納し、システム700に本願明細書に記載の種々の動作を実行させるために使用可能である。システムメモリ720は、異なる物理メモリ媒体、例えばハードディスク記憶装置、フロッピーディスク記憶装置、取り外し可能ディスク記憶装置、フラッシュメモリ、ランダムアクセスメモリ(RAM、SRAM、EDORAM、SDRAM、DDR、SDRAM、RAMBUSRAM、等)、読み出し専用メモリ(PROM、EEPROM、等)、等を用いて実装されてよい。コンピュータシステム700内のメモリは、メモリ720のような主記憶装置に限定されない。むしろ、コンピュータシステム700は、プロセッササブシステム780内のキャッシュメモリ及びI/O装置750上の2次記憶(例えば、ハードドライブ、ストレージアレイ、等)のような他の形式の記憶装置を含んでもよい。幾つかの実施形態では、これらの他の形式の記憶装置は、プロセッササブシステム780により実行可能なプログラム命令を格納してもよい。幾つかの実施形態では、メモリ720は、要素102~140のうちの1つ以上のためのプログラム命令を含んでよい。
【0059】
I/Oインタフェース740は、種々の実施形態に従い他の装置と結合され通信するよう構成される種々の種類のインタフェースのうちのいずれであってもよい。一実施形態では、I/Oインタフェース740は、フロントサイドから1つ以上のバックサイドバスへのブリッジチップ(例えば、Southbrigdge)である。I/Oインタフェース740は、1つ以上の対応するバス又は他のインタフェースを介して1つ以上のI/O装置750に結合されてよい。I/O装置750の例は、記憶装置(ハードドライブ、光ドライブ、取り外し可能フラッシュドライブ、記憶アレイ、SAN、又はそれらの関連する制御部)、(例えば、ローカル又はワイドエリアネットワークへの)ネットワークインタフェース装置、又は他の装置(例えば、グラフィック、ユーザインタフェース装置、等)を含む。一実施形態では、コンピュータシステム700は、(例えば、WiFi、Bluetooth、Ethernet、等を介して通信するよう構成される)ネットワークインタフェース750を介してネットワークに結合される。
【0060】
特定の実施形態が上述されたが、これらの実施形態は、単一の実施形態のみが特定の特徴に関して記載されたとしても、本開示の範囲を限定することを意図しない。本開示で提供される特徴の例は、特に断りの無い限り、限定ではなく説明を意図している。上述の説明は、本開示の利益を享受する当業者に明らかなように、このような代替、変更、及び均等物をカバーすることを意図している。
【0061】
本開示の範囲は、本願明細書で解決される問題のうちのいずれか又は全部を軽減するか否かにかかわらず、本願明細書に開示した任意の特徴又は特徴の結合(明示的又は暗示的のいずれも)、又はそれらの任意の一般化を含む。従って、新規な請求項が、任意のこのような特徴の組み合わせに対して、本願(又は本願に基づく優先権を主張する出願)の審査中に形成され得る。特に、添付の請求項を参照して、従属請求項による特徴は、独立請求項の特徴と結合されてよく、それぞれの独立請求項の特徴は、添付の請求の範囲に列挙されない特定の組み合わせではなく、任意の適切な方法で結合されてよい。