MCT USE ONLY. STUDENT USE PROHIBITED Designing an Enterprise Search Strategy 9-39 Index Data FAST search stores the index on index servers and query servers. The index includes metadata in addition to standard item references. The following formula estimates the index data storage requirements: TotalIndexSize = CorpusSize × 0.14 This estimates the total index. To calculate the storage requirements for each query server, you must know the number of index columns that you require. From a capacity perspective, an index column should hold no more than 15 million items in the default configuration. FAST search automatically divides the index evenly between all index columns. You can calculate the storage requirement for a single index column by using the following formula: IndexColumnSize = TotalIndexSize ÷ NumberOfColumns For each index and query server, you must also allow additional disk space for index updates and index rebuilds. To calculate disk requirements, use the following formula for each query server: IndexStorage = QueryComponentSize × 2.5 × NumberOfQueryComponents Additional Index Data In addition, FAST search requires some additional data storage for elements such as a Web analyzer and log data. The following formula estimates the additional data storage requirements: AdditionalData = CorpusSize × 0.005 Note: FAST search does not include People Search data, so the estimates that are provided do not include People Search data. You must configure SharePoint search to provide the People Search component when required. Additional Reading For more information about capacity sizing for search, see the “Disk Usage” section in the white paper called FAST Search Server 2010 for SharePoint Capacity Planning (FASTSearchSharePoint2010CapacityPlanningDoc.docx) at http://go.microsoft.com/fwlink/?LinkID=200898&clcid=0x409. MCT USE ONLY. STUDENT USE PROHIBITED 9-40 Designing a Microsoft® SharePoint® 2010 Infrastructure Lesson 4 Mapping Business Requirements to Search Design After you have identified how you can build SSAs into a SharePoint farm and established performance guidelines for search, you must reflect your organization’s business needs in your search implementation. Should you choose FAST search or SharePoint search? Should you build search into the farm or build a dedicated search farm? Do you require high availability? You can answer all of these questions by examining the business requirements and using them to drive your decision-making, based on your understanding of how the SSA behaves. MCT USE ONLY. STUDENT USE PROHIBITED Designing an Enterprise Search Strategy 9-41 Objectives After completing this lesson, you will be able to: • Identify key search planning decisions. • Identify the business reasons for using FAST search. • Plan taxonomy support for search. • Plan search administration. MCT USE ONLY. STUDENT USE PROHIBITED 9-42 Designing a Microsoft® SharePoint® 2010 Infrastructure Planning Search Requirements Key Points In planning search for SharePoint solutions, you must focus on a series of factors that may lead the search design in different directions. When you are planning the initial search architecture and topology, you must answer key questions to shape the search design. The key design questions include: • What is the corpus size, and are there any key search feature requirements? If the corpus size is above 100 million items, you could not support a single SharePoint search application. You could choose FAST search, which supports higher index item counts. Users may require specific search features, such as thumbnails or visual best bets, which are only available to implementations of FAST search. • What is the corpus size, and how many SharePoint farms exist? If you have a very large corpus (more than 50 million items) or several SharePoint farms in an enterprise environment, you may consider MCT USE ONLY. STUDENT USE PROHIBITED Designing an Enterprise Search Strategy 9-43 implementing a search farm (either dedicated or with other service applications). If you have multiple farms, but want to use local SSAs in each farm, you should consider if and how users in one farm can see search results from a different farm. For example, you could use search federation to show results from other farms, although SharePoint ranks each set of federated results separately. The corpus size will also help you estimate the search storage requirements. • What are your crawl performance requirements? Understanding the size of your corpus, how fresh you should keep the index, and crawl component performance will help you to decide on the number of servers, the number of crawl and property databases that you require, and the performance options for the index servers. • What are your query performance requirements? Do you have specific query performance requirements, such as displaying all search results within two seconds? If you have specific requirements, you can conduct performance testing and use tools such as query reports to analyze the query mechanism. Understanding your query performance requirements will help you to decide how many index partitions and query servers you require. • Do you require high availability for search? This will typically be related to your high-availability choices for the rest of the farm deployment. If you have chosen to implement high availability in the farm for Web content, you should consider whether users will also require search functionality to be highly available. If search should be highly available, does that include both query and index components? You can implement high availability by adding index and query servers to the farm and configuring the additional crawl and query components accordingly. You must also implement some form of SQL Server high availability for the crawl, property, and search administration databases, such as SQL Server database mirroring or SQL Server failover clustering. Question: What is the maximum recommended number of items for each index partition? MCT USE ONLY. STUDENT USE PROHIBITED 9-44 Designing a Microsoft® SharePoint® 2010 Infrastructure Business Reasons for FAST Search Key Points When you are planning search for your SharePoint environment, a key decision that you must make is whether to use only SharePoint search or implement FAST search for SharePoint. In some cases, you may base your decision on corpus size because FAST search can offer indexes of up to 500 million items whereas SharePoint search can only support up to 100 million items for each search application. However, in many cases, you may base your decision on the additional capabilities of FAST search. Reasons for an organization to choose FAST search include: • The ability to sort results on any crawled property such as metadata. • The ability to manually promote or demote specific results in the result set. • The ability to provide relevancy to the search with user context. That is, two people can see the same results, but the results are ranked differently according to the job role, location, or expertise of the two people. • Support for two-way synonyms. MCT USE ONLY. STUDENT USE PROHIBITED Designing an Enterprise Search Strategy 9-45 • Visual enhancements such as visual best bets, document thumbnails, or previews of Word or PowerPoint files directly on the results page. • Improved grammatical support, including additional lemmatization or stemming of words. For example, a search for “better” could include search results for “good.” FAST search does not include People Search. You must use SharePoint search to provide People Search results. Question: Does SharePoint search provide support for synonyms? MCT USE ONLY. STUDENT USE PROHIBITED 9-46 Designing a Microsoft® SharePoint® 2010 Infrastructure Planning Taxonomy Support for Search Key Points When you are planning search for your SharePoint environment, you may want to consider how metadata and your taxonomy will impact or assist search from a user perspective. When a user searches for something in SharePoint, SharePoint often returns a large result set that contains hundreds or thousands of results. This is particularly common if the user enters a common term. Users can use metadata in two ways to help make sense of and refine search results: • Users can use metadata properties and values to filter search results. When SharePoint displays the results page of a user’s search, if any files or items in the results have metadata properties, the user can select those properties from a list on the results page to refine the search results based on these tags. SharePoint search typically adds managed metadata values to this list automatically under the “Tags” heading. • Users can search for information by metadata field. If you have a metadata field called “Project ID” in your farm, you may want users to be able to search MCT USE ONLY. STUDENT USE PROHIBITED Designing an Enterprise Search Strategy 9-47 for all items related to “Project A,” which is specified in the “Project ID” column. Users can do this in two ways: • Enter a property search in the search box, using the <property>:<value> syntax. For example, Project ID:Project A. • From the advanced search page, choose Project ID from the property restrictions list of properties. To enable searching by metadata value, you must add a managed property for the metadata field, and map this managed property to one or more crawled properties (which is the set of properties that the last crawl discovered). This is often referred to as “promoting” the property. In addition, for the second option of choosing the property from the property drop down list on the advanced search page, you must edit the XML for the search Web Part to incorporate the managed property reference. In addition, you must configure the out-of-the-box search Web Parts to support the new managed properties if you want the user to be able to use them through the search user interface. Note: You can only map a managed property to a crawled property after the search application has performed a crawl on that property. Question: When you are trying to establish which properties might require promotion, who should you include in discussions? MCT USE ONLY. STUDENT USE PROHIBITED 9-48 Designing a Microsoft® SharePoint® 2010 Infrastructure Planning Search Administration Key Points In addition to planning the search topology, crawl schedule, crawler impact rules, and metadata integration, you should also consider who should administer certain nontechnical aspects of search. When a SharePoint farm is in pilot or production phases, many organizations discover additional refinements that can further improve the user search experience: • You can use best bets to help users find key content by promoting a specific location, item, or document into the best bets result list, making them easier to locate. An administrator, such as a site collection administrator, must manually configure each best bet entry, which has one or more associated keywords. SharePoint search displays best bet results separately to ranked search results. • You can add synonyms for specific words to help users include search terms that they may be unaware of, but that relate to the search term that they originally entered. You can add synonyms to the thesaurus file on the query servers to provide additional search results when users query specific search terms. Synonym matches can supplement results that are provided for the . Additional Index Data In addition, FAST search requires some additional data storage for elements such as a Web analyzer and log data. The following formula estimates the additional data. the white paper called FAST Search Server 2 010 for SharePoint Capacity Planning (FASTSearchSharePoint2 010 CapacityPlanningDoc.docx) at http://go .microsoft. com/fwlink/?LinkID=200898&clcid=0x409 from a list on the results page to refine the search results based on these tags. SharePoint search typically adds managed metadata values to this list automatically under the “Tags” heading.