Рекомендации по DDL

В этом документе описаны рекомендации по созданию таблиц в YMatrix.

0 Соглашения об именовании

Правило Обязательно
Имена баз данных, таблиц, столбцов, функций, представлений, последовательностей и псевдонимов должны содержать только строчные буквы, подчёркивания и цифры. Имя должно начинаться с буквы, не должно начинаться с pg, а также не может превышать 63 символов в длину Да
Имена столбцов не должны использовать зарезервированные или SQL-ключевые слова, такие как oid, xmin, ctid, select, insert, update Да
Имена индексов первичного ключа должны соответствовать шаблону pk_column_name; имена уникальных индексов — шаблону uk_column_name; обычные индексы — шаблону idx_column_name Да
Для секционированных таблиц следует использовать имя родительской таблицы в качестве префикса и правило секционирования — в качестве суффикса. Например: родительская таблица order, дочерние таблицы order_p_202010, order_p_202009 Да
Если поле представляет собой is_xxx, рекомендуется использовать формат имени is_xxx и тип BOOLEAN, например: is_deleted Нет
Рекомендуется, чтобы имена баз данных совпадали с именами сервисов приложения Нет
Имена таблиц должны быть понятными и самодостаточными. Избегайте двусмысленных сокращений и чрезмерно длинных имён. Следуйте шаблону Business Name_Table Function. Представлениям следует давать префикс, временным таблицам — использовать префикс tmp. Рекомендуется: trade_config, payment_task. Не рекомендуется: tradeconfig, paymenttask Нет

1 Хранение строк против хранения столбцов

Тип хранилища Подходит для
Ориентированное на строки Частые обновления или вставки
Запросы, обращающиеся к нескольким столбцам таблицы одновременно
Ориентированное на столбцы Таблицы с большим количеством столбцов, но запросы затрагивают лишь несколько из них
Операции агрегации по небольшому числу столбцов
Частые обновления отдельных столбцов без изменения остальных
Рекомендуется для большинства OLAP- и временных рядов

2 Движки хранения

YMatrix предоставляет четыре движка хранения: HEAP, AO и MARS3. Выбирайте подходящий движок в зависимости от объёма данных и требований к производительности записи.

Движок хранения Поддерживает Подходит для Уникальные особенности
HEAP Хранение строк Таблицы, требующие частых обновлений
Таблицы, использующие хранение строк
AO Хранение строк или столбцов Таблицы и секционированные таблицы с редкими обновлениями после начальной загрузки, где данные вставляются пакетами Интеграция с векторизованным исполняющим движком
MARS3 Гибридное (строка-столбец) или столбцовое хранение Сценарии временных рядов
OLTP-сценарии с высокочастотной малопакетной записью
OLAP-сценарии с низкочастотной крупнопакетной записью
Интеграция с векторизованным исполняющим движком
Сжатие цепочкой кодирования
Автоматическое многоуровневое хранение

Примечание!
Дополнительную информацию о движках хранения см. в разделе Обзор движков хранения.

3 Типы данных

Выбор точных типов данных помогает уменьшить занимаемое место, использование памяти и повысить эффективность запросов. Учитывайте следующее:

  • Минимизация размера: для целых и вещественных чисел выбирайте минимальный тип, способный покрыть требуемый диапазон. Например, используйте int2 вместо int4 или int8 для столбца возраста.
  • При использовании векторизованного исполняющего движка отдавайте предпочтение типам данных, лучше использующим векторизацию (например, int, float), при условии соответствия бизнес-требованиям.
  • Расширенные типы данных, такие как MXKV2, обеспечивают оптимальную производительность только при использовании с векторизованным исполняющим движком.

4 Ключи распределения

YMatrix распределяет данные по сегментам для использования параллельной обработки. При выборе ключа распределения учитывайте следующее:

  • Равномерное распределение: распределяйте данные равномерно, чтобы избежать перекоса и сбалансировать нагрузку на сегменты. Выбирайте столбец с высокой кардинальностью и равномерным распределением значений. При необходимости используйте случайное распределение для идеального баланса. Проверьте распределение данных с помощью: SELECT gp_segment_id,count(*) FROM table_name GROUP BY gp_segment_id;.
  • Производительность JOIN: для больших таблиц, часто участвующих в соединениях, используйте ключ соединения в качестве ключа распределения, чтобы обеспечить локальные соединения и избежать перемещения данных между сегментами.
  • Высокая кардинальность: предпочтительны столбцы с высокой степенью различимости (то есть большим количеством уникальных значений). Чем выше значение count(distinct column_name), тем лучше подходит столбец в качестве ключа распределения.
  • Не используйте столбцы, часто применяемые в условиях WHERE, в качестве ключей распределения; рассмотрите возможность их использования в качестве ключей секционирования.
  • Проверяйте распределение данных после начальной и инкрементной загрузки, чтобы минимизировать перекос.
  • Не используйте столбцы с датами или временными метками в качестве ключей распределения.

5 Секционирование

