Recently, my company's got the task to help the client to resolve some if its issues with Search in their environment. So, my aim here is to describe that problems and propose solutions I applied. In the some next articles I will descibe how to:
Previous versions of Microsoft Windows Sharepoint Services relied on Microsoft SQL Server full-text searching, WSS 3.0 uses the same Sharepoint search technology used by Enterprise Search in Microsoft Office Sharepoint Server 2007, but with some noted differences (I will decribe them in the next article "WSS 3.0 + SSE = Flexible Search for FREE)
The following picture provides a detailed view of the Search Service internal architecture:
Following are the components of the Search service's architecture.
- make search by PDF files;
- search content in any Web Application being in one site collection;
- make custom search scopes;
- be able to search using "This site" search scope.
Previous versions of Microsoft Windows Sharepoint Services relied on Microsoft SQL Server full-text searching, WSS 3.0 uses the same Sharepoint search technology used by Enterprise Search in Microsoft Office Sharepoint Server 2007, but with some noted differences (I will decribe them in the next article "WSS 3.0 + SSE = Flexible Search for FREE)
The following picture provides a detailed view of the Search Service internal architecture:
Following are the components of the Search service's architecture.
- Index Engine Processes the chunks of text and properties filtered from content sources, storing them in the content index and property store.
- Query Engine Executes keyword and SQL syntax queries against the content index and search configuration data.
- Protocol Handlers Opens content sources in their native protocols and exposes documents and other items to be filtered.
- iFilters Opens documents and other content source items in their native formats and filters into chunks of text and properties.
- Content Index Stores information about words and their location in a content item.
- Property Store Stores a table of properties and associated values.
- Search Configuration Data Stores information used by the Search service, including crawl configuration, property schema, scopes, and so on.
- Wordbreakers Used by the query and index engines to break compound words and phrases into individual words or tokens.
Content crawling, Indexing, Protocol Handlers, iFilters and Wordbreaker
Most of the capabilities for Search are configured automatically during installation.
One content source is automatically created for all user content Web applications. No administration details are exposed to site administrators. When a new site is created, the site's URL is added to the start addresses for the content source.
One content source is automatically created for the Central Administration Web application.
Full crawls occur as specified in the Administrator-controlled crawl schedule on the Central Administration configuration page.
The index engine uses a pipe of shared memory to request that the Filter Daemon begin filtering the content source. For the crawl process to succeed, the content source must have an associated protocol handler that can read its protocol. The Filter Daemon invokes the appropriate protocol handler for the content source based on the start address provided by the index engine. The Filter Daemon uses protocol handlers and iIndFilters to extract and filter individual items from the content source. Appropriate iFilters for each document are applied, and the Filter Daemon passes the extracted text and metadata to the index engine through the pipe.
At this point in the content crawling process, the index engine saves document properties to a property store that is separate from the content index. The property store consists of a table of properties and their values. Properties in this store can be retrieved and sorted. In addition, simple queries against properties are supported by the store. Each row in the table corresponds to a separate document in the full-text index. The actual text of a content item is stored in the content index, so it can be used for content queries. The property store also maintains and enforces document-level security that is gathered when a document is crawled.
At this point, the index engine uses wordbreakers to further process the text and properties picked up during the crawl. The wordbreaker component is used to break the text into words and phrases. The index engine also removes noise words and creates an inverted index for full-text searching.
Search Query Execution
When a search query is executed, the Query engine passes the query through a language-specific word-breaker. If there is no word-breaker for the query language, the neutral word-breaker is used, which performs white space-style word-breaking that breaks words and phrases where there are white spaces.
After word-breaking, the resulting words are passed through a stemmer to generate language-specific inflected forms of a given word. The use of word-breaker and stemmer in both the crawling and query processes enhances the effectiveness of search because more relevant alternatives to a user's query phrasing are generated. When the Query engine executes a property value query, the index is checked first to get a list of possible matches.
The properties for the matching documents are loaded from the property store, and the properties in the query are checked again to ensure that there was a match. The result of the query is a list of all matching results, ordered according to their relevance to the query words. If the user does not have permission to view a matching document, the Query engine filters that document out of the list that is returned.
Customizing Windows Sharepoint Services Search (for developers)
Query object model
Windows SharePoint Services 3.0 includes a Microsoft.SharePoint.Search.Query object model that you can use in custom search Web Parts and search applications to execute queries against the Search in Windows SharePoint Services service. For more information, see Windows SharePoint Services Search Query Object Model.
Query Web Service
Windows SharePoint Services 3.0 exposes its search functionalities through a Web service. This allows you to access Search results from client applications and Web applications outside of the context of the SharePoint site.
To access the Search Query Web service and its methods, set a Web reference to the following:
http://Server_Name/[Site_Name/]_vti_bin/spsearch.asmx
For more information, see Windows SharePoint Services Query Web Service.
Query Syntax
Search in Windows SharePoint Services supports three types of search syntax for building search queries:
- Windows SharePoint Services Search Keyword Syntax (search terms are passed directly to the Search service)
- Windows SharePoint Services Search SQL Syntax (extension of SQL syntax for querying databases)
- Windows SharePoint Services Search URL Syntax (search parameters are encoded in the URL, and posted directly to the search page).
Summing up all above:
WSS 3.0 uses Enterprise Search architecture in Microsoft Office Sharepoint Server 2007;
Search Sequence: Content is Crawled [certain Protocol Handlers and iFilters are used to succeed search process] -> Indexed [sndex engine saves documents properties to a property store that is separate from the content index] -> Wordbraker brakes the text into the words and phrases + Noise words are removed -> Index engine creates an inverted index for full-text searching;
Query Sequence: Query engine passes the query through a wordbraker -> Resulting words are passed through a stemmer -> Index is checked first to get a list of possible matches + Properties are loaded from the property store and checked if the match.
Order of results: Results are ordered according to words' relevance to the query words. Query engine filters out those documents / items which the user doesn't have permission for.
BIG thanks to:
No comments:
Post a Comment