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

В этой статье:

  • ClickHouse®
  • Greenplum®
  • MongoDB
  • MySQL®
  • PostgreSQL
  • Скорость переноса данных
  • Количество подключений к базе данных
  • Yandex Data Streams
  • Object Storage
  • Oracle
  1. Концепции
  2. Работа Yandex Data Transfer с источниками и приемниками

Особенности работы с эндпоинтами

Статья создана
Yandex Cloud
Улучшена
Dmitry A.
Обновлена 10 марта 2025 г.
  • ClickHouse®
  • Greenplum®
  • MongoDB
  • MySQL®
  • PostgreSQL
    • Скорость переноса данных
    • Количество подключений к базе данных
  • Yandex Data Streams
  • Object Storage
  • Oracle

Сервис Yandex Data Transfer имеет ряд ограничений и особенностей функционирования в зависимости от типов эндпоинтов.

ClickHouse®ClickHouse®

Трансферы типов Копирование и Копирование и репликация (на стадии копирования) из ClickHouse® в ClickHouse® не поддерживают работу с VIEW. В эндпоинте-источнике типа ClickHouse® VIEW должны быть включены в "Список исключенных таблиц", если "Список включенных таблиц" пуст или не указан. Если "Список включенных таблиц" непустой, в нем не должно присутствовать объектов VIEW.

Источник поддерживает MATERIALIZED VIEW, но работает с ними как с обыкновенными таблицами. Таким образом, в трансферах из ClickHouse® в ClickHouse® MATERIALIZED VIEW переносятся как таблицы, а не как объекты MATERIALIZED VIEW.

Если на приемнике ClickHouse® включена репликация, то движки для воссоздания таблиц будут выбраны в зависимости от типа источника:

  • При переносе данных из строковых СУБД будут использоваться движки ReplicatedReplacingMergeTree и ReplacingMergeTree.
  • При переносе данных из ClickHouse® будут использоваться движки семейства ReplicatedMergeTree.

Greenplum®Greenplum®

В трансферах из Greenplum® в Greenplum® и из Greenplum® в PostgreSQL схема не переносится в текущей версии Yandex Data Transfer. При наличии пользовательских типов данных в таблицах в таких трансферах, такие пользовательские типы необходимо создать в целевой базе данных вручную до запуска трансфера. Для переноса схемы вручную можно использовать утилиту pg_dump.

Источник считает FOREIGN TABLE и EXTERNAL TABLE обыкновенными представлениями и работает с ними в соответствии с общим алгоритмом для VIEW.

Данные, хранящиеся в MATERIALIZED VIEW, не переносятся. Для переноса данных из MATERIALIZED VIEW создайте обыкновенный VIEW, ссылающийся на переносимый MATERIALIZED VIEW.

MongoDBMongoDB

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

Трансфер в MongoDB не переносит индексы. Когда трансфер перейдет в статус Реплицируется, создайте индекс для каждой шардируемой коллекции вручную:

db.<имя_коллекции>.createIndex(<свойства_индекса>)

Описание функции createIndex() см. в документации MongoDB.

MySQL®MySQL®

Типы данных в таблицах приемника MySQL® могут иметь свойство unsigned:

  • unsigned smallint — значения более 2^31 не поместятся на приемнике.
  • unsigned bigint — значения более 2^63 не поместятся на приемнике.

Первичный ключ в MySQL® не может быть строкой неограниченной длины.

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

PostgreSQLPostgreSQL

При переносе данных с типом TIMESTAMP WITHOUT TIME ZONE применяется часовой пояс, указанный в параметре timezone базы данных источника PostgreSQL.

Пример

В колонке с типом данных TIMESTAMP WITHOUT TIME ZONE записано значение 1970-01-01 00:00:00. То, как при трансфере будет перенесено значение, зависит от параметра timezone в БД:

  • Если значение параметра равно Etc/UTC, то время переносится как 1970-01-01 00:00:00+00.
  • Если значение параметра равно Europe/Moscow, то время переносится как 1970-01-01 00:00:00+03.

Данные, хранящиеся в MATERIALIZED VIEW, не переносятся. Для переноса данных из MATERIALIZED VIEW создайте обыкновенный VIEW, ссылающийся на переносимый MATERIALIZED VIEW.

