Стоит ли использовать Elasticsearch в качестве основной бд?

Question

[blantcat]

Структура данных хорошо ложится в NoSQL. Нужен и поиск.
Встал вопрос, можно ли в качестве основной бд использовать Elasticsearch ? По сути это же и хранилище и поиск.
Подскажите, пожалуйста, какие могут быть проблемы?

Answer 1

[Иван Шумов]

Elasticsearch не является базой данных, а просто поисковым индексом. Использовать его как БД нельзя ни в коем случае.
- никакой консистентности
- никакого ACID
- управление доступом только в коммерческой версии за много денег
- чтобы изменить тип данных в документе надо изменить маппинг только через полное пересоздание индекса
- лимит по выдаче данных. Проблемы начинаются уже после первой тысячи в поиске ибо рассчитан он изначально на выдачу 1-3 результатов
- эластик ест столько памяти сколько есть на виртуалке. Дашь ей 2 Tb RAM и будь уверен - он займет все

Comments

[Andrey Shatokhin]

Ну тут вы немного переборщили.
NoSQL и ACID - такое вообще мало где успешно работает.
Управление доступом - фаерволы отменили чтоли? А групповые политики нужны мало кому. Это ж не публичное облако.
Пересоздание индекса - reindex api
Проблемы на 1000 станице выдачи? В Postgresql/mysql открыть 1000 страницу результатов запроса тоже очень больно.
Память - это джава же. Сколько напишешь в jvm.options столько и скушает. Вы вообще эластик настраивали сами?

[Иван Шумов]

Добавлю - для работы с данными абсолютно нормально использовать:
- реляционную базу для управления данными (Mysql, Postgres, MsSQL, Oracle, ....)
- поисковый индекс (Elasticsearch, Sphinx) для поиска
- NoSQL или Cache для агрегатов (Mongo, Redis, ....)
- Колоночные базы данных для аналитики (OLAP) (Clickhouse, Hbase, ...)

[Иван Шумов]

Andrey Shatokhin, да и это очень болезненно. ACID нужен для управления данными, поэтому базу без этого вообще использовать не стоит. NoSQL решения они вообще разнонаправленные и то о чем говорит ТС это document DB. Там надо

По доступам - файрволы это только первая зона обороны. Мало спасает ибо если на сервер проникли то привет, а еще же надо давать разным клиентам разные права

Про пересоздлание индекса - reindex api работает с такой скоростью что лучше бы не работал вообще. Данные из базы не должны иметь задержек во время таких операций (еще раз - эластик не база, а поисковый индекс)

По памяти - ограничивать эластик плохо по тому что inverted index и работа с алгоритмами требует очень много памяти.

[Andrey Shatokhin]

Иван Шумов,
База без ACID? т.е mongo у нас до 4.2 версии не юзабельна была? а Amazon DocumentDB и сейчас нельзя использовать?

Если на сервер проникли - у вас в коде/окружении/секретах/снимке памяти и так есть все для доступа к базе.

Reindex api - Пользуемся им часто и оно намного быстрее чем ALTER в реляционных базах при смене типа.

По памяти - вот реально как будто не настраивали эластик. Первый вопрос новичка с эластиком на бою - как ему дать более 2гб памяти. И в нем нет опции безлимит на память. О чем вы вообще?

[Иван Шумов]

Andrey Shatokhin,

База без ACID? т.е mongo у нас до 4.2 версии не юзабельна была? а Amazon DocumentDB и сейчас нельзя использовать?

Монго и сейчас это делать на самом деле не научилась, хоть и старается. MongoDB и DocumentDB только для документов. Связи есть, но лучше про них забыть ибо на втором уровне они уже проблема

Если на сервер проникли - у вас в коде/окружении/секретах/снимке памяти и так есть все для доступа к базе.

Не путаем сервер приложения и сервер базы данных. Первый доступен из интернета, как правило, а второй по хорошему нет

Reindex api - Пользуемся им часто и оно намного быстрее чем ALTER в реляционных базах при смене типа.

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

По памяти - вот реально как будто не настраивали эластик. Первый вопрос новичка с эластиком на бою - как ему дать более 2гб памяти. И в нем нет опции безлимит на память. О чем вы вообще?

Я видел эластик, которому 128Gb RAM было мало) впечатлений было море

[Иван Мельников]

т.е mongo у нас до 4.2 версии не юзабельна была?

Mongo неюзабельна в качестве основного хранилища данных. А вот как слой кэша она вполне юзабельна.

[Иван Шумов]

Иван Мельников, как слой кэша есть куда более вкусные инструменты)

[Иван Мельников]

Иван Шумов, какие?

[Иван Шумов]

Иван Мельников,
- добавление отдельных таблиц/документов
- datalake
- realtime миграция базы
- трансформеры
- ETL
- ...

от проекта зависит. можно придумать много чего интересного

[Vitaly Karasik]

эластик ест столько памяти сколько есть на виртуалке

Это не так.
См. настройки JVM.

