--- metadata: - name: generator content: Diplodoc Platform v5.50.6 alternate: - https://ytsaurus.tech/docs/en/user-guide/storage/replication.md - https://ytsaurus.tech/docs/ru/user-guide/storage/replication.md --- > **Documentation Index:** Fetch the complete configuration index at https://ytsaurus.tech/docs/ru/llms.txt # Репликация и erasure-кодирование В данном разделе содержится информация про репликацию и erasure-кодирование — механизмы достижения избыточности при хранении данных. Эти механизмы позволяют предотвратить потерю данных в распределенных системах при аппаратных сбоях. [Репликация](https://ru.wikipedia.org/wiki/Репликация_(вычислительная_техника)) требует много дискового пространства, но не требовательна к вычислительным ресурсам (CPU). [Erasure-кодирование](https://en.wikipedia.org/wiki/Erasure_code) требует больше вычислительных ресурсов и меньше дискового пространства. Атрибут `replication_factor` задает коэффициент репликации, атрибут `erasure_codec` — тип применяемого erasure-кодека. ## Репликация { #replication } Для репликации значение `erasure_codec` равно `none`, а `replication_factor` определяет число реплик чанков. При этом каждая реплика записывается в отдельную стойку — **rack** — для обеспечения **rack awareness**. Чанки остаются доступны для чтения при потере всех реплик, кроме одной. Рекомендуемое значение `replication_factor` в типичном случае равно трём, так как при меньшем значении потери данных будут встречаться часто. Чтобы изменить коэффициент репликации, установите атрибут `replication_factor`. Система автоматически создаст недостающее количество чанков или удалит лишние. CLI ```bash yt set //home/your_new_file/@replication_factor 6 ``` ## Erasure-кодирование { #erasure } Erasure-кодирование — способ хранения данных, который позволяет экономить место по сравнению с репликацией. Также erasure-кодирование позволяет надежнее хранить данные, так как переживает выпадение любых трех узлов кластера, в то время как тройная репликация переживает выпадение любых двух узлов кластера. {% note warning "Внимание" %} - Категорически не рекомендуется использовать erasure-кодирование для хранения foreign-таблиц в операциях `join reduce` и `reduce with foreign tables`, если объемы этих таблиц заметно меньше размеров первичных таблиц. При работе таких операций джобы перегрузят запросами узлы кластера, на которых расположены чанки foreign-таблицы. В меньшей степени это касается простых операций `reduce`, у которых число одновременно работающих джобов заметно превышает число чанков во входных таблицах. - Для процессов, которые требовательны к задержкам, использование erasure-кодирования может оказаться невозможным. - Не имеет смысла использовать erasure-кодирование для небольших объемов, так как выигрыш будет незначителен. {% endnote %} Атрибут `replication_factor` не влияет на erasure-чанки. Данные хранятся в одной копии. Может встречаться ситуация, когда в таблице есть как erasure-чанки, так и обычные. Такие таблицы могут образовываться при выполнении операции `merge`. Атрибут `erasure_codec` показывает тип применяемого erasure-кодека. Поддерживаются типы, перечисленные в таблице. При изменении значения атрибута изменится способ записи новых данных. Старые данные при этом останутся без изменений. | Кодек | Алгоритм | Описание | Объем на диске в сравнении со сжатыми данными | Стоимость восстановления | |-------|----------|----------|------------------------|--------------------------| | `isa_reed_solomon_6_3` | Использует [коды Рида-Соломона](https://ru.wikipedia.org/wiki/Код_Рида_—_Соломона). | При записи erasure-чанка, данные делятся на 6 частей (data-parts). Формируется 3 контрольные части для восстановления. | 1.5x | Стоимость восстановления высока по затратам CPU и по времени. | | `isa_lrc_12_2_2` | Использует [Local Reconstruction Codes (LRC)](https://www.microsoft.com/en-us/research/publication/erasure-coding-in-windows-azure-storage/?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F179583%2Flrc12-cheng%2520webpage.pdf), которые являются модификацией кодов Рида-Соломона. | При записи erasure-чанка данные делятся на 12 частей (data-parts). Подсчитываются 2 xor-части — для первых 6 частей с данными и для вторых 6. Подсчитываются 2 контрольных части для восстановления по схеме, аналогичной Риду-Соломону (erasure-parts). Это рекомендуемый вариант для всех случаев, когда нужно erasure-кодирование. | 1.33x | Стоимость восстановления умеренная по затратам на CPU и по времени. | В обоих случаях система выдерживает выпадение любых трех узлов кластера. Система старается записать каждую часть чанка на отдельную стойку (**rack**) для обеспечения **rack awareness**. Erasure-кодирование имеет следующие недостатки: - При выпадении даже одного узла кластера, системе необходимо будет начать фоновое восстановление для поддержания отказоустойчивости. Для восстановления требуется различное количество частей, например для `isa_reed_solomon_6_3` необходимо 6 различных частей. Процесс восстановления автоматический, но требует CPU и занимает некоторое время, от 10 до 60 минут. - Чтение может быть медленным, поскольку физически данные имеют лишь одну реплику. Фактически, при чтении, не из чего выбирать, и если единственный узел кластера, на котором лежит читаемая часть с данными, по тем или иным причинам сильно загружен, то чтение будет медленным. Если часть не удается прочесть длительное время, то система произведет восстановление этой части на клиенте — **восстановление при чтении**, которое требует дополнительного времени и вычислительных ресурсов. При использовании репликации система выбирает наименее загруженную реплику для чтения; - Запись данных — дорогостоящая операция с точки зрения потребления оперативной памяти (RAM). Для сравнения, по умолчанию для записи таблицы с использованием репликации требуется 100МБ оперативной памяти, а для записи таблицы с использованием erasure-кодирования — 1500МБ. ### Использование erasure-кодирования { #erasure_usage } Чтобы начать использовать erasure-кодирование, используйте команду `transform`. Данная команда является оберткой над операцией `merge` на клиентской стороне. Команда автоматически подбирает `data_weight_per_job` и другие параметры и запускает операцию `merge`. {% list tabs %} - CLI ```bash yt transform --src //path/to/table --dst //path/to/table --erasure-codec isa_reed_solomon_6_3 --compression-codec brotli_6 ``` - Python ```python import yt.wrapper as yt yt.transform(src, dst, erasure_codec=erasure_codec, ...) ``` {% endlist %} Чтобы выполнить операцию принудительно, запустите `merge` вручную с `force_transform=%true`, предварительно установив нужные кодеки на выходной таблице. Число `N` задается в байтах. Размер необходимо подобрать таким образом, чтобы чанк после сжатия занимал более 500МБ. CLI ```bash yt set //path/to/table/@erasure_codec isa_reed_solomon_6_3 yt set //path/to/table/@compression_codec brotli_6 yt merge --src //path/to/table --dst //path/to/table --spec '{force_transform = %true;data_weight_per_job=N} ``` Настройки кодирования данных содержатся в атрибутах таблицы. Чтобы увидеть их, выполните следующие команды: CLI ```bash yt get //path/to/table/@erasure_codec yt get //path/to/table/@compression_codec ``` Изменение атрибута приведет к тому, как новые данные будут записываться в таблицу. Старые данные при этом остаются без изменений. Чтобы узнать, в каком формате хранятся данные в таблице, выполните следующие команды: CLI ```bash yt get //path/to/table/@erasure_statistics yt get //path/to/table/@compression_statistics ```