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

Question

[Владимир Куц]

Есть база с несколькими таблицами на сервере.
Есть база на неком клиенте.
На сервере данные время от времени меняются. Допустим - структура базы не меняется. Допустим что после каждого изменения мы инкрементируем версию данных.
Теперь некий клиент обращается через АПИ к базе, указывая свою версию, в ответ мы должны в АПИ отдать некий json, в котором мы указываем какие записи необходимо добавить/изменить/удалить для синхронизации данных между версией на сервере и версией клиента, затратив на это как можно меньше ресурсов и минимизировав число запросов и данных отсылаемых от сервера, так как клиенты - мобильные...
Казалось бы - задача типовая - но толком данных в сети по реализации не нахожу.
Пока добавил к таблице версию, и при каждом изменении добавляю данные с версией. Но данный костыль не видится особо эффективным. Допустим в таблице около миллиона записей, а в в следующей версии вносятся пару изменений - приходиться во-первых хранить дубль данных, а во-вторых - лопатить миллионы записей на предмет изменений между версиями.
Где можно найти информацию на данную тему? Возможно можно как-то использовать другие движки бесплатных баз данных под это дело? Возможно где-то есть готовая реализация?

Comments

[Евгений Самсонов]

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

[Евгений Самсонов]

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

[Владимир Куц]

Евгений Самсонов, > Клиенту нужно выполнить все изменения последовательно
Как раз этого нужно избежать.
Допустим на версии 2 добавили миллион записей
на версии 3 этот миллион записей удалили, но добавили 2 новых записи

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

[Владимир Куц]

Иван, а где можно глянуть подобную реализацию? Если на входе мне просто нужно указать номера версий, а получить в итоге - что удалить/что добавить/а что изменить в таблице данных для синхронизации.

[Евгений Самсонов]

Владимир Куц, Тогда мержить изменения каждой записи и отдавать только те действия, которые актуальны. Если подумать, то, наверное, не так сложно это сделать

[Zhainar]

Как я понимаю, клиенты и сервер могут менять одни те же данные. Если клиент меняет данные, то на сервере должны быть данные клиента. Если сервер меняет данные, то на клиенте должны быть эти данные. Так?

[Владимир Куц]

Zhainar, нет - клиент данные не меняет. Он только таким образом синхронизирует свою версию базы с базой сервера.

[Zhainar]

Владимир Куц, тогда это похоже на репликацию, которую уверен можно настроить в любой базе с выбором нужных таблиц.

[Владимир Куц]

Zhainar,

тогда это похоже на репликацию

Не совсем. Нужно тянуть не историю, а разницу между состояниями таблиц произвольных версий

которую уверен можно настроить в любой базе с выбором нужных таблиц

Не совсем понятно как это сделать с БД на mysql/postgres и внешней произвольной структурой (в Json формате к примеру)

[Zhainar]

Владимир Куц, варианты предложены ниже. Но какая суть данного действия? Неправильные вопросы ведут к неправильным ответам.

[Владимир Куц]

> Но какая суть данного действия
суть описана в вопросе - минимизация пересылаемых данных при синхронизации разнородных стационарной и мобильной баз.

Answer 1

[Василий]

1) клиент хранит дату последней репликации с сервером.
2) сервер при каждом обновлении строки обновляет столбец changetAt у строки.
3) клиент при подключении отправляет на сервер дату своей последней репликации с сервером.
4) сервер делает выборку по дате и отправляет id строк клиенту
5) клиент смотрит какие id ему нужны и делает запрос на их обновление

Answer 2

[Philipp]

Если у вас в таблице 500к записей, то нет абсолютно никакого смысла скачивать ее всю на телефон за исключением одной ситуации - режима работы оффлайн. В данном случае просто делается актуальный слепок, архивируется и отправляется к клиенту. Скачать 100 МБ с телефона сейчас не проблема. При наличии интернета гораздо проще делать запросы через API.

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

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

Для обычных баз данных в режиме совместной работы настраивайте мастер-мастер репликацию с транзакциями. Для мобильных приложений используйте режим тонкого клиента.

Comments

[Владимир Куц]

Скачать 100 МБ с телефона сейчас не проблема

Проблема. Не везде 4G. Моб. клиент может находиться в зоне нестабильного приема 3G, а то и GPRS, в роуминге. По той же причине невозможна интенсивная работа с приложением в онлайн режиме.
Включить приложение в зоне нестабильного приема, получить пару-тройку коротких вчерашних-позавчерашних обновлений с БД чтобы как можно быстрее выйти в готовность к работе - далее интенсивная работа с данными оффлайн, и в итоге - короткий ответ серверу - основной режим работы.

При подключении клиент запрашивает обновление со временем последнего обновления и локальным временем (видел неправильно настроенные часы миллион раз)

Пока к такой схеме и склоняюсь, но поступаю проще - хранение номера версии данных. Клиент знает какая последняя версия у него, и делает запрос с номером свой версии. Сервер в ответ дает данные с версиями выше.

Для работы в обе стороны нужен полный лог операций и система разрешения конфликтов

Благо такое не требуется. Пока. Но если существуют такие решения - было бы неплохо применить и их с учетом на будущее.

Для обычных баз данных в режиме совместной работы настраивайте мастер-мастер репликацию с транзакциями

Из-за разнородности хранения данных на сервере и клиенте такое неприменимо, к сожалению.

Для мобильных приложений используйте режим тонкого клиента.

Тоже не подойдет из-за проблем описанных выше.

[Philipp]

Владимир Куц, вариант с версией не самый лучший, т.к. вам нужно заботиться о версионировании и т.д. Гораздо проще использовать шаблон с updatedAt полем.

Answer 3

[Петр]

Записывайте не версию, а время изменения состояния записи.
И будет достаточно получить все изменения которые произошли после указаного времени.

Comments

[Владимир Куц]

> Записывайте не версию, а время изменения состояния записи.
А чем это принципиально отличается от записи версии - если я ее инкрементирую после внесения данных. Временная метка - просто частный случай версии, насколько я понимаю )

[Петр]

Владимир Куц, Для этой задачи не нормального решения, это тоже самое, что случилось с dll (Dependency hell)

Answer 4

[Станислав Макаров]

Если вам нужно прям версионирование - смотрите 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

Насчёт конфликтов и "гита для табличных записей" - тут действительно всё непросто, я вот взялся писать диссер на эту тему..

Answer 5

[Владимир]

Вы изучили родные механизмы репликации в mysql (там попроще) а потом и в postgresql ? они вам не подходят ? есл да то опишите почему ?

Comments

[Владимир Куц]

На мобильном устройстве данные хранятся в специфическом формате. Для простоты примем что хранится некая структура в json собранная из актуальных данных.
Так вот - родные механизмы репликации mysql/postgresql позволяют настаивать репликацию с некой внешней структурой json c протоколами на базе json а лучше protobuf?
Если да - ткните в примеры успешной реализации. Я к примеру такое не нашел, и не думаю что репликация мне поможет.

[Владимир]

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

[Владимир Куц]

Владимир, да - это я в описании упустил )
Так да - были бы одинаковые движки на сторонах - проблем с репликацией не было.
По логу репликаций тоже непросто. В базу версии n+1 может добавиться скажем - тысячу записей, а в версии n+2 эту тысячу записей могут удалить и добавить пару записей.
Вот нужно как-то избежать тянуть инфу об этой тысяче записей клиенту, запрашивающему обновлении с версии n до актуальной, указав просто что нужно добавить пару записей....

[Владимир]

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