Pull to refresh
  • by relevance
  • by date
  • by rating

Seadragon и Всемирная цифровая библиотека

Lumber room
Как вы, наверняка, уже знаете вчера открылась Всемирная цифровая библиотека.


(кстати, функциональность демонстрационного ролика, похоже, еще не реализована… или я не туда смотрю?)

Казалось бы, причем тут Seadragon?
Читать дальше →
Total votes 8: ↑5 and ↓3 +2
Views 264
Comments 5

Полнотекстовый поиск по сайту — бич современного интернета

Website development *
Реализация хорошего поиска по сайту — часто сильно недооцененная по сложности задача. Поиск является слабым местом сайтов настолько часто, что когда я вижу строку поиска, у меня сразу же возникает предвзятое ощущение предстоящего фиаско. И чтобы лишний раз не расстраиваться, я сразу переадресую свой вопрос гуглу или яндексу и быстро нахожу то, что требовалось. Что же делать, чтобы как-то улучшить эту ситуацию?
ответы
Total votes 76: ↑64 and ↓12 +52
Views 26K
Comments 57

Twitter: 1 млрд запросов в сутки и новый поисковик

Search engines *
На данный момент нагрузка на серверы Twitter выросла до 1000 TPS (твитов в секунду) и 12000 QPS (запросов в секунду) — более 1 млрд запросов в сутки. Текущая инфраструктура ещё выдерживает, но чтобы создать запас на несколько лет вперёд, компания приняла решение обновить бэкенд для поисковой системы. «Если мы сработали хорошо, то вы не должны были ничего заметить за последние недели», — сообщается в блоге разработчиков Twitter.

До недавнего времени поисковый бэкенд Twitter был основан на старой SQL-системе от компании Summize. Её купили в июле 2008 года как раз для этих целей, а также взяли пять из шести разработчиков. Необходимость апгрейда Twitter стала понятна сразу после презентации iPhone 3G, тогда и началось сотрудничество с Summize. Но сейчас пришло время снова обновляться.

Примерно шесть месяцев назад было принято решение разработать новую, современную поисковую архитектуру, основанную на эффективном инвертированном индексе вместо реляционной базы данных. Поскольку Twitter любит open source, то в качестве начальной точки решения выбрали поисковую библиотеку Apache Lucene, написанную на Java.
Читать дальше →
Total votes 49: ↑44 and ↓5 +39
Views 1.2K
Comments 17

Отчет с конференции Lucene Revolution

Search engines *
В начале октября мне удалось побывать на конференции Lucene Revolution, которая проходила в городе-герое Бостоне. Эта конференция была посвящена открытым поисковым технологиям Apache Lucene и Apache Solr. Мне кажется, что на хабре в частности и в рунете в целом этим технологиям уделяется незаслуженно мало внимания. Давайте исправим это упущение.

Читать дальше →
Total votes 41: ↑38 and ↓3 +35
Views 3.6K
Comments 10

Полнотекстовый поиск в Grails

Groovy & Grails *
Подключить полнотекстовый поиск в Grails — задача довольно легкая. Для этого используется плагин Searchable, который делает все сущности Grails-приложения индексируемыми. Searchable позволяет абстрагировать весь процесс индексирования и поиска. При этом сам плагин использует библиотеку Compass, которая следит за тем, чтобы при изменении объекта (т.е. при сохранении в БД) он автоматически переиндексировался. Сам по себе Compass по сути является довольно мощным средством «поискового ORM»:
Читать дальше →
Total votes 6: ↑6 and ↓0 +6
Views 3K
Comments 0

16 практических советов по работе с CouchDB

NoSQL *
Где-то год назад при разработке нашего проекта мы дошли до некой точки развития, когда или начинается кропотливая настройка и оптимизация MySQL-сервера, или начинается опять же кропотливое изучение запросов, которые идут в БД. Так получилось, что именно тогда был бум статей про MongoDB, CouchDB и прочие NoSQL базы данных и соблазн попробовать их на живом проекте был крайне велик.

При выборе главную роль сыграла фраза «CouchDB предназначен именно для веба», а также то, что для доступа не требовались никакие прослойки — доступ осуществляется по любимому мной REST, а API выглядит очень простым и изящным. Вдобавок к этому CouchDB имеет крайне удобный веб-интерфейс для администрирования Futon, чего на тот момент не было у MongoDB, а также железную устойчивость к падениям.

