В октябре 2011 года профессиональная социальная сеть LinkedIn купила компанию IndexTank, которая занимается производством поисковых технологий. Очевидно, приобретена в первую очередь команда профессионалов под началом известного специалиста Диего Баша (Diego Basch), он же основатель и генеральный директор IndexTank, а в прошлом — один из ведущих разработчиков Inktomi. Как иногда бывает в таких случаях, прошлые продукты компании решили передать в open source. Диего Баш объявил, что исходные коды программного обеспечения IndexTank опубликованы под свободной лицензией Apache 2.0 и выложены на github.

indextank-engine: индексатор
indextank-service: API, BackOffice, Storefront и фреймворк Nebulizer для управления индексами

Поисковый движок IndexTank используется на многих крупных сайтах, в том числе Reddit, Wordpress (плагин для Wordpress) и BitTorrent. Он обеспечивает индексацию контента в реальном времени, поиск с учётом геолокации и т.д.

Программные интерфейсы позволяют разработчикам встраивать поиск IndexTank в свои приложения на Ruby, Java, .NET, Python, PHP и т.д. Документация по API здесь.

Если слово Xapian вам незнакомо, рекомендую ознакомиться с небольшой статьей.
Вкратце же, Xapian — представляет собой написанный на с++ набор инструментов для индексирования текстовой информации, с возможностью поиска по базе индексированной информации. Для работы не требует установленного сервера, достаточно наличия его библиотек. Может обрабатывать огромные массивы информации(проверено до 1.5Тб), измеряемой миллионами документов. Является конкурирующим продуктом Sphinx и Apache Lucene.
Мной он был выбран из этих трех продуктов за возможность использования из .Net.

Реализация хорошего поиска по сайту — часто сильно недооцененная по сложности задача. Поиск является слабым местом сайтов настолько часто, что когда я вижу строку поиска, у меня сразу же возникает предвзятое ощущение предстоящего фиаско. И чтобы лишний раз не расстраиваться, я сразу переадресую свой вопрос гуглу или яндексу и быстро нахожу то, что требовалось. Что же делать, чтобы как-то улучшить эту ситуацию?

Приглашаются к обсуждению все, имеющие опыт использования, в качестве хранилища данных, древовидных СУБД. Было бы полезно делится опытом разработки древовидных структур, описанием конкретики построения дерева индексов и алгоритмов полнотекстового поиска информации внутри хранилища данных.

Поскольку любая компьютерная система с целью оптимизации обмена производит обмен между памятью и диском в виде блоков, то атомарным элементом, хранящим данные на диске, является блок. Ни для кого не секрет, что многие СУБД (тот же ORACLE и MSSQL) фактически хранят данные в Б-деревьях. Б-дерево – это набор логически связанных блоков, выстроенных в иерархию, на каждом уровне которой определены блоки, у каждого из которых одинаковое количество уровней потомков. Описание алгоритма работы Б-дерева выходит за рамки данного блога.

Реляционный, объектный или прямой доступ обеспечивается логической моделью. Попробую предположить, что разумное использование логической модели данных, максимально приближенной к фактическому хранению – позволит более просто и быстро обрабатывать низкоуровневые данные, чем использование других логических моделей(SQL и пр.), хотя и существенно повышаются требования к уровню разработки механизмов доступа к данным. Возможно, что прямой доступ может быть представлен логическим деревом. Примером логического дерева данных – является глобал в СУБД Cache.

Приведу несколько примеров использования, из личного опыта, древовидных структур данных (глобалов).

В этой статье я открою секреты того, как работает adme.ru, а именно я расскажу о том как устроено хранение статей и тэгов, как работает полнотекстовый поиск, поиск по тэгам и всё такое…

В статье приведён пример структуры таблиц, рабочий конфиг Sphinx и немного php кода с примерами выборок.

Тэги – неотъемлемая часть всех современных сайтов и косвенный признак принадлежности сайта к пресловутому Вэб-Два-Ноль.

В статье я хочу рассказать об способах и алгоритмах тегирования информации.

Многие СУБД поддерживают методы полнотекстового поиска (Fulltext search), которые позволяют очень быстро находить нужную информацию в больших объемах текста.

В отличие от оператора LIKE, такой тип поиска предусматривает создание соответствующего полнотекстового индекса, который представляет собой своеобразный словарь упоминаний слов в полях. Под словом обычно понимается совокупность из не менее 3-х не пробельных символов (но это может быть изменено). В зависимости от данных словаря может быть вычислена релевантность – сравнительная мера соответствия запроса найденной информации.

В статье рассказывается как работать с полнотекстовым поиском на примере БД MySQL, а так же приведу примеры «нестандартного» использования данного механизма.

Многим при реализации поиска по сайту приходится делать запрос к базе данных, использующий оператор LIKE или регулярные выражения.
С выходом PostgreSQL 8.3 модуль полнотекстового поиска tsearch2 был встроен в ядро системы (об этом ранее уже писалось на Хабре), и с его помощью можно реализовать поиск по базе данных, который будет более функционален. В принципе, в статье, указанной выше, приведен пример использования этого модуля, но хотелось бы поделиться опытом реализации полнотекстового поиска в реальном проекте.