Насколько надежным является ElasticSearch в качестве основного хранилища данных против таких факторов, как потеря записи, доступность данных

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

Было бы много источников данных и будет хранить их в Поисковом хранилище. Может потребоваться предварительное вычисление исходных данных, которое может быть выполнено промежуточными компонентами.

Я просмотрел несколько блогов, чтобы понять, можно ли надежно использовать ES в качестве основного хранилища данных. В основном это зависит от того, какой прецедент мы ищем. Некоторая информация о используемом случае:

Около 300 миллионов записей каждый год с 1-2 КБ.
Предполагая хранить данные за 1 год, сегодня мы имеем 300 ГБ, но прецедент может увеличиться до 400-500 ГБ при росте данных.
На данный момент не уверен, как мы будем продвигать данные, но, грубо говоря, это может достигать 2-3 миллионов записей за 5 минут.
Запрос поиска низкий, но требует сложных запросов, которые могут искать данные за последние 6 недель до 6 месяцев.
документ будет проиндексирован почти во всех полях документа.

В некоторых блогах утверждается, что он достаточно надежен для использования в качестве первичного хранилища данных -

И некоторые блоги говорят, что у ES мало ограничений -

Кто-нибудь использовал Elastic Search в качестве единственной истины данных без первичного хранилища, такого как PostgreSQL, DynamoDB или RDS? Я посмотрел, что у ES есть определенные проблемы, такие как раздвоенные мозги и коррупция индекса, где может быть проблема с потерей данных. Итак, я ищу, чтобы узнать, пользовался ли кто-то ES и какие проблемы с данными

Спасибо.

Ответ 1

Короткий ответ: это зависит от вашего варианта использования, но вы, вероятно, не хотите использовать его в качестве основного хранилища.

Более длинный ответ: вы должны действительно понимать все возможные проблемы, которые могут возникнуть в результате отказоустойчивости и потери данных. У Elastic есть некоторая отличная документация по этим проблемам, которую вы должны действительно понять, прежде чем использовать ее в качестве первичного хранилища данных. Кроме того, Сообщение Афира по теме - хороший ресурс.

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

Ответ 2

Как правило, рекомендуется создавать избыточные решения для хранения данных. Например, это может быть быстрый и надежный подход, чтобы сначала просто нажимать все, как плоские данные, на статическое хранилище, такое как s3, тогда есть данные ES pull и index from. Если вам нужна большая гибкость при использовании ORM, у вас может быть слой RDS или Redshift между ними. Таким образом, данные всегда могут быть восстановлены в ES.

Это зависит от ваших потребностей и требований, как вы устанавливаете баланс между резервированием и гибкостью/производительностью. Если есть много данных, вы можете хранить исходные данные статически и просто индексировать некоторые его части с помощью ES.

Amazon Lambda предлагает отличные возможности:

Многие разработчики хранят объекты в Amazon S3 при использовании Amazon DynamoDB для хранения и индексирования метаданных объекта и обеспечения высокоскоростного поиска. AWS Lambda упрощает синхронизацию, запуская функция автоматического обновления индекса в Amazon DynamoDB каждый временные объекты добавляются или обновляются с Amazon S3.