Можливості пошукового движка dataparksearch

Можливості пошукового движка DataparkSearch

Як організувати пошук інформації на файловому сервері не тільки за назвою і типу документа, але і по його контенту? Чи можливо створити відповідний інструмент, доступний і прозорий для користувачів?

В даний час питання пошуку інформації стає все більш і більш актуальним. В мережі Інтернет давно йде конкурентна боротьба між пошуковими системами, постійно пропонують нові сервіси, можливості і досконалі механізми пошуку. Але потрібні дані складно знайти не тільки в Інтернеті. На домашніх комп'ютерах користувачів також накопичується величезна кількість і розібратися в цьому різноманітті іноді дуже не просто. В організаціях найчастіше інформацію централизуют і сортують на файлових серверах, але з часом пошук потрібних документів ускладнюється. Виробники програмного забезпечення відреагували на цю потребу. На сьогодні існують десятки пошукових машин, що працюють локально на PC, також з'явилися серверні пошукові машини.

Локальні пошукові машини в більшості своїй поширюються безкоштовно, тоді як корпоративні версії, що дозволяють користувачам здійснювати пошук інформації на сервері, коштують досить дорого. Безсумнівно, купуючи комерційний продукт, ми отримуємо грамотну технічну підтримку та інші переваги, але невеликі організації або власники приватних мереж не завжди в змозі заплатити тисячі доларів за подібні продукти. На щастя, в світі Open Source існують вільні проекти, які не поступаються за функціональністю своїм комерційним конкурентам, з якісною підтримкою і оновленнями.

Зараз ми розглянемо один з варіантів по організації пошуку документів на файловому сервері, який був реалізований на конкретному завданні.

Є файловий сервер під керуванням ОС Linux. Для спільного використання файлів встановлені популярні пакети samba і pro-ftp. На диску використовується файлова система reiserfs, як найбільш продуктивна для роботи з великою кількістю маленьких файлів (документи, близько 3 тисяч, різних форматів: txt, html, doc, xls, rtf). Дані відсортовані, але їх обсяг зростає з кожним днем, видалення застарілої інформації не вирішує проблему. Як організувати пошук по іменах і типам документів, а також по контенту? Як зробити його доступним для користувачів в локальній мережі?

Для вирішення цих питань нам знадобиться пошуковий движок, сервер баз даних (MySQL, firebirg.), Веб-сервер Apache [13] і близько гігабайти дискового простору для роботи комплексу.

Який з пошукових движків вибрати?

Існують локальні пошукові машини, такі як Google Desktop Search [1] або Ask Jeeves Desktop Search [2]. Можливо, для організації пошуку в маленькій компанії або на робочій станції користувача, під керуванням ОС Windows, ці движки можуть бути корисні, але не в даному випадку. Пошукові «монстри» на кшталт Яндекса дуже дороги, але якщо потрібна якісна допомога розробників, то великим компаніям, можливо, слід подумати про його оренду. Для * nix-сімейства існує кілька проектів. Це движки:

Перераховані движки позиціонуються як вільно поширювані пошукові машини для роботи в локальній і / або глобальної мережах. Хочу зауважити, що багато проекти не мультиплатформенні і не працюють під операційними системами компанії Microsoft. Для Windows-систем існують серверні рішення, такі як: MnogoSearch і «Шукач» [8].

Отже, коротко розглянемо пошукові машини під * nix-платформу:

MnogoSearch (колишній UdmSearch) - відомий багатьом і досить поширений движок. Існують версії як під Windows (30-денна безкоштовна версія), так і під * nix-платформи (ліцензія GNU). Можлива робота практично з усіма поширеними версіями СУБД SQL під обидві платформи. На жаль, на даний движок досить багато нарікань, тому я не зупинив свій вибір на ньому.

DataparkSearch - клон пошукового движка MnogoSearch. Дозволяє здійснювати пошук як по іменах файлів, так і по їх контенту. Обробка txt-файлів, HTML-документів і тегів mp3 вбудована, для обробки вмісту документів іншого типу необхідні додаткові модулі. Можливий пошук інформації, як на локальному жорсткому диску, так і в локальній / глобальної мережі (http, https, ftp, nntp і news).

