Использование elasticsearch в качестве центрального хранилища данных

в настоящее время мы используем elasticsearch для индексирования и выполнения поиска по документам 10M. Он отлично работает и мы довольны его работой. Мой коллега, который инициировал использование elasticsearch, убежден, что его можно использовать в качестве центрального хранилища данных, а другие системы данных (например, SQL Server, Hadoop/Hive) могут иметь данные. У меня не было никаких аргументов против этого, потому что мои знания слишком ограничены. Однако я обеспокоен.

Я знаю эти данные в elasticsearch хранятся эффективным способом для текстового поиска. Hadoop хранит данные так же, как файловая система, но таким образом, чтобы эффективно масштабировать/реплицировать блоки над несколькими узлами данных. Поэтому, на мой взгляд, более полезно использовать Hadoop (поскольку он более агностический w.r.t его представление о данных) в качестве центрального хранилища данных. Затем нажмите данные из Hadoop в SQL, elasticsearch и т. д...

Я прочитал несколько статей о Hadoop и elasticsearch случаи использования, и кажется обычным использовать Hadoop в качестве центрального хранилища данных. Однако я не могу найти ничего, что указывало бы на то, что elasticsearch не будет достойной альтернативой.

Пожалуйста, Помогите!

6
elasticsearch hadoop

2 ответов

Я бы настоятельно рекомендовал большинству пользователей не использовать elasticsearch в качестве основного хранилища данных. Он будет отлично работать, пока ваш кластер не расплавится из-за сетевого раздела. Даже такие настройки, как minimum_master_nodes, которые всегда устанавливаются ES pros, не спасут вас. См. Этот отличный анализ Aphyr с его серией Call Me Maybe: http://aphyr.com/posts/317-call-me-maybe-elasticsearch

eliasah, правильно, это зависит от вашего варианта использования, но если ваши данные (и работу) для тебя важно держаться подальше.

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

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

4

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

Elasticsearch-отличная поисковая система с открытым исходным кодом, построенная поверх Apache Lucene. Его функции и обновления позволяют ему в основном функционировать так же, как хранилище данных JSON без схемы, к которому можно получить доступ с помощью методов поиска и обычных команд CRUD-like базы данных.

тем не менее все преимущества Elasticsearch, которые приносит, есть еще некоторые основные недостатки:

  • безопасность - Elasticsearch не предоставляет никаких функций аутентификации или контроля доступа. он поддерживается, так как у них есть ввел щит.

  • сделки - нет поддержки транзакций или обработка на обработка данных. Ну теперь манипуляция данными обрабатывается с logstash.

  • долговечность - ES распределен и довольно стабилен, но резервные копии и долговечность не имеют такого высокого приоритета, как в других хранилищах данных.

  • зрелость инструменты - ES все еще относительно новый и не успел разработать зрелые клиентские библиотеки и сторонние инструменты, которые могут сделать разработку намного сложнее. Мы можем считать, что он уже достаточно зрелый с разнообразием разъемов и инструментов вокруг него, как платформы Kibana. Но он по - прежнему не подходит для больших вычислений-команды для поиска данных не подходят для "больших" сканирований данных и расширенных вычислений на стороне БД.

  • Наличие Данных - ES делает данные доступными в "почти реальном времени" , что может потребовать дополнительных соображений в вашем приложении (т. е. страница комментариев, где пользователь добавляет новый комментарий, обновление страницы может фактически не отображаться новый пост, потому что индекс все еще обновляется).

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

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

отказ от ответственности: этот ответ был написан некоторое время назад для Elasticsearch 1.x-серия. Эти критики все еще как-то стоят с 2.x-серия. Но Elastic работает над ними, как 2.серия x поставляется с более зрелыми инструментами, API и плагинами, например, security wise, например щит или даже транспортные клиенты, такие как Logstash или ударов, etc.

6