Забегая вперед скажу, что выбор полностью себя оправдал — мы избавились от огромного количества проблем при разработке и проектировании БД, код проекта сильно упростился и стал гораздо лучше структурирован, но самое главное — тот самый поворот в сознании, который нам дал CouchDB. За это время я лично набил множество шишек при разработке и хотел бы поделиться опытом с Хабрасообществом. Эти советы не для начинающих — это советы по использованию CouchDB на живом production.
Читать дальше →
Total votes 56: ↑55 and ↓1 +54
Views 15K
Comments 45

NoName Podcast S04E05

Self Promo

Вместо вступления


Подкаст вышел с опозданием, поскольку мы ждали, когда мне вернут микрофон. На момент записи его так и не отдали, поэтому меня слышно не очень хорошо, выводы сделали, своих ошибок повторять не будем.
Таинственный образом с хабра пропал «подкаст», поэтому слушайте нас на rpod-е.
Читать дальше →
Total votes 33: ↑29 and ↓4 +25
Views 845
Comments 1

Поиск с помощью Lucene в Playframework 1.x

Search engines *Java *
Sandbox
В моем веб-проекте на Playframework-e в один прекрасный момент потребовался поиск. Идею искать в базе через like я сразу отмел, потому что хотелось ранжирования и прочих плюшек «умного» поиска, а изобретать свой велосипед не было ни времени ни желания.
Так как проект на Java — было очень соблазнительно использовать для этого Lucene.
В гугле я сразу нашел замечательный модуль для Playframework-а под названием Search, также был найден модуль Elastic Search, который тоже использует Lucene, но он требует установки отдельного сервера, и потому был отметен. Модуль Search понравился мне своей простотой — все «навороты» в нем инкапсулированы, так что пользоваться им очень легко.
С установкой модуля, как и всегда в Play-e, проблем не возникло, команда play install search отработала на «ура» и выкачала модуль из репозитория.
Добавив module.search=${play.path}/modules/search-2.0 в application.conf я уже мог использовать его в приложении.
Следуя краткому руководству, я добавил к сущности Entry, по которой собственно и следовало осуществлять поиск, аннотацию @Indexed, а полю description — аннотацию @Field.
Написав в контроллере примерно следующий код:
public static void search(String phrase, int page) {
        int pageSize = PAGE_SIZE;
        Query query = Search.search("description:" + phrase, Entry.class);
        List<Entry> entries = query.page(page*pageSize, pageSize).fetch();
        long totalCount = query.count();
        render(entries, totalCount, page, pageSize, phrase);
}

Я уже был готов делать первые тесты и наращивать функционал, но тут начались проблемы…
Читать дальше →
Total votes 6: ↑5 and ↓1 +4
Views 2.7K
Comments 1

Организуем поиск молекулярных структур с помощью Lucene и Chemistry Development Kit

Search engines *Java *
Sandbox
Библиотека полнотекстового поиска Lucene предоставляет возможность организовать поиск по текстовым документам. Существуют так же средства, с помощью которых можно организовать поиск «похожих» химических структур, например, OpenBabel. Иногда может возникнуть потребность объединить эти два вида поиска в единой «канве». Например, если нужно создать систему, которая может отвечать на такие запросы: найти вещество, в текстовом описании которого есть слово «аминокислота», структурно похожее на индол (ожидается, что мы найдём аминокислоту триптофан). В этой статье описано решение данной задачи на основе полнотекстового движка Lucene.
Читать дальше →
Total votes 3: ↑3 and ↓0 +3
Views 2.1K
Comments 4

Как мы ускорили поиск на hh.ru

HeadHunter corporate blog Search engines *Concurrent computing *
image
Некоторое время назад наш поиск стал работать быстрее. Особенно это заметно на сложных для движка запросах, в которых используется минимум фильтров и высокочастотные слова, что требует построить фасеты по результатам и отсортировать максимальные объёмы документов. Но и запросы средней сложности, где в выдаче немного документов, стали обрабатываться заметно быстрее. Почему возникла необходимость что-то ускорять и как мы это делали?
Читать дальше →
Total votes 40: ↑32 and ↓8 +24
Views 15K
Comments 28

Как это сделано: префиксный поиск

VK corporate blog Website development *Search engines *
Мы живем во времена, когда кажется, что все просто и все есть. Нужно сделать масштабируемый проект — используем MongoDB, нужна очередь — вот RabbitMQ, нужно поднять функционал поиска — раз плюнуть: ставим Sphinx, Solr, ElasticSearch (нужное подчеркнуть).

Но здесь лишь доля правды: — при определенном везении можно поставить нужный сервер и все зашевелится. Загвоздка с поиском состоит в том, что пользователи уже порядком привыкли к высокой планке, которую задают «большие ребята», а тот поиск, что поднимется у вас «из коробки», будет явно недотягивать. И если очередь или базу данных вы можете добить железом прежде, чем будете оптимизировать, то поиск железом не добьешь.

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

Мы посмотрим, как с помощью нашего проекта http://indexisto.com сделан поиск на сайте http://maximonline.ru и сравним его с тем, что есть на других сайтах.

Для начала несколько примеров. Возьмем запрос «Битва за Лос Анджелес» и представим, что его напишут неправильно «Лос Анжелес биттва». Как видно, пользователь не знает точно, как пишется имя города, и забыл, как звучит название фильма, а также у него дрогнула рука в конце на слове «битва».

Выберем достойные проекты рунета, в которых есть префиксный поиск, и попробуем поискать там наш запрос:

Проект Правильный запрос Неправильный запрос
afisha.ru

все ОК

Не найдено
ivi.ru

все ОК

Не найдено
vk.com

все ОК

Не найдено
maximonline.ru

все ОК

все ОК

Читать дальше →
Total votes 103: ↑81 and ↓22 +59
Views 40K
Comments 37

Почтовый офис Яндекса: как мы сделали сервис, анализирующий результаты рассылок в реалтайме

Яндекс corporate blog Open source *Yandex API *
У Яндекса есть сервис для добросовестных рассыльщиков писем — Почтовый офис. (Для недобросовестных у нас в Почте есть Антиспам и кнопка «Отписаться».) С его помощью они могут понимать, какое количество их писем пользователи Яндекс.Почты удаляют, сколько времени их читают, насколько дочитывают. Меня зовут Антон Холодков, и я занимался разработкой серверной части этой системы. В этом посте я расскажу о том, как именно мы ее разрабатывали и с какими трудностями столкнулись.



Для рассыльщика интерфейс Почтового офиса полностью прозрачен. Достаточно зарегистрировать в системе свой домен или email. Сервис собирает и анализирует данные по множеству параметров: имени и домену отправителя, времени, признаку спам/не спам, прочитано/не прочитано. Также реализована агрегация по полю list-id — специальному заголовку для идентификации рассылок. Источников данных у нас несколько.
Читать дальше →
Total votes 62: ↑55 and ↓7 +48
Views 25K
Comments 51

Обработка логов с учётом предыдущих сообщений в logstash/elasticsearch

Webzilla corporate blog
Про отлов ядерных MCE (machine check error) и прочей гадости с помощью netconsole я писал недавно. Крайне полезная вещь. Одна проблема: throttling на CPU из-за локального перегрева (длительной нагрузки) фиксируется как MCE. Случается бэкап — и админам приходит страшное сообщение об MCE, которое на практике означает «чуть-чуть перегрелось» и точно не требует внимания к себе в 3 часа ночи.

Смехотворность проблемы ещё тем, что Linux фиксирует MCE после того, как throttling закончился. То есть режим 'normal', но вместо этого оно превращается MCE. Выглядит это так:
CPU0: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature/speed normal
CPU0: Core temperature/speed normal
mce: [Hardware Error]: Machine check events logged

При этом мы точно хотим реагировать на нормальные MCE. Что делать?

В рамках logstash обработка сообщений предполагается stateless. Видишь сообщение — реагируешь. Внедрять же ради одного типа сообщений более сложную систему — оверкилл.

Казалось бы, есть фильтр (не путать с output) elasticsearch, который позволяет делать запросы. К сожалению, он не умеет делать 'if'ы, то есть remove_tag и add_tag будут отрабатывать вне зависимости от того, удался поиск или нет.

Грустно.
Читать дальше →
Total votes 10: ↑10 and ↓0 +10
Views 8.1K
Comments 7

Материал по работе с Apache Lucene и созданию простейшего нечёткого поиска

Java *
Tutorial
Пост расcчитан на начинающих, на людей незнакомых с технологией Apache Lucene. В нем нет материала о том, как устроен Apache Lucene внутри, какие алгоритмы, структуры данных и методы использовались для создания фреймворка. Пост является обучающим материалом-тизером, написанным для того, чтобы показать, как организовать простейший нечёткий поиск по тексту.

В качестве материала для обучения предоставлен код на github, сам пост в качестве документации и немного данных для тестирования поисковых запросов.
Подробности
Total votes 11: ↑10 and ↓1 +9
Views 29K
Comments 6

Основы Elasticsearch

Website development *Search engines *

Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.


Подобные движки используются при сложном поиске по базе документов. Например, поиск с учетом морфологии языка или поиск по geo координатам.


