0

私は、ユーザーがファイルのコンテンツをオンラインですばやく検索できるようにしたいと考えている小さなオンラインドキュメント管理会社のWebスクリプトを書いています。多くのアカウントは非常に小さいですが（100個の2MBファイル未満）、1,000,000ファイル以上のアカウントがいくつかあります。PDFおよびDOC/DOCXのサポートが必要です。バイナリファイルはインデックスに登録されません。

基本的な検索結果を提供するシンプルなソリューションを探しています。派手すぎるものはありません。各ユーザーにはホームフォルダがあります（検索ではサブフォルダのみが検索されます）。そのため、検索システムが最適である必要があることに注意してください。たとえば、100 MBのアカウントを持つユーザーがホームフォルダを検索すると、次のようになります。他の4TBのファイルを検索しないように意味します。

何を指示してるんですか？

これが私が見ていたいくつかのオプションです：

1）このためにWindows Searchを使用することを考えていました-コマンドラインツールまたはAPIを使用します。しかし、各サーバーは文字通り10億のファイルを持つことができ、上位3つの結果を即座に配信する必要があります。Windows Searchは機能しますか？それとも、これは欲求不満をもたらしますか？

2）カスタム：インデックス情報を保持するための単純なオープンソースのMySQLデータベースプログラムを作成します。英語には約100,000の単語があります...次に、カスタムの単語と頭字語があります。したがって、高速検索を行うには、単語とユーザーアカウントに基づいてインデックスを作成するのが理にかなっています。DBサイズを小さくするために、「ジョギング」が「ジョギング」、「フィドル」が「フィドル」になるように前処理します。 サーバーごとに150の顧客アカウントがある場合、1つの大きなDBを使用するのは理にかなっていますか、それともUserIDフィールドを削除して各ユーザーにDBを提供するのが理にかなっていますか？

Tables:
Table WorldTable
EnglishWord (pk) | WordID (fk)

Table FileTable
FileID (pk) | FilePath

Table WordIndex
WordID (pk) | FileID (fk) | UserID | SettingsPatternID

Table Settings
SettingsPatternID | Top (bool) | IsWordForm (bool)

IsWordForm =完全一致ではなく、単語の形式であることを示します。例：ファイル内の単語は、元々ドキュメント内で「ジョギング」または「ダンス」でしたが、「ジョギング」または「ダンス」という短い形式でファイルされています。（クエリがワードフォームでもあった場合は、関連性に役立ちます。）IsWordFormの可能性は高いです。トップ=単語はドキュメントのトップ50ワードにあります（タイトルを示します）

5〜15％の小さなストレージオーバーヘッドが欲しいのですが。CPUは非常に貴重です...しかし、各ファイルはWordIndexに数千のレコードを生成するため、ファイルごとに多くのオーバーヘッドが発生します。つまり、

WordID, FileID, UserID, SettingsPatternID
WordID, FileID, UserID, SettingsPatternID
WordID, FileID, UserID, SettingsPatternID

...これは最長のテーブルであり、WordIDは不必要に繰り返されます。

3）MySQLを使用したハッシュ単語の検索になることがわかっているため、純粋なリレーショナルデータベースは最適なモデルではない可能性があります...

一致するファイルのリストに各単語を「ハッシュ」する方が効率的かもしれません。例：単語ごとに、2列のテーブルを作成します。私たちはそれが何であるかを知っているので、あなたはテーブルの中で単語を「調べる」必要はありません。このリストは、単語ごとに2列のテーブルにすることができます。

Table *The Word*
FileID | UserID | SettingsPatternID
(There would be 100,000 of these. One for each unique word.)

Table Settings
SettingsPatternID | Top (bool) | IsWordForm (bool)

4）SolRも調べましたが、やり過ぎだと思います。それは悪い仮定ですか？PDFとDOCをサポートしていますが、統合するのもかなりの作業です...自分でそれを行うのはほぼ同じ量の作業になると思いますが、もちろん、コーダーとして、仮定が間違っていることがよくあります。 。

考えてください!!!

4

1 に答える 1

2

4）SolRも調べましたが、やり過ぎだと思います。それは悪い仮定ですか？PDFとDOCをサポートしていますが、統合するのもかなりの作業です...自分でそれを行うのはほぼ同じ量の作業になると思いますが、もちろん、コーダーとして、仮定が間違っていることがよくあります。 。

間違いなくSolRを使用してください。統合にはコストがかかりますが、セットアップと保守がはるかに簡単になります。

さらに、それ以外の場合は自分で実装（およびデバッグ、保守...）する必要のある機能の多くがすでに含まれています。

ただし、SolRの機能を確認し、それらの機能を中心に基本的なインターフェースを設計し、書面で承認してもらうことをお勧めします。「テキスト検索」は、「システムに自分の心を読み取れるようにしたい」という言葉になりすぎることがよくあります。また、効率的なテキスト検索は「単純なスクリプト」ではないことを説明します。文字通り何千もの博士号があります。セマンティクス、ステミング、関連性、近接性などを含む論文。それらの論文の多くは、SolR/Luceneへの道を見つけました。

ユーザーがパフォーマンス面、スケーラビリティ面、および結果面の両方で満足する可能性があると想定した場合、SolRは「やり過ぎ」です。grep私を信じてください、彼らはそうしません。

Googleマシンを提案してみてください。また、コストに関連するベースラインを確立するのにも役立ちます。つまり、「Googleのパフォーマンスが必要な場合、これはGoogleの価格です。Googleの規模の経済がない他のアドホックな実装では、同じレベルのパフォーマンスを達成するためにはるかに多くのコストがかかります」。

于 2012-10-19T09:48:32.223 に答える