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

Question

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

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

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

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

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

Спасибо!

Answer 1

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

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

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

Answer 2

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