Привет! =) Задача стоит такая. Есть источник данных, пусть это будет mongodb база, есть целевое хранилище данных, пусть это будет тоже mongodb база. Бизнес ставит задачу: Хочу мигрировать данные из источника в целевое хранилище с минимальным временем простоя сервисов которые работают с базой источником и базой целевого назначения. Предположим, что у нас база источник будет называться source, а целевая база будет иметь имя target. Отлично! Теперь предполагаем, что у нас с базой source работает много приложений, больше сотни, и все они пишут в source, читают оттуда данные и обновляют их, а также удаляют данные. И есть ещё сотня сервисов которые работают с базой target, они там тоже устраивают междусабойчик, пишут много, читают много. Формальная задача: Обеспечить миграцию данных из source базы в target базу с сохранением структурности данных. Т.е. есть в source базе бд с именем test, в бд с именем test существует коллекция users, коллекция users имеет структуру документа
{
"_id": Number(),
"firstname": String(),
"lastname": String(),
"age": Number(),
"email": String()
}
Необходимо получить структурность из source db/test/users в target db/test/users с сохранением всех данных
Для решения задачи необходимо использовать: kafka в однонодовой инсталляции mongodb Source в однонодовой инсталляции mongodb Target в однонодовой инсталляции kafka-connect в однонодовой инсталляции
Т.к. сервисов много, необходимо использовать докер образы. Желательно создать overlay сеть, в сети запустить контейнеры и обращаться по именам контейнеров как по dns. Чтобы данная задача была решена, просто в mongoDb данные вычитывать не получится, нужна реактивность, реактивность достигается через чтение журнала Oplog коллекцию. Operation Log (журнал операций) Данный журнал oplog становится доступен только после старта базы в replicaSet режиме. Для ReplicaSet режима не требуется кластер, можно его запустить и на одной ноде mongoDB, но если хочется, можно поднять и полный replicaSet в минимум трёх нодах. Примеры с поднятием ReplicaSet mongo в Docker есть на официальном сайте. Либо умельцы подготовили всё за вас. =)
На выходе должен быть docker-compose.yml или bash script (кому как удобнее), которым будет запускаться решение где: MongoSource Kafka kafka-connect mongoTarget И когда я зайду в mongoSource, в базу test, в коллекцию users опубликую данные, то эти данные должны появиться в mongoTarget, в базе test, в коллекции users. По желанию можно добавить kafka-ui, тогда это будет ещё один компонент в docker-compose.yml или bash script. Kafka-ui позволяет смотреть потоки данных в kafka, рулить connectors, topics, clusters и т.д. Обязательно должен быть README.md или любой другой файл в репозитории с описанием запуска и работы вашего решения. Всё положить в репу на github или gitlab, кому как удобно, главное публично!
Требуется именно перекачка данных из MongoSource в MongoTarget! Обратной совместимости делать не нужно! Так, позаботился на всякий случай.
Задача такая же как и с mongoDB, но теперь у вас есть проблема... Разработчики сперва имели схему MongoDb в коллекции users такого вида
{
"_id": Number(),
"firstname": String(),
"lastname": String(),
"age": Number(),
"email": String()
}
Но потом пришли другие разработчики и что-то поменялось, теперь схема такая ''' { "_id": String(), "firstname": String(), "lastname": String(), "age": LongInt(), "email": String(), "sex": String() } "'''
Вот тут есть проблема с типами данных, которые необходимо поправить при вставке в базу Для этого можно использовать либо Schema Registry, либо самопальный воркер который будет читать из топиков kafka и сам всё складывать в target DB.
Не рекомендую, но предлагаю написать свой воркер на nodejs, python (что хотите), его задача максимально тупая "Взять данные, проверить тип поля, преобразовать тип поля, положить в базу. Можно взять faust-streem на python. Schema Registry просто сложнее, но кто разберётся, будет молодец! =)
На выходе у вас будет всё тоже самое, что в задаче с mongoDB первого варианта, только добавляется воркер как ещё одна сущность в docker-compose.yml или bash script. Не забываем про README.md!
Тут всё не так как у людей. Есть kafka, в неё кто-то или что-то кидает данные, мы не знаем кто или что такое делает, для нас это магия. Что нам известно, это формат данных который приходит в топик kafka и есть clickhouse. Бизнес говорит "Хочу все данные из топика metrics в kafka складывать автоматически в ClickHouse в табличку metrics и потом что-то там считать" Понимаем, что данные метрические, какие-то значения и их может быть много, много столбиков будет в ClickHouse и ClickHouse нам хорошо подходит для этого дела. Магия как была с MongoDB не прокатит, тут мы просто читаем из Kafka и кладём в ClickHouse. Так вот, чтобы сотворить такую штуку, надо сам ClickHouse подключить к kafka. да-да, просто коннекторов найти нельзя. Есть в ClickHouse движок kafka engine который специально был создан и используется для связности между kafka и ClickHouse. Тут мы просто шагаем в доку по ClickHouse (она на русском и подробная) и просто поднимаем решение.
Понятно, что я ожидаю docker-compose.yml или bash script который запустит мне kafka clickHouse Schema Registry Kafka-ui на усмотрение В итоге должно быть так, что закинув объект в топик kafka он появится в ClickHouse
Какой объект, какого формата, тут ваш разум пусть думает, ограничений нет. Главное описать всё в README.md и положить в репу!
Я работаю на os Linux Debian 11 Если ваше решение заточено под другую систему и оно у меня не взлетит, я не буду фиксить его в порывах запуска. Ваша задача сотворить всё универсально или устроить демодей в реалтайме, как вариант, подключение по ssh. Представьте, что у вас максимально тупой заказчик, который просто хочет решение, без всяких там README.md больших и кучи технических особенностей. У вас есть вводная информация от заказчика по задачам и информация по окружению OS Linux Debian 11, процессор Intel на архитектуре amd64 (x64), оперативной памяти в 16 GB и хранилка NVME SSD на 1 TB, есть свежий docker, containerd и docker-compose. Удачи! По всем вопросам писать можно мне в t.me/ravino_doul Но в силу большого завала, я отвечаю не всегда быстро, можно часто пушить, это допускается.