YMatrix — распределённая база данных. Создавайте секции на основе объёма данных. Основные моменты:

  • Настройте Автоматическое управление секциями (APM) для секционированных таблиц.
  • Если доступно объектное хранилище, а таблица использует MARS3, включите Автоматическое многоуровневое хранение.
  • Размер секции: для временных рядов разделяйте данные по году или месяцу. Избегайте ежедневного секционирования. Избыточное секционирование усложняет обслуживание и снижает производительность — особенно для столбцового хранения, где слишком много физических файлов уменьшает выгоды от оптимизации запросов.
  • Предварительное создание секций: не создавайте слишком много секций заранее. Создавайте их непосредственно перед использованием. Для месячных секций создавайте 12 секций следующего года в конце текущего года.
  • Стоимость обслуживания: в сценариях временных рядов используйте временное секционирование. Резервируйте и перемещайте данные по секциям. Вовремя очищайте устаревшие или пустые исторические секции. См. Регулярная очистка (VACUUM).
  • Применяйте секционирование только тогда, когда запросы могут выиграть за счёт исключения секций (pruning). Отдавайте предпочтение диапазонному секционированию перед списочным. Не используйте один и тот же столбец одновременно для распределения и секционирования.
  • Минимизируйте использование секций по умолчанию. Избегайте многоуровневого секционирования. Предпочтительнее меньшее количество секций с большим объёмом данных в каждой.

Особые замечания по обслуживанию секций таблиц MARS3:

  • Операции вроде ALTER требуют блокировки всей таблицы и могут блокировать параллельные запросы.
  • Одновременный запрос слишком большого числа секций значительно замедляет выполнение. Для таблиц MARS3 поддерживайте размер секции около 5 ГБ на сегмент.

Особые замечания по обслуживанию секций таблиц HEAP/AOCO:

  • Для таблиц HEAP стремитесь к ~5 ГБ на секцию на сегмент. Также контролируйте размеры индексов.
  • Для таблиц AOCO стремитесь к ~3 ГБ на секцию на сегмент. Также контролируйте размеры индексов.

Примечание!
Вышеуказанные рекомендации по размеру секций применимы к YMatrix 6.X.

6 Размер блока

Для таблиц MARS3 настройте параметр compress_threshold на уровне таблицы. Увеличение этого значения снижает частоту операций ввода-вывода, но может снизить эффективность фильтрации на уровне блоков.

7 Сжатие и несжатие

Сжатие, как правило, рекомендуется, особенно для таблиц с ориентацией на столбцы. Оно позволяет использовать простаивающие ресурсы ЦП для снижения времени ввода-вывода, уменьшая нагрузку на I/O и повышая производительность запросов.

Если используется движок хранения MARS3:

  • YMatrix рекомендует сжатие цепочкой кодирования, которое уменьшает размер данных на диске и объем данных, считываемых при запросах.
  • Сжатие добавляет накладные расходы на распаковку. При настройке запросов отдавайте предпочтение быстрым алгоритмам распаковки. Собственные алгоритмы YMatrix (кроме gorilla) обычно распаковываются быстрее, чем LZ4. Выбор делайте на основе характеристик данных.

HEAP не поддерживает явное сжатие.

8 Индексы

Индексы ускоряют выполнение запросов и хранятся отдельно. Этот раздел описывает особенности индексации.

Для таблиц HEAP и AO поддерживаются методы индексов B-tree, BRIN, Bitmap и Hash. Специализированные индексы для текстовых, пространственных и других типов данных включают GIN, GiST, ODIN, SP-GiST и TOAST.

MARS3 в настоящее время поддерживает только индексы BRIN. Вы можете дополнительно создать один или несколько индексов mars3_brin для повышения производительности запросов.

9 Реплицированные таблицы

  • Реплицированные таблицы хранят полную копию данных на каждом MXSegment, что уменьшает перемещение данных между сегментами для небольших таблиц.
  • Большие таблицы не должны использовать репликацию из-за высоких затрат на хранение и обслуживание.
    • Пример: детальная факт-таблица содержит сотни миллионов строк, а таблица прав пользователей — всего несколько сотен строк. Прямое соединение этих таблиц может породить миллиарды промежуточных строк. Репликация небольшой таблицы прав на все сегменты позволяет избежать дорогостоящей перераспределения данных.
  • Используйте параметр DISTRIBUTED REPLICATED для определения реплицированных таблиц.
  • Кроме того, эта стратегия устраняет ограничения на выполнение пользовательских функций между узлами.

10 Таблицы только на мастер-узле

Таблицы только на мастер-узле хранят данные исключительно на мастер-узле (MXMaster), не распределяя их по вычислительным узлам (MXSegments).

  • Идеально подходят для высокопроизводительных транзакционных (TP) рабочих нагрузок, позволяя избежать сложности и накладных расходов распределённой архитектуры. Операции над такими таблицами не требуют отправки задач на сегменты, что снижает издержки координации и повышает производительность TP.
  • Определяйте такие таблицы с помощью предложения DISTRIBUTED MASTERONLY. Подробности см. в разделе CREATE TABLE.
  • Используйте команду mxstart -am для запуска базы данных в режиме только мастер-узла.
  • Рекомендации по использованию:
    a. Хранение данных на мастер-узле потребляет его ресурсы; внимательно следите за распределением ресурсов.
    b. Аналитические запросы (AP) не могут использовать распределённую параллельную обработку, что потенциально может привести к снижению производительности.

11 Представления

  • Если ваша рабочая нагрузка включает частые агрегатные запросы, рассмотрите возможность создания Непрерывного представления (CV).
  • Если ваши запросы часто включают скользящие агрегации по недавним окнам данных, рассмотрите возможность создания представления Скользящее окно.