B2B WebアプリのLucene/SOLRをセットアップする方法は？

Question

与えられた：

• クライアントごとに1データベース（ビジネスカスタマー）
• 5000のクライアント
• クライアントには2〜2000人のユーザーがいます（AVGは〜100人のユーザー/クライアントです）
• データベースごとに100K〜1000万レコード
• ユーザーはこれらのレコードを頻繁に検索する必要があります（データをナビゲートする最良の方法です）

おそらく関連情報：

• 毎週いくつかの新しいクライアント（営業時間中はいつでも）
• 複数のWebサーバーとデータベースサーバー（ユーザーは任意のWebサーバーを介してログインできます）
• Lucene（およびSolr）には幅広いサポートがあるので、言語またはSQLブランドの不可知論者を維持しましょう

例えば：

ジョエル・スポルスキーは言った ポッドキャスト＃11 彼のホストされているWebアプリ製品であるFogbugz On-DemandがLuceneを使用していること。彼には何千人ものオンデマンドクライアントがいます。そして、各クライアントは独自のデータベースを取得します。

彼らはanを使用します クライアントごとのインデックスとクライアントのデータベースに保存します. 。詳細についてはわかりません。そして、これがルーセンにとって深刻なmodなかどうかはわかりません。

質問：

各クライアントがデータベース内でのみ検索できるように、Lucene検索をどのようにセットアップしますか？

インデックスをどのようにセットアップしますか？
インデックスはどこに保存しますか？
すべての検索クエリにフィルターを追加する必要がありますか？
クライアントがキャンセルした場合、どのように（の一部）インデックスを削除しますか？ （これは些細なことかもしれません - まだ確かではありません）

可能な解決策：

各クライアント（データベース）のインデックスを作成する

• Pro：検索はより速い（1つのインデックスのすべての方法よりも）。インデックスは、クライアントのデータのサイズに関連しています。
• CON：これが何を伴うのかわかりませんし、これがルーセンの範囲を超えているかどうかもわかりません。

Database_Nameフィールドを備えた単一の巨大なインデックスを持っています。必ずデータベース_NAMEをフィルターとして含めてください。

• プロ：よくわかりません。たぶん、すべてのデータベースを検索するために、技術サポートや請求局に適しているかもしれません。
• CON：検索はより遅い（クライアントごとのインデックスよりも）。クエリフィルターが削除された場合、欠陥セキュリティ。

最後に一つだけ：
また、使用する回答も受け入れます solr （ルーセンの拡張）。おそらく、この問題により適しています。わからない。

Answer 1

Fogbugz stackexchangeから私を召喚しました。私の名前はジュードです。私は現在のフォグバッツの検索アーキテクトです。

Fogbugz On Demand Searchアーキテクチャがどのように設定されているかの大まかな概要を次に示します[1]：

• データの移植性、セキュリティなどに関連する理由により、オンデマンドのデータベースとインデックスをすべて分離します。
• Lucene（Lucene.net、実際には）を使用していますが、データベースに完全にインデックスを保存できるように、バックエンドをかなり大幅に改造しました。さらに、各ウェブホストでローカルキャッシュが維持されるため、不要なデータベースヒットを可能な限り回避できます。
• フィルターはほぼ完全にデータベース側（検索以外のFogbugzの側面で使用されているため）であるため、検索パーサーはクエリをフルテキストと非フルテキストコンポーネントに分離し、ルックアップを実行し、結果を組み合わせます。これは、ルーセンが作ることができる多くの有用な最適化を無効にするため、少し残念です。

私たちがやったことにはいくつかの利点があります。クライアントデータとそのインデックスは同じ場所に保存されるため、アカウントの管理は非常に簡単です。ただし、最低基準を下回る本当に厄介なエッジケース検索のセットなど、いくつかのネガもあります。遡及的に、私たちの検索はクールで、当時はよくできていました。私がもう一度やるなら、私は このアプローチを思いとどまらせます.

単純に、検索ドメインが非常に特別なものである場合、または開発者をぼんやりと速い検索に捧げることをいとわない限り、Elasticsearch、Solr、Xapianのような優れた製品に優れていることになるでしょう。

私が今日これをしていたなら、私の検索ドメインが非常に具体的でない限り、私はおそらく使用するでしょう ElasticSearch、Solr、またはXapian 私のデータベース支援フルテキスト検索ソリューション用。それに関して、それはあなたの補助的なニーズ（プラットフォーム、クエリの種類、拡張性、あるセットの癖に対する耐性など）に依存します。

1つの大きなインデックスと多くの（！）散在するインデックスのトピックについて：両方が機能します。この決定は、どのようなアーキテクチャを構築しようとしているのか、どのようなパフォーマンスが必要かにあると思います。 2秒間の検索応答が妥当であると判断した場合、かなり柔軟になりますが、200msを超えるものは受け入れられないと言って、オプションが非常に速く消え始めます。すべてのクライアントの単一の大きな検索インデックスを維持しながら、さらに多くのことをすることができます 効率的 多くの小さなインデックスを処理するよりも、必ずしも速くはありません（指摘したように）。私は個人的に、安全な環境では、クライアントデータを分離することの利点は過小評価されないことであると感じています。インデックスが破損すると、すべての検索が停止することはありません。愚かな小さな虫は、機密データを公開しません。ユーザーアカウントはモジュラーのままです。アカウントのセットを抽出して新しいサーバーに貼り付ける方が簡単です。等

それがあなたの質問に答えたかどうかはわかりませんが、私は少なくともあなたの好奇心を満足させたことを願っています:-)

1]：2013年、FogbugzはElasticSearchで検索およびフィルタリング機能のパワーを発揮し始めました。私たちはそれが好き。

Answer 2

シャリン・シェカル・マンガー 私に答えました solr-userメーリングリスト そしてプライベートメールで。 ShalinはSolrの貢献者であり、今後の本の著者です solr in action.

メーリングリストでの彼の返信：

インデックスをどのようにセットアップしますか？

クライアントごとに複数のコアのセットアップを検討します。検索トラフィックに応じて、奴隷をセットアップする必要がある場合があります。

インデックスはどこに保存しますか？

1つのボックスに5Kコアをセットアップしても機能しません。したがって、クライアントを複数のボックスに分割する必要があります。

すべての検索クエリにフィルターを追加する必要がありますか？

いいえ、ただし、クエリを正しいホストに送信する必要があります（おそらくマッピングDBが役立ちます）

クライアントがキャンセルした場合、どのように（の一部）インデックスを削除しますか？ （これは些細なことかもしれません - まだ確かではありません）

クライアントごとに異なるコアを使用すると、これは非常に簡単です。

メールによる彼の返信：

私は過去に同様のユースケースに取り組んでおり、solr側にいくつかの重い最適化を伴うマルチコアアプローチを使用しました。見る http://wiki.apache.org/solr/lotsofcores - 私はこれらの変更をまだSOLRに押し込むことができませんでした。

Answer 3

5Kデータベースから正確に検索しているもの、Luceneが必要な理由、および各データベースのデータサイズについては、まだ不明です。しかし、私はとにかく強打します：

1. マルチコアSOLR（各Core = 1インデックス）を調べる必要があり、クエリする一意のURLがあります。認証は依然として問題であり、アプローチする1つの（ハッキッシュ）方法は、URLを推測しにくくすることです。

2. Webサーバーは、アクセスできるものに応じてSolrインスタンス/コアを照会できます。

フィルターアプローチから離れ、すべてのデータベースを組み合わせた1つの巨大なインデックスを作成することをお勧めします。

Hth