Redis vs Elasticsearch vs Sphinx для хранения данных и поиск по ним?

Question

[P747]

Добрый день!

Что по вашему лучше всего подойдет для хранения данных и поиск по ним, например каталог товаров? Чтобы удовлетворяло следующим условиям:

1. Хранение данных каталога с быстрым доступом
2. Поиске по информации, в особенности русскими названиями-запросами
3. Простота в использовании: синтаксис запросов, документация
4. Наименьшая нагрузка на "железо"
5. Отказоустойчивость
6. Безопасность
7. Масштабирование

Comments

[xmoonlight]

Всё что знали - написали?!)))

[P747]

xmoonlight, Не))

[xmoonlight]

P747, Вон, подтверждение моей догадки: выбрано ответом! ;)

Answer 1

[Иван Шумов]

Мммм, какой классный холивар, давайте я вставлю свои 5 копеек. Сначала прелюдия:
Redis:
это кэш с парой-тройкой фич. Не предназначен для хранения и поиска данных как класс

Elasticsearch, Sphinx:
Два принципиально разных поисковых движка. Хорошо делают свою работу, но не предназначены для хранения данных, только для хранения поисковых индексов.

1. Хранение данных каталога с быстрым доступом

Поскольку ни одна их указанных систем не является базой данных стоит задуматься о другом виде баз данных. В зависимости от того что выберете то и масштабировать придется по-разному

2. Поиске по информации, в особенности русскими названиями-запросами

Это умеет сегодня любой поисковый движок

3. Простота в использовании: синтаксис запросов, документация

Документация есть у всех адекватных поисковых машин, синтаксис везде достаточно простой

4. Наименьшая нагрузка на "железо"

А вот тут начинаем смеяться. Если мы говорим о поиске то первое правило - все выделенные ресурсы что вы выделите будут съедены. Даже если у вас 100 товаров по 2кб. Память будет съедена первой, потом получит свою порцию и процессор

5. Отказоустойчивость

Это не про поиск, а про архитектуру, сеть, сервера, и все в таком духе. Если что то горизонтальное масштабирование поисковых машин это боль - все хорошо пока не сломалось и там очень часто кластер не восстановись

6. Безопасность

Опять не про поисковые машины. Есть 3 части: encryption in transit (ssl), encryption at rest (AES), auth (зависит от движка). В принципе все и так поддерживают сегодня

7. Масштабирование

И снова не про поиск, а про архитектуру. Вертикально масштабировать проще всего в облаках и дорого, горизонтально масштабировать - больно

Comments

[xmoonlight]

Я ж говорю: автор, всё, что знал - сказал)))

[Иван Шумов]

xmoonlight, да ты сам хорош - советуешь отмирающий solr, который объединяется с lucene, на котором и так работает elasticsearch)

[xmoonlight]

Иван Шумов, ))
1. Я советую вообще ничего не юзать, а делать нормально с нуля.
2 А про отмирающий - давай-ка, доказательство!)

[Иван Шумов]

xmoonlight, извини, не предоставлю. Эту информацию получил от нашего Competency Center по Search. От них пришила информация что сейчас идет активно объединение solr и lucene. Коллеги туда активно контрибьютят

[xmoonlight]

Иван Шумов,

извини, не предоставлю. Эту информацию получил от нашего Competency Center по Search.

Ну, вот и ответ, показывающий твою некомпетенцию в данном вопросе.

[Иван Шумов]

xmoonlight, ну, мне не нужно иметь компетенцию во всем, а выделенной группе людей, которые кроме как поиском ничем не занимаются последние лет 10 я склонен доверять, особенно когда это несколько сотен человек

[xmoonlight]

Иван Шумов,

которые кроме как поиском ничем не занимаются последние лет 10 я склонен доверять, особенно когда это несколько сотен человек

Скока лет несколько сотен поиск то делают и никак не сделают?!! Кому там доверять?!!

Ответ на вопрос автора, который ты написал, это они надиктовали все хором или это твои личные домыслы?

[Иван Шумов]

OnYourLips, это правда только от части. Мы пробовали так делать и это очень быстро показало непригодность идеи

[Иван Шумов]

xmoonlight, это все мой опыт кроме части про lucene - это я выцепил из общения с коллегами в конце того года

[xmoonlight]

Иван Шумов,

это все мой опыт

))
Куда там сотням с 10 годами-то до тебя))

Итог: Генерировать "ссылки на несуществующий источник", не предоставлять доказательств и вводить всех в заблуждение, чтобы казаться компетентным - это все, что ты научился делать.

P747, советую подумать прежде, чем следовать советам в этом ответе...

[Иван Шумов]

xmoonlight, опровергнуть предоставленную мной информацию ты тоже не можешь)

[xmoonlight]

Иван Шумов, этого и не требуется: достаточно того, что ты уже наговорил про свой опыт...

[Иван Шумов]

xmoonlight, Окей, это твоё мнение

[xmoonlight]

Иван Шумов, Возможно, что ничего не исключено.

[Иван Шумов]

OnYourLips, логи можно потерять, это не критические данные системы, к ним другие требования

