私はスカンジナビアのイエローページで働いています。同社は、独自の検索技術を FAST ESP に移行することを検討しています。
インストール数が比較的少ない大規模で高価なシステムと同様に、システムの長所と短所に関するフィードバックを得ることは困難です。
FAST ESP の経験があり、共有したいスタックオーバーフラワーはいますか?
8841 次
14 に答える
15
:)私は、Lycosソフトウェアエンジニアとしての日々から、1997年から検索エンジンテクノロジーを開発および統合している検索アーキテクトです。
http://thomasnet.comを強化する検索エンジンとしてFASTESPを使用しています。私は2003年からESP（当時はFDS 3.2として知られていました）を使用しています。
FAST ESPは非常に柔軟性があり、多くのドキュメントタイプ（html、pdf、wordなど）のインデックス作成に対応できます。Webドキュメント用の非常に堅牢なクローラーがあり、中間のFastXML形式を使用して、カスタムドキュメント形式をシステムにロードしたり、コンテンツAPIを使用したりできます。
エンジンの私のお気に入りの部分の1つは、ドキュメント処理パイプラインです。これを使用すると、すぐに使用できる数十の処理プラグインを利用できるだけでなく、PythonAPIを使用して独自のカスタムドキュメント処理ステージを作成できます。私たちが作成したカスタムステージの例は、WebサイトのURLを調べて、それが属する会社を識別し、追加のメタデータをWebドキュメントに添付できるようにするステージです。
コンテンツの追加とクエリの実行、システムステータスの取得とクラスターサービスの管理のために、いくつかの一般的な言語（C ++ / C＃/ Java）で非常に堅牢なプログラミング/統合SDKを備えています。
ESPにはFASTQueryLanguage（FQL）と呼ばれるクエリ言語があり、非常に堅牢で、基本的なブール検索（AND、OR、NOT）だけでなく、フレーズや用語の近接検索も実行できます。それに加えて、ドキュメントごとに異なる形式のドキュメントメタデータ（XML）を検索するために使用できる「スコープ検索」と呼ばれるものがあります。
パフォーマンスに関しては、かなり直線的にスケーリングします。ベンチマークを行って1台のマシンでのパフォーマンスを判断する場合、別のマシンを追加すると、通常、パフォーマンスが2倍になる可能性があります。システムは、1台のマシン（開発用のみ）または多数（本番用）で実行できます。フォールトトレラントであり（負荷分散されたインデックスの1つがオフラインになった場合でも、いくつかの結果を提供できます）、完全なフェイルオーバーサポートがあります（1つ以上の重要なマシンが停止するか、メンテナンスのためにオフラインになる可能性があり、システムは続行されます正しく機能するために）
だから、その非常に強力です。最近のドキュメントはかなり良いです。それで、あなたは尋ねます、欠点は何ですか？
さて、検索可能にする必要のあるデータの形式が頻繁に変更される場合、それは苦痛かもしれません。ESPには「インデックスプロファイル」と呼ばれるものがあります。これは基本的に、どのドキュメントフィールドが重要であり、インデックス作成に使用する必要があるかを判断するために使用する構成ファイルです。ESPにフィードされるものはすべて、データベーステーブルの行をロードする場合でも「ドキュメント」です。各ドキュメントにはいくつかのフィールドがあり、一般的なフィールドは、タイトル、本文、キーワード、ヘッダー、ドキュメントベクトル、処理時間などです。独自のカスタムフィールドをいくつでも指定できます。
コンテンツが（Webドキュメントのように）ほとんど同じ形式を維持している場合、それは大きな問題ではありません。ただし、インデックスを作成するフィールドとその処理方法を大幅に変更する必要がある場合は、インデックスプロファイルを編集する必要があります。インデックスプロファイルへのいくつかの変更は「ホットアップデート」です。つまり、サービスを中断することなく変更を加えることができます。ただし、大きな変更のいくつかは「コールドアップデート」であり、変更を有効にする前に完全なデータの再フィードとインデックス作成が必要です。データセットのサイズとクラスター内のマシンの数によっては、この操作に数時間または数日かかる場合があります。コールドアップデートは、本番システムがコールドアップデートを実行してデータをリロードしている間にオンラインにすることができる追加のハードウェアに十分な資金がない限り、スケジュールするのが面倒です。
あなたの場合、あなたのデータフォーマットが非常に頻繁に変わるとは思えません。微調整が必要な場合は、スコープフィールドにメタデータを追加して、データの完全な再読み込みを行う必要性を回避できます。
おそらく遭遇する問題のほとんどは、製品を使用するための最初の学習曲線です。開発クラスター（またはノード）に必要な処理を実行させ、インデックス付きフィールド構成を頻繁に大幅に変更する必要がない場合は、非常に安定した信頼性の高い検索エンジンを使用できます。あなたのアプリケーションにとって、それは良い一致のように聞こえます。中小企業やスタートアップにとっては、それほど高価ではないオープンソースのオプションがあり、それほど多くのパフォーマンスや耐久性を必要としない場合は十分です。
この評価がお役に立てば幸いです。:)
よろしくお願いいたします。MichaelMcIntoshシニアサーチアーキテクト@TnRGlobal
于 2009-02-10T04:02:42.713 に答える
4
2008 年から 2009 年にかけて、私はロシアのイエロー ページ (yell.ru) で「検索エンジン エンジニア」として働いていました。私の主な担当は、FAST ESP システムを扱うことでした。私は、特定のデータ処理用のカスタム ドキュメント プロセッサ (カスタム ステージ) と、データ プッシュ パイプライン用の "接着剤" コードを作成して維持しています。FAST ESPに関して。私はそれについて「複雑な」感じを持っていました。ここにいくつかの欠点があります。
高価な製品です。1回限りの初期支払いとは別に、年間（および注目に値する）ライセンス料を支払う必要があります。そうしないと、サーバーが機能しなくなります. 私たちの過ちは、非常に限られた「1 秒あたりの最大要求」レート (1 秒あたり最大 10 クエリ) を持つ (比較的) 低コストのライセンスを取得したことです。これは単なる「業務上の制限」であると何度か言われましたが、実際には、サーバーのピーク スループットのハードな技術的制限でした。このピーク制限によりパフォーマンスが台無しになり、一時的な「評価」ライセンスに戻りました (驚いたことに!) パフォーマンスの制限はありません (期間の制限のみ)。
ドキュメンテーションは優れていますが、技術的な詳細についてはあまり詳しくありません。ドキュメントを読んだだけでは本当にトリッキーなことはできません。詳細はここでは簡単ではありません。顧客が行うことを意図していないため、「ソリューション部門」に連絡する（および「ソリューション」を購入する）必要があると言われたら。
一部の部分は驚くほどトリッキーでバグがあります。いくつかの例: カスタム辞書を配置する際に、英語以外の記号に関するいくつかの問題があります。カスタム ブースト値を含む一連のフレーズをシステムにロードすると、システムが遅くなり、応答しなくなることがありました。
奇妙な技術的限界があちこちにあります。たとえば、検索可能なフィールドに割り当てられるブースト値は 8 つだけです。
概して、サイトの基本的な検索エンジンとして FAST ESP を使用することで、ユーザーのニーズに対応するのに苦労しました。最後に、システムは別の (オープン ソース) ソリューションに置き換えられ、私は解雇されました ;-) 話の終わり。
于 2010-09-07T10:09:00.430 に答える
1
FAST ESPテクノロジーは確かなものですが、これは実際には検索プラットフォーム（したがって、「ESP」）であり、すぐに使用できる検索エクスペリエンスではないことを覚えておいてください。結果の品質は、インデックスの品質に直接関係します。つまり、コンテンツのドキュメント処理パイプラインとインデックスプロファイルを実際に調整する必要があります。
これには厳格なルールはありません。あなたは本当にプラットフォームとあなたのコンテンツを理解する必要があります。時間と試行錯誤が必要です。また、リソースを大量に消費するため、ハードウェアを無駄にすることはできません。それを正しく行うための時間とリソースがあれば、それはうまく機能しますが、中途半端な仕事は、箱から出してすぐに使えるものやLuceneよりも良くはありません（そしておそらく悪くなります）。
于 2009-02-12T19:33:24.307 に答える
1
私はここ数年、FASTESPをサポートしてきました。全体的に4/5。
これまでの私の経験では、FAST ESPプラットフォームは堅実ですが、さまざまなコネクタにはいくつかの癖があります。
Lotus Notesコネクタは特に貧弱であり、100,000を超えるドキュメントがインデックスに登録されると定期的に機能しなくなります。
ファイルのNTFSアクセス許可が更新されたときに、ファイルトラバーサーがドキュメントの更新を反映しないなど、他の癖はかなり大きなものになる可能性があります。これは、誰もが見ることができないはずのドキュメントを見ることができることを意味します–悪いセキュリティ問題。
ここに他の人の感情を反映します。FASTESPは非常に優れていますが、それは確かに「すぐに使える」ソリューションではありません。実装には3〜12か月の投資が必要ですが、非常に強力なエンジンで報われるでしょう。
于 2009-08-24T03:32:03.820 に答える
1
@Michael McIntosh: コールド アップデートを回避するために、一般的なフィールドをインデックスに追加できます。たとえば、5 つの汎用整数、5 つの文字列、および 5 つの日付を追加します。突然新しい整数を導入する必要がある場合は、igeneric1 など、既にある「パディング」を使用できます。
しばらくして、コールド アップデートを実行したい場合は、これらのフィールドを統合して適切な名前を付けます。
于 2009-07-08T11:15:21.163 に答える
1
filetraverserがACLの変更を取得しないことについて、以前の回答にコメントするだけです（回答に直接返信するのに十分な評判がありません）：
aclplugin を有効にすることで、ファイル トラバーサーにファイル アクセス許可の変更を取得させることができます。
filetraverser -c <collection> -r <dir> -M -E -J $FASTSEARCH/etc/filetraverser/aclplugin.xml
私たちが見つけた唯一の厄介なことは、一度に 1 つのプラグインしか使用できないことです。そのため、acl プラグインと lazy プラグインの両方をネイティブに使用することはできません。ただし、両方を呼び出すカスタムプラグインを作成することで、これを解決しました。
于 2012-06-21T08:17:15.643 に答える
1
私たちは多数の FAST ESP アプリケーションを実装してきましたが、比較的高い実装コストを前もって投資する限り、ESP は常に非常に安定した高性能プラットフォームであることが証明されています。イエローページの質問に関しては、ESP を使用して米国最大のオンライン ディレクトリ サイトを実装および管理しており、膨大な QPS (1 秒あたりのクエリ数) を処理しています。他の人が述べたように、主要な代替技術である Google、Solr/Lucene なども非常に有能であり、選択は技術/ユーザーの要件と予算に大きく依存します。
于 2010-04-01T13:02:56.887 に答える
0
FASTESPは良いです。少なくともGoogle検索アプライアンスと比較した場合。しかし、どのエンタープライズ検索エンジンを選択するかは、完全に要件次第です。
于 2009-04-30T22:50:12.527 に答える
0
FAST ESP 以外には、Autonomy の IDOL プラットフォーム (AFAIK) と Apache Solr の 2 つのオプションしかありません。
于 2011-06-03T22:35:06.140 に答える
0
私は、いくつかの企業イントラネット サイト (大企業) に FAST ESP を実装しようとしています。私は検索技術 (90 年代後半の Verity) を少し扱ったことがあります。
幸いなことに、実際に始める前に FAST ESP 開発者コースを受講しました。コースはとても簡単で、簡単に勉強できる人なら、おそらくオンライン クラスを受講するだけで十分です。私にとってこれらの最大の利点は、プロジェクトが開始される前に API に関する注意を喚起できることでした。API を使用したいくつかのプログラミング ラボをざっと見てみると、かなり多くのコードを作成する必要があることに気付きました。
私は主に API に失望しています。FAST ESP は MS によって 1 年も経たないうちに購入されたばかりなので、.NET API のクリーンアップに役立つことを願っています。.NET API は、誰かがボタンをクリックして、ネイティブ Java サーブレットとのインターフェイスとなる COM ラッパーを作成したようなものです。API の命名規則とメソッドは、理解するのに十分簡単です (すべての FAST ESP コレクション/配列が 0 ベースではなく 1 ベースであることを覚えている限り)。しかし、私は彼らがここで多くの仕事をすることができると信じています. Java API は、私がこれまでに見たり使用したりした他のすべての Java API とほとんど同じように見えました。おそらく、FAST ESP は Java ベースの検索エンジンであり、その開発者は .NET ソフトウェア エンジニアではなく Java ソフトウェア エンジニアであるため、命名規則と構造は標準の Java API のように見えます。
最初は、ASP.NET を使用していたので、MS SharePoint Web コントロールの機能を模倣する一連の Web コントロールを開発しました。クラスルームとすべての ASP.NET の例では、すべてがインライン ASP.NET コーディングであり、「コード ビハインド」コーディングはまったく、またはほとんどありませんでした。ヤフー！Developer Network には、検索インターフェイス、結果、ページャーなどを設計するための優れた設計パターンがいくつかあります。
全体として、これまでのところ、かなりうまく機能しています。私たちはまだ開発段階にあり、今後数週間以内にサイトのベータ テストを開始する予定です。FQL (Fast Query Language) は少し複雑すぎます。ユーザーは、言語が十分に「Google に似ていない」と不満を言うでしょう。FQL pdf ファイルを検索すると、その言語をプレビューできます。単純な検索 (すべての用語、任意の用語など) を使用することもできます。
何か具体的に知りたいことがあれば、聞いてください。情報を入手しようとします。VM 環境で FAST ESP を使用しています。これはサポートされていないと彼らは言いますが、問題なく動作し、ベンチマークの結果も問題ありません。
于 2009-03-05T23:58:34.127 に答える
0
高度なドキュメント処理プラグインの作成に関する資料はありますか? たとえば、コンテンツからカスタム情報を抽出しますか? Python で行われていると聞いたことがありますが、実際にそれを行う方法を学ぶための資料はないようです。
于 2010-09-21T15:13:12.183 に答える
0
@anand: .NET Content API のいずれかを選択するか、HTTP/XML を介してすべてを行い、必要に応じて XML のスタイルを設定できます。
于 2009-07-08T11:10:57.630 に答える
0
@anand、FAST ESP .NET API を使用できます。インストールには、PDF ドキュメント、サンプル コード、および API リファレンス マテリアルがあります。
于 2009-06-02T20:53:25.217 に答える