с базой (постгя)?
Вот есть, например, таблица с пользоватедями и их никами, бэкенды регулярно что-то там обновляют в никах. Мне хочется все эти данные с никами загрузить в эластик и через эластик осуществлять поиск по никам.
Есть, например, PgSync - приблуда, которая гоняет данные из пг в эластик, но она пипец глючная + работает на хранимках, переодически обваливает базу (не в правильном порядке инициализирует хранимки, что приводит к тому, что база кидает ошибки на любой апдейт в течение секунды) и может потерять данные (как раз из-за неправильной работы с хранимками)
Поднимать полноценный энтерпрайз ЕТЛ с произвольными коннекторами -- ну как-то жирно выглядит. И с ним потом опять проблемы наверняка будут.
Делать процедуру на бэкенде, которая сохраняет и в базу, и в эластик друг за другом тоже не хочу. Там тогда надо обрабатывать падающие транзакции, обходить кейсы, когда эластик затупливает, рейсы пойдут - звучит тоже как напряжно и ненадежно.
Кажется, было бы хорошим решением складывать в кафку диффы, а потом одним отдельным сервисом доставать и обновлять эластик. Но самому писать такое чот лениво, а готовых решений не нашел.
Может подскажете, что вообще сейчас в мире есть удобного для такой проблемы? Если что, мы в aws-е сидим, можем какие-то внутренние сервисы прикупить для этого
У нас реализовано на стороне бэкенда(отдельным микросервисом). После записи в базу формируется json для эластика и отправляется в кафку, потом отдельным сервисом пишется в эластик. Проблем действительно много, но чёт сомневаюсь, что есть готовое решение для этого.
Отдельный сервис сами писали?
Ну да. Это очень маленький сервис, который только пишет в эластик то, что получил по кафке. Микросервисы наше всё)). Из проблем могу отметить наличие задвоений и пропусков данных. Потому сразу могу посоветовать уникальный id выбирать самому на основе данных, а не отдавать на откуп эластику. Соответственно, при записи тогда лучше использовать index а не create api. Ну и метрики навесить, как оказалось у нас эластик падал пару раз и от этого образовались пропуски.
а зачем коммитить оффсет, если записать не получилось?
Саш а как ваще правильно готовить кафку?) 1 партиция = 1 читающий поток?
Да, оно по умолчанию так идёт
там вообще идет консьюмер на партицию, а каждый консьюмер это отдельный поток
Вот так сделали. Я с этой проблемой тока начал разбираться, смотрю что можно исправить.
Обсуждают сегодня