ПредишенСледващото

Възможността за DataparkSearch търсачката

Как да се организира търсене на информация за файлов сървър не само по име и вид на документа, но и от съдържанието му? възможно да се създаде подходящ инструмент, достъпна и прозрачна за потребителите е?

В момента въпросът за извличане на информация става все по-значима информация. В интернет отдавна е конкуренцията между търсачките постоянно предлагане на нови услуги, възможности и сложни търсачки. Но е трудно да се намерят необходимите данни не само в Интернет. огромно количество акумулирани също домашен компютър на потребителя, за да се разбере, а понякога не е много лесно в този сорт. Организациите често централизират информация и сортиране на файлови сървъри, но във времето, за да откриете правилните документи по-трудно. Производителите на софтуер са отговорили на тази нужда. В момента има десетки търсачки работят локално на компютъра, също така се появяват при търсене на сървъра двигатели.

Местните търсачки се разпространяват най-вече безплатно, докато корпоративните версия, което позволява на потребителите да търсят информация на сървъра, са доста скъпи. Разбира се, закупуване на търговски продукт, имаме компетентен техническа поддръжка и други ползи, но по-малки организации или собственици на частни мрежи не винаги са в състояние да плащат хиляди долари за подобни продукти. За щастие, в света на отворения код, има свободни проекти, които не са по-ниско в функционалността на своите търговски конкуренти, с качеството на подкрепа и актуализации.

Сега ние считаме, една от опциите за организиране на документи за търсене на файлов сървър, което е извършено на определена задача.

Налице е файлов сървър с Linux. За да споделяте файлове инсталирани пакети самба и популярен про-FTP. На диска се използва файловата система ReiserFS, като най-продуктивните да се работи с голям брой малки файлове (документи, на около 3000 различни формати: TXT, HTML, док, XLS, RTF). Данните са подредени, но обемът им нараства всеки ден, отстраняването на остаряла информация не решава проблема. Как да се организира търсене на името и вида на документите, както и съдържание? Как да го предоставят на потребителите в локалната мрежа?

За да се отговори на тези въпроси, ние се нуждаем от търсачката, сървър за бази данни (MySQL, firebirg.), Apache уеб сървър, [13] и за гигабайт дисково пространство за експлоатацията на комплекса.

Кои от търсачките да избера?

Има местни търсачки като Google Desktop Search [1] или Ask Jeeves Desktop Search [2]. Може би за организиране търсене в малка фирма или на работното място на потребителя, работещ под Microsoft Windows, тези двигатели могат да бъдат полезни, но не и в този случай. Търсене "чудовища" като Yandex е много скъпо, но ако искате качество помогне на разработчиците, големи компании, може да се наложи да се мисли за отдаване под наем. За * никс-семейство, има няколко проекти. Това двигатели:

Тези двигатели са разположени както двигателите отворените търсене източник за работа в местни и / или WAN мрежи. Бих искала да отбележа, че много от проектите не мултиплатформена и не се показва на операционна система на Microsoft. Има от страна на сървъра решения, като например за Windows-базирани системи: MnogoSearch и "Snoop" [8].

Така че, помислете за кратко търсачките по * никс-платформа:

MnoGoSearch (бивш UdmSearch) - известен на мнозина и е често срещано явление двигател. Има версии, като под Windows (30-дневна безплатна версия) и под * никс-платформа (лиценз GNU). Възможност за работа с почти всички версии на SQL бази данни и за двете платформи. За съжаление, този двигател доста критики, така че аз го избрах.

DataparkSearch - търсене клонинг двигател MnogoSearch. Тя ви позволява да търсите и двете имена на файлове и тяхното съдържание. Обработка TXT файл, HTML-документи и етикети вградени mp3, за лечение на други видове съдържание, допълнителни модули документи. Можете да търсите информация за локалния твърд диск, както и LAN / WAN (HTTP, HTTPS, FTP, NNTP и новини).

