[Документация Yandex Cloud](../../index.md) > [Yandex Data Transfer](../index.md) > [Концепции](index.md) > Работа Yandex Data Transfer с источниками и приемниками # Особенности работы с эндпоинтами Сервис Yandex Data Transfer имеет ряд ограничений и особенностей функционирования в зависимости от типов эндпоинтов. ## ClickHouse® {#clickhouse} Трансферы типов **Копирование** и **Копирование и репликация** (на стадии копирования) _из ClickHouse® в ClickHouse®_ не поддерживают работу с `VIEW`. В эндпоинте-источнике типа ClickHouse® `VIEW` должны быть включены в **Список исключённых таблиц**, если **Список включённых таблиц** пуст или не указан. Если **Список включённых таблиц** непустой, в нем не должно присутствовать объектов `VIEW`. Источник поддерживает `MATERIALIZED VIEW`, но работает с ними как с обыкновенными таблицами. Таким образом, в трансферах _из ClickHouse® в ClickHouse®_ `MATERIALIZED VIEW` переносятся как таблицы, а не как объекты `MATERIALIZED VIEW`. Если на приемнике ClickHouse® включена репликация, то движки для воссоздания таблиц будут выбраны в зависимости от типа источника: * При переносе данных из строковых СУБД будут использоваться движки [ReplicatedReplacingMergeTree](https://clickhouse.com/docs/ru/engines/table-engines/mergetree-family/replication) и [ReplacingMergeTree](https://clickhouse.com/docs/ru/engines/table-engines/mergetree-family/replacingmergetree). * При переносе данных из ClickHouse® будут использоваться движки семейства [ReplicatedMergeTree](https://clickhouse.com/docs/ru/engines/table-engines/mergetree-family/replication). ## Greenplum® {#greenplum} В трансферах _из Greenplum® в Greenplum®_ и _из Greenplum® в PostgreSQL_ схема не переносится в текущей версии Yandex Data Transfer. При наличии пользовательских типов данных в таблицах в таких трансферах, такие пользовательские типы необходимо создать в целевой базе данных вручную до запуска трансфера. Для переноса схемы вручную можно использовать утилиту [pg_dump](https://techdocs.broadcom.com/us/en/vmware-tanzu/data-solutions/tanzu-greenplum/7/greenplum-database/utility_guide-ref-pg_dump.html). Источник считает `FOREIGN TABLE` и `EXTERNAL TABLE` обыкновенными представлениями и работает с ними в соответствии с общим алгоритмом для `VIEW`. Данные, хранящиеся в `MATERIALIZED VIEW`, не переносятся. Для переноса данных из `MATERIALIZED VIEW` создайте обыкновенный `VIEW`, ссылающийся на переносимый `MATERIALIZED VIEW`. ## MongoDB {#mongodb} По умолчанию сервис не шардирует коллекции, переносимые в шардированный кластер. Подробнее читайте в разделе [Подготовка к трансферу](../operations/prepare.md#target-mg). Трансфер в MongoDB не переносит индексы. Когда трансфер перейдет в статус **Реплицируется**, создайте индекс для каждой шардируемой коллекции вручную: ```javascript db.<имя_коллекции>.createIndex(<свойства_индекса>) ``` ## MySQL® {#mysql} Типы данных в таблицах приемника MySQL® могут иметь свойство `unsigned`: * `unsigned smallint` — значения более 2^31 не поместятся на приемнике. * `unsigned bigint` — значения более 2^63 не поместятся на приемнике. Первичный ключ в MySQL® не может быть строкой неограниченной длины. Приемник MySQL® игнорирует имя схемы в источнике и создает таблицы в схеме, имя которой указано в настройках эндпоинта. ## PostgreSQL {#postgresql} При переносе данных с типом `TIMESTAMP WITHOUT TIME ZONE` применяется часовой пояс, указанный в параметре `timezone` базы данных источника PostgreSQL. {% cut "Пример" %} В колонке с типом данных `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`. {% endcut %} Данные, хранящиеся в `MATERIALIZED VIEW`, не переносятся. Для переноса данных из `MATERIALIZED VIEW` создайте обыкновенный `VIEW`, ссылающийся на переносимый `MATERIALIZED VIEW`. Если определение переносимого `VIEW` содержит вызов `VOLATILE` [функции](https://www.postgresql.org/docs/current/xfunc-volatility.html), то трансфер читает данные из такого `VIEW` с уровнем изоляции `READ UNCOMMITTED`. Консистентность между данными в этом `VIEW` и данными других переносимых объектов не гарантируется. Чтение из `MATERIALIZED VIEW` в определении `VIEW` равносильно вызову `VOLATILE` функции. Источник считает `FOREIGN TABLE` обыкновенными представлениями и работает с ними в соответствии с общим алгоритмом для представлений. Если в источнике трансфера _из PostgreSQL в PostgreSQL_ задан непустой **Список включённых таблиц**, пользовательские типы данных, присутствующие в этих таблицах, не переносятся. В этом случае перенесите пользовательские типы данных вручную. При переносе [партиционированных таблиц](https://www.postgresql.org/docs/current/ddl-partitioning.html) необходимо учитывать следующее: * **Для таблиц, партиционированных декларативным методом**: * Пользователю необходим доступ к основной таблице и всем ее партициям на источнике. * Трансфер выполняется по принципу «как есть»: на приемнике будут созданы все партиции и основная таблица. * На этапе копирования партиции переносятся на приемник независимо друг от друга. Для этого настройте [параллельное копирование](sharded.md), оно ускорит трансфер. * На этапе репликации данные будут автоматически попадать в нужные партиции. * Если после того, как трансфер перешел на этап репликации, на источнике будут созданы новые партиции, необходимо будет перенести их на приемник вручную. * Пользователь может перенести на приемник только часть партиций. Для этого он должен добавить эти партиции в [Список включенных таблиц](../operations/endpoint/source/postgresql.md#additional-settings) или закрыть доступ к ненужным партициям на источнике. * **Для таблиц, партиционированных методом наследования**: * Пользователю необходим доступ к родительской таблице и всем таблицам-наследникам. * На этапе копирования данные из таблиц-наследников не дублируются в родительскую таблицу. Чтобы перенести данные из таблиц-наследников, их необходимо явно указать в списке переносимых таблиц. * На этапе копирования таблицы-наследники переносятся на приемник независимо друг от друга. Для этого настройте [параллельное копирование](sharded.md), оно ускорит трансфер. * На этапе репликации данные будут автоматически попадать в нужные таблицы-наследники или в родительскую таблицу, если наследование используется не для партиционирования. * Если после того, как трансфер перешел на этап репликации, на источнике будут созданы новые таблицы-наследники, необходимо будет перенести их на приемник вручную. При переносе базы данных из PostgreSQL в другую СУБД пользователь может включить в эндпоинте-источнике настройку [Объединить наследуемые таблицы](../operations/endpoint/source/postgresql.md#additional-settings). Поведение трансфера зависит от значения настройки и таблиц, указанных в параметре **Список включённых таблиц**: * Настройка включена: | **Указанные таблицы** | **Поведение трансфера** | |-------------------|---------------------| | Только родительская таблица | Будет перенесена родительская таблица с данными из всех таблиц-наследников | | Все или некоторые таблицы-наследники | Будет перенесена родительская таблица с данными из указанных таблиц-наследников | | Родительская таблица и все таблицы-наследники | Будет перенесена родительская таблица с данными из всех таблиц-наследников | | Родительская таблица и некоторые таблицы-наследники | Трансфер завершится с ошибкой | * Настройка выключена: | **Указанные таблицы** | **Поведение трансфера** | |-------------------|---------------------| | Только родительская таблица | Будут перенесены все таблицы-наследники указанной родительской таблицы | | Все или некоторые таблицы-наследники | Будут перенесены только указанные таблицы-наследники | | Родительская таблица и все таблицы-наследники | Будут перенесены все таблицы-наследники указанной родительской таблицы | | Родительская таблица и некоторые таблицы-наследники | Трансфер завершится с ошибкой | Для ускорения трансфера настройте [параллельное копирование](sharded.md). ### Скорость переноса данных {#postgresql-speed} Средняя скорость переноса одной таблицы в один поток для трансферов из PostgreSQL в: * PostgreSQL — 21 Мбит/сек. * Другую СУБД — 3,5 Мбит/сек. Увеличить скорость переноса данных можно с помощью [параллельного копирования](sharded.md). ### Количество подключений к базе данных {#postgresql-connection-limit} В PostgreSQL есть [ограничение на количество подключений пользователя](../../managed-postgresql/concepts/settings-list.md#setting-conn-limit) к базе данных. Если для трансфера количество подключений превышает это ограничение, то трансфер будет работать неправильно или не будет работать вовсе. Рассчитать количество подключений, которое потребуется трансферу, можно по формулам: * Для PostgreSQL-источника и типа трансфера _**Копирование**_: ```text <количество_воркеров> * <количество_потоков> + 1 ``` Где: * `количество_воркеров` и `количество_потоков` — параметры трансфера, в котором указан PostgreSQL-источник. * `1` — подключение для мастер-транзакции. * Для PostgreSQL-источника и типа трансфера _**Копирование и репликация**_: ```text <количество_воркеров> * <количество_потоков> + 2 ``` Где: * `количество_воркеров` и `количество_потоков` — параметры трансфера, в котором указан PostgreSQL-источник. * `2` — подключения для мастер-транзакции и слот-монитора. * Для PostgreSQL-приемника: ```text <количество_воркеров> * <количество_потоков> ``` Где `количество_воркеров` и `количество_потоков` — параметры трансфера, в котором указан PostgreSQL-приемник. Если расчетное количество превышает ограничение, выполните одно из действий: * [Уменьшите количество воркеров или потоков](../operations/transfer.md#update) в трансфере. * [Увеличьте максимальное допустимое количество подключений](../../managed-postgresql/operations/cluster-users.md#update-settings) для пользователя в PostgreSQL. ## Yandex Data Streams {#yds} По умолчанию при переносе данных из Data Streams в ClickHouse® для каждой партиции создается отдельная таблица. Чтобы все данные попадали в одну таблицу, укажите правила конвертации в [дополнительных настройках эндпоинта для источника](../operations/endpoint/source/data-streams.md#additional-settings). ## Object Storage {#object-storage} Трансферы из источника данных Object Storage работают в режиме APPEND-ONLY. Удаление файла из Object Storage никак не повлияет на данные в приемнике. При обновлении файла: если в приемнике указаны синтетические ключи, то строки из файла обновятся в приемнике, если не указаны — допишутся. По умолчанию первичный ключ содержит 2 колонки: имя файла и номер строки в файле. ## Oracle {#oracle} Источник игнорирует `VIEW` и `MATERIALIZED VIEW` в трансферах любого типа. _ClickHouse® является зарегистрированным товарным знаком [ClickHouse, Inc](https://clickhouse.com)._