Как стать автором
Обновить

Комментарии 12

Плохо ходить в эластик с фронта. Это всё-таки БД, хоть и с http интерфейсом: авторизация, изменение схемы, обновление версий, это всё будет приносить боль в такой схеме.

Впрочем он он всегда будет приносить боль, я бы отметил некоторое количество недостатков.
1) Невозможность изменить схему после создания. Мапинги можно добавлять только на новые поля, если изначально неправильно был выбран тип поля, а он 100% будет выбран неправильно при сколько-нибудь сложной схеме данных, что бы изменить мапинги придется полность пересоздать индекс и перелить в него данные.
2) Невозможность перешардирования на лету, как это например сделано в кассандре. Шард это физическая сущность, которая всегда привязана к ноде, если количество шардов не делится на количество нод, а так будет всегда при горизонтальном масштабировании, что бы изменить количество шардов нужно пересоздать индекс и перелить в него данные.
3) Неуправлемое кеширование полей, пресловутая fielddata. Размер fielddata зависит от параметров запроса, если он большой, инстанс упадет в OOM, если его ограничить инстанс перейдет в режим CB и производительность сильно упадет.
4) Это jvm, со всеми вытекающими плюсами и минусами. Из минусов, ограничение на вертикальное масштабирование из размера хипа(а его займет та самая fielddata), накладные на GC, не самая выдающаяся производительность.
5) Отсутсвие нормальной авторизации, её либо не будет совсем, либо это будет сквозное шифрование.
6) Пертурбации с лицензирванием.


Эти недостатки, мне кажется, общеизвестны и частично описаны в документации. Когда для схожей задачи был выбран эластик пару лет назад, очень надеялся что это все проблемы, но была обнаружена еще одна. Пункт 3 и 4 из списка выше, выливаются в ботлнек на поиск в виде нескольких тысяч rps на 1 ноду. При нагрузке выше начинается гонка при получении блокировки к fielddata cache и дальнейшее масштабирование возможно только увеличением колчества нод и шардов.

Какие есть альтернативы эластику?

Можно использовать индексы в postgres, поддерживающие полнотекстовый поиск. Но у меня нет такого опыта. В монге, кажется, тоже есть поддержка.

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

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

Для небольших индексов, либо больших, но с низким рейтом поиска - эластик не плох.

В статье упоминается lucene - эластик работает поверх него. Есть еще tantivy

Советую рассмотреть bleve, 4 месяца назад ушел на него с эластика. Сказать доволен - ничего не сказать. Bleve вообще не потребляет ресурсов по сравнению с эластиком, работает шустро, и дает полный контроль. Из минусов, нужно будет немного покодить на Go (хотя для меня это плюс).

Apache Solr. С шардированием все сильно проще. Тоже ява, но тут как и с эластиком, вертикально масштабировать можно, но аккуратно.

Есть еще OpenSearch - клон эластика от AWS с другой лицензией. И уже упомянутый Solr (он тоже на основе индекса Lucene)

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

У всех индексов стоит read-only флаг. Данные в этих индексах публичные, чувствительной информации в эластике не было вообще

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории