Версия сайта для слабовидящих
Как расширить возможности MPP-СУБД Greenplum, используя фоновые рабочие процессы и почему это небезопасно. А также рассмотрим, что такое API Greenplum Partner Connector и как это использовать.
Фоновые рабочие процессы
Обычно фоновыми процессами в СУБД называются системные задания, которые запускаются при запуске базы данных и выполняют различные служебные задачи. К таким рутинным сервисным задачам относятся те, которые нужны для поддержания базы данных в рабочем состоянии, например, очистка после прерываний, запись блоков на диски и пр. Однако, в Greenplum, как и в PostgreSQL, фоновые рабочие процессы позволяют запускать пользовательский код, чтобы расширить возможности базы данных.
Такие процессы запускаются, останавливаются и контролируются PostgreSQL, имея время жизни, тесно связанное со статусом сервера. Такие процессы могут подключаться к области общей памяти базы данных Greenplum и к внутренним базам данных. Также они могут выполнять несколько транзакций последовательно, как обычный серверный процесс, подключенный к клиенту. Фоновые рабочие процессы могут использовать библиотеку libpq, которая является интерфейсом PostgreSQL Pro для программирования приложений на языке C и содержит соответствующий набор функций. Таким образом, клиентские программы в фоновых рабочих процессах могут подключаться к серверу, передавать ему запросы и принимать результаты этих запросов.
Однако, при использовании фоновых рабочих процессов есть высокие риски нарушения надежности и безопасности, поскольку они исполняют программы, написанные на низкоуровневом языке C и имеют неограниченный доступ к данным. Поэтому при включении модуля с фоновыми рабочими процессами, администратор кластера Greenplum должен тщательно убедиться в допустимости их запуска. Одним из вариантов смягчения таких рисков является использование Docker-контейнеров, о чем мы писали здесь.
Фоновые рабочие процессы могут быть инициализированы во время запуска базы данных Greenplum путем включения имени модуля в параметр конфигурации сервера shared_preload_libraries. Модуль, желающий запустить фоновый рабочий процесс, может зарегистрировать его, вызвав метод RegisterBackgroundWorker(BackgroundWorker *worker) из своей функции _PG_init(). Фоновые рабочие также могут быть запущены после того, как система запущена и работает, вызвав функцию RegisterDynamicBackgroundWorker(BackgroundWorker *worker, BackgroundWorkerHandle **handle). В отличие от метода RegisterBackgroundWorker(), который можно вызывать только из postmaster, главного управляющего процесса, метод RegisterDynamicBackgroundWorker()необходимо вызывать из обычного бэкэнда, т.е. обслуживающего или другого рабочего процесса.
Когда фоновый рабочий процесс регистрируется с помощью функции RegisterDynamicBackgroundWorker(), серверная часть, выполняющая регистрацию, может получить информацию о его статусе. Для этого надо должны передать адрес BackgroundWorkerHandle * в качестве второго аргумента функции RegisterDynamicBackgroundWorker(). Если рабочий процесс успешно зарегистрирован, по этому адресу будет записан указатель на скрытую структуру, который можно затем передать функции GetBackgroundWorkerPid(BackgroundWorkerHandle *, pid_t *) или TerminateBackgroundWorker(BackgroundWorkerHandle *). С помощью функции GetBackgroundWorkerPid() можно получить состояние рабочего процесса:
- BGWH_NOT_YET_STARTED означает, что рабочий процесс ещё не запущен управляющим;
- BGWH_STOPPED означает, что процесс запущен, но сейчас не работает;
- BGWH_STARTED показывает работающий в данный момент процесс.
Рабочие процессы могут передавать асинхронные уведомления, вызывая либо команду NOTIFY через серверный интерфейс программирования (SPI, Server Programming Interface), либо функцию Async_Notify() напрямую. Такие уведомления будут отправлены в момент фиксации транзакции. Фоновые рабочие процессы не должны регистрироваться командой LISTEN для получения асинхронных уведомлений из-за отсутствия инфраструктуры для получения таких уведомлений рабочим процессом. Максимальное количество зарегистрированных фоновых рабочих процессов ограничено параметром конфигурации сервера max_worker_processes.
API Greenplum Partner Connector
Помимо фоновых рабочих процессов, серверный интерфейс программирования Greenplum включает JDBC и ODBC-драйверы прямого доступа к данным, а также API Greenplum Partner Connector (GPPC API), который позволяет писать переносимые UDF-функции на языках программирования C и C++. Хотя Greenplum Partner Connector поддерживается для версии 4.3.5.0 и выше, функции, разработанные с помощью API GPPC, не требуют перекомпиляции или модификации для работы с более старыми или новыми версиями СУБД. Функции, записываемые в API GPPC, можно вызывать с помощью SQL-команд, включая управление аргументами функций простых и составных типов данных и возвращаемыми значениями, управления памятью и обработки данных. UDF-функции C/C++, разработанные с помощью API GPPC, компилируются в общую библиотеку. Эти функции становятся доступны пользователям базы данных Greenplum после установки общей библиотеки в кластере и регистрации GPPC-функций как пользовательских функций SQL.
При разработке с помощью API GPPC разработчик должен писать код на языке C или C++в системе с той же аппаратной и программной архитектурой, что и хосты Greenplum. Код UDF-функции должен использовать API GPPC, типы данных и макросы, но не использовать API функций языка C PostgreSQL, файлы заголовков, функции или макросы. Код функции #include не должен быть заголовочным postgres.hфайлом или использовать PG_MODULE_MAGIC. Для выделения и освобождения памяти необходимо использовать только встроенные в GPPC функции памяти. Имена символов в объектных файлах не должны конфликтовать друг с другом или с символами, определенными на сервере базы данных Greenplum.
Регистрация функции GPPC включает сопоставление сигнатуры функции GPPC с UDF-функцией SQL, определяемое с помощью команды CREATE FUNCTION .. AS, указывающей имя общей библиотеки GPPC. Можно использовать одно и то же имя для функций GPPC и SQL. Динамический загрузчик базы данных Greenplum загружает файл общей библиотеки GPPC в память при первом вызове пользователем UDF-функции, связанной с этой общей библиотекой.
Узнайте больше подробностей про администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
