Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 49 pdf

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

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