20 июня 2024 года вышел очередной релиз Greenplum. Разбираемся с ключевыми новинками выпуска 7.2: сканирование индекса в AO-таблицах, изменения в оптимизаторе GPORCA, улучшенная обработка геопространственных данных и новая служба централизованного управления сегментами Postmaster.
Новинки Greenplum 7.2 для дата-инженера
Начнем с изменений, повышающих производительность Greenplum. Одним из них стало сканирование индекса в AO-таблицах, оптимизированных для добавления данных. Ранее поддерживалось только сканирование битовых карт в памяти. Вообще сканирование индексов в AO-таблицах – не новая функция для Greenplum, однако, она была отключена из-за ограничений CBO-модели. Теперь эти ограничения устранены и сканирование индексов в AO-таблицах приводит к значительному повышению производительности для определенных шаблонов запросов до 1000 раз. Для этого появились 2 новых параметра:
- gp_cpu_decompress_cost, который позволяет пользователю точно настраивать стоимость распаковки во время сканирования индексов AO-таблиц;
- gp_enable_ao_indexscan, чтобы выполнять сканирование индексов в AO-таблицах.
Оптимизатор GPORCA теперь поддерживает параметризованные запросы, полные хэш-соединения и оконные агрегаты с функцией DISTINCT, снижая зависимость от планировщика на базе Postgres. Также появились новые подсказки оптимизатора, в т.ч. по мощности, доступу к таблицам, типу соединения и порядку соединения, для уточнения планов запросов и повышения производительности.
Теперь Greenplum поддерживает операторы OFFSET/LIMIT pushdown для внешних таблиц с данными, распределенными по нескольким удаленным серверам при установке mpp_execute = ‘all segments’. Это означает, что операции OFFSET и LIMIT выполняются непосредственно на удаленных серверах, а не на уровне центрального сервера, что уменьшает объем данных, передаваемых по сети. Настройка mpp_execute = ‘all segments’ указывает, что операции должны выполняться на всех сегментах (узлах) многопроцессорного кластера параллельно. Таким образом, выполнение OFFSET/LIMIT операций на внешних серверах распределяется между всеми сегментами, повышая общую производительность Greenplum.
Для колоночных AO-таблиц команда ADD COLUMN больше не требует записи значений по умолчанию для всего столбца. Ранее при добавлении нового столбца, нужно было заполнить все строки этого столбца значениями по умолчанию, что было довольно ресурсоемким процессом. Теперь это больше не требуется, а сам процесс добавления столбцов стал быстрее.
В Greenplum 7.2 включена поддержка поиска по системному каталогу pg_attribute_encoding с использованием системного кэша syscache. Системный каталог PostgreSQL хранит информацию о кодировке атрибутов (столбцов) таблиц, а системный кэш используется для ускорения доступа к метаданным базы данных. Теперь поиск информации о кодировках столбцов будет выполняться быстрее благодаря использованию этого кэша.
Благодаря поддержке пространственного индекса H3 производительность индексирования геопространственных данных в Greenplum 7.2 стала намного выше. Иерархическая система геопространственного индексирования H3 обеспечивает гексагональную иерархическую геопространственную индексацию. Это значительно повышает производительность пространственных запросов, превосходя традиционные решения PostGIS за счет сокращения времени выполнения запросов с ~80 секунд до ~0,7 секунды. А модуль 3DCityDb обеспечивает обработку пространственных данных.
Изменения в администрировании
Чтобы сделать процесс восстановления резервной копии основного сегмента более прозрачным, команда gpstate -e теперь отображает дополнительное поле под названием Startup recovery remaintes bytes. Это поле сообщает количество байтов восстановления архива журнала упреждающей записи (WAL) запуска, оставшихся для сегмента зеркала, который находится в процессе восстановления, прежде чем сегмент будет помечен как рабочий (up) в конфигурационной таблице gp_segment_configuration. Так можно понять, сколько байтов данных из WAL-журнала еще нужно восстановить для зеркального сегмента, т.е. резервной копии основного сегмента. Инструмент gpsupport gp_log_collector теперь поддерживает сбор журналов для VMware Greenplum Disaster Recovery с помощью новых опций -with-gpdr-primary и -with-gpdr-recovery.
Вместо HA-сервиса для обеспечения высокой доступности основных сегментов Greenplum в кластере без зеркал теперь используется новая служба Postmaster. Замена исключает ранее происходившие конфликты между обычными утилитами кластера, такими как gpstart/gpstop, и службой HA. В Greenplum, обеспечивающем высокую доступность данных, традиционно использовались зеркала для репликации данных. Однако, теперь, Postmaster работает как центральная служба и берет на себя управление процессами сегментов Greenplum, наблюдая состояние сегментов и отвечая за их перезапуск в случае сбоев. Использование Postmaster упрощает управление кластером, поскольку теперь административные задачи и задачи высокой доступности координируются одной службой. Это улучшает согласованность и надежность работы кластера Greenplum.
В Greenplum 7.2 теперь есть новый параметр конфигурации сервера — gp_appendonly_compaction_segfile_limit. Этот параметр задает минимальное количество файлов сегментов, необходимых для вставок перед следующим сжатием. А параметр gp_max_partition_level ограничивает количество уровней иерархии разделов, которые можно создать с использованием классического синтаксиса. Также добавлена поддержка сжатия данных методом RLE (Run-Length Encoding) с использованием эффективного алгоритма Zstandard (zstd). Метод сжатия RLE заменяет последовательности одинаковых элементов на один элемент и количество его повторений.
Для удобства администрирования добавлена конфигурация gp_resgroup_print_operator_memory_limits, которая позволяет вывести лимиты памяти для операторов (в пояснении), назначенные управлением памятью группы ресурсов. Также в выпуске 7.2. исправлены проблемы, связанные с транзакциями, аварийными завершениями процессов, некорректной аутентификацией, созданием индексов, перемещением файлов, восстановлением данных, утечками памяти и пр. Еще устранены ошибки с утилитами управления кластером и потоком данных, в т.ч. в утилите gpcheckperf и доступе к внешним таблицам, данные которых хранятся на внешних (удаленных) серверах, а не внутри основного кластера БД.
Наконец, Greenplum 7.2 расширяет свою экосистему новыми компонентами. В частности, добавлен pg_cron – планировщик заданий на основе cron, работающий внутри базы данных, который позволяет планировать выполнение SQL-команд непосредственно в БД, упрощая рутинное обслуживание и задачи обработки данных за счет автоматизации. А совместимость с Oracle обеспечивает расширение orafce_ext, позволяя выполнять совместимые с Oracle функции SQL для работы с типом данных данных RAW, поддержки интерфейсов Oracle и модуля UTL_RAW.
Освойте администрирование и эксплуатацию Greenplum для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
