Лучшие практики касательно Greenplum
Модель данных
База данных Greenplum представляет собой аналитическую MPP-базу данных (shared-nothing). Эта модель существенно отличается от транзакционной базы данных SMP. В связи с этим рекомендуется использовать следующие лучшие практики:
- База данных Greenplum лучше всего работает с денормализованной схемой, подходящей для аналитической обработки MPP, например, со схемой Star или Snowflake;
- Использовать одинаковые типы данных для столбцов, используемых в соединениях между таблицами.
Хранение данных без кластеризованных индексов (heap) vs. Оптимизированное для добавления хранение данных (append-optimized storage)
- Используйте heap для таблиц, данные в которых будут часто обновляться с помощью операций UPDATE, DELETE и INSERT;
- Используйте append-optimized storage для аналитической обработки больших массивов данных, когда данные загружаются большими пакетами и над ними производятся в основном операции чтения;
- Избегайте операций INSERT, UPDATE или DELETE для append-optimized таблиц.
Строковое vs. Колоночное хранение данных
- Используйте строковое хранение для рабочих нагрузок с итеративными транзакциями, где требуются и частые обновления данных;
- Используйте строковое хранение в случае частого применения команды SELECT;
- Используйте строковое хранение для рабочих нагрузок общего назначения или смешанных рабочих нагрузок;
- Используйте колоночное хранение в случае редкого употребления команды SELECT а также в том случае, если агрегация данных вычисляется по небольшому числу столбцов;
- Используйте колоночное хранение для таблиц, содержащих отдельные столбцы, которые регулярно обновляются без изменения других столбцов в строке.
Компрессия
- Используйте компрессию для больших таблиц с оптимизированным для добавления хранением данных для улучшения операций ввода-вывода;
- Установите параметры компрессии столбцов на том уровне, где находятся данные;
Распределение
- Задайте столбцовое или случайное распределение для всех таблиц. Не используйте настройку по умолчанию;
- Используйте один столбец, который позволит равномерно распределить данные по всем сегментам;
- Не осуществляйте распределение по столбцам, которые будут использоваться в запросах, содержащих WHERE;
- Не осуществляйте распределение по датам или временным меткам;
- Никогда не распределяйте и не разбивайте таблицы по одному и тому же столбцу;
- Локальные join позволяет значительно повысить производительность за счет распределения по одному столбцу для больших таблиц, зачастую объединяемых вместе;
- Обязательно следите за равномерностью распределения данных после первоначальной и последующих загрузок;
Управление очередью ресурсов
- Установите значение vm.overcommit_memory равное 2;
- Настройте операционную систему таким образом, чтобы она не работала с большими страницами;
- С помощью gp_vmem_protect_limit можно установить максимальный размер памяти для работы, выполняемой в каждом сегменте базы данных;
-
Вы можете использовать gp_vmem_protect_limit, вычислив следующее:
- gp_vmem – общий размер памяти Greenplum Database
- Если общий размер памяти меньше 256 ГБ, используйте следующую формулу:
gp_vmem = ((SWAP + RAM) – (7.5GB + 0.05 * RAM)) / 1.7
- Если общий размер памяти равен или превышает 256 ГБ, используйте следующую формулу:
gp_vmem = ((SWAP + RAM) – (7.5GB + 0.05 * RAM)) / 1.17
где SWAP — это пространство подкачки на хосте в ГБ, а RAM — это количество ГБ оперативной памяти, установленной на хосте.
- max_acting_primary_segments – максимальное количество первичных сегментов, которые могут работать на хосте при активации зеркальных сегментов из-за отказа хоста или сегмента;
- gp_vmem_protect_limit
gp_vmem_protect_limit = gp_vmem / acting_primary_segments
Преобразуйте в МБ для установки значения конфигурационного параметра.
-
В сценарии, где генерируется большое количество рабочих файлов, коэффициент gp_vmem рассчитывается по следующей формуле для учета рабочих файлов:
- Если общий объем памяти менее 256 ГБ:
gp_vmem = ((SWAP + RAM) – (7.5GB + 0.05 * RAM - (300KB * <total_#_workfiles>))) / 1.7
- Если общий объем памяти равен или более 256 ГБ:
gp_vmem = ((SWAP + RAM) – (7.5GB + 0.05 * RAM - (300KB *
<total_#_workfiles>))) / 1.17- Никогда не устанавливайте gp_vmem_protect_limit слишком большим или превышающим физический объем оперативной памяти;
- Используйте вычисленное значение gp_vmem для расчета настройки параметра операционной системы vm.overcommit_ratio:
vm.overcommit_ratio = (RAM - 0.026 * gp_vmem) / RAM
- Используйте statement_mem для выделения памяти, используемой для запроса, на сегмент db;
- С помощью очереди ресурсов можно задать как количество активных запросов (ACTIVE_STATEMENTS), так и объем памяти (MEMORY_LIMIT), который может быть использован запросами;
- Привяжите всех пользователей к очереди ресурсов. Не используйте очередь по умолчанию;
- Установите PRIORITY в соответствии с реальными потребностями очереди для данной рабочей нагрузки и времени суток. Избегайте использования MAX;
- Убедитесь, что выделение памяти для очереди ресурсов не превышает значения параметра gp_vmem_protect_limit;
- Обновляйте настройки очередей ресурсов в соответствии с ежедневным потоком операций.
Секционирование
- Секционируйте исключительно большие таблицы;
- Секционируйте таблицу на основе часто используемых столбцов, например столбцов даты;
- Никогда не секционируйте и не распределяйте таблицы по одному и тому же столбу;
- Не используйте секционирование по умолчанию;
- Не используйте многоуровневое секционирование;
- Убедиться в том, что запросы выборочно сканируют секционированные таблицы, можно, изучив EXPLAIN-план запроса;
- При использовании столбцово-ориентированного хранилища не следует создавать слишком много секционирований, поскольку общее количество физических файлов на каждом сегменте вычисляется следующим образом: физические файлы = сегменты x столбцы x секционирования
Индексы
- В целом в Greenplum нет необходимости для использования индексов;
- Создайте индекс по одному столбцу столбцовой таблицы с целью сквозного просмотра таблиц, требующих запросов с высокой селективностью;
- Не индексируйте столбцы, которые часто обновляются;
- Перед загрузкой данных в таблицу следует сбросить индексы. После загрузки создайте индексы заново;
- Создайте индексы B-tree;
- Не создавайте растровые индексы для столбцов, которые часто обновляются;
- Избегайте использования растровых индексов для уникальных столбцов, данных с очень высокой или очень низкой кардинальностью. Растровые индексы лучше всего работают, когда столбец имеет низкую кардинальность - от 100 до 100 000 различных значений;
- Не используйте растровые индексы для транзакционных рабочих нагрузок;
- Не следует индексировать секционированные таблицы. Если индексы все же необходимы, то столбцы индекса должны отличаться от столбцов секционирования.
Очереди ресурсов
- Используйте очереди ресурсов для того, чтобы управлять рабочей нагрузкой на кластер;
- Свяжите все роли с очередью ресурсов, определенной пользователем;
- С помощью параметра ACTIVE_STATEMENTS можно ограничить количество активных запросов, которые могут выполняться одновременно;
- С помощью параметра MEMORY_LIMIT можно контролировать общий объем памяти, который могут использовать запросы, выполняемые по очереди;
- Настраивайте очередь ресурсов в соответствии с рабочей нагрузкой и временем суток.
Мониторинг и поддержка
- Выполните "Рекомендуемые задачи мониторинга и обслуживания" в Руководстве администратора Greenplum;
- Выполните gpcheckperf во время установки и после, сохраняя результаты для сравнения производительности системы с течением времени;
- Используйте все имеющиеся в Вашем распоряжении инструменты, чтобы понять, как ведет себя система при различных нагрузках;
- Изучите любое необычное событие, чтобы определить его причину;
- Следите за активностью запросов в системе путем периодического выполнения объяснительных планов для обеспечения оптимального выполнения запросов;
- Пересматривайте планы с целью определения того, используется ли тот или иной индекс;
- Знайте расположение и содержание файлов системного журнала и контролируйте их на регулярной основе, а не только при возникновении каких-либо проблем.
ANALYZE
- Определите, нужен ли анализ базы данных. Анализ не требуется, если для режима gp_autostats_mode установлено значение on_no_stats (по умолчанию) и таблица не разбита на разделы;
- При работе с большими наборами таблиц утилита analyzedb предпочтительнее ANALYZE, так как не требует анализа всей базы данных. Утилита analyzedb обновляет статистические данные для указанных таблиц инкрементально и параллельно. Для append optimized таблиц analyzedb обновляет статистику инкрементально только в том случае, если она не является текущей. Для heap таблиц статистика обновляется всегда. ANALYZE не обновляет метаданные таблицы, которые утилита analyzedb использует для определения актуальности статистики таблицы;
- При необходимости выборочно запускайте ANALYZE на уровне таблиц;
- Всегда выполняйте ANALYZE после операций INSERT, UPDATE и DELETE, которые существенно изменяют данные;
- Всегда выполняйте ANALYZE после операций CREATE INDEX.
- Если выполнение ANALYZE для очень больших таблиц занимает слишком много времени, запустите ANALYZE только для столбцов, используемых в join, WHERE, SORT, GROUP BY или HAVING;
- При работе с большими наборами таблиц используйте analyzedb вместо ANALYZE.
Vacuum
- Выполняйте VACUUM после крупных операций UPDATE и DELETE;
- Не используйте VACUUM FULL. Вместо этого применяйте CREATE TABLE...AS , переименовайте таблицу и удаляйте изначальную таблицу;
- Частое выполнение VACUUM для системных каталогов позволяет избежать разрастания каталогов и необходимости выполнения VACUUM FULL для таблиц каталогов;
- Никогда не прерывайте VACUUM для таблиц каталога.
Загрузка данных
- Увеличивайте параллелизм при увеличении числа сегментов;
-
Равномерно распределяйте данные по максимальному количеству узлов ETL;
- Разделяйте большие файлы на равные части и распределяйте данные по максимально возможному количеству файловых систем;
- Запускайте по 2 gpfdist для каждой файловой системы;
- Запускайте gpfdist на максимально возможном количестве интерфейсов;
- Используйте gp_external_max_segs для управления количеством сегментов, которые будут запрашивать данные у процесса gpfdist;
- Всегда поддерживайте четное соотношение между gp_external_max_segs и количеством процессов gpfdist.
- Всегда сбрасывайте индексы перед загрузкой данных в существующие таблицы и заново создавайте индекс после загрузки;
- Выполняйте VACUUM после ошибок загрузки для восстановления пространства.
gptransfer (устарел)
Важно: gptransfer устарел и будет удален из последующих версий Greenplum.
- Избегайте использования опций --full или --schema-only. Вместо этого скопируйте схемы в целевую базу данных другим методом, а затем перенесите данные;
- Сбросьте индексы перед переносом таблиц и воссоздавайте их по завершении переноса;
- Переносите небольшие таблицы в базу данных с помощью команды SQL COPY;
- Переносите большие таблицы с помощью gptransfer;
- Перед выполнением переноса протестируйте работу gptransfer. Экспериментируйте с опциями --batch-size и --sub-batch-size для достижения максимального параллелизма. Определите правильное пакетирование таблиц для итеративных запусков gptransfer;
- Используйте только полные имена таблиц. Точки (.), пробельные символы, кавычки (') и двойные кавычки ("") в именах таблиц могут вызвать сложности;
- Если вы используете опцию --validation для проверки данных после передачи, не забудьте также использовать опцию -x для установки блокировки на исходную таблицу;
- Убедитесь, что в базе данных созданы все роли, функции и очереди ресурсов. Эти объекты не передаются при использовании опции gptransfer –t;
- Скопируйте конфигурационные файлы postgresql.conf и pg_hba.conf из исходного кластера в целевой кластер;
- Установите необходимые расширения в целевую базу данных с помощью gppkg.
Безопасность
- Защитите идентификатор пользователя gpadmin и разрешите доступ к нему только системным администраторам;
- Администраторы должны входить в Greenplum только под именем gpadmin при выполнении определенных задач по обслуживанию системы (таких как обновление или расширение);
- Ограничьте количество пользователей, имеющих роль SUPERUSER. Эта роль минует все проверки привилегий доступа в Greenplum Database, а также очереди ресурсов. Подобные права должны предоставляться только системным администраторам. См. раздел "Изменение атрибутов ролей" в Руководстве администратора базы данных Greenplum;
- Пользователи баз данных никогда не должны входить в систему под именем gpadmin, а ETL или производственные рабочие нагрузки не должны выполняться под именем gpadmin;
- Назначьте отдельную роль Greenplum Database каждому пользователю, приложению или службе, которые входят в систему;
- Для приложений или веб-сервисов следует рассмотреть возможность создания отдельной роли для каждого приложения или сервиса;
- Используйте группы для управления привилегиями доступа;
- Проводите жесткую политику в отношении паролей ОС;
- Обеспечьте защиту важных файлов операционной системы.
Шифрование
- Шифрование и расшифровка данных требуют значительных затрат; шифруйте только те данные, которые действительно требуют шифрования;
- Перед внедрением любого решения по шифрованию в производственную систему необходимо провести тестирование производительности;
- Сертификаты сервера в системе Greenplum должны быть подписаны центром сертификации (ЦС), чтобы клиенты могли аутентифицировать сервер;
- Клиентские соединения с Greenplum должны использовать SSL-шифрование, когда соединение проходит по незащищенному каналу;
- Симметричная схема шифрования, в которой один и тот же ключ используется как для шифрования, так и для дешифрования, имеет более высокую производительность, чем асимметричная схема, и должна использоваться в тех случаях, когда ключ может быть безопасно разделен;
- Используйте криптографические функции для шифрования данных на диске. Данные шифруются и расшифровываются в процессе работы с базой данных, поэтому важно защитить клиентское соединение с помощью SSL, чтобы избежать передачи незашифрованных данных;
- Используйте протокол gpfdists для защиты данных ETL при загрузке и выгрузке из базы данных.
Высокая степень доступности
Важно: Следующие рекомендации относятся к развертыванию программно-аппаратного комплекса, не к общедоступной облачной инфраструктуре, где уже могут существовать решения по обеспечению высокой степени доступности.
- Используйте RAID хранилище, предполагающее использование от 8 до 24 дисков;
- Используйте RAID 1, 5 или 6, чтобы дисковый массив мог справиться с отказом одного из дисков;
- Настройте "горячий резерв" в дисковом массиве, чтобы при обнаружении отказа диска автоматически начать его восстановление;
- Обеспечьте защиту от выхода из строя всего дискового массива и ухудшения качества работы при восстановлении путем зеркалирования дисков;
- Регулярно контролируйте использование диска и при необходимости добавляйте дополнительное пространство;
- Контролируйте перекоса в использовании сегментов для обеспечения равномерного распределения данных и равномерного потребления памяти во всех сегментах;
- Запланируйте, как переключить клиентов на нового мастера при возникновении сбоя, например, путем обновления адреса мастера в DNS;
- Настройте мониторинг для отправки уведомлений в приложение мониторинга системы или по электронной почте при отказе основного устройства;
- Настройте зеркала для всех сегментов;.
- Оперативное восстановление отказавших сегментов с помощью утилиты gprecoverseg позволяет восстановить систему в максимально сжатые строки;
- Настройте Greenplum для отправки SNMP-уведомлений на сетевой монитор;
- Настройте в конфигурационном файле $MASTER_DATA_DIRECTORY/postgresql.conf отправку уведомлений по электронной почте, чтобы система Greenplum могла отправлять администраторам письма при обнаружении критических проблем;
- Используйте конфигурацию Dual Cluster для обеспечения дополнительного уровня резервирования и дополнительной пропускной способности обработки запросов;
- Регулярно выполняйте резервное копирование баз данных Greenplum;
- Используйте инкрементное резервное копирование, если heap таблицы относительно небольшого размера;
- Если резервные копии сохраняются в локальном кластере хранилище, по завершении резервного копирования переместите файлы в безопасное место, находящееся вне кластера;
- Если резервные копии сохраняются в файлах NFS, используйте решения наподобие Dell EMC Isilon, чтобы избежать сложностей с выполнением операций ввода-вывода;
- Рассмотрим возможность использования интеграции Greenplum для потоковой передачи резервных копий на корпоративные платформы резервного копирования Dell EMC Data Domain или Veritas NetBackup.
