Архитектура MySQL. Когда несколько пользователей имеют локальную базу данных и все синхронизируются с облачной
Я создаю это веб-приложение в Node.js и MySQL, и я борюсь за синхронизацию данных.
Вот сценарий:
Предположим, у нас есть 1000 клиентов, у которых у всех есть локальная база данных веб-сервера в их офисе / сайте. Пользователь может войти в систему, редактировать данные, датографы данных и т. Д. Все эти действия, например, способствуют получению около 500 КБ табличных данных в день на клиента / сайт. Таким образом, у каждого из 1000 клиентов есть локальная база данных, которая будет постоянно обновляться новыми данными много раз в день.
В то же время для всех 1000 клиентов существует облачный сервис, который позволяет им войти в систему и посмотреть, что все их данные, как если бы они присутствовали локально на месте. Они также могут вносить изменения из облака, редактировать / создавать / удалять данные.
Теперь у меня есть следующие проблемы:
Каждый сайт должен быть синхронизирован с облачным сервером. Что вы порекомендуете? (Репликация с несколькими хозяевами? Кластеризация? Написать собственную?) Каковы плюсы и минусы?
Что делать, когда сайт клиента находится в автономном режиме и новые данные добавляются как в локальную, так и в облачную базу данных? Как обычно происходят конфликты и слияния?
Заранее спасибо!
3 ответа
Мнение из личного опыта: Репликация MySQL плохо масштабируется. Если ваша синхронизация не удалась, вам понадобится какой-то механизм для уведомления и восстановления. Если у вас есть тысяча из них, вы будете выполнять много оперативной работы.
Другое мнение: рассмотрим отслеживание изменений. Когда любой конец вносит изменение, передайте это изменение в систему управления изменениями. В предопределенное время пусть оба конца заблокируют изменения, оба конца запустят процесс отбраковки дубликатов из журнала изменений, а затем оба конца обновят свою базу данных без дубликатов. Наконец, разблокировать изменения. В то же время, оба конца написаны для ознакомления с системой изменений для составления списка ожидающих изменений.
Это непростая ситуация: у вас есть крупномасштабный дистрибутив. Насколько это возможно, сводите к минимуму движущиеся части, чтобы уменьшить количество точек обслуживания.
Представьте себе параллельную реальность, когда банкоматы не имеют связи с банком, они работают с копией базы данных и синхронизируются только к концу дня.
Вы сможете доехать до каждого банкомата в городе и многократно снимать все имеющиеся у вас деньги. Они заметят мошенничество только тогда, когда вы уже миллионер и покидаете страну.
Это просто пример, но вы видите, что даже если вы разберетесь в механике синхронизации, у вас все равно могут возникнуть непредвиденные проблемы, не только с изменением значений, но и с созданием разных записей с одним и тем же первичным ключом и т. Д. Это может быть серьезной проблемой.,
Я считаю, что нет общей технологии решения этого, вообще. Вы должны внимательно изучить аспекты синхронизации каждого отдельного действия, которое ваше приложение может выполнить в базе данных. Возможно, в процессе будет создан исполняемый скрипт SQL, который будет использоваться для синхронизации, я не знаю.
Репликация Mysql не является чем-то, на что можно положиться для этой цели.
Однако, если вы согласны на хранилище, основанное только на документах, решение Couch DB сможет решить эту проблему. Мы использовали базу данных дивана в течение некоторого времени, и это в значительной степени решило эту проблему, когда мы синхронизировали локальную базу данных дивана с кластером дивана сервера. Я знаю, что это старый пост, но я надеюсь, что кто-то найдет это полезным. Удачи!