Търсещата машина работи с най-честата SQL RDBMS като MySQL [10], Firebird [11], PostgreSQL [12] и други. Според разработчиците, DataparkSearch работи постоянно в различни * никс-операционни системи: FreeBSD, Solaris, Red Hat, SUSE Linux и други. В сравнение с MnogoSearch в двигателя са фиксирани някои бъгове, променили към по-добро, някои функции. разработчиците на уебсайтове и връзки към работния вариант на двигателя в интернет. Голям плюс - документация за качеството на руски.

Така че, сравнявайки "за" и "против" за изпълнението на търсещата машина на файлов сървър търсене DataparkSearch двигател е избран.

За работа, ние трябва: Apache уеб сървър, MySQL сървър за бази данни и изходните кодове DataparkSearch. Инсталирайте Apache сървъра и базата данни MySQL (с всички необходими библиотеки). Ако вашият сървър е друга база данни, можете да го използвате (вж. Документацията за двигателя). След това, ние разопаковате архиви DataparkSearch и пристъпи към монтажа на нашия комплекс.

Install.pl стартирате скрипта и да отговорят на необходимите въпроси: избор на инсталация двигател директория, бази данни и други параметри, свързани с работата на двигателя. Препоръчително е да оставите настройките по подразбиране. Опитните потребители, прочетете документацията се намира в папката док ръчно да конфигурирате двигателя (изберете командата). Ако инсталационния скрипт не може да намери MySQL, не може да бъде определен за библиотеки за развитие (libmysql14 дявола). Сега събира и инсталиране DataparkSearch команди правят и да се инсталира.

Създаване на база данни:

ш $ mysqladmin създаде търсене

SH # MySQL --user = корен MySQL

MySQL> Разрешете всички привилегии ON *. * ДО потребител @ Localhost

Идентифицирани от "парола" С предоставянето на опции;

Да предположим, че името на потребителя - търсещия, парола - QWERTY.

Сега indexer.conf създадете файл в / и т.н. / директория на двигателя, примери на файла (за някои задачи) могат да бъдат намерени в директорията / док / проби източник DataparkSearch. Пример за минимална конфигурация, показана на Фиг. 1.

Фигура 1. минималния набор от параметри indexer.conf

DoStore магазин сгъстен копия на индексирани документи. Секции - модул осигурява гъвкави индексиране функции. Да кажем, че можете да създадете ограничение на маркера или коригира индексиране не само съдържанието на файловете, но URL (хост, име на пътя). Langmap - специални езикови карти за кодиране и разпознаване на езици, за да бъдат ефективни, ако документите са по-големи от 500 байта.

Вторият желаната конфигурация на файла - резултати от търсенето файл search.conf. Препоръчително е да се вземе готов шаблон (файл /etc/search.htm-dist) и да го редактирате, за да отговаря на нуждите ви. Трябва да се отбележи, че основните параметри, представени в indexer.conf файл трябва да съответства на настройките в search.htm, в противен случай няма да има грешки в работата на двигателя. Search.htm се състои от няколко части: първата - променливи - съдържа данни за двигателя (search.cgi сценария) на и са необходими всички други единици за формиране на HTML-страници с резултати от търсенето. Пример променливи блокират в search.conf показано на фиг. 2.

Фигура 2. Минимални стандарти search.htm

Помислете search.htm повече. Както може да се види, параметрите и DBAddr LocalCharset съвпадат с еднакви параметри в indexer.conf. Ако вашият уеб клиент поддържа XML формат, можете да настроите ResultContentType текст / XML. По-долу са HTML блокове, необходими за проектирането на страницата с резултати, те не са представени тук, се дължи на големия обем. Препоръчително е да използвате готови шаблони, намиращи се в /etc/search.htm-dist файл. Придружаващата ги документация напълно описва формата на HTML блокове (дизайн), всеки може да го персонализирате по ваш вкус.

Сега можете да стартирате файла от папка показалец sbin двигател DataparkSearch на с -Ecreate параметър. Ако всичко е направено правилно, това ще се създаде необходимата SQL-таблиците в базата данни. Ако имаше грешки, трябва да проверите вашето потребителско име и парола в MySQL indexer.conf файл, това е най-често срещаната грешка.

