Главная SharePoint, Без рубрики, Новое Настраиваем корпоративный поиск: SharePoint 2010 Search Server Express (Часть 2)
  • Настраиваем корпоративный поиск: SharePoint 2010 Search Server Express (Часть 2)

    SearchТерерь, когда установка сервера поиска сложности не составляет самое время поговорить об архитектуре и принципах его работы. Ибо настраивать достаточно сложный сервис без понимания базовых вещей дело неблагодарное. Что бы в процессе моего обьяснения у вас перед глазами была нужная картинка, зайдите в  центре администрирования и далее выберите поочередно – Manage Service Application –> Search Service Application. Выбрав службу поиска, в верхней ленте нажмите "Manage".  Опустившись в самый низ страницы вы увидите топологию вашей службы поиска. (Search Application Topology). Описание, приведенное ниже справедливо для службы поиска в любом выпуске SharePoint 2010.

     

    Search1

    Изображение 1. Просмотр текущей топологии службы поиска. (Search Application Topology)

    Search2

    Изображение 2. Архитектура поиска SharePoint 2010

    Как работает поиск?

    Первый компонент архитектуры это Index Server или Индексирующий сервер, содержащий один или несколько Crawler-ов (Обходчиков)

    При запуске Crawler (Обходчик) берет адрес источника контента (Content Source) и устаналивает соединение.

    Обходчик должен понимать  форматирование и в некоторых случаях бинарный формат хранения файла. Это понимание приходит к нему с установкой Filter Pack 2.0 (x64). Если помните, Filter Pack является обязательным предварительным компонентом для инсталяции SharePoint. В стандартный набор понимаемых форматов входят документы Microsoft Office 2003, 2007, 2010; HTML; text файлы; XML; TIFF.  Для индексировании других форматов придется устанавливать дополнительные iFilter-ы.

    Crawler разбивает текст на слова, выкидывает знаки пунктуации и пробелы так, чтобы SharePoint мог определить конец одного слова и начало другого. Финально Crawler выкидывает такие слова как  "at", "the" "is".

    Далее Index Server передает текстовую информацию (Операция Index propagation) в соответсвующий раздел индекса на Query server. Парадокс заключается в том, что сервер индексирующий контент не хранит индекс у себя.

    Query server содержит раздел с индексом и отвечает на поисковые запросы пользователей. Пользователь открывает сайт SharePoint, вводит запрос в строке поиска, после чего Web Front End сервер перенаправляет этот запрос на Query server. Этот сервер извлекает информацию из индекса, который впрочем хранится локально на одном из его дисков и возвращает ответ.

    Но это еще не все, искать мы можем как по содержимому файла, так и по его метаданным. Каждый документ окружает облако дополнительной информации: кто создал, когда создал, формат документа, язык, срок действия и.т.д Это как раз и называется метаданными или данными о данных. Вся эта информация так же индексируется, но сохраняется не в разделе индекса на Query server, а в отдельной базе данных Search Property Database. Следовательно при получении поискового запроса Query server лезет за информацией как в индекс, так и базу данных свойств.

    Это не единственная база, которая была создана на этапе работы мастера по конфигурированию фермы из первой части статьи.

    Так же мы имеем:

    Search Crawl Database – содержит информацию о статусе обходов, индексированных файлах и истории обходов. Инфа о том, что и когда мы индексировали, а так же чем это закончилось.

    Search Administration Database – наполнена данными о конфигурации службы поиска, ее топологии, источниках обхода и всех дополнительных настройках, которые могут быть включены. Фактически она хранит конфиг сервисного приложения Search.

    Немного о масштабе решения.

    Думаю, что многие читая первую часть статьи, задавались вопром: Ну и на какое кол-во документов такое решение рассчитано? Явно же MS бесплатно ничего серьезного не даст?

    Давайте попробуем разобраться в вопросе. Для начала вспомним о том, что SharePoint 2010 Search Server Express подается как решение поиска с одним сервером! А следовательно раздел индекса будет только один.

    Посчитать его приблизительный  размер легко:  TotalIndexSize = CorpusSize × 0.035

    Следовательно проиндексируя 1 Террабайт документов, мы получим индекс порядка 36 гигабайт. Вроде немного, но у нас есть четкое ограничение по размеру SQL баз данных, мы же помним о потолке в 10 Гигабайт.

    Но  размер баз данных  тоже считается несложно:

    ——————————————————–

    TotalPropertyDBSize = CorpusSize × 0.015

    TotalPropertyLogSize = CorpusSize × 0.0031

    ——————————————————–

    Выполняя простые вычисления, мы определяем, что после индексирования 1 Террабайт документов файл базы свойств будет равен 15 гигабайтам, а транзакционный лог порядка 3 гигайбайт.

    Упс! Мы вышли за допустимые пределы.

    Давайте перевернем формулу и попробуем посчитать какой обьем (CorpusSize ) нам под силу заиндексировать. Я оттолкнулся от размера базы в 9.5 гигабайт.

    CorpusSizeTotalPropertyDBSize  /  0.015

    CorpusSize = 9500 Мегабайт / 0.015 =  630 000 Мегабайт = 630 Гигабайт

    Ответ: с SQL Express мы можем заиндексировать 630 Гигабайт документов.

    Что говорит MS по этому поводу? Они говорят, что на должно хватить бесплатной версии на 300,000 документов. Проверим это утверждение.

    В моей личной подборке статей и презентаций средний размер офисного документа равен 1 мегабайту. Следовательно в 630 Гигабайт войдет порядка 600 тысяч документов.

    Вывод:  Тут Microsoft даже поскромничал, указав 300,000 документов, хотя вы всегда сами можете взять средний размер своего документа и прикинуть собственные границы.

    Праздновать победу рано, мы забыли еще про две базы данных: Search Crawl Database и Search Administration Database.

    Сразу откинем Search Administration Database, ее размер гарантировано будет меньше 10 Гигабайт, просто в ней нет столько данных для достижения такого размера.

    А вот базу Search Crawl Database легко посчитать:

    ——————————————————–

    TotalCrawlDBSize = CorpusSize × 0.046

    TotalCrawlLogSize = CorpusSize × 0.011

    ——————————————————–

    Смотрим, что получается, при тех же же вводных данных размером 630 Гигабайт.

    TotalCrawlDBSize = 630 000 Мегабайт  × 0.046 = 28 гигабайт.

    TotalCrawlLogSize = 630 000 Мегабайт × 0.011 =  7 гигабайт.

    Вывод: Epic Fail?  Что же получается, тот расчет на 600 тысяч документов оказался неправильным и его нужно поделить на 3? И на выходе мы получим 200 тыс. документов, что даже меньше обещаний вендора?

    Если ваш мозг окончательно не взорван моими рассуждениями, то я предлагаю следующее. А именно взять реальные документы с реальным весом, проиндексировать их, а затем сравнить расчетные данные с реальными!

    Search6

    Изображение 3. Индексируемые документы.

    Я насобирал на компьтютере 1048 файлов весом 2,79 Гигабайта. В данной подборке файлы форматов: **.doc/**.docx/**.xls/**.ppt/**.pdf. И запустил создание индекса.

    Примечаение: на сервере Ifilter для формата PDF установлен.

    Сравнение реальных размеров и расчетных.

    Формат записей: Размер чего =  Размер рассчетный /  Размер реальный

    TotalIndexSize = 94 Мегабайта / 22 Мегабайта

    Примечаение: Индекс можно найти в папке "C:\Program Files\Microsoft Office Servers\14.0\Data\Office Server\Applications"

    TotalPropertyDBSize = 41 Мегабайт / 19 Мегабайт

    TotalCrawlDBSize  =  128 Мегабайт / 9 Мегабайт

    Вывод, финальный и правильный.

    Проведя этот эксперимен можно сделать вывод, что расcчетные данные являются потолочными и содержат очень и очень хороший запас прочности. Вы должны понимать, что я получил свои данные на основе “возни в песочнице”, а поэтому сделать вывод о неточности официальных формул нельзя.

    Но общие тренды ясны:

    а) официальные формулы имеют очень приличный запас прочности

    б) 300 000  обещанных документов на SharePoint 2010 Search Server Express вы однозначно заиндексируете, а если повезет то и гораздо больше.

    Имейте ввиду, что заменив в данной архитектуре SQL Express на полноценную версию, вы сразу поднимете колличество индексируемых документов до границы в 8-10 миллионов штук. Ну а используя данную статью, несложно прикинуть на что можно расчитывать в вашем конкрентом случае.

    Продолжение следует…

    v.1

    MCT/MVP Илья Рудь

Комментарии

  1. Ещё раз спасибо.

  2. Не за что. Главное, чтоб тема нужна была, а то самому себе писать неинтересно.

    ИМХО Как минимум бесплатные версии SharePoint уже давно пора двигать в конторах. Прогресс не должен стоять на месте. У нас у сотрудников очень низкий КПД. Это неправильно.

  3. Илья, шарпоинт тут не поможет.
    Как в том бородатом анекдоте: “Когда я работал вышибалой в борделе, у нас в таких случаях не кровати передвигали, а девок меняли.”

  4. Ну я думаю тебя за руки никто не держит – поменяй. У меня страна одна, поэтому приходится идти по более сложному пути.

  5. Да какое там продвигать. В организации куплено все и SP и SQL и несколько серверов. Не так давно удалось перенести официальные документы на SP. А так даже простые предложения начать индексировать в поиск файловые шары подразделений идут лесом. Это я к тому что очень тяжело пересаживать народ с простых файловых шар и “сбора подписей” через outlook.

  6. Все убедили, сажусь делать вебкаст , состоящий из коротких роликов на тему один день из жизни сотрудника, использующего share point. Буду использовать его в качестве ответа на вопрос Зачем?

  7. Добрый день,
    Интересуют мысли по поводу перспективности работы с SharePoint как IT-специалиста(что то вроде SharePoint Administrator)

    Заметно, что Microsoft _очень_ активно сейчас продвигает этот продукт (как и его back-end MS SQL Server).

    Но пока не видно, что бы были вакансии именно на это направление, хотя очень много вариантов подработки в этой области, опять же потому что сейчас все начали внедрять у себя SharePOint.

    Интересно, поменяеться ли ситуация в будущем? И насколько перспективное направеление(в плане зп 🙂 ), по сравнению с другими MS направелниями?

    Спасибо

  8. 1. МС далеко не активно продвигает это направление.
    2. Вакансии явно на это направление есть для программистов. Админу это идет как один из продуктов в наборе.
    3. Думаю, что очень перспективно. Спецов по SharePoint сейчас 0. Рынок дойдет рано или поздно и спрос будет более яркий на данную нишу.

  9. Илья спасибо за развернутый ответ!

  10. Добрый день Илья,
    можно ли задавать тебе вопросы с которыми я сталкиваюсь в процессе изучения администрирования Sharepoint2010?

  11. Можно, если вопросы не из серии “почему у меня не работает?”. Таких и и у меня много.

  12. Илья,как правильнее перенести портал http://name1 на новое железо,имя портала станет name2.SQL тоже переезжает
    Самое простое как я понимаю полный бэкап фермы backup-spfarm
    и потом полное восстановление restore-spfarm на новом железе
    Нужно ли будет прописывать альтернативные пути,если да то как они будут выглядеть?
    Спасибо

  13. Все вопросы на irud”_@_”live.ru. Здесь комменты только по статье.

  14. Добрый день Илья. Подскажите пожалуйста в чем может быть проблема. С недавнего времени процесс mssearch стал кушать память помного – приходится перезагружать. происходит это ночью (тогда-же и полный индекс делается) думал что это связано что много мелких сохраняется . но сохраняются они в течении дня (а каждые 30 мин разносный индекс делается) и не каждый день растет так на много (400-900МГб)…