Прежде чем начать очередное повествование, которое будет абсолютно неинтересно любителям смехуечек (делегация фишкинет встала и молча вышла из зала) - небольшое лирическое отступление. Мне на мыло написал чувак с забавным вопросом, мол где я, везучий сукин сын, нахожу столько проектов под малоизвестный и нераспространенный ноде. Отвечаю: проектов под эту платформу практически нет, языком программирования это назвать нельзя, это скорее server-side runtime environment для javascript, инструментарий для решения определенного круга задач. Меня находят совершенно по другим критериям (мой рост, соотношение размера ступни к диаметру зрачка, могу говорить, как Сталоне, ну вы поняли), я лишь выбираю NodeJS для реализации. А мог бы выбирать ерланговские Mochiweb, Misultin, Cowboy (показывающие даже более быстрые результаты) или пайтоновский Tornadoweb, но мне родной JS как-то ближе к телу, к тому же под него есть отличный репозитарий готовых велосипедов на все случаи жизни под названием NPM. Хотя, возможно, в ближайшем будущем тут появятся посты и про вышеназванные технологии. Интересно? Жми на +1.

Итак, как меня учили в гуманитарном ВУЗе, начнем с постановки проблематики. Ко мне обратился мой знакомый, подрядчик одной крупной фирмы в Британии со следующим вопросом: есть 40 GB документов в HTML формате (при ближайшем рассмотрении, размер сократился до 18 GB, что тоже немало, столько примерно весит html дамп русскоязычной википедии состоянием на 2008 год), информация крайне конфиденциальная (дневники принцесс и королей, ага) и собиралась за столетнюю историю компании, лет 5-6 тому назад фирма перешла на какую-то свою систему хранения документации, но старый дамп остался статичным и требовал индексации для поиска по нему. Интранет не позволял использовать Google, импортировать все в новую систему документооборота никто не хотел, кому нужен информационный мусор при какие-то результаты санитарных анализов воды в Нью-Гэмпшире за 1928 год? Нужно отдать должное сотрудникам этой конторы, они усердно оцифровывали все и толково составляли каталоги вручную, а значит к каждому документу был доступ по какой-то гиперссылке с другой страницы. Готовые решения я даже не искал по определенным техническим причинам, было принято решение делать свой crawler + indexer, что в наше время оказалось вполне тривиальной задачей.

Самого паука, который будет путешествовать по пыльному архиву, написать, как два пальца об асфальт, об этом мы поговорим чуточку позже, остановимся лучше на технологии поиска и хранения индекса. Всякие реляционные базы данных отпали сразу после того, как я выполнил du -sh в директории с каталогом. Хотел было попробовать сделать что-то свое на основе NoSQL, но из всех известных мне движков не позволял мне искать подобным образом (чуть позже я случайно наткнулся на Riak, увы, было уже поздно), только MongoDB мог похвастаться поддержкой регулярок при выборке, а про полноценный же full text и речь не шла, в официальном мануале советовали разбивать текст на ключевые слова, но это ужасное решение. Именно поэтому было принято решение хотя бы здесь не изобретать двухколесные механизмы и использовать готовые удобные решения. Я успел посмотреть на Apache Solr и ElasticSearch, которые построены на Java Lucene и на Sphinx. Последний сразу отпал, так как его преимущества в виде ненужных мне индексации SQL баз данных и своего Query Language для сложных выборок были сведены на нет необходимостью писать отдельную XML pipe для добавления статики. Solr, имеющий великолепный административный интерфейс, большое коммьюнити, возможность индексировать DOC и PDF (ну мы и сами можем использовать Apache Tika в любом другом движке) показался каким-то слишком сложным для быстрого старта и избыточным, плюс ему не хватало внятной документации (доки в wiki это FFFUUUU). Поэтому я и остановился на ElasticSearch, который может похвастаться великолепным REST API на основе JSON, русской морфологией из коробки, различными текстовыми анализаторами и возможностью сочетать их в любой последовательности, либо даже создавать свои собственные, встроенными языками скриптования (js или python) для выборки и фильтрации, многими вариантами storage для нашего индекса, кучей параметров сортировки и ранжирования, подсвечиванием результатов, wildcard запросами и AND, OR ключевыми словами, простым созданием кластера и репликацией между нодами, даже возможность использования поискового движка в качестве key-value хранилища данных при правильном маппинге. И да, все работает без малейшей конфигурации в стиле load`n`run, я только изменил network.host на 127.0.0.1 и после запуска получил работающее хранилище нашего индекса. А еще у еластика есть, если и не идеальная, то хотя бы внятная документация и крутое Java API, которое, впрочем, нам не понадобится.