За да тествате това се препоръчва да се индексират малка част от ресурса, за да видите, ако се появят някакви грешки, новият повторно индексиране не отнема много време. Индексирането се извършва показалец команда без параметри, в края на краищата, ние ще донесе резултати: изминало време, броят на документи и скорост.

Copy бин / search.cgi DataparkSearch файл от директорията, в CGI-бен папка на нашия уеб сървър и редактирате файла index.shtml ни Apache уеб сървър (който се намира в папката HTML), добавяне на търсенето код:

Сега можете да отидете на Localhost ресурс, като се използват всички налични браузър. Във формуляра, който се появява, въведете дума за търсене, кажете "процесор" (вж. Фиг. 3). В резултат на това ние трябва да се страницата с резултатите от търсенето, освен такива документи (вж. Фиг. 4). Ако вместо на страницата с резултатите от търсенето ще бъде документ, с грешки, проверете сценария. Влизайки в CGI-бен директория на уеб сървъра, изпълнете скрипта «тест seach.cgi >> test.htm». Ако страницата с резултати се формира правилно, проверете конфигурацията на Apache сървъра: Прави ли пътя е да CGI-скрипт се изпълнява, ако тест скрипт test.cgi в директорията на уеб сървър.

Фигура 3. въвеждане на данни Форма

Фигура 4. резултати от търсенето

Добавяне на допълнителни модули (parsetov)

По подразбиране, двигателят работи само с файлове на HTML и TXT, но е възможно да инсталирате допълнителни модули (parsety), които преобразуват различни видове документи в HTML или TXT (обикновен текст). Възможност за работа с XLS (Excel), док (Word), RTF (Word), PPT (Point за захранване), PDF (Acrobat Reader), а дори и оборота в минута (RedHar Package Manager) на файла, само метаданните ще бъде показано в последния. В нашия случай, ще се наложи преработка на офис формати. За док XLS и има няколко parsetov: catdoc [14] конвертира документи в TXT формат, XLHTML [15] и vwHtml [16] конвертира файлове в HTML формат.

Аз препоръчвам използване catdoc пакет, тъй като скоростта на превръщане в превръщане TXT формат е много по-висока в HTML формат, а програмата е XLHTML понякога "увисва" при конвертиране на документи. Въпреки че разработчиците очаквани този проблем и да препоръчват да се избегне "замразяване" Парсента настроен indexer.conf параметър ParserTimeOut 300 (броят е даден в секунда), но времето за индексиране, след това допълнително се увеличи.

Ние също се нуждаят от друго parset - unrtf [17] - да се работи с RTF-файл, го преобразува документи в HTML-код или текст / обикновен формат на избор на потребителя.

Изтеглете и инсталирайте пакетите, за да се свържете Парсента трябва да добавите линии, за да indexer.conf:

За формат XLS (xls2csv програма влиза catdoc пакет):

приложни Mime / vnd.ms-Excel текст / обикновен "xls2csv $ 1"

AddType прилагане / vnd.ms-Excel * .xls * .XLS

док за вашите документи да изглежда така:

Mime заявление / MSWord текст / обикновен "catdoc $ 1"

AddType прилагане / vnd.ms-Excel * .doc * .DOC

AddType текст / RTF * * .rtf * .RTF

AddType заявление / RTF * .rtf * .RTF

Mime текст / RTF * текст / HTML "/ ЮЕсАр / местни / хамбар / unrtf --text $ 1"

Mime заявление / RTF текст / HTML "/ ЮЕсАр / местни / хамбар / unrtf --text $ 1"

Добре е да припомним, че някои Windows-базирани приложения понякога създават файлове с едно и също разширение в горната част на регистъра, така че нека да добави към списъка на AddType същото продължение, но с различни имена.

За индексиране, можете да добавите всички видове документи, но двигателят ще се показва само линкове към имената на файловете.

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

режим на кеша

