Есть ли веская причина для использования Elasticsearch REST API для приложения JVM?

Я работаю над приложением Java, используя, среди прочего, Elasticsearch.

До сих пор я использовал клиент узла Java. Затем некоторое время назад я услышал от некоторых коллег, что REST API предпочтительнее по следующим причинам:

  1. Возможность обновления Elasticsearch без изменения версии транспортного клиента, т. е. версия клиента Java зависит от того, какая версия запущена в кластере ES.
  2. Клиенты узла/транспорта будут объявлены устаревшими в следующих выпусках?
  3. Безопасность

Я сейчас пытаюсь выяснить, сколько это держится.

Что касается № 1, состояние документации Elasticsearch что (обычно) достаточно, чтобы клиент и кластер ES имели одну и ту же основную версию. Таким образом, REST API на самом деле не предлагает ничего лучшего.

Затем №3 обрабатывается Shield.

Про №2 ничего не нашел.

Из приведенной выше информации единственная причина, по которой я могу захотеть использовать REST API в своем приложении Java, — это независимость от версии, просто на всякий случай. Кроме этого, не так много; это правда правда? И правда ли, что клиент узла/транспорта будет объявлен устаревшим?


java rest jvm transport elasticsearch
person Haris Osmanagić    schedule 29.03.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я не эксперт по ES, но мы просто задаем себе одни и те же вопросы, и вот наши мысли по этому поводу.

  1. ES client version vs. ES server version :
    • Native client follow the rules you stated: major version compatibility. It was not the case until recently and for really specific features (Percolator for instance), this is still not (breaking changes on minor versions),
    • Кажется, Jest, лучшая абстракция HTTP-клиента на сегодняшний день, имеет те же ограничения: документация говорит версия 1.x не работает с 2.x,
    • Последним решением было бы использовать HTTP-клиент низкого уровня, но с потерей хороших плавных абстракций Java. Это не выдерживает сравнения,
    • Вы не можете обращаться к смешанной версии ES с приложением Java на основе собственного клиента (в случае гетерогенных сред с экземплярами как 1.x, так и 2.x). Это должно быть возможно с HTTP-клиентом и, таким образом, может облегчить, например, некоторые сценарии прогрессивной миграции.
  2. Native client deprecation :
  3. Security :
    • basic HTTP security is easy to setup with some middleware if needed (Apache frontend for instance) or using https://github.com/Asquera/elasticsearch-http-basic,
    • Shield официальный, работает как с нативным, так и с HTTP, но не бесплатный…

В нашем приложении мы используем Spring Data ES. Очень прост в использовании, с очень небольшим количеством строк кода, но страдает отставанием версии (поддержка 2.x через 6 месяцев после выпуска ES 2) и основан на собственном клиенте. С нашей точки зрения, компромиссы стоят повышения эффективности разработки.

Наконец, SAAS предлагает только HTTP API, поэтому в этом случае у вас нет выбора.

person Doc Davluz    schedule 12.04.2016
comment
Альфа 5.0 уже существует, поэтому прямо сейчас и, основываясь на ваших отзывах, мне кажется лучшей идеей придерживаться нод-клиента, пока у ES не появится собственный HTTP-клиент. Тогда будет проще определиться.: ) Спасибо большое! - person Haris Osmanagić; 13.04.2016