Рекомендации по 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 Таблицы-копии
- Данные реплицированной таблицы сохраняются на каждом сегменте, что уменьшает перемещение и перераспределение данных малых таблиц между секциями.
- Большие таблицы не подходят для стратегии распределения с репликацией, поскольку репликация больших объёмов данных на каждый узел требует значительных затрат на хранение и обслуживание.
- Например, таблица детализированных данных сцены содержит миллиарды записей, а таблица прав пользователей — всего несколько сотен. Теперь необходимо связать таблицу детализированных данных сцены с таблицей прав пользователей с помощью запроса. Если они связаны напрямую, будет задействовано сотни миллиардов записей. Только путём копирования таблицы прав пользователей на каждый Segement можно избежать таких огромных затрат.
- Таблица-копия настраивается с помощью параметра
DISTRIBUTED REPLICATED.
- Помимо указанных функций, использование этой стратегии также позволяет снять ограничения на действия, которые пользовательские функции могут выполнять на узлах.
10 Представления
- Если в сценарии запросов много кластерных запросов, рекомендуется создать представление Continuous Cluster.
- Если сценарий запросов включает непрерывную агрегацию данных за последний период времени, рекомендуется создать представление sliding window.
