მე დავამთავრე up დღეში 2 სწრაფი ტრენინგი მზიანი Needham, სამაგისტრო, და მე bursting ერთად იდეები (რომელშიც ყველა კარგი სასწავლო კლასების გაკეთება ჩემთვის). One particular aspect of FAST has me thinking and I wanted to write it down while it was still fresh and normal day-to-day "stuff" მივიღებთ ის ჩემი უფროსი.

ჩვენ SharePoint WSS 3.0 / MOSS განმახორციელებელი ხშირად წინაშე მკაცრი პრობლემა ნებისმიერი გონივრულად ზომის SharePoint პროექტი: როგორ უნდა მიიღონ ყველა untagged მონაცემები ჩაიტვირთება SharePoint ისეთი, რომ ეს ყველაფერი ჯდება ჩვენს კარგად შემუშავებული ინფორმაციის არქიტექტურის?

საკმაოდ ხშირად, ეს არ არის ისეთი რთული პრობლემა, რადგან ჩვენ ფარგლებს საკუთარ თავს out of trouble: "We don’t care about anything more than 3 months old." "We’ll handle all that old stuff with keyword search and going-forward we’ll do it the RIGHT way…" Etc.

მაგრამ, what happens if we can’t scope ourselves out of trouble and we’re looking at 10’s of thousands or 100’s of thousands (ან თუნდაც მილიონობით) საქართველოს Docs — დატვირთვა და ჭდეებისთვის რომლის ჩვენი devout სურვილი?

სწრაფი შეიძლება იყოს პასუხი.

სწრაფი ის საძიებო პროცესი მოიცავს უამრავ მოძრავი ნაწილები, მაგრამ ერთი გამარტივებული შეხედულება ამ:

• Crawler პროცესი ეძებს შინაარსი.
• იგი მიიჩნევს, შინაარსი და ხელში off to საბროკერო პროცესი, რომელიც მართავს აუზი დოკუმენტი პროცესორები.
• საბროკერო პროცესი ხელში off ერთ დოკუმენტში პროცესორები.
• დოკუმენტის პროცესორი აანალიზებს დოკუმენტი და მეშვეობით მილსადენის პროცესი, აანალიზებს bejeezus გარეთ დოკუმენტი და ხელში off to ინდექსი მშენებელი ტიპის პროცესი.

On starship FAST, we have a lot of control over the document processing pipeline. We can mix and match about 100 მილსადენის კომპონენტები და, ყველაზე საინტერესოა, we can write our own components. Like I say, FAST is analyzing documents every which way but Sunday and it compiles a lot of useful information about those documents. Those crazy FAST people are clearly insane and obsessive about document analysis because they have tools and/or strategies to REALLY categorize documents.

ასე რომ, … გამოყენებით სწრაფი ერთად ჩვენი საკუთარი მილსადენის კომპონენტი, we can grab all that context information from FAST and feed it back to MOSS. It might go something like this:

• დოკუმენტი, რომელიც იკვებება შევიდა სწრაფი from MOSS.
• ნორმალური crazy-obsessive სწრაფი დოკუმენტი დამუშავების და კატეგორიზაციის ხდება.
• ჩვენი საკუთარი მილსადენის კომპონენტი მცირდება ზოგიერთი კონტექსტში ინფორმაციის off to მონაცემთა ბაზა.
• პროცესში საკუთარი დიზაინი ნათქვამია კონტექსტში ინფორმაცია, აკეთებს რაღაც გადაწყვეტილება, თუ როგორ უნდა მოერგოს რომ MOSS დოკუმენტის ჩვენს ია და აღნიშნავს ის გამოყენებით ვებ სერვისი და ობიექტური მოდელის.

რა თქმა უნდა, ასეთი ავტომატიზირებული პროცესი შეიძლება იყოს სრულყოფილი რომ არა obsessive (და შესაძლოა გიჟური, მაგრამ, in-, კარგი გზა სწრაფი ადამიანი), ჩვენ შეიძლება ჰქონდეს რეალური საბრძოლო ესროლეს მართლაც ეფექტური მასის დატვირთვის პროცესი, რომელიც არ მეტი, ვიდრე უბრალოდ შეავსოთ SQL მონაცემთა ბაზა რამოდენიმე ძლივს-საძიებო დოკუმენტები.

</ბოლო>

გამოწერა ჩემი დღიური.