Хранение информации и основные операции в Arenadata DB¶
Сравнение хранилищ типа “heap” и “append-optimized”¶
Существуют два типа хранения данных в таблицах – heap и append-optimized.
Хранение типа heap следует использовать для таблиц и разделов, которые получают итеративные пакетные, однострочные, а также синхронные операции UPDATE, DELETE и INSERT.
Хранение append-optimized следует использовать для таблиц и разделов, которые редко обновляются после начальной загрузки и в которых последующие вставки выполняются только в больших пакетных операциях.
Important
Никогда не выполнять однострочные операции INSERT, UPDATE или DELETE в таблицах типа append-optimized
Important
Никогда не выполнять параллельные пакетные операции UPDATE или DELETE в append-optimized (это не касается одновременных операций вставки INSERT)
Хранение данных по столбцам и строкам¶
Построчное хранение необходимо использовать для рабочих нагрузок с итеративными транзакциями, в которых требуются обновления и частые вставки. Также его следует использовать для общих целей или в случае, если рабочие нагрузки носят смешанный характер.
Хранить данные по столбцам стоит в том случае, когда запросы необходимы для поиска узкого спектра данных. Также хранение по столбцам подходит при наличии отдельных столбцов, которые регулярно обновляются без изменения других столбцов в строке.
Сжатие¶
Для улучшения ввода-вывода в системе следует использовать сжатие для append-optimized таблиц. Параметры сжатия столбцов следует установить на уровне, на котором находятся данные. Рекомендуется балансировать более высокий уровень сжатия с временем и циклами ЦП, необходимыми для сжатия и распаковки данных.
Распределение¶
Для корректного распределения данных необходимо следовать рекомендациям:
- Задать значения столбца или выбрать случайное распределение для всех таблиц. Не использовать значение по умолчанию;
- Использовать один столбец, который будет равномерно распределять данные по всем сегментам;
- Не распределять на столбцы, которые будут использоваться при запросе WHERE;
- Не распределять на даты или временные метки;
- Никогда не распределять и не разделять таблицы в одном столбце;
- Достичь локальных объединений для значительного повышения производительности, распределив их в одном столбце для больших таблиц, которые обычно объединяются вместе;
- Убедиться, что данные равномерно распределены после начальной загрузки и после инкрементных нагрузок;
- В конечном итоге убедиться, что нет искажений данных.
Управление памятью¶
Для управления памятью необходимо следовать рекомендациям:
- Установить значение параметра
vm.overcommit_memory
на2
; - Не настраивать ОС для использования огромных страниц;
- Использовать
gp_vmem_protect_limit
, чтобы установить максимальный размер памяти, которую экземпляр может выделить для работы, выполняющейся в каждом сегментном хосте; - Не допускать, чтобы значение
gp_vmem_protect_limit
превышало значения физического RAM в системе; - Установить правильное значение для
gp_vmem_protect_limit
следующим образом:
(SWAP + (RAM vm.overcommit_ratio)) 0.9 / number_segments_per_server
- Использовать
statement_mem
для выделения памяти, используемой для запроса на сегмент db; - Использовать очереди ресурсов для установки количества активных запросов (ACTIVE_STATEMENTS) и суммы памяти (MEMORY_LIMIT), которые могут использоваться запросами в очереди;
- Связать всех пользователей с очередью ресурсов. Не использовать значения, установленные по умолчанию;
- Установить PRIORITY в соответствии с реальными потребностями очереди для рабочей нагрузки;
- Убедиться, что распределение памяти очереди ресурсов не превышает
gp_vmem_protect_limit
; - Обновить параметры очереди ресурсов в соответсвии с ежедневным потоком операций.
Секционирование¶
При секционировании необходимо следовать рекомендациям:
- Секционировать можно только большие таблицы;
- Использовать секционирование только в том случае, если обрезка разделов может быть выполнена на основе критериев запроса;
- Выбирать секционирование по диапазону вместо секционирования по списку;
- Разбить таблицу на основе предиката запроса;
- Не разделять и не распределять таблицы по одному столбцу;
- Не использовать секционирование по умолчанию;
- Не использовать многоуровневое секционирование; создавать меньше разделов с большим количеством данных в каждом разделе;
- Проверить, что запросы выборочно сканируют секционированные таблицы путем изучения плана запроса EXPLAIN;
- Не создавать слишком много разделов с хранилищем, ориентированным на хранение по столбцам, из-за общего количества физических файлов на каждом сегменте:
физические файлы = сегменты * столбцы * разделы
Индексы¶
Как правило, при работе с базой данных ADB необходимости в использовании индексов нет. Однако, если это требуется, следует создать индекс в одном столбце таблицы (хранение данных по столбцам) для сквозного доступа для таблиц высокой кардинальности, требующих запросов с высокой избирательностью. И следовать рекомендациям:
- Не индексировать столбцы, которые часто обновляются;
- Всегда отбрасывать индексы перед загрузкой данных в таблицу. После загрузки повторно создавать индексы для таблицы;
- Создавать выборочные индексы B-дерева;
- Не создавать bitmap-индексы в столбцах, которые находятся в процессе обновления;
- Не использовать bitmap-индексы для уникальных столбцов и данных очень большой или маленькой кардинальности;
- Не использовать bitmap-индекс для транзакционных нагрузок;
- Как правило, не следует индексировать секционированные таблицы. Если все же индексы необходимы, столбцы индекса должны отличаться от столбцов секции.
Очереди ресурсов¶
Для управления рабочей нагрузкой в кластере необходимо использовать очереди ресурсов:
- Использовать параметр
ACTIVE_STATEMENTS
для ограничения количества активных запросов, которые члены конкретной очереди могут запускать одновременно; - Использовать параметр
MEMORY_LIMIT
для управления общим объемом памяти, который может использоваться для запросов, запущенных в очереди; - Не устанавливать все очереди в MEDIUM, так как это фактически ничего не делает для управления рабочей нагрузкой;
- Изменять очереди ресурсов в зависимости от рабочей нагрузки.
COPY¶
Самый низкоуровневый способ импортировать и экспортировать данные:
- Не создает паразитных блокировок в отличии от средств бекапирования;
- Работает как на мастере, так и на сегментах;
- Интегрируется со сторонним ПО;
- Текст и BINARY;
- Может экспортировать результат выполнения запроса, представлений и т.д.