Пошукова машина функціонує з найпоширенішими СУБД SQL, такими як MySQL [10], firebird [11], PostgreSQL [12] та іншими. За заявою розробників, DataparkSearch стабільно працює на різних * nix-операційних системах: FreeBSD, Solaris, Red Hat, SUSE Linux та інших. У порівнянні з MnogoSearch в движку були виправлені деякі помилки, змінені в кращу сторону деякі функції. На сайті розробників наведені посилання на робочі версії движка в мережі Інтернет. Великий плюс - якісна документація російською мовою.

Отже, порівнявши всі «за» і «проти», для реалізації пошуку на файловому сервері був обраний движок пошукової машини DataparkSearch.

Для роботи нам знадобляться: веб-сервер Apache, сервер бази даних MySQL і вихідні коди DataparkSearch. Встановлюємо сервер Apache і БД MySQL (з усіма необхідними бібліотеками). Якщо на вашому сервері встановлена ​​інша СУБД, то можна використовувати і її (див. Документацію по движку). Далі розпакуємо архіви DataparkSearch і приступимо до складання нашого комплексу.

Запустимо скрипт install.pl і відповімо на необхідні питання: вибір папки установки движка, бази даних та інші пов'язані з параметрами роботи движка. Рекомендується залишить настройки за замовчуванням. Досвідчені користувачі, прочитавши документацію, розташовану в папці doc, можуть вручну конфігурувати движок (команда configure). Якщо при інсталяції скрипт не може знайти mysql, можливо не встановлені бібліотеки для розробників (libmysql14 devil). Тепер скомпілюємо і встановимо DataparkSearch командами make і make install.

Створимо базу даних:

sh $ mysqladmin create search

sh # mysql --user = root mysql

mysql> GRANT ALL PRIVILEGES ON *. * TO користувач @ localhost

IDENTIFIED BY 'пароль' WITH GRANT OPTION;

Припустимо, ім'я користувача - searcher, пароль - qwerty.

Тепер створюємо файл indexer.conf в папці / etc / движка, приклади даного файлу (для деяких завдань) можна знайти в папці / doc / samples початкових кодів DataparkSearch. Приклад з мінімальними настройками наведено на рис. 1.

Малюнок 1. Мінімальні набір параметрів indexer.conf

