Управление версиями набора данных в СУБД с использованием инициалов и дельт

Question

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

К сожалению, текущее решение не очень хорошо масштабируется. Транзакции настолько большие и длительные, что наша СУБД увядает с различными проблемами конкуренции. Кроме того, отсутствует хороший контрольный журнал того, как применяются дельты, что затрудняет устранение неполадок, вызывающих рассинхронизацию локальной и удаленной версий набора данных.

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

Остается только вопрос о том, как именно составить представление набора данных до заданной версии от начальной и дельты. (TimeMachine от Apple делает нечто подобное, используя жесткие ссылки в файловой системе для создания «представления» на определенный момент времени.)

Есть ли у кого-нибудь опыт решения такого рода проблем или внедрения именно этого решения?

Спасибо!

Answer 1

Спасибо тем, кто попробовал.

Для всех, кто попадает сюда, я тестирую решение, которое добавляет столбцы dataset_version_id и dataset_version_verb в каждую рассматриваемую таблицу.Затем коррелированный подзапрос внутри хранимой процедуры используется для получения текущего dataset_version_id при получении определенных записей.Если последняя версия записи имеет dataset_version_verb со значением «delete», она отфильтровывается из результатов с помощью предложения WHERE.

Этот подход пока дает в среднем ~ 80% снижения производительности, что может быть приемлемо для наших целей.

Answer 2

иметь одну писатель и несколько читательских баз данных.Вы отправляете запись в одну базу данных, и она распространяет те же самые изменения на все другие базы данных.Базы данных читателей в конечном итоге будут согласованными, и время обновления будет очень быстрым.Я видел это в средах, которые получают более 1 миллиона просмотров страниц в день.Он очень масштабируемый.Вы даже можете поставить аппаратный маршрутизатор перед всеми читаемыми базами данных, чтобы сбалансировать их нагрузку.