Рекомендации по DDL
В этом документе описаны рекомендации по созданию таблиц с использованием YMatrix.
0 Соглашения об именовании
| Требование |
Обязательно |
Имена баз данных, таблиц, столбцов, функций, представлений, последовательностей, псевдонимов и т.д. должны состоять из строчных букв, подчёркиваний и цифр, начинаться со строчной буквы и не должны начинаться с pg. Длина имени объекта не должна превышать 63 символов |
Да |
Имена полей (или столбцов) не должны использовать зарезервированные имена или ключевые слова, такие как oid, xmin, ctid, select, insert, update и т.д. |
Да |
Имя первичного ключа — pk_column_name, уникального индекса — uk_column_name, обычного индекса — idx_column_name |
Да |
Для секционированных таблиц следует использовать имя родительской таблицы в качестве префикса, а характеристики дочерней таблицы — в качестве суффикса, например, родительская таблица order, дочерние таблицы order_p_202010, order_p_202009 |
Да |
Если поле означает «является ли xx», рекомендуется использовать формат is_xxx и тип Boolean, например is_deleted |
Нет |
| Желательно, чтобы имя базы данных совпадало с именем сервиса приложения |
Нет |
Имена таблиц должны быть понятными и осмысленными, избегая двусмысленных сокращений или чрезмерно длинных наименований. Рекомендуется следовать формату business name_table purpose, представлениям добавлять префикс, временным таблицам — префикс 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.
4 Ключ распределения
YMatrix поддерживает распределение данных по разным узлам для использования возможностей параллельной обработки и повышения производительности. При выборе ключа распределения следует учитывать следующие факторы:
- Равномерность данных. Равномерное распределение данных позволяет эффективно избежать узких мест и сбалансировать нагрузку между узлами. Например, можно использовать один столбец, который равномерно распределяет данные по всем сегментам, в качестве ключа распределения. Значения в столбце, используемом в качестве ключа распределения, должны иметь большой и равномерный диапазон; в противном случае может возникнуть перекос данных. В особых случаях можно рассмотреть случайное распределение для обеспечения абсолютной равномерности. Запрос для проверки распределения данных выглядит следующим образом:
SELECT gp_segment_id, count(*) FROM table_name GROUP BY gp_segment_id;.
- Удобство JOIN. Для больших таблиц, участвующих в соединениях, желательно использовать поля соединения в качестве ключей распределения. Это значительно повышает производительность за счёт локальных соединений и избегания перемещения данных между узлами.
- Дискретность полей. Выбирайте поле с наибольшим количеством различных значений в таблице в качестве ключа распределения. Чем больше значение
count(distinct field_name) (то есть количество уникальных значений в этом поле), тем более подходящим является это поле в качестве ключа распределения.
- Не используйте столбцы из условия
WHERE запроса в качестве ключей распределения; вместо этого используйте их в качестве ключей секционирования.
- Проверяйте данные после начальной и инкрементной загрузки, чтобы минимизировать перекос данных.
- Не используйте даты или временные метки в качестве ключей распределения.
5 Настройка секционирования
YMatrix — распределённая база данных, которая создаёт различные секции в зависимости от объёма данных. При настройке секционирования следует учитывать несколько ключевых моментов:
- Размер секции. Для сценариев временных рядов обычно рекомендуется секционирование по году или месяцу, а не по дням. На практике чрезмерно детальное планирование секций затрудняет обслуживание и снижает производительность: при хранении по столбцам слишком большое количество физических файлов может мешать оптимизации запросов.
- Резервирование секций. Не нужно заранее резервировать слишком много секций. Их можно создавать перед использованием. Например, если используется месячное секционирование, можно создавать 12 новых секций на следующий год в конце каждого года.
- Стоимость обслуживания секций. В сценариях временных рядов часто в качестве ключа секционирования используется время. По мере прохождения времени можно резервировать и перемещать данные по секциям. Устаревшие секции, в которых подтверждено отсутствие данных или нет актуальных данных, следует своевременно очищать. Подробнее см. в разделе Регулярная очистка (Vacuuming).
- Используйте секционирование только тогда, когда возможно исключение секций (partition pruning) на основе условий запроса. Отдавайте приоритет диапазонному секционированию перед списочным и избегайте одновременного распределения и секционирования таблицы по одному и тому же столбцу.
- Ограничьте использование секций по умолчанию, не применяйте многоуровневое секционирование и стремитесь создавать меньше секций, чтобы каждая содержала больше данных.
Особенности операций обслуживания секций для таблиц MARS2/MARS3:
- Операции
ALTER над секциями требуют блокировки всей таблицы, что может вызвать взаимоблокировки запросов.
- Одновременный запрос слишком большого количества секций может значительно замедлить выполнение. Поэтому для таблиц MARS2/MARS3 рекомендуется ограничивать размер одной секции на одном сегменте примерно 5 ГБ.
Особенности выполнения операций обслуживания секций для таблиц HEAP/AOCO:
- Для таблиц HEAP рекомендуется ограничивать размер одной секции на одном сегменте примерно 5 ГБ. Также необходимо контролировать размер индексов.
- Для таблиц AOCO рекомендуется ограничивать размер одной секции на сегменте примерно 3 ГБ. Также необходимо контролировать размер индексов.
Примечание!
Указанные рекомендуемые значения размера секций применимы к YMatrix 5.X.
6 Размер блока
Вы можете настроить порог сжатия, указав параметр compress_threshold на уровне таблицы MARS3. Увеличение этого значения может снизить количество операций ввода-вывода, но также может снизить скорость фильтрации блоков.
7 Сжатие и несжатие
Рекомендуется использовать сжатое хранение, особенно для таблиц с хранением по столбцам, где сжатие особенно эффективно. Сжатое хранение позволяет использовать свободные ресурсы ЦП для компенсации времени чтения/записи, снижая нагрузку на ввод-вывод и повышая эффективность запросов.
Если вы используете движок хранения MARS2 или MARS3 для создания таблиц:
- Что касается типов сжатия, YMatrix рекомендует использовать цепочечное сжатие. Оно уменьшает объём данных на диске и снижает объём данных, считываемых при запросах.
- Сжатие также связано с накладными расходами на распаковку, поэтому при оптимизации запросов следует отдавать предпочтение алгоритмам с более высокой скоростью распаковки. Собственные алгоритмы YMatrix, за исключением Gorilla, как правило, превосходят LZ4 по скорости распаковки и могут выбираться в зависимости от характеристик данных.
HEAP не поддерживает явное сжатие.
8 Индексы
Индексы — это метод ускорения запросов. Данные индексов обычно хранятся отдельно, поэтому этот раздел рассматривает их отдельно.
Для таблиц HEAP и AO существуют различные методы индексации: Btree, Brin, Bitmap, Hash. Для текстовых и пространственных данных дополнительно доступны Gin, Gist, Odin, Spgist и Toin.
MARS2 в настоящее время поддерживает индексы первичного ключа и индексы Brin. Первые — это ключи сортировки, то есть индексы, указанные с помощью mars2_btree, которые хранятся отдельно в указанном файле индекса. Вторые — это индексы minmax, созданные для конкретного столбца и хранящиеся в отдельном файле метаданных. Примечания:
- Если ключ сортировки состоит из нескольких столбцов, внимательно определите порядок этих столбцов. Чем дальше столбец находится в ключе сортировки, тем хуже эффект фильтрации, хотя локальная сортировка всё ещё положительно влияет на сжатие. Например, если требуется точечный запрос по устройству, ключ сортировки в сценарии временных рядов — номер устройства
(vin). Если требуется детальный запрос, агрегированный запрос или запрос по нескольким устройствам в определённый период времени, ключ сортировки обычно включает номер устройства и временную метку (vin,daq_time).
- Выбор индексов Brin тесно связан с результатами сортировки. Если количество кортежей в отсортированном столбце уже мало, сортировка может не обеспечить фильтрацию и даже внести отрицательные накладные расходы, поэтому такие столбцы следует исключить.
MARS3 в настоящее время поддерживает индексы Brin. Вы можете дополнительно создать один или несколько индексов mars3_brin для повышения эффективности запросов (аналогично индексу minmax для таблиц MARS2).
9 Таблицы-копии
- Данные таблицы-копии сохраняются на каждом сегменте, что уменьшает перемещение и перераспределение данных малых таблиц между секциями.
- Большие таблицы не подходят для стратегии распределения через копирование, поскольку дублирование больших объёмов данных на каждом узле требует значительных затрат на хранение и обслуживание.
- Например, таблица детализированных данных сцены содержит миллиарды записей, а таблица прав пользователей — всего несколько сотен. Теперь необходимо связать таблицу детализированных данных сцены с таблицей прав пользователей с помощью запроса. Если соединять их напрямую, потребуется обработка сотен миллиардов записей. Только путём копирования таблицы прав пользователей на каждый сегмент можно избежать таких огромных затрат.
- Таблица-копия настраивается с помощью параметра
DISTRIBUTED REPLICATED.
- Помимо указанных функций, использование этой стратегии также позволяет снять ограничения на действия, которые пользовательские функции могут выполнять на узлах.
