Уведомления

Группа в Telegram: @pythonsu

#1 Май 18, 2013 19:07:38

Ashedu
Зарегистрирован: 2012-11-23
Сообщения: 22
Репутация: +  0  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

Доброго дня.

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

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

Офлайн

#2 Май 18, 2013 19:13:46

doza_and
От:
Зарегистрирован: 2010-08-15
Сообщения: 4138
Репутация: +  252  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

Ashedu
при внесении изменений в базу с одной машины, должно происходить это же изменение на другой
А архитектура у вас какая? Если поднят сервер MYSQL , то все данные и будут общие. Т.е вроде как автоматом будет как вы хотите. Или вы автономно будете программы использовать, а потом сливать базы?



Отредактировано doza_and (Май 18, 2013 19:14:41)

Офлайн

#3 Май 18, 2013 19:21:00

Ashedu
Зарегистрирован: 2012-11-23
Сообщения: 22
Репутация: +  0  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

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

И если эти записи меняются в базе, надо это как-то отлавливать эти изменения и обновлять в программе.

Офлайн

#4 Май 19, 2013 09:26:32

doza_and
От:
Зарегистрирован: 2010-08-15
Сообщения: 4138
Репутация: +  252  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

Если система слабо нагружена более естественно просто обновлять данные по таймеру.
Не являюсь специалистом по 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.



Офлайн

#5 Май 19, 2013 11:56:23

Lexander
От:
Зарегистрирован: 2008-09-19
Сообщения: 1139
Репутация: +  33  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

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

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



Офлайн

#6 Май 19, 2013 12:46:07

Ashedu
Зарегистрирован: 2012-11-23
Сообщения: 22
Репутация: +  0  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

doza_and
Если система слабо нагружена более естественно просто обновлять данные по таймеру.
Lexander
Так что +1.
По таймеру я делать принципиально не хочу. Данных много, дергать огромные таблицы, затем отрисовывать - медленный процесс. Именно из-за этого захотелось более осмысленного обновления.

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

Lexander
К MySQL сделать запрос, который будет проверять и по запросу от клиента возвращать статус: есть изменения / нет изменений (чуть сложнее - где они произошли: какие именно наборы данных обновить).
Спасибо. А вам случйно не встречались примеры реализации?

Офлайн

#7 Май 19, 2013 14:17:23

Lexander
От:
Зарегистрирован: 2008-09-19
Сообщения: 1139
Репутация: +  33  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

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

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

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

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

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



Офлайн

#8 Май 19, 2013 14:43:34

Ashedu
Зарегистрирован: 2012-11-23
Сообщения: 22
Репутация: +  0  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

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

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

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

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

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

Да, изменение таблиц допустимо… Но даже если в каждой строке будет запись о времени изменения, по которой мы дернем нужные данные для обновления, всё равно придется использовать таймер, что в данном случае, возможно, допустимо, но всё равно коробит. Коробит потому что в моем опыте постоянно возникали проблемы наподобие “MySQL server has gone away” при осуществлении запросов через треды.

Офлайн

#9 Май 19, 2013 16:23:32

doza_and
От:
Зарегистрирован: 2010-08-15
Сообщения: 4138
Репутация: +  252  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

:( https://github.com/mcarter/orbite
d2 не откликается

Ashedu
что позволяет работать ей автономно
Ashedu
а так же каждый компьютер может выступать в роли БД
Ashedu
Да, изменение таблиц допустимо…

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

Если все это в самом деле надо, я бы смотрел уже в сторону такого “противотанкового ружья” mongodb+Celery….
Понимаю, программа есть, переделывать не хочется. Тогда надо максимально упростить постановку. Например отказаться от возможности работы без сервера.



Офлайн

#10 Май 19, 2013 19:49:36

Lexander
От:
Зарегистрирован: 2008-09-19
Сообщения: 1139
Репутация: +  33  -
Профиль   Отправить e-mail  

Система синхронизации приложений на разных машинах. Архитектура.

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” при осуществлении запросов через треды.
Так не используйте треды.
Это известная проблема при написании многопоточных программ.
Исправляется введением одного менеджера соединений или пула соединений, которому потоки скидывают в очередь запросы, а он их выполняет и возвращает потокам результат.

А еще вам нужно подумать, если еще не подумали, над извечным вопросом нескольких синхронизируемых баз - разрешением конфликтов слияния данных.



Отредактировано Lexander (Май 19, 2013 19:52:21)

Офлайн

Board footer

Модераторировать

Powered by DjangoBB

Lo-Fi Version