fox_12
@fox_12
Расставляю биты, управляю заряженными частицами

Версионирование данных в базе?

Есть база с несколькими таблицами на сервере.
Есть база на неком клиенте.
На сервере данные время от времени меняются. Допустим - структура базы не меняется. Допустим что после каждого изменения мы инкрементируем версию данных.
Теперь некий клиент обращается через АПИ к базе, указывая свою версию, в ответ мы должны в АПИ отдать некий json, в котором мы указываем какие записи необходимо добавить/изменить/удалить для синхронизации данных между версией на сервере и версией клиента, затратив на это как можно меньше ресурсов и минимизировав число запросов и данных отсылаемых от сервера, так как клиенты - мобильные...
Казалось бы - задача типовая - но толком данных в сети по реализации не нахожу.
Пока добавил к таблице версию, и при каждом изменении добавляю данные с версией. Но данный костыль не видится особо эффективным. Допустим в таблице около миллиона записей, а в в следующей версии вносятся пару изменений - приходиться во-первых хранить дубль данных, а во-вторых - лопатить миллионы записей на предмет изменений между версиями.
Где можно найти информацию на данную тему? Возможно можно как-то использовать другие движки бесплатных баз данных под это дело? Возможно где-то есть готовая реализация?
  • Вопрос задан
  • 1437 просмотров
Пригласить эксперта
Ответы на вопрос 5
@VasyaM13221
1) клиент хранит дату последней репликации с сервером.
2) сервер при каждом обновлении строки обновляет столбец changetAt у строки.
3) клиент при подключении отправляет на сервер дату своей последней репликации с сервером.
4) сервер делает выборку по дате и отправляет id строк клиенту
5) клиент смотрит какие id ему нужны и делает запрос на их обновление
Ответ написан
zoonman
@zoonman
CEO @ LinuxQuestions.ru
Если у вас в таблице 500к записей, то нет абсолютно никакого смысла скачивать ее всю на телефон за исключением одной ситуации - режима работы оффлайн. В данном случае просто делается актуальный слепок, архивируется и отправляется к клиенту. Скачать 100 МБ с телефона сейчас не проблема. При наличии интернета гораздо проще делать запросы через API.

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

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

Для обычных баз данных в режиме совместной работы настраивайте мастер-мастер репликацию с транзакциями. Для мобильных приложений используйте режим тонкого клиента.
Ответ написан
petermzg
@petermzg
Самый лучший программист
Записывайте не версию, а время изменения состояния записи.
И будет достаточно получить все изменения которые произошли после указаного времени.
Ответ написан
Если вам нужно прям версионирование - смотрите SQL:2011 и его реализации под нужные вам РСУБД.

Если вам нужна всё-таки репликация, причём между разношёрстными базами и участниками процесса - посмотрите на www.symmetricds.org
What are some examples of using database replication?

Remote offices replicated to a central office
Cross platform database replication between different databases
Replication between on-premise databases and cloud databases
Consolidation of multiple databases into a data warehouse
Regional database replication to improve access times for local users
High availability of a database using a primary and secondary instance


Насчёт конфликтов и "гита для табличных записей" - тут действительно всё непросто, я вот взялся писать диссер на эту тему..
Ответ написан
@MechanID
Админ хостинг провайдера
Вы изучили родные механизмы репликации в mysql (там попроще) а потом и в postgresql ? они вам не подходят ? есл да то опишите почему ?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы