난 하루를 마쳤다 2 써니 Needham에 빠른 훈련, MA, 그리고 아이디어와 붕괴 야 (나는 모든 좋은 훈련 수업). 하나의 특정 측면의 빠른 날 생각을 했다 내가 하 고 싶 었 동안 그것은 아직도 신선 하 고 정상적인 나날 "물건 적어" 내 머리를 밖으로 밀어.
우리 SharePoint WSS 3.0 / 모스 구현자 자주 어떤 합리적인 크기의 SharePoint 프로젝트와 어려운 문제에 직면: 그런 모든 우리의 완벽 하 게 설계 된 정보 아키텍처 내에서 맞는 SharePoint에 로드 된 모든 태그 데이터 어떻게 받을 수 있나요?
만큼 자주, 우리 자신을 문제의 범위 때문에이 같은 어려운 문제가 되지 않습니다.: "우리는 아무것도 걱정 하지 않는 이상 3 개월 오래 된입니다." "우리 키워드 검색으로 모든 물건을 처리할 거 고가 앞으로 우리가 할 거 야 그것은 올바른 방법으로…" 등.
하지만, 우리 자신을 문제의 범위 수 없습니다 그리고 우리는 수천의 10 또는 수천의 100 보고 하면 어떻게 됩니까 (또는 심지어 수백만) 워드 프로세서의 — 로드 그리고 우리의 경건한 소원의 태그?
빠른 답이 될 수 있습니다..
FAST의 검색 프로세스가 포함 되어 움직이는 부품을 많이 하지만 한 단순화 된 보기가:
- 크롤러 프로세스 콘텐츠 찾습니다..
- 그것은 콘텐츠를 찾아서 문서 프로세서의 풀을 관리 하는 브로커 프로세스를 떨어져 손.
- 브로커 프로세스 문서 프로세서 중 하나에 떨어져 손.
- 문서 프로세서는 문서를 분석 하 고 파이프라인 과정을 통해, 문서에서 bejeezus를 분석 하 고 인덱스 작성기 형식 과정 떨어져 손.
빠른 우주선에, 우리는 많은 처리 파이프라인 문서 제어. 우리는 대 한 일치와 혼합 수 있습니다. 100 파이프라인 구성 요소 및, 대부분 흥미롭게도, 우리는 우리 자신의 구성 요소를 작성할 수 있습니다.. 내가 말한 것 처럼, 어떤 방법은 모든 하지만 일요일 빠른 문서 분석은 고 그것은 그 문서에 대 한 유용한 정보를 많이. 그 미친 빠른 사람들은 명확 하 게 미친 고 문서 분석에 대 한 강 박 도구 또는 정말 문서를 분류 하는 전략을가지고 있기 때문에.
그래서 … 빨리 우리 자신의 사용자 지정 파이프라인 구성 요소와 조합 하 여 사용, 우리 빨리에서 모든 컨텍스트 정보를 들고 수 있으며 이끼 다시 피드. 그것은 이것 같은 것을 갈 수도 있습니다.:
- 문서 모스에서 빨리에 공급.
- 일어나는 정상적인 미친 강 박 빠른 문서 구문 분석 및 분류.
- 우리 자신의 사용자 지정 파이프라인 구성 요소는 데이터베이스에 해당 컨텍스트 정보 중 일부 드랍 스.
- 우리의 자신의 디자인의 프로세스 컨텍스트 정보를 읽으십시오, 우리의 IA에서 MOSS 문서에 맞게 하는 방법에 몇 가지 결정 하 게 하 고 웹 서비스와 개체 모델을 사용 하 여 표시.
물론, 완벽 하지만 강 박 덕분에 그런 자동화 프로세스 수 있습니다. (아마도 insane-but-in-a-good-way 빠른 사람), 우리 진짜 더 보다는 다만 간신히 검색 가능한 문서 잔뜩 있는 SQL 데이터베이스를 채우지 진정으로 효과적인 대량 로드 프로세스에서 총 싸움을 할 수 있습니다..
</끝>