управление доступом только в коммерческой версии за много денег

Это уже не так - начиная с 6.8/7.1

чтобы изменить тип данных в документе надо изменить маппинг только через полное пересоздание индекса

А в SQL по-другому?

[Иван Шумов]

Vitaly Karasik,

Это не так.
См. настройки JVM.

Эта фраза всегда подразумевала что эластик есть много и чтобы работать адекватно быстро ему приходится постоянно увеличивать лимит сколько он будет жрать

Это уже не так - начиная с 6.8/7.1

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

А в SQL по-другому?

во-первых не в SQL, а в реляционных базах данных, а во-вторых - да

[Vitaly Karasik]

Иван Шумов,

А в SQL по-другому?

во-первых не в SQL, а в реляционных базах данных, а во-вторых - да

AFAIK, в MySQL and Postgres это так. (Да, я знаю, что есть и другие реляционные БД, я говорю про широко используемые)

Эта фраза всегда подразумевала что эластик есть много и чтобы работать адекватно быстро ему приходится постоянно увеличивать лимит сколько он будет жрать

Это релевантно для любых баз данных, ИМХО, а для полнотекстового поиска - вдвойне.

Ну, то есть только последние полгода.

Но и раньше это не было showstopper - всегда были методы организовать access control.

[Иван Шумов]

Vitaly Karasik,

AFAIK, в MySQL and Postgres это так. (Да, я знаю, что есть и другие реляционные БД, я говорю про широко используемые)

В эластике изменение маппинга это реально снос индекса как бы там что не говорили про reindex api. В БД все-таки таблицы для этого никто не удаляет, время для перестройки индекса существует, да, но в это время просто проседает перфоманс. В эластике же надо заново наполнить его данными

Это релевантно для любых баз данных, ИМХО, а для полнотекстового поиска - вдвойне.

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

Но и раньше это не было showstopper - всегда были методы организовать access control.

не находил вменяемых. если не сложно поделиться - буду благодарен

[blantcat]

Иван Шумов
почитав диалог, теперь вообще засомневался, стоит ли брать ту же монгу как основное хранилище )

[Иван Шумов]

blantcat, и это тоже правильная мысль) каждому инструменту свое применение на самом деле. К тому же без знания инструмента лучше действовать наверняка, а новые инструменты пробовать на каких-то небольших историях и только потом вводить в проект

[Vitaly Karasik]

Иван Шумов,

Но и раньше это не было showstopper - всегда были методы организовать access control.

не находил вменяемых. если не сложно поделиться - буду благодарен

Я работал с X-Pack (деньги не showstopper для серьезных проектов), с Nginx в кач-ве фронтенд, и с сервисами которые обеспечивали контроль (Elastic, Logz.io)
Вариант, про который читал - https://search-guard.com/.

[phikus]

Иван Шумов,

Я видел эластик, которому 128Gb RAM было мало) впечатлений было море

А это не тот случай, когда не рекомендуется выделять эластику больше 32Гб?

[Иван Шумов]

phikus, возможно, деталей не помню, но вообще это далеко не предел)

[phikus]

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

[bozuriciyu]

А ничего что Монга тоже отжирает всю память , причем не отдает ее обратно? Т.е. на один сложный запрос отожрала пару Гигов - и все, без перезагрузки процесса она его не отдаст))

[Иван Шумов]

bozuriciyu, кластер и рестарт нод по кругу - типовая задача для девопсов)

[Иван Шумов]

phikus, все возможно, но я уже не в том проекте и как-то даже не интересно как там дела)

Answer 2

[Andrey Shatokhin]

Я бы не использовал. По причини боли при мажорных обновлениях. А они бывают не редко.
1. Нужно переиндексировать все индексы в актуальную версию перед обновлением на следующую. (reindex api спасает, но все равно не приятно делать на горячей бд)
2. В мажорных обновлениях часто меняют типизацию. В NoSQL с нестрогой типизацией это всегда неожиданно.
3. Бекапы старых версий не развернуть на новых. Бекап с возрастом в пару лет становится тыквой прям по определению.
4. Проблемы производительности если хранить много лишних данных в индексах. (Кушает память на весь документ, а не только на нужные поля - часто срабатывает gc, который кушает проц. Уменьшается эффективность кеша)
5. И главное. Он асинхронный. т.е запись в выдаче появляется не сразу. Это иногда приводит к сложностям в коде

Answer 3

[Иван Мельников]

Назначение ElasticSearch – быстрый поиск. Как в ElasticSearch вы будете поддерживать согласованность данных?
При этом, если в будущем планируется расширение на кластер, то надо помнить, что в ElasticSearch отсутствуют кластерные транзакции.

Answer 4

[Vitaly Karasik]

Как всегда ответ - "зависит". Зависит от ваших данных, от апликации. От того, насколько преимущества полнотекствого поиска перекрывают недостатки Elastic.
Посмотрите дискуссию здесь например https://discuss.elastic.co/t/elasticsearch-as-a-pr...