В этой статье я расскажу про основы ES на примере индексации постов блога. Покажу как фильтровать, сортировать и искать документы.

Читать дальше →
Total votes 39: ↑38 and ↓1 +37
Views 508K
Comments 78

Как Discord индексирует миллиарды сообщений

High performance *Instant Messaging *Open source *System Analysis and Design *Google Cloud Platform *
Translation


Миллионы пользователей ежемесячно отправляют миллиарды сообщений в Discord. Поиск в этих сообщениях стал одной из самых востребованных функций, какие мы сделали. Да будет поиск!

Требования


  • Экономически эффективный: Основное взаимодействие пользователя с Discord — это наш текстовый и голосовой чат. Поиск — вспомогательная функция, и стоимость инфраструктуры должна отражать это. В идеале это значит, что поиск не должен стоить дороже, чем фактическое хранение сообщений.
  • Быстрый и интуитивно понятный: Все создаваемые нами функции должны быть быстрыми и интуитивными, в том числе поиск. Он должен выглядеть и ощущаться по высшему стандарту.
  • Самовосстановление: У нас нет отдела DevOps (пока), так что поиск должен выдерживать сбои с минимальным человеческим вмешательством или вообще без него.
  • Линейно масштабируемый: Как и с хранением сообщений, увеличение ёмкости поисковой инфраструктуры должно предусматривать добавление нодов.
  • Ленивая индексация: Не все пользуются поиском — мы не должны индексировать сообщения, пока кто-то не попытается хотя бы раз их найти. Вдобавок, после сбоя индекса должна быть возможность переиндексации серверов на лету.
Читать дальше →
Total votes 25: ↑25 and ↓0 +25
Views 10K
Comments 2

Как устроены адресные подсказки «Дадаты»

HFLabs corporate blog High performance *Website development *Search engines *System Analysis and Design *


«Дадата» с 2014 года пилит «Подсказки». Они помогают быстро и без ошибок вводить контактные данные: адреса, реквизиты банков и компаний, емейлы — вот это все.


Штука устроена затейливо, и мы решили о ней рассказать. Возьмем подсказки по адресам, потому что они самые сложные.


Справочники и индексация


«Подсказки» знают, что подсказывать, потому что у них есть гигантские справочники. Хоть статья эта о подсказках по адресам, для пользы дела перечислю и другие справочники «Дадаты».


Читать дальше →
Total votes 37: ↑37 and ↓0 +37
Views 12K
Comments 10

Нечеткий поиск (fuzzy search) в реляционных базах данных

Website development *Java *MongoDB *Database Administration *
Для поиска нужной информации на веб-сайтах и в мобильных приложениях часто используется поиск по словам или фразам, которые пользователь свободно вводит с клавиатуры (а не выбирает например из списка). Естественно, что пользователь может допускать ошибки и опечатки. В этом случае полнотекстовый поиск, полнотекстовые индексы, которые реализованы в большинстве баз данных не дают ожидаемого результата и практически бесполезны. Такой функционал все чаще реализуют на основе elasticsearch.

Решения с использованием elasticsearch имеют один существенный недостаток — очень большая вероятность рассогласования основной базы данных, например PostgreSQL, MySQL, mongodb и elasticsearch, в которой хранятся индексы для поиска.
Читать дальше →
Total votes 12: ↑11 and ↓1 +10
Views 8.5K
Comments 6

Как устроен поиск

HeadHunter corporate blog Search engines *Algorithms *
Привет, юзернейм! Каждый день мы сталкиваемся с поиском различных данных. Почти на каждом веб-сайте с большим количеством информации сейчас есть поиск. Поиск есть в домашних компьютерах, в мобильных телефонах, в различного рода программном обеспечении. Конечно, если спросить любого разработчика про поиск с точки зрения технологий, на ум сразу придет elasticsearch, lucene или sphinx. Сегодня я хочу заглянуть с тобой «под капот» полнотекстового поиска и разобраться в первом приближении, как же он работает, на примере hh.ru.

image
Читать дальше →
Total votes 56: ↑54 and ↓2 +52
Views 29K
Comments 11

Небольшие трюки с Elasticsearch

Server Administration *Database Administration *
Небольшая заметка, скорее для себя, о мелких трюках по восстановлению данных в Elasticsearch. Как починить красный индекс если нет бэкапа, что делать если удалил документы, а копии не осталось — к сожалению в официальной документации об этих возможностях умалчивают.
Читать дальше →
Total votes 15: ↑14 and ↓1 +13
Views 11K
Comments 5