Найти - Пользователи
Полная версия: Система синхронизации приложений на разных машинах. Архитектура.
Начало » Python для экспертов » Система синхронизации приложений на разных машинах. Архитектура.
1 2
Ashedu
Доброго дня.

Хочу сделать синхронизацию (частичное обновление данных) для, например, двух копий программы, работающих с одной базой данных. То есть, при внесении изменений в базу с одной машины, должно происходить это же изменение на другой.

Как этого достичь? Программа должна быть особым образом построена или достаточно отслеживать изменения в базе данных? (Используется MySQL)

doza_and
Ashedu
при внесении изменений в базу с одной машины, должно происходить это же изменение на другой
А архитектура у вас какая? Если поднят сервер MYSQL , то все данные и будут общие. Т.е вроде как автоматом будет как вы хотите. Или вы автономно будете программы использовать, а потом сливать базы?
Ashedu
doza_and
А архитектура у вас какая? Если поднят сервер MYSQL , то все данные и будут общие. Т.е вроде как автоматом будет как вы хотите. Или вы автономно будете программы использовать, а потом сливать базы?
При загрузке программы берется информация из базы, отображается, хранится в памяти. Некоторая информация обновляется при открытии доп. диалогов, но в основном окне наполнение не имеет синхронизации.
Например в основном окне список лиц:
1. Ваня, 12.12.90. муж.
2. Катя, 13.12.90 жен.

И если эти записи меняются в базе, надо это как-то отлавливать эти изменения и обновлять в программе.
doza_and
Если система слабо нагружена более естественно просто обновлять данные по таймеру.
Не являюсь специалистом по MYSQL в Firebird использовал реализованные в ней события http://www.janus-software.com/fbmanual/manual.php?book=php&topic=49

Первое впечатление что в MySQL это странно сделано http://stackoverflow.com/questions/5771925/python-how-to-get-notifications-for-mysql-database-changes

Кроме того, если вы будете опираться на механизм передачи сообщений базы данных то вы сильно будете привязаны к именно к этой базе.

Тут уже начинается область священных войн. Где обеспечивать целостность данных, на уровне приложений или на уровне движка СУБД. (MySQL наше все а программки к ней можно писать на разных языках или, сравните, моя программа это все, доступ к данным только через мои процедуры - а движки баз можно к ней разные цеплять.)

Я как программист предпочитаю подход 2. В этом случае механизм уведомлений нужен независимый от базы. Мне например нравится https://pypi.python.org/pypi/Pyro4
Для простых проектов можно воспользоваться http://docs.python.org/2/library/asyncore.html
http://docs.python.org/2/library/asynchat.html

Можно смотреть в сторону RabbitMQ.
Lexander
doza_and
Если система слабо нагружена более естественно просто обновлять данные по таймеру.
Исходя из описания, выбора особого нет и этот вариант хоть и простой, зато самый эффективный.
Так что +1.
Архитектурно это реализация Push-сообщений через периодические запросы клиента.
Все остальные варианты в лучшем случае требуют серьезных доработок типа промежуточного сервера приложений или смены СУБД.

Если клиенты мобильные и есть ограничение на трафик, то периодически обновлять все данные по таймеру - дорого, поэтому небольшая доработка все равно нужна.
В алгоритм изменения данных отслеживаемых таблиц нужно добавить код, поднимающий флаг изменений.
К MySQL сделать запрос, который будет проверять и по запросу от клиента возвращать статус: есть изменения / нет изменений (чуть сложнее - где они произошли: какие именно наборы данных обновить).
Потом уже пользователь либо сам обновляет данные, либо программа делает это автоматом.
Ashedu
doza_and
Если система слабо нагружена более естественно просто обновлять данные по таймеру.
Lexander
Так что +1.
По таймеру я делать принципиально не хочу. Данных много, дергать огромные таблицы, затем отрисовывать - медленный процесс. Именно из-за этого захотелось более осмысленного обновления.

doza_and - спасибо за ссылки, ушел курить документации.