[P747]

Иван Шумов, Одно только не понял, почему нельзя использовать поисковые движки как хранилище? Можно же в индекс добавить колонки, например название товара, ссылку на картинку, цену и т.д.

[Иван Шумов]

P747, во-первых по тому что способ хранения и обработки данных рассчитан на поиск, а не на обработку: забудьте о транзакциях и блокировках. Вторая часть - консистентность, регулярно происходит необходимость удаления индекса для изменения маппинга для поиска и данные при этом не сохранить. Тут проще иметь отдельную базу и механизм загрузки данных в индекс.

[Иван Шумов]

Bavashi, в эластике невозможно изменить маппинг без удаления индекса. Все новые поля он типизирует самостоятельно и если новое поле должно быть строкой, но первое значение а него будет, например, "12345" то оно примет его как число и больше строки принимать не будет. И много других подводных камней.

[P747]

Иван Шумов, Я имею ввиду в качестве кэша для фронтенда, а не вместо БД

[Иван Шумов]

P747, а, ну как кэш-то пожалуйста) только Redis и Memcached быстрее как кэш (получение по ключу) и кушают меньше памяти и процессора

[Иван Шумов]

Bavashi, совсем последние, признаюсь, не смотрел. Что касается Java то никаких проблем не вижу, вообще) Просто был уже опыт, облизано со всех сторон и было принято во всех проектах использовать инструменты только по прямому назначению.

[P747]

Иван Шумов, Так как вы говорите Redis не поисковой движок, уже по нему не поищешь полноценно получается)

[Иван Шумов]

Bavashi, ну, вообще не слышал и не замечал подобную тенденцию. Вообще, по многолетней практике, если кто-то пытается делать 2 вещи то получаются обе хуже чем одна. Я изучаю много разных подходов в проектах, и чем дальше тем чаще применяется Single responsibility принцип, даже для баз

[Иван Шумов]

P747, все так) но свою работу он выполняет на ура и на уровне с ним только memcached) Ну, есть еще пара других вещей в виде In-memory data grid

[P747]

Иван Шумов, Не могли бы вы статью на хабре написать об особенностях и тонкостях эластика и сфинкса?

[Иван Шумов]

P747, настолько детальная статья не в моей компетенции. Примерно представляю что будут ожидать читатели от подобной статьи и даже знаю нескольких людей кто делает это куда лучше

[P747]

Иван Шумов, Вкратце, с какими вы проблемами можно столкнуться при использовании эластика, сфинкса?

[Иван Шумов]

P747, в вкратце это не описать - это большие системы и проблемы зависят от частных случаев

Answer 2

[ManticoreSearch]

DISCLAIMER: сотрудник Manticore
---------------------------------------------
Посмотрите на Manticore Search (форк Sphinx).

1. Хранение данных каталога с быстрым доступом

Да, хранение есть по дефолту:

➜  ~ docker run --name manticore --rm -d manticoresearch/manticore && \
docker exec -it manticore mysql && \
docker stop manticore

992d3e61b7949f82c16b472f4947c81fee58f2a720aa5bbba4fe478383583661
MySQL [(none)]> create table f(name text, color string);
MySQL [(none)]> insert into f(name,color) values('Something good', 'red');
MySQL [(none)]> select highlight() from f where match('good');
+-----------------------+
| highlight()           |
+-----------------------+
| Something <b>good</b> |
+-----------------------+
MySQL [(none)]>

2. Поиске по информации, в особенности русскими названиями-запросами

Всё, как в Sphinx, только charset_table не нужно писать. Дефолта обычно достаточно для всех языков.

3. Простота в использовании: синтаксис запросов, документация

Дока тут https://docs.manticoresearch.com/
Интерактивные курсы здесь https://play.manticoresearch.com/
В частности про синтаксис запросов https://play.manticoresearch.com/fulltextintro/

4. Наименьшая нагрузка на "железо"

Чуть лучше, чем в Sphinx https://manticoresearch.com/2019/05/14/benchmark_m...

5. Отказоустойчивость

Есть репликация https://play.manticoresearch.com/replication/

6. Безопасность

Есть поддержка https для JSON-протокола https://play.manticoresearch.com/https/

7. Масштабирование

Как в Sphinx

Answer 3

[xmoonlight]

Ни один из перечисленных!
Собственная разработка с грамотной архитектурой будет лучше любого из существующих решений.

Если нет возможности проектирования под свою задачу и создания полноценного решения с "нуля" - берите solr.

Comments

[Мирон]

И как это сочетается с требованием №1

Хранение данных каталога с быстрым доступом

Solr это индекс текста для поиска NLP или похожего, так же на Lucene.
Хранилище данных + быстрый доступ + индексация и быстрый поиск по контексту, это три противоречивых требования, которые пока не выполнил ни один производитель ПО в полном объеме.
Вопрос, которым из 7 требований озвученных в вопросе можно пожертвовать? :)))

Answer 4

[Пума Тайланд]

Редис явно не туда попал
А так под ваши запросы больше сфинкс подходит