Если определение переносимого VIEW содержит вызов VOLATILE функции, то трансфер читает данные из такого VIEW с уровнем изоляции READ UNCOMMITTED. Консистентность между данными в этом VIEW и данными других переносимых объектов не гарантируется. Чтение из MATERIALIZED VIEW в определении VIEW равносильно вызову VOLATILE функции.

Источник считает FOREIGN TABLE обыкновенными представлениями и работает с ними в соответствии с общим алгоритмом для представлений.

Если в источнике трансфера из PostgreSQL в PostgreSQL задан непустой "Список включенных таблиц", пользовательские типы данных, присутствующие в этих таблицах, не переносятся. В этом случае перенесите пользовательские типы данных вручную.

При переносе партиционированных таблиц необходимо учитывать следующее:

  • Для таблиц, партиционированных декларативным методом:

    • Пользователю необходим доступ к основной таблице и всем ее партициям на источнике.
    • Трансфер выполняется по принципу как есть: на приемнике будут созданы все партиции и основная таблица.
    • На этапе копирования партиции переносятся на приемник независимо друг от друга. Для этого настройте параллельное копирование, оно ускорит трансфер.
    • На этапе репликации данные будут автоматически попадать в нужные партиции.
    • Если после того, как трансфер перешел на этап репликации, на источнике будут созданы новые партиции, необходимо будет перенести их на приемник вручную.
    • Пользователь может перенести на приемник только часть партиций. Для этого он должен добавить эти партиции в Список включенных таблиц или закрыть доступ к ненужным партициям на источнике.
  • Для таблиц, партиционированных методом наследования:

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

    При переносе базы данных из PostgreSQL в другую СУБД пользователь может включить в эндпоинте-источнике настройку Объединять наследуемые таблицы. В этом случае:

    • На приемник будет перенесена только родительская таблица, которая будет содержать данные тех таблиц-наследников, которые были явно указаны в списке переносимых таблиц.
    • Пользователь по-прежнему может ускорить трансфер, поскольку копирование таблиц-наследников с источника в общую таблицу на приемнике происходит параллельно. Для ускорения трансфера включите параллельное копирование.

Скорость переноса данныхСкорость переноса данных

Средняя скорость переноса одной таблицы в один поток для трансферов из PostgreSQL в:

  • PostgreSQL — 21 Мбит/сек.
  • Другую СУБД — 3,5 Мбит/сек.

Увеличить скорость переноса данных можно с помощью параллельного копирования.

Количество подключений к базе данныхКоличество подключений к базе данных

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

Рассчитать количество подключений, которое потребуется трансферу, можно по формулам:

  • Для PostgreSQL-источника и типа трансфера Копирование:

    <количество_воркеров> * <количество_потоков> + 1
    

    Где:

    • количество_воркеров и количество_потоков — параметры трансфера, в котором указан PostgreSQL-источник.
    • 1 — подключение для мастер-транзакции.
  • Для PostgreSQL-источника и типа трансфера Копирование и репликация:

    <количество_воркеров> * <количество_потоков> + 2
    

    Где:

    • количество_воркеров и количество_потоков — параметры трансфера, в котором указан PostgreSQL-источник.
    • 2 — подключения для мастер-транзакции и слот-монитора.
  • Для PostgreSQL-приемника:

    <количество_воркеров> * <количество_потоков>
    

    Где количество_воркеров и количество_потоков — параметры трансфера, в котором указан PostgreSQL-приемник.

Если расчетное количество превышает ограничение, выполните одно из действий:

  • Уменьшите количество воркеров или потоков в трансфере.
  • Увеличьте максимальное допустимое количество подключений для пользователя в PostgreSQL.

Yandex Data StreamsYandex Data Streams

По умолчанию при переносе данных из Data Streams в ClickHouse® для каждой партиции создается отдельная таблица. Чтобы все данные попадали в одну таблицу, укажите правила конвертации в дополнительных настройках эндпоинта для источника.

Object StorageObject Storage

Трансферы из источника данных Object Storage работают в режиме APPEND-ONLY. Удаление файла из Object Storage никак не повлияет на данные в приемнике. При обновлении файла: если в приемнике указаны синтетические ключи, то строки из файла обновятся в приемнике, если не указаны — допишутся. По умолчанию первичный ключ содержит 2 колонки: имя файла и номер строки в файле.

OracleOracle

Источник игнорирует VIEW и MATERIALIZED VIEW в трансферах любого типа.

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

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

Предыдущая
Сериализация
Следующая
Гарантии поставки
Проект Яндекса
© 2025 ООО «Яндекс.Облако»