Lexander
К MySQL сделать запрос, который будет проверять и по запросу от клиента возвращать статус: есть изменения / нет изменений (чуть сложнее - где они произошли: какие именно наборы данных обновить).
Спасибо. А вам случйно не встречались примеры реализации?
Lexander
Ashedu
По таймеру я делать принципиально не хочу. Данных много, дергать огромные таблицы, затем отрисовывать - медленный процесс. Именно из-за этого захотелось более осмысленного обновления.
Понятно и логично.
Тогда придется делать посредника и задействовать технологию Comet или WebSockets.
Исходя из описания задачи, думаю, Long Polling будет вполне достаточно, Streaming вам не нужен.
Есть готовые решения на Гитхабе.
Например, Orbited и Orbited2 - 2 реализации сервера, Twisted-Comet или Diesel.
А можно вообще Tornado взять.

Ashedu
А вам случйно не встречались примеры реализации?
Именно под MySQL не видел, но не факт что их нет, просто не было надобности.

Какая у вас хоть клиентская платформа?

Под осмысленным обновлением вы понимаете инкрементальное обновление данных или все же допустима полная перезагрузка данных при изменении (когда уже точно известно, что изменения были)?

Допустимо ли изменение структуры таблиц? Можно просто добавить автобновляемое поле поле timestamp и простым запросом COUNT по этому полю узнать о факте изменений в таблице.
А два таких поля позволят даже вычислить строки, которые обновлялись.
Ashedu
Lexander
Какая у вас хоть клиентская платформа?

Под осмысленным обновлением вы понимаете инкрементальное обновление данных или все же допустима полная перезагрузка данных при изменении (когда уже точно известно, что изменения были)?

Допустимо ли изменение структуры таблиц? Можно просто добавить автобновляемое поле поле timestamp и простым запросом COUNT по этому полю узнать о факте изменений в таблице.
А два таких поля позволят даже вычислить строки, которые обновлялись.

Под windows всё работает, в том числе и база, сидящая на локалхосте.
Чтобы не было недопониманий и критики в сторону вышесказаного - структура такова:
- Программа состоит из пакета (сама программа + mysql сервер), что позволяет работать ей автономно, а так же каждый компьютер может выступать в роли БД.
- Каждая другая копия программы может подключится к удаленной БД. Так и организовывается работа с одной базой.
Собственно ничто не запрещает вынести базу на выделеный сервер и подключать все копии программ к нему.
Но всё это консумерки души. И не должно влиять на решение поставленой задачи.

Полная перезагрузка недопустима, от этого и бежим. Обновлять нужно только то, что изменилось.

Да, изменение таблиц допустимо… Но даже если в каждой строке будет запись о времени изменения, по которой мы дернем нужные данные для обновления, всё равно придется использовать таймер, что в данном случае, возможно, допустимо, но всё равно коробит. Коробит потому что в моем опыте постоянно возникали проблемы наподобие “MySQL server has gone away” при осуществлении запросов через треды.
doza_and
:( https://github.com/mcarter/orbite
d2 не откликается
Ashedu
что позволяет работать ей автономно
Ashedu
а так же каждый компьютер может выступать в роли БД
Ashedu
Да, изменение таблиц допустимо…

У вас большая команда? При такой общей постановке может оказаться очень большая сложность приложения.
Как вы будете делать слияние изменений? Как распространяются изменения схем базы?

Если все это в самом деле надо, я бы смотрел уже в сторону такого “противотанкового ружья” mongodb+Celery….
Понимаю, программа есть, переделывать не хочется. Тогда надо максимально упростить постановку. Например отказаться от возможности работы без сервера.
Lexander
https://pypi.python.org/pypi/orbited
https://bitbucket.org/desmaj/orbited
https://github.com/gameclosure/orbited2
http://labs.gameclosure.com/orbited2/

Ashedu
Но даже если в каждой строке будет запись о времени изменения, по которой мы дернем нужные данные для обновления, всё равно придется использовать таймер, что в данном случае, возможно, допустимо, но всё равно коробит.
В MySQL нет реализации механизма Notifications, как в Postgres, MS SQL Server или Oracle.
Поэтому даже готовые сторонние решения сводятся в периодическому опросу, т.е. через таймер.
Ashedu
Коробит потому что в моем опыте постоянно возникали проблемы наподобие “MySQL server has gone away” при осуществлении запросов через треды.
Так не используйте треды.
Это известная проблема при написании многопоточных программ.
Исправляется введением одного менеджера соединений или пула соединений, которому потоки скидывают в очередь запросы, а он их выполняет и возвращает потокам результат.

А еще вам нужно подумать, если еще не подумали, над извечным вопросом нескольких синхронизируемых баз - разрешением конфликтов слияния данных.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB