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

Я работаю над поисковой панелью с возможностями полнотекстового поиска, поддерживаемой ES. Поиск будет первоначально потребляться приборной панелью пользовательского интерфейса. Я планирую создать прикладной уровень веб-службы приложений (WS) между панелью мониторинга пользовательского интерфейса и ES, который будет направлять бизнес-поиск в ES.

В будущем может быть несколько клиентов для WS, каждый со своими собственными бизнес-сценариями и сложными требованиями к данным (в основном поля ответов). В них много сущностей и огромное количество полей. Каждый клиент должен будет указать, какие поля сущностей он хочет вернуть с какими полями.

Чтобы поддержать это динамически изменяющееся требование, один из подходов может заключаться в том, чтобы WS был проходом к ES (с предварительной проверкой, такой как контроль доступа и последующее преобразование в ответ от ES). API-интерфейсы WS будут выглядеть точно так же, как API-интерфейсы ES, пользовательский интерфейс должен создавать запросы ES через JS-клиент и отправлять его в WS, который после контроля доступа будет получать данные из ES.

Я новичок в ES и скептически отношусь к этому подходу. Могут ли быть какие-то особые проблемы в этом подходе. Один из моих коллег работал над ES раньше, но всегда с бэкэнд-клиентом Java, поэтому он не слишком уверен.

Я посмотрел клиента ES Js, и здесь есть официальный.

Некоторый контекст здесь:

У нас есть около 4 различных объектов (может увеличиться в будущем) с полными текстовыми полями и полями типа ключевых слов. Типичный поиск может иметь несколько фильтров и поисковых терминов и может указывать поля результатов. Кроме того, некоторые поиски будут проходить между объектами, а некоторые - отдельными. Мы поддерживаем отдельную сущность для каждой сущности.

Всего 1 ответ


Что я понимаю из вашего поста, ниже - это то, чего вы хотите достичь на высоком уровне.

В будущем может быть несколько клиентов для WS, каждый со своими собственными бизнес-сценариями и сложными требованиями к данным (в основном поля ответов)

И поскольку вы не уверены, как это сделать, вы думаете о том, чтобы собирать запросы Elasticsearch из Javascript только в своем интерфейсе. Я не очень большой поклонник этого подхода, так как он раскрывает, как вы строите запросы и если какой-то хакер знает важную информацию, подобную приведенной ниже, то может поставить весь ваш кластер ES на колени:

  1. Знает, какие типы подстановочных запросов.

  2. Знает имена индексов и сведения о кластере ES (хотя у вас может быть контроль доступа, но вы все равно предоставляете важную информацию).

  3. Как вы строите свои поисковые запросы.

Выше приведено лишь несколько примеров, которые добавят больше информации.

Правильный подход

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

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


Есть идеи?

10000