DoStore зберігає стислі копії проіндексованих документів. Sections - модуль, що надає гнучкі можливості індексування. Припустимо, можна створити обмеження за тегом або налаштувати індексацію не тільки взаємодію між файлами, але і URL (хост, шлях, ім'я). Langmap - спеціальні мовні карти для розпізнавання кодувань і мов, ефективні, якщо документи розміром більше 500 байт.

Другий необхідний конфігураційний файл - файл результатів пошуку search.conf. Рекомендується взяти готовий шаблон (файл /etc/search.htm-dist) і відредагувати його під свої запити. Потрібно зауважити, що основні параметри, вказані у файлі indexer.conf, повинні збігатися з параметрами в search.htm, інакше будуть помилки при роботі движка. Search.htm складається з декількох блоків: перший - variables - містить дані для роботи движка (скрипт search.cgi), а всі інші блоки необхідні для формування html-сторінки результатів пошуку. Приклад блоку variables в search.conf наведено на рис. 2.

Малюнок 2. Мінімальні параметри search.htm

Розглянемо search.htm докладніше. Як видно, параметри DBAddr і LocalCharset збігаються з ідентичними параметрами в indexer.conf. Якщо ваш веб-клієнт підтримує формат xml, то можна встановити параметр ResultContentType text / xml. Нижче йдуть HTML-блоки, необхідні для дизайну сторінки результатів, вони тут не представлені через великий обсяг. Рекомендується користуватися готовим шаблоном, розташованим в файлі /etc/search.htm-dist. У супровідній документації повністю описаний формат HTML-блоків (дизайну), бажаючі можуть налаштувати його на свій смак.

Тепер можна запускати файл indexer з папки sbin движка DataparkSearch з параметром -Ecreate. Якщо все було зроблено правильно, то будуть створені необхідні sql-таблиці в БД. Якщо з'явилися помилки, слід перевірити ім'я користувача mysql і пароль у файлі indexer.conf, це найбільш поширена помилка.

Для тестування рекомендується проіндексувати невелику ділянку ресурсу, щоб якщо виникнуть помилки, нова переіндексація не зайняла багато часу. Індексування виконується командою indexer без параметрів, в результаті нам виведуть результати: витрачений час, кількість документів та швидкість роботи.

Скопіюємо файл bin / search.cgi з директорії DataparkSearch в папку cgi-bin нашого веб-сервера і відредагуємо файл index.shtml нашого веб-сервера Apache (розташований в папці html), додавши в нього код форми пошуку:

Тепер можна зайти на ресурс localhost, використовуючи будь-який доступний браузер. У формі, що з'явилася ввести шукане слово, припустимо «процесор» (див. Рис. 3). У підсумку ми повинні отримати сторінку з результатами пошуку, якщо, звичайно, такі документи існують (див. Рис. 4). Якщо замість сторінки з результатами пошуку з'явиться документ з помилками, то слід перевірити роботу скрипта. Зайшовши в директорію cgi-bin веб-сервера, виконаємо скрипт «seach.cgi test >> test.htm». Якщо сторінка результатів сформована правильно, слід перевірити конфігурацію сервера Apache: чи правильно вказано шлях до cgi-скрипта, чи виконується тестовий скрипт test.cgi в директорії веб-сервера.

Малюнок 3. Форма введення даних

Малюнок 4. Сторінка результатів пошуку

Додавання додаткових модулів (парсетов)

За замовчуванням движок працює тільки з файлами html і txt, але можливо встановити додаткові модулі (парсети), які перетворять інші типи документів в html або txt (plain text). Можлива робота з xls (Excel), doc (Word), rtf (Word), ppt (Power Point), pdf (Acrobat Reader) і навіть rpm (RedHar Package Manager) -Файл, в останньому будуть відображатися тільки метадані. У нашому випадку знадобиться обробка офісних форматів. Для xls і doc існує кілька парсетов: catdoc [14] перетворює документи в txt-формат, XLHTML [15] і vwHtml [16] конвертують файли в HTML-формат.

Я рекомендую використовувати пакет catdoc, так як швидкість перетворення в txt-формат набагато вище перетворення в HTML-формат, до того ж програма XLHTML іноді «підвисала» при конвертації документів. Хоча розробники передбачали цю проблему і рекомендують щоб уникнути «зависання» парсета встановити в indexer.conf параметр ParserTimeOut 300 (число вказується в секундах), але час індексування тоді ще більше зросте.

Також нам знадобиться ще один парсет - unrtf [17] - для роботи з rtf-файлами, він конвертує документи в html-код або text / plain-формат на вибір користувача.

Завантажити та встановити потрібний пакет, для підключення парсета потрібно додати рядки в indexer.conf:

Для формату xls (програма xls2csv входить в пакет catdoc):

Mime application / vnd.ms-excel text / plain "xls2csv $ 1"

AddType application / vnd.ms-excel * .xls * .XLS

для документів doc параметри виглядають так:

Mime application / msword text / plain "catdoc $ 1"

AddType application / vnd.ms-excel * .doc * .DOC

AddType text / rtf * * .rtf * .RTF

AddType application / rtf * .rtf * .RTF

Mime text / rtf * text / html "/ usr / local / bin / unrtf --text $ 1"

Mime application / rtf text / html "/ usr / local / bin / unrtf --text $ 1"

Варто нагадати, що деякі Windows-додатки іноді створюють файли з тим же розширенням в верхньому регістрі, тому додамо в список AddType ті ж розширення, але з іншими назвами.

Для індексації можна додавати будь-які типи документів, але движок буде показувати тільки посилання на імена файлів.

Припустимо, якщо необхідно проіндексувати rpm або iso-файли і отримати з них метадані, вам знадобиться спочатку знайти відповідну програму (парсет) і додати потрібні параметри в index.conf. Список підтримуваних типів документів можна подивитися, наприклад, у файлі mime.types сервера Apache. Готові рішення для конвертації файлів або отримання з них метаданих можна знайти серед параметрів пакета Midnight Commander, в файлі mc.ext.

Режим зберігання cache

Існує кілька способів прискорити роботу движка, один з них - використовувати метод зберігання даних cache. Для роботи в цьому режимі нам будуть потрібні утиліти cached і run-splitter, що знаходяться в директорії sbin щодо движка. Якщо у вас вже створена SQL-база даних в іншому режимі (dpmode), не забудьте спочатку її видалити і тільки потім змінити режим зберігання. Очистимо базу даних командами: «indexer -С» (очищення SQL-таблиць) і «indexer Edrop» (видалення таблиць). Далі створіть з файлу шаблону cached.conf-dist, розташованого в папці etc нашого движка, файл cached.conf. Не забудемо змінити в ньому параметри доступу до SQL БД:

Тепер можна відредагувати файли index.conf і search.conf, змінивши в них параметри:

Цього зміни в цілому досить, але якщо ви бажаєте досягти ще більшої гнучкості движка, то рекомендується ознайомитися з додатковими параметрами режиму cache і внести необхідні зміни в конфігураційні файли.

Далі перейдемо в директорію sbin нашого движка і запустимо утиліту cached з параметрами:

cached 2> cached.out

Демон запуститься і буде записувати зневадження в файл cached.out. Порт роботи cached за замовчуванням - 7000, але якщо необхідно, його можна змінити (в cached.conf).

Заново створимо SQL-таблиці для нового режиму зберігання даних командою «indexer -Ecreate» і проіндексуємо сервер - indexer. Після завершення виконаємо команду:

Повинен сказати, що даний метод прискорює не тільки швидкість пошуку по базі, а також швидкість індексування. Тепер можна спробувати зробити пошук по БД, якщо все було зроблено правильно, то ми отримаємо результати пошуку.

У наведеній конфігурації використовувалися мінімальні параметри налаштування, за допомогою додаткових можна домогтися більшої функціональності і гнучкості движка, все залежить від поставлених завдань. Для підвищення швидкості роботи пошуку движка можна використовувати модуль mod_dpsearch для сервера Apache. Потреба в даному модулі виникає, якщо індексуються сотні тисяч документів і необхідно підвищити швидкість роботи движка до максимуму. Також в документації можна знайти і інші методи прискорення роботи движка, наприклад: оптимізація SQL БД або використання віртуальної пам'яті в якості кеша.

Досить часто виникає необхідність в пошуку граматичних форм слів. Припустимо, нам потрібні всі форми слова «процесор» (процесори, процесорів.), Для цього можна налаштувати модулі ispell або aspell. Більш докладно про них написано в документації.

У DataparkSearch є можливість індексувати сегменти мереж, за це відповідає параметр: subnet 192.168.0.0/24 в indexer.conf.

Також можливо забороняти індексувати певні типи файлів або конкретні папки на серверах: Disallow * .avi або Disallow * / cgi-bin / *.

У шаблонах конфігураційних файлів можна знайти описи (з прикладами) інших корисних параметрів, які можуть знадобитися для реалізації певного завдання.

Ми не розглядали питання про створення публічного пошукового сервісу в Інтернеті, якщо ж вам це потрібно, ознайомтесь з відповідною документацією по СУБД, веб-сервера і іншим моментам, що стосуються захисту інформації від несанкціонованого доступу.

Сервер був встановлений на машині: AMD Athlon 2500 Barton, 512 Мб DDR 3200 (Dual), HDD WD 200 Гб SATA (8 Мб кеш, 7200 оборотів). Конфігурація движка: движок DataparkSearch (v4.38), СУБД MySQL (v4.1.11), веб-сервер Apache (v1.3.33), проводиться індексація doc, xls, rtf (конвертація в text / plain), html, txt-файлів. Використовується режим зберігання даних multi. Обробка приблизно 2 тис. Файлів, розташованих на даній машині (розмір на диску

1 Гб), і індексація їх контенту вимагає 40 хв, розмір БД після роботи приблизно дорівнює 1 Гб. Мушу зауважити, що швидкість роботи движка з нелокальними ресурсами буде залежати від швидкості каналу. Також швидкість індексування залежить від використовуваних парсетов. Використання режиму зберігання cache покращує швидкість роботи приблизно на 15-20%. В якості клієнтського ПЗ використовуються веб-браузери, перевірялася робота на: Firefox, Opera, Konqueror, Microsoft Internet Explorer і навіть Lynx - проблем не виникло. Всю роботу серверної частини движка можна автоматизувати за допомогою всім відомого демона cron, помістивши в нього потрібні параметри для індексації даних.