Чанки
В данном разделе собрана информация о чанках - частях таблицы или файла, которые хранят данные.
Общие сведения
Данные, хранящиеся в таблицах, файлах и журналах, разбиты на части, называемые чанками. Чанк хранит непрерывный диапазон данных.
В частности, в каждом чанке таблицы содержится некоторый диапазон ее строк.
Чанк — неизменяемая сущность: после создания чанка данные в нем нельзя изменить.
Физически данные чанков хранятся на узлах кластера. Мастер-сервера YTsaurus отслеживают расположение чанков, а также поддерживают их в реплицированном состоянии.
Мастер-сервера YTsaurus хранят только метаданные. Тем не менее, метаданные имеют существенный размер, поэтому, чтобы ограничить потребление памяти мастер-серверами, количество чанков, доступных аккаунту, квотируется.
Размер чанков
Чанки не монолитны, они состоят из блоков, чтобы можно было читать и записывать чанк частями.
Блоки статических таблиц по умолчанию имеют размер 16 мегабайт, а блоки динамических таблиц — 256 килобайт.
Размер блока можно изменить в настройках table_writer
, атрибут block_size
.
Как правило, чанк занимает на узле кластера сотни мегабайт или единицы гигабайт.
Размер создаваемых чанков можно настраивать через секцию table_writer
, атрибут desired_chunk_size
.
Не рекомендуется делать чанки слишком маленькими. Это приводит к увеличению их количества, что расходует память мастер-серверов. Также, мелкие чанки замедляют чтение: возрастает количество запросов к мастеру и к диску, которые необходимо сделать, чтобы прочитать все данные.
Чтение данных
Когда клиент вызывает процедуру чтения данных из статической таблицы, на прокси-сервере выполняются следующие шаги:
- Получение от мастер-сервера списка чанков, из которых состоит таблица.
- Получение от мастер-сервера списка узлов кластера, на которых находятся реплики чанка.
- Скачивание данных с узлов кластера и передача клиенту.
Запись данных
Запись осуществляется схожим образом:
- Разделение потока входных данных на части.
- Оформление каждой части в виде чанка.
- Передача данных на узлы кластера и привязка к таблице.
Формат чанка
В YTsaurus существуют два формата чанков: построчный и поколоночный.
Формат чанка задает параметр optimize_for
. Для построчного формата optimize_for
имеет значение lookup
, для поколоночного — scan
.
Построчный формат: optimize_for=lookup
В построчном формате каждая строка целиком хранится в одном блоке.
Построчный формат подходит для динамических таблиц, из которых данные выбирают по ключу.
Поколоночный формат: optimize_for=scan
Поколоночный формат не хранит информацию о типе рядом с каждым значением и использует легковесные техники сжатия колонок.
По умолчанию данные каждой колонки, указанной в схеме, попадают в отдельную последовательность блоков внутри чанка. Это ускоряет чтение небольшого числа колонок.
Если требуется прочитать одну строку или небольшой диапазон строк по ключу, потребуется совершить столько обращений к диску, сколько в таблице колонок. Для минимизации обращений к диску можно использовать атрибут group
в описании колонок в схеме, который позволит хранить связанные данные в одном блоке. Подробнее можно прочитать в разделе Схема данных.
Примечание
Использование поколоночного формата без схемы бессмысленно.
Пример указания формата
CLI
yt set //tmp/table/@optimize_for scan
Установка атрибута влияет только на будущие чанки и не конвертирует таблицы (аналогично установка атрибутов @erasure_codec
и @compression_codec
).
Чтобы конвертировать уже записанные данные в новый формат, выполните операцию Merge:
CLI
yt merge --mode ordered --src //tmp/table --dst //tmp/table --spec '{force_transform = %true}'
Для динамической таблицы аналогичную задачу решает forced compaction. Перед его использованием обязательно изучите статью Фоновая компактификация.
Пример запуска операции через CLI:
yt set //tmp/table/@forced_compaction_revision 1
Также в случае поколоночного формата у динамической таблицы стоит обратить внимание на атрибут group
на схеме колонки. Если из таблицы часто лукапятся строчки без фильтрации колонок, то имеет смысл выставить на все колонки одну и ту же группу. Про группы подробнее в документации про схему таблицы.
Владельцы чанков
Узлы Кипариса, состоящие из чанков, — таблицы, файлы и журналы, называются владельцами чанков.
Множество чанков, принадлежащих владельцам чанков, организовано в виде древовидной структуры данных. Листьями структуры являются чанки, а промежуточными вершинами — чанк-листы (chunk_list
).
Помимо атрибутов, присущих всем узлам Кипариса, владельцы чанков имеют следующие дополнительные атрибуты:
Имя | Тип | Описание | Обязательный |
---|---|---|---|
chunk_list_id |
Guid |
Идентификатор корневого списка чанков. | Да |
chunk_ids |
array<Guid> |
Список идентификаторов всех чанков. | |
chunk_count |
int |
Количество чанков. | |
compression_statistics |
CompressionStatistics |
Статистика по типам использованных кодеков сжатия и размерам данных. | Да |
erasure_statistics |
ErasureStatistics |
Статистика по типам использованных erasure-кодеков и размерам данных. | Да |
optimize_for_statistics |
OptimizeForStatistics |
Статистика по типам использованных типов чанков (optimize_for ). |
Да |
multicell_statistics |
MulticellStatistics |
Статистика распределения чанков по мастер-серверам. | Да |
uncompressed_data_size |
int |
Общий несжатый объем данных всех чанков (без учета репликации и erasure-кодирования). | Да |
compressed_data_size |
int |
Общий сжатый объем данных всех чанков (без учета репликации и erasure-кодирования). | Да |
compression_ratio |
double |
Коэффициент сжатия, отношение сжатого объема к несжатому. | Да |
update_mode |
string |
Способ изменения данных под транзакцией: none , append или overwrite ; для узлов вне транзакции это none . |
Да |
replication_factor |
integer |
Коэффициент репликации (для erasure-кодирования равен 1). | Да |
compression_codec |
string |
Имя кодека сжатия. | Да |
erasure_codec |
string |
Имя erasure-кодека. | Да |
vital |
bool |
Являются ли чанки этого узла витальными | Нет |
media |
Media |
Коэффициенты репликации и другие настройки медиумов. | Да |
primary_medium |
string |
Первичный медиум. | Да |
Витальность данных
Система YTsaurus разделяет чанки на два вида: витальные и невитальные. По умолчанию данные в системе витальные (атрибут vital
равен true
) и их потеря — серьезный инцидент. Потеря данных может произойти из-за выпадения узлов кластера.
Невитальные данные - это те данные, потеря которых не является критичной. Настройки кластеров YTsaurus таковы, что недоступность невитальных чанков не вызывает срабатывания мониторингов и вмешательства эксплуатации. Типичными примерами невитальных данных являются промежуточные результаты операций: планировщик сам заметит потери и выполнит пересчет. Для невитальных данных атрибут vital
равен false
.
Примечание
Система не считает витальными чанки, записанные без erasure-кодирования и имеющие единичный коэффициент репликации.
Данные могут быть утрачены при выпадении узлов кластера. Чтобы этого избежать, по умолчанию данные в YTsaurus хранятся в трёх копиях.
Однако, при выпадении нескольких хостов система может потерять доступ ко всем копиям. Если при утрате витальных данных были прерваны вычисления, перезапустите их.