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

Сервис 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.

Данные, хранящиеся в 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® для каждой партиции создается отдельная таблица. Чтобы все данные попадали в одну таблицу, укажите правила конвертации в дополнительных настройках эндпоинта для источника.

OracleOracle

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

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