Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Data Transfer
  • Доступные трансферы
  • Начало работы
    • Взаимосвязь ресурсов сервиса
    • Типы и жизненные циклы трансферов
    • Объекты, переносимые трансфером
    • Периодическое инкрементальное копирование
    • Параллельное копирование
    • Трансформация данных
    • Сериализация
    • Работа Yandex Data Transfer с источниками и приемниками
    • Гарантии поставки
    • Операции над трансфером
    • Сеть в Yandex Data Transfer
    • Скорость копирования данных в Yandex Data Transfer
    • Захват изменения данных
    • Какие задачи решает сервис
    • Квоты и лимиты
  • Решение проблем
  • Управление доступом
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • Публичные материалы
  • Обучающие курсы
  1. Концепции
  2. Периодическое инкрементальное копирование

Периодическое инкрементальное копирование

Статья создана
Yandex Cloud
Обновлена 27 июня 2024 г.

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

Примечание

Инкрементальное копирование можно настроить для источников PostgreSQL, ClickHouse® и Airbyte®.

Чтобы найти измененные данные, в таблице используется ключевая колонка, значения в которой меняются при каждом добавлении или обновлении данных. Для ключевой колонки рекомендуется построить индекс, чтобы каждый вызов не приводил к полному сканированию таблицы (fullscan). Если в таблицу только добавляются данные, в качестве ключевой колонки подходит столбец id. Если в таблице могут изменяться существующие данные, в качестве ключевой колонки рекомендуется добавить столбец updated_at с временным типом данных и записывать в него текущее время при каждом изменении. Трансфер запоминает максимальное значение в ключевой колонке и при следующей активации будет считывать только те данные, которые были добавлены или обновлены с момента последнего запуска.

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

Чтобы периодическое инкрементальное копирование давало корректный результат, в таблице источника должны выполняться следующие условия:

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

Время ожидания завершения транзакцийВремя ожидания завершения транзакций

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

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

Время ожидания завершения транзакций должно быть:

  • Дольше, чем средняя транзакция вставки или изменения данных. В стандартных приложениях такие транзакции выполняются за несколько секунд.
  • Значительно меньше периода между запусками трансфера, так как напрямую влияет на время выполнения трансфера.

Рекомендуемое значение и значение по умолчанию — 15 секунд.

ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc.

Была ли статья полезна?

Предыдущая
Объекты, переносимые трансфером
Следующая
Параллельное копирование
Проект Яндекса
© 2025 ООО «Яндекс.Облако»