Теперь можем переходить непосредственно к написанию нашего crawler-а, который будет переходить по ссылкам и отправлять данные в ElasticSearch. Прежде всего, я написал свою обертку вокруг RESTа еластика для облегчения процесса индексации и поиска, она очень простая и реализует только функционал двух функций - index (плюс update) и search. Код обвязки можно посмотреть. Его мы будем использовать, как в нашем поисковом боте, так и в серверном приложении, возвращающем ответ пользователю. Теперь непосредственно о преимуществах NodeJS в этой сфере. Прежде всего, это мультипоточность из коробки, разумеется, на всех современных языках можно добиться аналогичного результата (ну разве что кроме похапе, но оно там абсолютно не нужно); и, второй по значимости плюс, - jQuery. Да, я не опечатался, мы будем использовать селекторы и модификаторы jquery на серверсайде. Все это возможно благодаря великолепной библиотеки JSDOM, которая позволяет нам получить виртуальный DOM из кода HTML разметки и эмулировать все вызовы к нему. Почему jQuery? Ответ прост - банальная лень в ущерб определенной производительности, конечно же мы можем использовать регулярки для выборки всех ссылкок, но $('a').each() выглядит проще и симпатичней. Столкнулся с необычной проблемой, которая описана в том числе и в коде самого краулера: ElasticSearch почему-то наотрез игнорировал точки, двоеточия, слешы и прочие символы, поэтому сделать проверку статуса индексации ссылки через ее url не получилось, для этой цели используется md5 хэш. В целом, получилось достаточно быстрое решение, данный блог, скормленный своей главной страницей нашему боту, был полностью добавлен в кеш еластика за полторы минуты всего-то в 3 потока. Я старался, по мере возможности, комментировать исходный код, надеюсь, что у вас не возникнет проблем с его чтением. В идеале, я советую использовать 10 потоков с queueInterval около 100, если ваши сетевая подсистема и процессор выдержат подобные высокие нагрузки, с такими значениями мне удавалось индексировать около трехсот страниц википедии в минуту на средненьком железе и канале в 30 mbit\s. Паук проверяет вхождение домена индексируемой ссылки в разрешенный список и ищет дозволенный content-type в ответе, реализует своеобразный robots.txt при помощи массива регулярок indexQueryPath. К тому же возможна переиндексация при достижении определенного возраста индекса, у меня, по умолчанию, это 100 дней. Процесс индексации в вашей консоли будет выглядеть как-то так. Работающий скрипт в memory leaks замечен не был, но вот JSDOM и jQuery очень любят процессор, будьте готовы к высоким нагрузкам. Для демонстрации я прошерстил этот бложек и написал небольшое приложение поиска по всем постам, состоящее из такой вот серверной части. Его работу можно посмотреть в лаборатории им. Бена Ганна по ссылке.

В заключение, хочу выразить благодарность разработчикам и сообществу NodeJS и ElasticSearch. При всей моей нелюбви к красноглазому opensource, два этих великолепных программных продукта, создаваемых на чистом энтузиазме, помогли мне сделать работу в срок, обрадовать вычурных британцев и купить новую дозу героина. Очень сложно затягивать жгут на руке и писать сюда, до новых встреч, друзья.