Стратегия сетевого приложения., Помогите определиться, какой путь надежней. |
Здравствуйте, гость ( Вход | Регистрация )
Стратегия сетевого приложения., Помогите определиться, какой путь надежней. |
dzyk |
14.9.2008, 17:57
Сообщение
#1
|
Студент Группа: Участник Сообщений: 21 Регистрация: 13.4.2008 Пользователь №: 148 Спасибо сказали: 0 раз(а) Репутация: 0 |
Имеется приложение. Ядро - база данных SQLite(информация в таблицах изменяется 20-30 раз в день). Сейчас необходимо реализовать одновременное использование БД на нескольких компьюетрах "сети"(постоянных соединений нет, кто-то подключается, кто-то отключатеся, IP динамические, всего 5-6 машин).
Вот мои варианты. 1. Связать приложения по UDP и отсылать каждые х-минут контрольную сумму файла БД SQLite. Если не совпадает то коннект по TCP и клонирование самого свежего файла БД SQLite. 2. Поставить сервер MySQL|PostgreSQL|other (нереально, нет выделенного сервера) 3. Ваше предложение |
|
|
AD |
14.9.2008, 18:00
Сообщение
#2
|
Профессионал Группа: Участник Сообщений: 2003 Регистрация: 4.2.2008 Из: S-Petersburg Пользователь №: 84 Спасибо сказали: 70 раз(а) Репутация: 17 |
|
|
|
dzyk |
14.9.2008, 18:06
Сообщение
#3
|
Студент Группа: Участник Сообщений: 21 Регистрация: 13.4.2008 Пользователь №: 148 Спасибо сказали: 0 раз(а) Репутация: 0 |
|
|
|
Novak |
14.9.2008, 18:19
Сообщение
#4
|
Активный участник Группа: Участник Сообщений: 319 Регистрация: 15.3.2008 Из: Замкадыш Пользователь №: 121 Спасибо сказали: 28 раз(а) Репутация: 6 |
Может, стоит реализовать синхронизацию копий БД, которые хранятся на каждом компе, путём оповещения при каждом изменении?
Ещё вариант - попробовать реализовать своеобразный динамический сервер, то есть данную роль передавать при отключении. Для этого выстроить определённый порядок обращений (с начала по этому ip, потом по другому и т.д.). В любом случае при этом крайне желательны статические IP Но лучше всего было бы поставить на один компьютер нормальную СУБД, решается много проблем разом. |
|
|
dzyk |
14.9.2008, 18:55
Сообщение
#5
|
Студент Группа: Участник Сообщений: 21 Регистрация: 13.4.2008 Пользователь №: 148 Спасибо сказали: 0 раз(а) Репутация: 0 |
попробовать реализовать своеобразный динамический сервер Это самый интересный вариант, но сложно. Развивая Вашу идею: 1 Программы, живущие в настоящее время в сети, вещают в сеть свой IP+контр сумму файла БД+время жизни в онлайн 2 Если контр сумма не совпадает, то кешировавшиеся ранее SQL запросы передаются по TCP тем, кто был в оффлайне ?от программы, которая дольше всех живет в сети. Самое сложное - создать кэш запросов к БД SQLite, так как в программе используется в основном QSQLTableModel. |
|
|
Litkevich Yuriy |
14.9.2008, 19:08
Сообщение
#6
|
разработчик РЭА Группа: Сомодератор Сообщений: 9669 Регистрация: 9.1.2008 Из: Тюмень Пользователь №: 64 Спасибо сказали: 807 раз(а) Репутация: 94 |
SQLite не поддерживает транзакции, т.е. к БД одновременно сможет подключатся только одно приложение/компьютер/пользователь. Поэтому лучше использовать MySQL он как SQLite может быть встроен в приложение и работать с неким файлом. Но коль уж нет единого места для БД, то тогда видимо все равно какая БД.
Мой вариант такой - ставим на все тачки Git, у каждого своя копия файла БД и при необходимости работать с БД сначало обновляем свою копию БД, средствами Git, он в отличие от Subversion может работать с децентрализованой средой. Но пускать его видимо нодо будет руками, либо выдрать часть кода из QGit - Qt'явая оболчка для Git'а. |
|
|
Novak |
14.9.2008, 19:26
Сообщение
#7
|
Активный участник Группа: Участник Сообщений: 319 Регистрация: 15.3.2008 Из: Замкадыш Пользователь №: 121 Спасибо сказали: 28 раз(а) Репутация: 6 |
Всё же стоит выделить один комп для постоянной работы СУБД, пусть он даже и не будет чистым сервером))
Просто как представишь себе все проблемы работы в подобной децентрализованной среде.. |
|
|
ViGOur |
14.9.2008, 20:06
Сообщение
#8
|
Мастер Группа: Модератор Сообщений: 3296 Регистрация: 9.10.2007 Из: Москва Пользователь №: 4 Спасибо сказали: 231 раз(а) Репутация: 40 |
dzyk, мне кажется, что ты предложил самое оптимальное решение.
Только вот я не думаю, что целесобразно копировать весь файл бд, лучше просто передавать новые, изменившиеся или удаленные записи. Так как не понятно до каких размеров вырастет бд, и какая связь у клиентов с тобой. Например те же 10-20Gb постоянно передавать по сети 20-30 раз в день это не мало... |
|
|
dzyk |
14.9.2008, 20:41
Сообщение
#9
|
Студент Группа: Участник Сообщений: 21 Регистрация: 13.4.2008 Пользователь №: 148 Спасибо сказали: 0 раз(а) Репутация: 0 |
SQLite не поддерживает транзакции, т.е. к БД одновременно сможет подключатся только одно приложение/компьютер/пользователь не согласен. SQLite is a software library that implements a ... transactional SQL database engine. я не думаю, что целесобразно копировать весь файл бд Справедливое замечание. Но я не знаю как кэшировать SQL запросы, я ведь использую класс QSQLTableModel |
|
|
ViGOur |
14.9.2008, 22:21
Сообщение
#10
|
Мастер Группа: Модератор Сообщений: 3296 Регистрация: 9.10.2007 Из: Москва Пользователь №: 4 Спасибо сказали: 231 раз(а) Репутация: 40 |
Но я не знаю как кэшировать SQL запросы, я ведь использую класс QSQLTableModel Нужно подумать как обойти класс QSQLTableModel...Например у той же Berkeley DB аля логирование, файлы логов, которые создаются при добавлении новой записи, изменении или удалении. Но это как вариант стороны в которую капать... |
|
|
Текстовая версия | Сейчас: 26.11.2024, 21:59 |