私は 1 日を終えた 2 日当たりの良いニーダムで学習の高速の, MA, アイデアをあふれています (私にはそのすべての良いトレーニング クラス). まだ新鮮な通常の日常的な」ものであった、それを書き留めたいし、の 1 つの特定の側面を高速、私に考えること" 私の頭にそれをプッシュ.
我々 SharePoint WSS 3.0 / MOSS 実装者頻繁にあらゆる適度なサイズの SharePoint プロジェクトとタフな問題に直面します。: どのように我々 は完璧にデザインされた情報アーキテクチャ内に収まるように、SharePoint に読み込まれるすべてのタグなしデータを取得するには?
十分な頻度, トラブルのうち自分自身を範囲このような難しい問題にはなりません: "については何も気にしない以上 3 ヶ月。" 「処理するので、キーワード検索ですべてのその古いものと行く前方やるよ右の方法…" など.
しかし, トラブルの範囲自分自身できないし、何千もの 10年または 100 の何千もを見ている場合はどう (または数百万も) ドキュメントの — 読み込み と 敬虔な願いであるのタグ付け?
高速答えであるかもしれない.
FAST の検索処理に多く可動部品にはが含まれていますが 1 つの簡略化されたビューはこれ:
- コンテンツを検索クローラー プロセス.
- コンテンツを検索し、ドキュメント プロセッサのプールを管理するブローカー プロセスに渡し、.
- ブローカー プロセスに渡し、いずれかのドキュメント プロセッサ.
- ドキュメント プロセッサは、ドキュメントを分析して、パイプライン プロセスを介して, ドキュメント bejeezus を分析し、インデックス ビルダー型プロセスに渡し、.
高速宇宙船に, 我々 はドキュメント処理パイプラインを制御の多くを持っています。. ミックスし、一致について 100 パイプライン コンポーネントと, 最も興味深いは, 我々 は、独自のコンポーネントを書くことができます。. 私が言うよう, 高速は文書を分析してあらゆる方法が、日曜日とそれらのドキュメントに関する有用な情報の多くをコンパイル. 狂気の高速人と、明らかに非常識とドキュメントの分析についての強迫観念があるツールや本当にドキュメントを分類するための戦略.
だから … 独自のカスタム パイプライン コンポーネントとの組み合わせで高速を使用してください。, 高速からすべてのコンテキスト情報を取得し、それをコケにフィード. それはこのような何かを行くかもしれない:
- モスから高速にドキュメントが供給され.
- 通常の狂った強迫高速ドキュメントの解析と分類が起こる.
- カスタム パイプライン コンポーネント データベースにオフにそのコンテキスト情報の一部を削除します。.
- 当社独自の設計プロセスは、コンテキスト情報を読み取ります, 私たち IA 内 MOSS ドキュメントに適合する方法についていくつかの決定になり、web サービスとオブジェクト モデルを使用してマーク.
もちろんです, そのような自動化されたプロセスは完璧ですが、強迫のおかげですることができます。 (おそらく insane-but-in-a-good-way の高速人), 我々 はほとんど検索可能なドキュメントの束を持つ SQL データベースがいっぱいにだけよりも真に効果的な質量負荷プロセスでのショットの戦い現実があります。.
</終了>
