Комментарии 12
Лучше бы рассказали куда они raven плагины дели, удобно было
а можно ссылочку на то, о чем вы говорите?
Боюсь ссылочки найдутся очень старые. В ES 0.90x и до какой-то старшей версии была возможность приделывать river-jdbc плагин (тут я что-то затупил в прошлом комментарии raven!=river), которые сами коннектились в БД и тянули данные автоматически (в том числе апдейт записей). Потом, насколько я понял, решили, что это не очень с точки зрения производительности или еще каким-то причинам. С точки зрения удобности было замечательно в смысле отсутствия каких-то действий по изменению основного приложения (что сделать иногда не представляется возможным) на предмет добавления данных в индекс ES
Но что если пользоваться не LIKE, а MATCH… AGAINST, который решает и проблемы со скоростью и с релевантностью и с опечатками?
Не решает. Elasticsearch работает сильно быстрее и качественнее. Да и проще в плане фильтрации, релевантности и пр.
У меня примерно на 1 млн товарах MySQL с MATCH работало худо-бедно, а то и ложило сайт при набеге пользователей. Elasticsearch выдает результаты очень быстро.
Плюс, для MATCH нужно либо держть денормализованные данные (например, у меня поля товаров в соседней таблице и еще пара таблиц с другими данными), либо делать поиск по нескольким таблицам.
У меня примерно на 1 млн товарах MySQL с MATCH работало худо-бедно, а то и ложило сайт при набеге пользователей. Elasticsearch выдает результаты очень быстро.
Плюс, для MATCH нужно либо держть денормализованные данные (например, у меня поля товаров в соседней таблице и еще пара таблиц с другими данными), либо делать поиск по нескольким таблицам.
Странно, у меня на 1млн товаров поиск работает шикарно. И при этом характеристики сервера отнюдь не поражают воображение.
В чем проблема делать поиск по нескольким полям нескольких таблиц?
Проблема в скорости и нагрузке.
Ну смотрите, у меня есть (примерно, чтоб не вдаваться в подробности) следующие таблицы (число записей на текущий момент):
— каталоги (1220)
— сайты каталогов (1450)
— товары (2 300 000)
— наименования свойств товаров (4200)
— значения свойств товаров (8 200 000)
Все вместе около 3 Гб.
Точно уже не помню, но вроде как это все таблицы по которым должен искать поиск.
Все эти таблицы постоянно по 100500 раз в день меняются силами примерно 20 человек. Поиск должен работать в реальном времени, учитывать снятые с публикации товары и каталоги, учитывать морфологию, орфографические ошибки, ранжировать по разным параметрам. Все поля varchar либо text.
Не то чтобы это совсем не работало на MySQL, но работало оно медленно.
Может быть мои понятия «медленно» отличается от ваших, но с Elasticsearch я получаю ответ за 50-100 мс и это раз в 10 быстрее MySQL, но кстати довольно долго по меркам Эластика. Правда я уперся в память, да и так устраивает.
При этом load average: 1.59, 1.58, 1.64 — на текущий момент.
MySQL ложил полностью веб-сервер при наплыве людей, которых, кстати, не так и много.
Может быть я просто не умею его готовить, но Эластик мне показаться более… правильным вариантом под мою ситуацию.
Ну смотрите, у меня есть (примерно, чтоб не вдаваться в подробности) следующие таблицы (число записей на текущий момент):
— каталоги (1220)
— сайты каталогов (1450)
— товары (2 300 000)
— наименования свойств товаров (4200)
— значения свойств товаров (8 200 000)
Все вместе около 3 Гб.
Точно уже не помню, но вроде как это все таблицы по которым должен искать поиск.
Все эти таблицы постоянно по 100500 раз в день меняются силами примерно 20 человек. Поиск должен работать в реальном времени, учитывать снятые с публикации товары и каталоги, учитывать морфологию, орфографические ошибки, ранжировать по разным параметрам. Все поля varchar либо text.
Не то чтобы это совсем не работало на MySQL, но работало оно медленно.
Может быть мои понятия «медленно» отличается от ваших, но с Elasticsearch я получаю ответ за 50-100 мс и это раз в 10 быстрее MySQL, но кстати довольно долго по меркам Эластика. Правда я уперся в память, да и так устраивает.
При этом load average: 1.59, 1.58, 1.64 — на текущий момент.
MySQL ложил полностью веб-сервер при наплыве людей, которых, кстати, не так и много.
Может быть я просто не умею его готовить, но Эластик мне показаться более… правильным вариантом под мою ситуацию.
Или использовать тот же Sphinx для индексации mysql базы.
Из своего опыта использования Elastcisearch могу сказать, что лучше не использовать их нативный клиент. Лучше обходиться рест интерфейсом. Так как при переезде с одного мажорного релиза на другой будет очень много боли, как у меня было с 4 на 5.
Так же в примере отсылка документов в эластик включена в транзакцию. а что если транзакция свалится по «оптимистику», документ будет создан в эластике, следовательно и в поисковой выдаче будет присутствовать.
Так же в примере отсылка документов в эластик включена в транзакцию. а что если транзакция свалится по «оптимистику», документ будет создан в эластике, следовательно и в поисковой выдаче будет присутствовать.
поскольку, на мой взгляд, он лучший
Интересно было бы почитать, почему лучший в сравнении со Sphinx. Автор нигде больше это не обсуждает? Как, например, Аксенов: habrahabr.ru/company/oleg-bunin/blog/310208.
Доклад, по которому складывается впечатление, что все гладко и просто.
На деле — испытываю дискомфорт уже при стартовой настройке по официальной документации.
На деле — испытываю дискомфорт уже при стартовой настройке по официальной документации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как прикрутить нормальный поиск к устаревшему SQL-бэкенду