Сегодня познакомимся с возможностями и ограничениями open-source проект Diskquota, направленного на оптимизацию управления дисковым пространством базы данных Greenplum.
Зачем ограничивать использование диска в Greenplum и как это сделать
Эффективная утилизация аппаратных ресурсов, в т.ч. жесткого диска – один из факторов, позволяющих ускорить работу любой СУБД, в т.ч. Greenplum. Будучи популярным проектом с открытым исходным кодом, Greenplum активно дополняется с помощью сообщества. Помимо самой СУБД, библиотеки и утилит, расширяющих ее функциональные возможности, на официальной странице Greenplum выложен проект Diskquota. Он реализует управление квотами дискового пространства на основе различных объектов базы данных, таких как схема и роль.
Diskquota основан на pg_quota — расширении для ограничения использования дискового пространства PostgreSQL. Дисковое пространство, используемое каждым отношением, присваивается его владельцу. Пространство, используемое временными файлами или временными отношениями, объектами каталога и пр., игнорируется. Поскольку Greenplum основана на PostgreSQL, эта MPP-СУБД часто использует ее дополнения. Однако, Diskquota отличается от pg_quota: оно поддерживает больше DDL- и DML-запросов, которые могут изменить использование диска объектами базы данных. А также Diskquota ориентирован на MPP-архитектуру Greenplum.
Diskquota позволяет гибко ограничить использование диска, поддерживая следующие варианты применения:
- запрещение загрузки данных запроса в схему/роль вне квоты до его выполнения;
- отмена данных запроса в схему/роль, если предел квоты будет достигнут динамически во время выполнения запроса
Разумеется, на практике применение этих ограничений реализуется не мгновенно: есть некоторая задержка при обнаружении схем или ролей, предел квоты которых превышен.
Расширение Diskquota основано на платформе фонового рабочего процесса в Greenplum 6 и более поздних версиях. Для каждого мастера базы данных существует только один процесс запуска расширения. Для сегментов Greenplum процесса запуска нет. Процесс запуска отвечает за управление рабочими процессами, вызывая метод RegisterDynamicBackgroundWorker() для создания новых рабочих процессов и сохранения их дескрипторов. Также процесс запуска вызывает метод TerminateBackgroundWorker() для завершения рабочих процессов, которые отключены, когда администратор базы данных изменяет конфигурацию diskquota.monitor_databases. Существует множество рабочих процессов, по одному для каждой базы данных, указанной в diskquota.monitor_databases. Как и процесс запуска, рабочие процессы запускаются только на главном узле.
Каждый рабочий процесс вызывает серверный интерфейс программирования (SPI, Server Programming Interface) для получения размера активной таблицы, чтобы ограничить общую стоимость рабочих процессов. Чтобы это не стало узким местом, пока Diskquota позволяет работать с максимум 10 базами данных одновременно. Рабочие процессы отвечают за мониторинг использования диска схемами и ролями для целевой базы данных, а также за соблюдение квот. При этом периодически, что можно настроить в diskquota.naptime, пересчитывается размер активных таблиц, чтобы обновить схему или использование диска владельцем. Затем результат сравнивается с лимитом квоты для этих схем или ролей. Если лимит превышен, соответствующие схемы или роли помещаются в карту отклонения в общей памяти. Такая карта отклонений используется для принудительной отмены выполнения запросов, которые планируют загружать данные в эти схемы или роли.
Поскольку Greenplum имеет MPP-архитектуру, программа запуска diskquota и рабочие процессы выполняются на мастере, что позволяет экономить ресурсы памяти в сегментах и упрощает связь между мастером и сегментом путем периодического вызова запросов к SPI. Сегменты используются для обнаружения активной таблицы и расчета ее размера. Мастер агрегирует размер таблицы из каждого сегмента и поддерживает модель дисковых квот.
Как работает расширение Diskquota
Важной концепцией расширения Diskquota являются активные таблицы, размер которых может измениться за последний интервал проверки квоты. Они обнаруживаются на стороне сегмента с помощью хуков (перехватчиков) в методах smgecreate(), smgrextend() и smgrtruncate(). Активные таблицы сохраняются в общей памяти. Рабочий процесс Diskquota периодически вызывает запросы на отправку ко всем сегментам и использует активные таблицы в общей памяти. При этом relfilenode преобразуется в отношение и вычисляется размер таблицы с помощью метода pg_table_size(), который суммирует размер таблицы в каждом сегменте.
Расширение Diskquota использует два типа общей памяти:
- для сохранения карты отклонения, чтобы поддерживать до 1 МБ объектов базы данных, размер которых превышает квоту;
- для сохранения списка активных таблиц, чтобы поддерживать активные таблицы размером до 1 МБ, и пользователь может сбросить ее в GUC diskquota_max_active_tables.
Поскольку общая память предварительно выделена, пользователю необходимо перезапустить базу данных при изменении значения этой конфигурации. Если общая память карты отклонения заполнена, можно загрузить данные в некоторые схемы или роли, для которых достигнут предел квоты. Если общая память активной таблицы заполнена, рабочий процесс diskquota может не обнаружить соответствующее изменение использования диска вовремя.
Как уже было отмечено выше, Diskquota реализует два типа перехватчиков принудительного применения ограничений: до выполнения SQL-запроса и во время него. Перехватчик до запроса реализуется в ExecutorCheckPerms_hook в функции ExecCheckRTPerms(). Перехватчик во время выполнения запроса реализуется в DispatcherCheckPerms_hook в функции checkDispatchResult(). Для запросов, загружающих огромное количество данных, диспетчер опрашивает соединение с тайм-аутом опроса. Хук будет вызываться при каждом таймауте опроса с параметром waitMode == DISPATCH_WAIT_NONE. Пока применение квот во время выполнения запроса поддерживается только асинхронной утилитой работы с дисковыми структурами Diskpatcher.
Предел квоты схемы или роли хранится в таблице quota_config схемы данных diskquota в БД Greenplum. Таким образом, каждая база данных хранит и управляет своей собственной конфигурацией дисковых квот. Хотя роль является объектом базы данных на уровне кластера Greenplum, дисковую квоту роли зависит от базы данных. Это означает, что роль может иметь разные ограничения квоты в разных базах данных, позволяя использовать ресурсы диска изолировано.
Чтобы использовать Diskquota в Greenplum, надо установить это расширение и включить его в БД с помощью команды
create extension diskquota;
Для установки квоты на схему данных используется команда diskquota.set_schema_quota. Например, следующая команда устанавливает квоту на использование дискового пространства для схемы с именем s1 размером в 1 MB. Это означает, что общий размер всех таблиц и других объектов в схеме s1 не должен превышать 1 мегабайт.
select diskquota.set_schema_quota('s1', '1 MB');
Определить порядок схем, в которых сервер баз данных будет искать объекты (таблицы, функции и т.д.), если для них не указано явное имя схемы, позволяет команда set search_path. Например,
set search_path to s1;
означает, что при выполнении запросов без указания схемы сервер будет сначала искать объекты в схеме s1.
Посмотреть ограничение квоты схемы данных и ее текущее использование позволяет простой запрос на выборку:
select * from diskquota.show_fast_schema_quota_view;
Если администратор Greenplum создал расширение diskquota в базе данных, соединение с ней устанавливается из рабочего процесса diskquota. Поэтому для удаления базы данных администратору необходимо сперва удалить расширение diskquota в ней, и только потом приступать к удалению самой БД.
Diskquota также поддерживает ограничение использования диска для временной таблицы. Что касается роли, то есть владельца временной таблицы, diskquota рассматривает ее как обычную таблицу, суммируя ее размер с квотой владельца. А для схемы данных ее временная таблица расположена в пространстве имен pg_temp_backend_id, поэтому размер временной таблицы не суммируется с квотой текущей схемы. Если в определенной схеме нет таблицы или ни один владелец таблицы не имеет определенной роли, эти схемы или роли не будут перечислены в show_fast_schema_quota_view и show_fast_role_quota_view.
Поскольку Greenplum не поддерживает уровень изоляции READ UNCOMMITTED, о чем мы писали здесь, невозможно обнаружить новую созданную таблицу внутри незафиксированной транзакции. Поэтому принудительное применение вновь созданной таблицы не будет работать. После фиксации транзакции рабочий процесс diskquota может обнаружить вновь созданную таблицу и соответствующим образом применить ее в последующих запросах.
Обойти это ограничение позволяет расчет дополнительного размера незафиксированных данных для схемы и роли в рабочем процессе. Поскольку pg_table_size удерживает блокировку совместного доступа AccessShareLock, метод получения статистики по таблице stat() вызывается напрямую.
Узнайте больше про администрирование и эксплуатацию Greenplum для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
