Вот что мы придумали. Используя столбец состояния с 3 значениями.
0 = Not indexed
1 = Updated
2 = Indexed
Будет 2 работы...
Задание 1 выберет первые X записей, где статус = 0, и поместит их в очередь, например RabitMQ. Затем потребитель массово вставит эти записи в ES и обновит статус записей БД до 1.
Для обновлений, поскольку мы контролируем наши данные... Сохраненная процедура SQL, которая обновляет эту конкретную запись, установит ее статус на 2. Job2 выберет верхние x записей, где статус = 2, и вытолкнет их на RabitMQ. Затем потребитель массово вставит эти записи в ES и обновит статус записей БД до 1.
Конечно, нам может понадобиться промежуточный статус для поставленных в очередь, чтобы ни одно из заданий снова не взяло ту же запись, но одно и то же задание не должно запускаться, если оно не завершено. Вероятность обновления записи в очереди невелика. Поскольку обновления происходят только в конце дня, обычно на следующий день.
Итак, я знаю, что есть реки (но они устарели и, вероятно, не гибки, как ETL)
Я хотел бы массово вставлять записи с моего SQL-сервера в Elasticsearch.
Напишите какое-нибудь запланированное пакетное задание, будь то ETL или любой другой инструмент, не имеет значения.
выберите из таблицы, где id › lastIdInsertedToElasticSearch, это позволит загружать последние записи в Elasticsearch с заданным интервалом.
Но что, если запись обновляется на сервере SQL? Что было бы хорошим шаблоном для отслеживания обновленных записей на сервере SQL, а затем отправки обновленных записей в ES? Я знаю, что у ES есть версии документов при указании одного и того же идентификатора. Но, кажется, не может визуализировать закономерность.
