Политики распределения данных
YMatrix поддерживает три основные политики распределения данных, определяющие способ хранения данных по узлам кластера и напрямую влияющие на производительность запросов и стабильность кластера.
Обзор политик распределения
| Метод распределения |
Сценарий использования |
Преимущества |
Недостатки |
| HASH |
Крупные таблицы, участвующие в соединениях по равенству по ключу распределения |
Строки с одинаковым значением ключа размещаются на одном узле, что обеспечивает эффективные соединения по равенству |
Недостаточная случайность значений ключа может привести к перекосу данных (data skew) |
| RANDOM |
Крупные таблицы, не требующие соединений и не имеющие подходящего ключа распределения |
Более равномерное распределение данных, снижающее риск перекоса |
Непредсказуемое размещение данных; оптимизатор не может использовать шаблоны распределения для оптимизации |
| REPLICATED |
Небольшие таблицы, редко обновляемые, но часто используемые в JOIN или индексах |
Полная копия таблицы хранится на каждом узле |
Увеличенный объём занимаемого места |
Хэш-распределение (HASH)
Принцип работы
- При создании таблицы один или несколько столбцов указываются в качестве ключа распределения.
- При вставке данных система вычисляет хэш-значение на основе ключа распределения и направляет строку на определённый segment-узел.
- Значения
NULL также хэшируются и назначаются конкретному сегменту так же, как и любые другие значения, что обеспечивает согласованное поведение при распределении.
Ключевые преимущества
- Равномерное распределение данных: ключ распределения с высокой кардинальностью предотвращает возникновение «горячих точек» из-за чрезмерной нагрузки на один узел.
- Высокая производительность запросов: запросы с условиями равенства (
WHERE column = value) могут напрямую обращаться к соответствующему сегменту без сканирования других узлов.
- Эффективные JOIN’ы: при соединении нескольких таблиц по одному и тому же ключу распределения объём передачи данных между сегментами минимален, что повышает скорость выполнения соединений.
Сценарии использования
- Большинство бизнес-таблиц (справочники сущностей, факт-таблицы), особенно с частыми запросами и большим объёмом данных.
- Сценарии, требующие частых точечных запросов или многотабличных соединений (например, финансовые системы, системы обработки заказов в электронной коммерции).
- Таблицы с чётко выраженным измерением запросов высокой кардинальности.
Случайное распределение (RANDOM)
Принцип работы
- Данные случайным образом распределяются по segment-узлам при вставке.
- Ключ распределения не требуется; система автоматически обеспечивает равномерное распределение по узлам.
Ключевые преимущества
- Полностью равномерное распределение данных без «горячих точек».
- Простая конфигурация — не требуется проектировать ключ распределения.
Сценарии использования
- Временные таблицы ETL и промежуточные таблицы обработки.
- Тестовые таблицы или небольшие таблицы с низкой частотой запросов.
- Таблицы без чётких измерений запросов и не требующие многотабличных соединений.
Примечания
- Соединения (JOIN) между таблицами требуют перераспределения данных по всем узлам, что приводит к снижению производительности. Не подходит для основных бизнес-таблиц.
Реплицированное распределение (REPLICATED)
Принцип работы
- Полная копия таблицы хранится на каждом segment-узле кластера.
- Запросы могут читать данные непосредственно с локального узла без межузловой передачи данных.
Ключевые преимущества
- Чрезвычайно высокая производительность запросов на одном узле: отсутствие перемещения данных обеспечивает быстрое время отклика.
Сценарии использования
- Небольшие таблицы (обычно менее 100 МБ), такие как измерения (dimension tables), справочники кодов или таблицы конфигураций.
- Часто запрашиваемые небольшие таблицы (например, план счетов, таблицы ролей пользователей).
- Измерения, участвующие в соединениях со множеством других таблиц (например, справочные таблицы ГИС).
Примечания
- Высокие накладные расходы на хранение: избыточность данных линейно возрастает с увеличением числа узлов.
- Сниженная производительность записи: все копии на всех узлах должны обновляться синхронно, что делает данный метод непригодным для таблиц с частыми операциями записи.