Има няколко начина, за да се ускори работата на двигателя, един от тях - използват метода на кеша за съхранение на данни. Да работи в този режим се нуждаем кеширани инструменти и тичам-сплитер, находящ се в sbin директорията по отношение на двигателя. Ако вече сте създали SQL-база данни в различен режим (dpmode), не забравяйте да го премахнете първо и след това да промените начина на съхранение. Почистете базата данни на екипа: «показалец -С" (почистване SQL-таблици) и «Indexer Edrop» (маси, изтриване). След това създайте от cached.conf-дист шаблон файл, намиращ се в папка и т.н. на нашия двигател, cached.conf файл. Не забравяйте да го промените в настройките за достъп до базата данни на SQL:

Сега можете да редактирате файловете и index.conf search.conf, чрез промяна на параметрите в тях:

Това променя цялата е достатъчно, но ако искате да се постигне още по-голяма гъвкавост на двигателя, се препоръчва да се запознаят с разширен режим на настройките на кеша и да направи необходимите промени в конфигурационните файлове.

На следващо място, се придвижете до директорията sbin нашия двигател и стартиране на кеширана с параметри:

кеширана 2> cached.out

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

Повторно създаване на SQL-таблица, определена за новия «Indexer -Ecreate» командния режим на съхранение и индекса на сървъра - показалец. След завършване на цикъла:

Аз трябва да кажа, че този метод не само ускорява скоростта на търсене на базата, както и скоростта индексиране. Сега можете да се опитате да търсите в базата данни, ако всичко е направено правилно, ние ще получите резултати.

В конфигурацията, показана за използване на минималните настройки, с допълнителна възможност за постигане на по-голяма функционалност и гъвкавост на двигателя, всичко зависи от задачите. За да се подобри mod_dpsearch модул, можете да използвате скоростта на търсачката за сървъра Apache. Необходимостта от този модул се случва, когато стотици хиляди индексирани документи и трябва да се увеличи скоростта на двигателя на максимум. Също така, документацията може да се намери и други методи за ускоряване на работата на двигателя, като например оптимизация на SQL бази данни или използването на виртуална памет като кеш.

Доста често има нужда да намери граматични форми на думи. Да кажем, че имаме нужда от всички форми на думата "процесор" (процесори, процесори.), Защото е възможно да се регулира ispell или Aspell модули. За повече информация за тях е писано в документите.

В DataparkSearch, че е възможно да се индексират мрежови сегменти, е отговорен за този параметър е: подмрежа 192.168.0.0/24 в indexer.conf.

Възможно е да се забрани индексирането специфични типове файлове или определени папки на сървъра също: Забрани * .avi или забраняване * / CGI-хамбар / *.

В конфигурационния файл шаблони можете да намерите описанието (с примери) на други полезни опции, които могат да бъдат необходими за изпълнението на конкретна задача.

Ние не смятаме, че създаването на обществена услуга за търсене в интернет, но ако имате нужда от него, моля, обърнете се към съответната документация за базата данни, уеб сървър и други гледни точки, свързани със защитата на информацията от неоторизиран достъп.

Сървърът е инсталиран на машината: AMD Athlon 2500 на Бартън, 3200 512 MB DDR (Dual), твърд диск WD 200GB SATA (8 MB кеш, 7200 оборота в минута). конфигурация на двигателя: DataparkSearch двигателя (v4.38), MySQL база данни (v4.1.11), Apache уеб сървър (v1.3.33), индексация док, XLS, RTF (конвертиране на текстови / обикновена), HTML, TXT файлове. Използвайте многопотребителски режим на съхранение. Обработка на около 2 THS. Файловете, които се намират на машината (от размера на диска

1 GB) и индексиране на съдържание изисква 40 минути, размерът на база данни, след обработка е около 1 GB. Трябва да се отбележи, че скоростта на двигателя с не-местни ресурси ще зависи от канала за скорост. Също скорост индексиране зависи от използваната parsetov. Използване на режим на кеш памет подобрява скоростта на работа с около 15-20%. Като клиентски софтуер, използван от тествани да работят Уеб браузъри: Firefox, Opera, Konqueror, Microsoft Internet Explorer, а дори и Lynx - няма проблем. Цялата работа от страна на сървъра Двигателят може да бъде автоматизирано с помощта на добре познатия демон Cron, поставете правилните настройки за индексиране на данните.

Подкрепете проекта - споделете линка, благодаря!