Я бы хотел синхронизировать некоторые таблицы MySQL в индекс ElasticSearch для поиска.
Но почти все примеры, которые я могу найти, показывают большой плохой жирный "SELECT * FROM", это нормально для примера, но я нахожусь в рабочей среде, приближаю 10 миллионов строк в одной из моих таблиц, поэтому я даже не хочу пробовать «ВЫБРАТЬ *» каждые две минуты.
Я привык к Сфинксу, и это
UPDATE ... SET current_id = last_id, last_id = MAX(id);
SELECT * WHERE id > (SELECT current_id...);
своего рода стратегия.
Я почти в порядке, но только «почти», поскольку элемент обычно имеет огромную вероятность быть измененным в первые минуты своей жизни, он будет проиндексирован «новорожденный» и останется как есть.
Так что я могу представить более эффективные стратегии, такие как триггеры, хранящие первичный ключ в таблице «для индексации», при обновлении и создании, когда река становится
SELECT * FROM ... WHERE id IN (SELECT id ... FROM to_index)
Никогда не пробовал, но кажется лучше, по крайней мере, лучше для начала.
Также есть вопрос об удаленных строках ...
Но могут существовать хорошо известные стратегии, хорошо обсужденные и проверенные, я их не нашел, не упустил ли я что-то важное? Или я единственный парень, который пытается избежать SELECT *
на миллионы сырцов?
В readme
немного длинновато, но об этом есть раздел:
https://github.com/jprante/elasticsearch-river-jdbc#how-to-select-incremental-data-from-a-table
Идея состоит в том, чтобы сохранить отметку времени на уровне микросекунд для изменений каждой строки и попросить ES выполнить запрос с момента последнего прогона реки:
{
"type" : "jdbc",
"jdbc" : {
"url" : "jdbc:mysql://localhost:3306/test",
"user" : "",
"password" : "",
"sql" : [
{
"statement" : "select * from \"products\" where \"mytimestamp\" > ?",
"parameter" : [ "$river.state.last_active_begin" ]
}
],
"index" : "my_jdbc_river_index",
"type" : "my_jdbc_river_type"
}
}