Требуется ли для Elasticsearch CRUD refre sh? - PullRequest
Новая
       132

Требуется ли для Elasticsearch CRUD refre sh?

2 голосов
/ 20 июня 2020

Мне нужно синхронизировать c данные RDBS с Elasticsearch. Общий подход к достижению этого заключается в применении изменений в RDBS, а затем использовании очереди сообщений (или таблицы, используемой для ETL) для применения тех же изменений в ES.

Тот же блог Elasticsearch предлагает выдавать 1000 сообщений из очередь и pu sh их в массовом запросе со вставками, обновлениями и удалениями.

Известно, что ES работает в режиме реального времени NEAR, и требуется refre sh, прежде чем изменения будут видны поисковым запросам .

Учитывая этот факт, возникает вопрос: выполните ли CRUD операцию с EXPLICIT ID (GET, INSERT, UPDATE, DELETE), нужно обновить sh, если выполнено в ряду? Другими словами: находятся ли CRUD в строке В РЕАЛЬНОМ ВРЕМЕНИ?

Читая несколько статей, похоже, что они не нуждаются в refre sh, и они применяются в реальном времени, но я хотел бы получить подтвердите.

Для большей ясности: мне не нужно выполнять поиск запросы (где refre sh необходим, чтобы сделать изменения видимыми), но просто с использованием явного доступа по идентификатору. Я не возражаю , когда эти изменения станут видимыми для поиска.

Если два запроса CRUD выполняются подряд на ES:

  1. ИНДЕКС документ с идентификатором = 1

  2. ОБНОВЛЕНИЕ (или УДАЛЕНИЕ) документ с идентификатором = 1

Требуется ли 2) дождаться обновления sh чтобы увидеть 1)?

Если да, я не могу найти способ добиться согласованности между RDBS и ES, потому что одни и те же операции в строке завершатся обновленным (или удаленным) документом в RDBS, но не будет работать на ES из-за отсутствия refre sh.

1 Ответ

1 голос
/ 20 июня 2020

Короткий ответ:

Refre sh не требуется. Он будет последовательным, что означает, что операции выполняются по порядку. ES гарантирует, что последний запрос всегда будет успешным. И он делает изменения постоянными при каждом index/update/delete запросе.

В случае, если в другом сетевом разделе для идентификатора получено два запроса на запись, а затем один успешен первым, то более ранний не будет обновлен, поскольку согласованность достигается за счет управления версиями. Данные последней версии всегда успешны.

Длинный ответ:

Вам нужно рассмотреть множество концепций, таких как translog, fsync, consistency at ES, 'optimistic concurrency control', versioning, partitioning, availability.

ES обеспечивает согласованность с использованием управления версиями. Поэтому, когда вы отправляете index/update/delete запросы, он выполняет следующие действия на высоком уровне:

  1. Записывает его в журнал
  2. Делает его постоянным - есть свойство интервала по умолчанию. По истечении этого интервала или после каждой index/delete/update операции
  3. Отправляет запрос на узел
  4. Узел, получивший запрос, идентифицирует лидера раздела, которому принадлежат данные.
  5. Узел-лидер-раздела записывает данные и пересылает их на другие узлы-реплики, где этот раздел должен быть реплицирован.
  6. Как только все подтверждены, вернуть статус клиенту через начальный узел, который получил -the-request.

В этом есть много концепций / алгоритмов, чтобы сделать его мощной распределенной системой.

...