![]() |
|
Модераторы: LSD, AntonSaburov |
![]()
|
|
| unkis |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 802 Регистрация: 8.9.2004 Репутация: нет Всего: 1 |
Ребята подскажите пожалуйста, существует ли готовое решение, алгоритм или метод для синхронизации двух таблиц в разных базах данных?
У меня следующая задача: Есть Клиент (К) - Сервер (С) приложение. На клиенте установлена H2 база данных а на Сервере MySQL. Общаются они между собой при помощи Вебсервися. Задача заключается синхронизавать одну одинаковую таблицу находящуюся на Клиенте и на Сервере. Данные в эту таблицу могут писаться как на клиентской стороне так и на серверной. Прежде чем изобретать велосипед хотел узнать у вас, может кто-то сталкивался с таким и знает в какую сторону смотреть? Спасибо -------------------- www.unkis.com |
|||
|
||||
| COVD |
|
||||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1655 Регистрация: 26.7.2005 Репутация: 17 Всего: 43 |
Возможно, надо искать решение не в контексте синхронизации баз данных, а как синхронизацию кеша. Клиентов, по определению, может быть много. А сервер один. Поэтому обычно синхронизируют клиентов с сервером, но не наоборот. Клиентская база данных по сути обычно является разновидностью клиентского кеша. Отсюда следует, что клиент должен сначала внести изменение в мастер-таблицу на сервере, и только потом, в случае успеха, продублировать это в локальном кеше, т.е. в вашем случае в локальной таблице. Локальный кеш, вообще говоря, необязателен. Тогда и проблемы синхронизации нет. Синхронизация локального кеша предполагает использование понятия версии. Например, это время последнего обновления. Один из вариантов - клиенты периодически посылают на сервер условный запрос, где в хедере указывается имеющаяся на клиенте версия.
"distributed cache", "in-memory data grid", .. - там вопросы синхронизации решены, но такие системы предполагают в основном внутрисерверное применение, т.е. там мультикаст, тср. Например, Hazelcast. Это сообщение отредактировал(а) COVD - 15.1.2011, 17:57 |
||||
|
|||||
| Старовъръ |
|
|||
![]() Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 491 Регистрация: 8.5.2008 Репутация: 4 Всего: 10 |
Distributed Cache - здесь, по-моему, не причем, вопрос о синхронизации таблиц, а не кешей; хотя с другой стороны, если все записи будут проходить через кеш, то, наверно, как-то можно расширить распределенный кеш, чтоб он в БД клал данные при изменении оных на другой машине. Data Grid - это вообще по сути замена базы данных, т.к. данные хранятся постоянно в памяти, а в обычную БД как правило пишутся только для архивации.
По-моему задача вообще решается не на уровне баз данных. Если данные пишутся только из самих приложений, то можно какой-то механизм оповещений придумать, как и предложил COVD, - с optimistic lock'ом. В противном случае мм.. проблема однозначно есть -------------------- |
|||
|
||||
| v2v |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1620 Регистрация: 20.9.2006 Где: Киев Репутация: 8 Всего: 56 |
Допустим что клиенты сидят на "дайл-апе" с большим временем ожидания и маленькой скоростью, представляете сколько будет занимать времени обновления данных в бд на сервере. Да ещё если специфика задачи требует регулярную запись в таблицы, так это вообще ужас клиентского интерфейса. Я уж не говорю про мобильных клиентов, которые могут вообще без подключения к серверу работать. Как же им сохранять данные? Ответ.. клиентская бд. Теперь по сути. На параллельном проекте в прошлой контори писали приложение с клиентской и серверной бд. На сколько я помню прикрутить что либо реальное для репликаций им не удалось, в итоге создавался велосипед. Собственно мне тоже не известны решения по объединению MySQL и H2. Но MySQL и MySQL однозначно подружить можно. Вам стоит определится что будет проще: свой велосипед, или другие технологии? Это сообщение отредактировал(а) v2v - 17.1.2011, 00:10 |
|||
|
||||
| COVD |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1655 Регистрация: 26.7.2005 Репутация: 17 Всего: 43 |
Но ведь раз встает задача синхронизации, значит эта клиентская бд не основное хранилище данных, а .. локальный персистент кеш. Нет? |
|||
|
||||
| v2v |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1620 Регистрация: 20.9.2006 Где: Киев Репутация: 8 Всего: 56 |
впервые слышу такое понятие. Погуглив немного, нашёл такую ссылку. таким образом данное понятие и ассоциируется с ембедед(клиентской) бд . |
|||
|
||||
| COVD |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1655 Регистрация: 26.7.2005 Репутация: 17 Всего: 43 |
Браузер сохраняет загруженные странички на диске. Говорят, что браузер кеширует. Не вижу принципиальной разницы, когда сохраняется в локальную базу данных. ОК, не применяют термин, значит не применяют.
|
|||
|
||||
| Старовъръ |
|
|||
![]() Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 491 Регистрация: 8.5.2008 Репутация: 4 Всего: 10 |
Ну вообще да - это вполне катит на название локального кеша. Единственное в таком случае все данные, которые берутся из-вне и сохраняются, можно называть локальным кешем
Это сообщение отредактировал(а) Старовъръ - 19.1.2011, 09:41 -------------------- |
|||
|
||||
| COVD |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1655 Регистрация: 26.7.2005 Репутация: 17 Всего: 43 |
А если не "из-вне"? Если программа использует локальную базу данных, которую надо раз в сутки синхронизировать с чем-то, то, возможно, эта программа вовсе не "клиент", а терминал, рабочая станция, или еще что-то? |
|||
|
||||
![]()
|
| Правила форума "Java" | |
|
|
Если Вам помогли, и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, LSD, AntonSaburov, powerOn, tux, javastic. |
| 1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | Java: Общие вопросы | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |