שלום
חברים,
היום
אני רוצה לפרט קצת על נושא החיפוש הארגוני בפלטפורמטת SharePoint.
מנוע
החיפוש ב-SharePoint 2010
הוא כנראה ה-Feature
הכי חשוב במוצר. Microsoft
ביצעה מספר שיפורים ב-Search Component
לעומת המנוע שקיים ב-Moss 2007.
למנוע
החיפוש יש יכולת לעבד מידע ממספר סוגים של מקורות תוכן כגון : Databases, Public Folders, LOB
Systems, Federated locations ואיפלו ב- Internet.
מנוע
החיפוש ב-SharePoint 2010
מכיל מספר רכיבים כגון : Service Application ו- Service
Application Proxy, Query Processor, Query Component, Index
Partition, Crawl Component, Admin Database, Property
databases ו- Crawl databases.
אז
מה זה בעצם כל ארסנל הרכיבים האלו ..? אנסה קצת לשפוך אור על הנושא ולחבר את הפאזל
המורכב הזה.
אפשר
לכנס את כל הרכיבים ל-4 טופולוגיות עיקריות :
-
Administration
-
Query
-
Crawl
-
Query
Processor
מבנה
רכיב ה-Administration,
כולל את הרכיב עצמו ואת ה-Administration Database. רכיב ה-Administration מעדכן את ה-Administration Database ומנטר את פעולות המשתמש(בחיפוש). הרכיב יכול לרוץ על כל שרת (FE/Application)
אך ממולץ להריץ אותו על השרת שמריץ את רכיב ה-Crawl. ה-Administration Database אחרי על אחסון של הגדרות ה-Service
Application , הגדרות של רכיב ה- Administration
, רשימת הערכים ל-Index (Crawl Properties),הגדרות
Scopes, התחברות ומתארי אבטחה. כשמתבצע חיפוש התוצאות שיחזרו יהיו
התוצאות היחידות שהמשתמש שמבצע את החיפוש רשאי לראות. כדי שהתהליך יעבוד כמו שצריך
הרכיב Query Processor
צריך לגשת למטמון של מתאר האבטחה (Security Descriptor), או לטבלה MSSecurityDescriptor. אם הDescriptors קיימים במטמון התהליך יהיה מהיר יותר ומנגד אם ה-Descriptors לא במטמון התהליך יהיה איטי יותר, ה-Query
Processor ימשוך את ה-Descriptors וישמור אותם במטמון.ישנה מגבלה של Security
Descriptors שניתן לאחסן בזכרון, כברירת מחדל הערך הוא
1000. כמתווסף Descriptor
חדש ה-Descriptor הישן ביותר נמחק. חשוב לדעת שרכיב
האדמיניסטרציה הינו רכיב יחיד ולא ניתן ליצור מספר רכיבים כאלו בחווה (בניגוד
לרכיבי Crawl
ו- Query) המשמעות היא גם שלא ניתן ליצור מס' Databases של Administration.
טיפ : כדאי מאוד לעשות Mirroring ל-Administration databases בגלל שאם הוא לא יהיה זמין אז רכיב החיפוש לא יעבוד (לא יהיה ניתן
לבצע Index ושאילתות).
מבנה
רכיב ה-Query
אחראי על לקיחת השאילתא והחזרת תוצאה תואמת למשתמש הקצה. ה-Query כולל את ה-Index Partition , רכיב/י Query
ואת ה-Property Database. Index
Partition הינו קונספט חדש ב-SharePoint
2010. ב- Moss 2007 היה רכיבאינדוקס יחיד לכל SSP, ב-SharePoint 2010
ניתן להגדיר מספר רכיב חיפוש ל Index
ובכל רכיב ניתן להגידר Index Partition. Index
Partition הינו חלק לוגי של כלל ה-Index בחווה ומאפשר אחזור של תוצאות מהיר יותר. כדי להבין אניטואיטיבית
יותר טוב אפשר לדמות את ה-Index Partition לרשימה מספרי טלפון של אנשים (שם פרטי,שם משפחה וטלפון, רשימה
ממויינת). במידה ומתבצע חיפוש ברשימה על איש מסוים האחזור יקח יותר זמן בגלל
שנצטרך לעבור איש איש עד שנמצא את האיש המבוקש.
עכשיו דמיינו שהיינו מחלקים את הרשימה בעזרת לשוניות ועל כל לשונית היינו כותבים
את האות הרשונה של שם המשפחה החיפוש והאחזור היו הרבה יותר מהירים. מעבר לכך Index
Partition מאפשר לנו ליצור יתירות בחווה ע"י
שכפול של Index Partition
במיקום שונה. ה-Index עצמו (קובץ Index) מאוחסן פיזית על השרת ולא ב-Database, אבל המאפיינים של הערך מאוחסנים ב-Property
Database. Index Partition יכול להיות משוייך ל-Property Database אחד בלבד. כשמתכננים את ארכיטקטורת החיפוש בחווה כדאי לתכנן אותה
כך שיצירת Index Partition
תהיה לכל 10 מיליון פריטים. ה-Property
Database הינו ה-Database הגדול ביותר מבין ה-Databases ברכיב החיפוש והוא יכול לתמוך עד 50 מיליון פריטים בקרוב, לכן
צריך לחשוב על הקמה של יותר מ Database אחד במידה ומדובר בארגון המחזיק הרבה פריטים.
טיפ : כדאי לדאוג למספיק
זכרון כדי לאחסן 33% מהטבלאות הקריטיות במטמון. הטבלאות הקריטיות הן : MSSDocSDIDs, MSSDocProps ו- MSSDocResults
מבנה
רכיב ה-Crawl
כולל את הרכיב עצמו ואת ה- Crawl Database. רכיב Crawl
אחראי על תהליך האינדוקס הכולל את אינדוקס התוכן, ניטור מצב האינדוקס, מציאת ועיבוד
של לינקים על דפי אתר, הוצאת עוגנים מהתוכן (שורשים או לחילופין מילים שהחלטנו לא
לאנדקס) וניהול של Index Partitions.
ניתן להגדיר יותר מרכיב Crawl
אחד בחווה ובמידה ומגדירים יותר מרכיב אחד, אחד מהרכיבים יהיה Master
Crawler, כלומר הרכיב שאחראי על מרבית האינדוקסים
ואחראי על כל הפעילויות שנלוות לרכיב Crawl
כגון : תזמונים לסיום האינדוקס ,עדכון מצב האינדוקס והפעלה של אינדוקס אחר במידה
והרכיב קורס (Failover).
ה-Crawl Database אחראי על אחסון של Crawl Logs
ו Crawl
Queue.
ה-Database לא מסתמך על כמות הזכרון הקיימת במכונה (כמו ה-Property
Database) אך זקוק לכמות גדולה יותר של משאבים בשל
פעולות -IOPS מרובות, בנוסף גם ה- Database הזה תומך ב-Mirroring. חשוב לדעת שלמרות ש-SharePoint 2010 תומך ב-Claims-based authentication ניתן לבצע אינדוקסים ע"י שימוש ב-Windows
authentication User בלבד.
טיפ : בכל שפה ישנם מילים
שאין לנו צורך לאנדקס אותם ("מילים רועשות"), למשל מילות קישור כמו
"גם" , "ו", "ל" וכו'. למילים אלו אין משמעות ולכן
לא נרצה לאנדקס אותם. SharePoint משתמש בקבצי TXT
שמכילים את המילים האלו ע"מ להנחות את ה-Crawler לא לאנדקס את מילים אלו. ניתן למצוא את הקבצים ולהוסיף להם מילים
אותן אנו לא מעוניינים לאנדקס. דוגמא : הקובץ בעברית נקרא, noiseheb.txt. חפשו את הקובץ והוסיפו מילים בהתאם.
רכיב
ה-Query Processor
הינו הרכיב האמון על השאילתות של משתמשי הקצה. התהליך הוא : שרת האפליקציה
"קורא" ל-Search Service Application Proxy במטרה לתקשר עם השרת שמריץ את ה-Query
וה-Site Settings Service, במידה וה-Service פעיל השרת המארח יריץ QP (Query
Processor) לכל Service
Application. התקשורת מעשית דרך WCF
מה
שמאפשר ל-SharePoint לאחזר תוצאות בצורה מאובטחת ולהחזיר תוצאות
רלוונטיות לפי הרשאת המשתמש.
ישנו
שוני בין תהליך האינדוקס ב-SharePoint Server 2010 ל- SharePoint
Foundation 2010 :
-
ב-SharePoint
Foundation לא ניתן להגדיר את רכיב ה-Crawl (ניתן ליצור אך לא להגדיר), הגדרות כמו Service
Account, משתמש בעל גישה לתוכן (Content
Access Account), Search Database, Failover
ותזמון לאינדוקסים.
-
מקורות
התוכן היחידים שניתן לאנדקס בעזרת Search Foundation הינם מקורות תוכן של SharePoint בלבד.
-
לא
ניתן לבצע אינדוקס מצטבר ב-SharePoint Foundation .
לסיכום,
אנו יכולים לראות שרכיב החיפוש הינו רכיב מורכב מאוד וכדאי לתכנן את הקמתו בקפידה
ע"מ לא להעמיס את החווה בנתונים מיותרים ובנוסף להפיק את מיטב הביצועים
מהמנוע חיפוש.
אחרי
שקראת את המאמר תוכל לעבור למאמר הבא שלי שמדבר על יצירה והגדרה של Search
Service Application בעזרת PowerShell
, מומלץ מאוד להשתמש בדרך פעולה זו כדי להגדיר את ה-Service
Application כנדרש.
בהצלחה
!
רון
נס.
============================================================================================================================================================================================================================================================
Hello Friends,
Today I want to elaborate a bit on
the subject of SharePoint enterprise search Platform.
Search engine in SharePoint 2010 is probably the most
important feature in the product. Microsoft has made a number of improvements
in Search Component compared to the existing engine in Moss 2007.
Search engine has the ability to process data from
multiple types of content sources, such as: Databases, Public Folders, LOB
Systems, Federated locations and Eiffel on Internet.
Search engine in SharePoint 2010 contains a number of
components such as: Service Application and Service Application Proxy, Query
Processor, Query, Component Index Partition, Crawl Component, Database Admin,
Property databases and Crawl databases.
So what are all these components Arsenal..? I will try
to shed some light on the subject and connect this complex puzzle.
You can bring all the components into 4 main topologies:
- Administration
- Query
- Crawl
- Query Processor
The Structure of the Administration component, including
the component itself and the Administration Database. Administration component
updates the Administration Database and monitors user actions (search). The
component can run on any server (FE / Application) but recommended to run it on
the server that runs the component Crawl. The Administration Database is
responsible for the storage of the Service Settings Application, Component
Settings - Administration, the list of values to Index (Crawl Properties),
Scopes settings, login and security descriptors. When a searched result is will
return, only results that the user performing the search is allowed to see.
To make the Process to work properly, The Query
Processor component need to access the cache of the security descriptor
(Security Descriptor) or MSSecurityDescriptor table. If the Descriptors are
caching the process will be faster and on the other hand if the Descriptors not
caching the process will be slower.
The Query Processor will attract the Descriptors and
will keep them in the cache. There is a limit of Security Descriptors that can
be stored in memory, the default value is 1000. When The Query Processor Add a
new Descriptor the oldest Descriptor are deleted.
It is Important to know that administrative component is
a single component and we can’t create multiple components in the farm (as
opposed to elements Crawl and Query) It also means that you can’t create a
number of Databases Administration.
Tip: It is better to make Mirroring to
Administration databases because if he is not available then the search
component will not work (will not be make reservation and queries).
The Query component is responsible for taking the query
and returns the result corresponds to the end user. The Query contains the Index
Partition, Query Component / s and the Property Database. Index Partition is a
new concept in SharePoint 2010. In Moss in 2007 there was a single Index Component
for each SSP; in SharePoint 2010 we can configure number of component to the search
component. Index Partition is a logical
part of the entire index in the farm and enables Enterprise Search Service to
return results faster. To understand better Intuitive We can simulate the Index
Partition to a list of phone numbers (first name, last name and telephone
sorted list). If we make a search in the list it will take some more time
because we have to move each one until we find the wanted man. Now imagine that
we divide the list using tabs and each tab would allow me to write the letter
of the last name, the search will be much faster. Furthermore Index Partition
allows us to create redundancy by replication of farm Index Partition to different
location. The Index are stored (an Index File) physically on the server and not
in Database, but the characteristics of the Property are stored in database. Index
Partition can be associated with one Property Database only. When you plan the
architecture of the search in the farm, you should plan it so that creating
Index Partition per 10 million items.
The Property Database is the largest Database and can
support approximately 50 million items, so you need to think about the
construction of more than one database if an organization holds a lot of items.
Tip: You should worry for enough memory to
store 33% critical cache tables. Critical tables are: MSSDocSDIDs, MSSDocProps
and MSSDocResults
The Crawl component includes the component itself and
the Crawl Database. Crawl component is responsible for the overall process of
indexing the content, monitoring the index status, finding and processing links
on Web pages, published Anchors content (roots or alternatively words we
decided not to index) and management of Index Partitions.
You can set up more than one Crawl component in the farm
and. when you defining more than one element, one of the element will be Master
Crawler, i.e. this component will be responsible for most of the Indexes and
responsible for all related activities component Crawl such as timings end indexing,
update index Status and Activate another index if the Failover happen.
The Crawl Database is responsible for storing and Crawl Logs
and Crawl Queue.
The Database is not reliant on the amount of memory
available in the machine (such as the Property Database) but needs a greater
amount of resources due to multiple IOPS-operations, as well as the database
that supports mirroring.
It is important to know that while SharePoint 2010 supports
Claims-based authentication, we can performed Crawl by using Windows
authentication User only.
Tip: every language has words that doesn’t need
to Crawl them ("Noisy Words"), such as linking words "or",
"and", "to", etc... This word doesn’t have meaning and we
don’t want to crawl them. SharePoint uses TXT files that contain those words in
order to guide the crawler not to index the words. You can find the files and
add words which you do not want to crawl. Example: The file is called in English,
noiseenu.txt. Look for the file and add words accordingly.
Query Processor Component is the component that responsible
for end-user queries. The process is: The web server "calls" to the
Search Service Application proxy to communicate with the server which is
running the Query and Site Settings Service. If the service is active, the
server that hosting the service will run QP (Query Processor) for each Service
Application. The communication is in WCF, so SharePoint securely retrieve
results and return relevant results by user authorization.
There is a difference between the processes of Crawling
in SharePoint Server 2010 to SharePoint Foundation 2010:
- SharePoint Foundation cannot set the Crawl component
(can be created but not set) as the Service Account settings, with access to
the content (Content Access Account), Search Database, failover and scheduling Index.
- The only Content sources that SharePoint Foundation is
possible to crawl are SharePoint content sources.
- Unable to perform incremental indexing in SharePoint
Foundation.
In conclusion, we can see the search component is very
complex component and we should plan its construction carefully in order not to
overload the farm in addition to redundant data and make the best of search
engine performance.
After you read the article you can go to my next article
talks about the creation and definition of Search Service Application using
PowerShell highly recommended to use this way to configure the Service
Application required.
Good Luck J
Ron Ness.
