FWIW В прошлой жизни я работал на веб-сайте электронной коммерции, на котором было 4 разных серверных базы данных. (Mon go, MySql, Redis, ElasticSearch), так что больше 1 не является проблемой вообще, но вам нужно рассматривать одну базу данных записи, IE, если между ними ничего не совпадает, одна источник правды, другой подозреваемый. Для моего примера, Redis и ElasticSearch были почти эфемерными - взорвать их, и они воссоздаются из неподвластных mysql и mon go источников. Теперь mySql и Mon go одновременно были немного странными, и мы были вынуждены медленно перемещаться. Это означает, что различные типы записей были переведены с MySql на mon go. Этот процесс выглядел примерно так: - Уровень ORM записывает как mysql, так и mon go, чтение все еще происходит из MySql. - данные регулярно сравниваются. - прошло несколько месяцев без каких-либо нарушений, записи в MySql отключены, а чтения перенесены в понедельник go.
Конечная цель больше не была MySql, все было в понедельник go. Я понизил эту касательную, потому что кажется, что вы могли бы делать подобное - записывать в обе базы данных на любом используемом вами уровне абстракции базы данных (ORM, DAO, другие вещи, которые я не в курсе с et c.) И в конечном итоге переместить читает в зависимости от того, где они должны go. Если вам нужны большие пакеты для записи, вы можете буферизовать на этом уровне абстракции, пока не будет достигнут порог по вашему выбору, прежде чем отправлять его.
С учетом всего сказанного, в зависимости от сложности ваших данных, ночное задание ETL будет вполне выполнимо, но вы сталкиваетесь с дополнительной сложностью управления и мониторинга этого дополнительного процесса. Другим потенциальным недостатком является то, что данные всегда устаревают за день.