Расширение pgpro_duckdb может функционировать в рамках любого экземпляра Postgres Pro Enterprise и выполнять аналитические запросы, используя различные источники данных, включая таблицы Postgres Pro, а также локальные, сетевые и S3-хранилища. В этом разделе приведены общие рекомендации по развёртыванию встроенной аналитической платформы и объясняется, как распределить OLAP-нагрузку между серверами Postgres Pro.
Во всех сценариях развёртывания большую часть OLAP-данных необходимо хранить как Parquet-файлы в локальном, сетевом или S3-хранилище. Запросы к таблицам куч Postgres Pro используются только для изначального экспортирования OLAP-данных в Parquet-файлы. Таблицы куч также можно использовать, чтобы перенести изменения из таблиц, которые ещё не были экспортированы, и после этого объединить их с OLAP-данными из Parquet-файлов. Это позволяет выполнять вычисления на основании последнего состояния таблицы.
При выборе сценария развёртывания учитывайте следующие факторы:
Влияние аналитических запросов на OLTP-нагрузку:
Аналитические запросы выполняются на ведущем сервере.
Аналитические запросы выполняются на синхронном резервном сервере.
Аналитические запросы выполняются на асинхронном резервном сервере.
Аналитические запросы выполняются на автономном сервере Postgres Pro.
За более подробной информацией обратитесь к разделу Влияние аналитических запросов на OLTP-нагрузку.
Требования к безопасности данных и распределению OLAP-нагрузки:
Несколько групп аналитиков используют один сервер Postgres Pro.
Каждая группа аналитиков использует выделенный сервер Postgres Pro.
За более подробной информацией обратитесь к разделу Требования к безопасности данных и распределению OLAP-нагрузки.
Доступные сетевые и вычислительные ресурсы, а также ресурсы хранения:
OLAP-данные хранятся локально и доступны одному экземпляру Postgres Pro Enterprise.
OLAP-данные хранятся в сетевом хранилище и доступны нескольким экземплярам Postgres Pro Enterprise.
OLAP-данные хранятся в S3-хранилище и доступны нескольким экземплярам Postgres Pro Enterprise.
За более подробной информацией обратитесь к разделу Доступные сетевые и вычислительные ресурсы, а также ресурсы хранения.
В этом разделе описан сценарий развёртывания с ведущим сервером, синхронным резервным сервером и асинхронным резервным сервером. OLTP-нагрузка обрабатывается ведущим сервером. В сценарии не учитывается разница между физической и логической репликацией.
Риск влияния аналитических запросов на OLTP-нагрузку зависит от того, где они выполняются:
Ведущий сервер: высокий риск, так как нагрузки OLTP и OLAP конкурируют за вычислительные ресурсы в одном кластере Postgres Pro. В этом случае неправильный аналитический запрос может помешать обработке OLTP-нагрузки.
Синхронный резервный сервер: риск снижен, но не отсутствует, так как неправильный аналитический запрос всё ещё может привести к сбою синхронного резервного сервера и при определённой серверной конфигурации оказать влияние на ведущий сервер.
Асинхронный резервный сервер: риск минимален. В этом случае даже если неправильный аналитический запрос приводит к сбою асинхронного резервного сервера, ведущий сервер продолжает обрабатывать OLTP-нагрузку.
Рекомендации по обработке OLAP-нагрузки:
Используйте ведущий сервер и синхронные резервные серверы для обработки стабильной и проверенной OLAP-нагрузки в соответствии с доступными вычислительными ресурсами. При этом избегайте предоставления прямого доступа группам аналитиков, а также выполнения незапланированных (ad-hoc) аналитических запросов, непроверенных аналитических запросов, а также аналитических запросов с непредсказуемым использованием ресурсов.
Используйте асинхронные резервные серверы для обработки и тестирования большей части OLAP-нагрузки перед обработкой на ведущем сервере или синхронном резервном сервере. Для интерактивного анализа и выполнения незапланированных аналитических запросов можно использовать каскадные резервные серверы, которые не оказывают влияния на ведущий сервер.
Используйте автономные серверы Postgres Pro, работающие с общим сетевым или S3-хранилищем, для создания, тестирования и выполнения незапланированных аналитических запросов с непредсказуемым временем выполнения.
В настоящее время расширение pgpro_duckdb использует базовую модель доступа, которая управляется ролью, указанной в параметре конфигурации duckdb.postgres_role. Члены этой роли имеют полный доступ к функциям pgpro_duckdb. Чтобы разграничить доступ к данным между несколькими группами аналитиков, используйте внешние инструменты. Например, вы можете настроить доступ на уровне приложения, которое проверяет права доступа конкретного пользователя, после чего создаёт и отправляет аналитический запрос расширению pgpro_duckdb.
Чтобы позволить всем аналитикам выполнять аналитические запросы и при этом назначить им разные права доступа, используйте выделенные серверы Postgres Pro для каждой группы аналитиков. В этом случае права доступа к необходимым данным, например данным S3-хранилища, можно настроить на каждом сервере с необходимой степенью детализации.
При развёртывании встроенной аналитической платформы распределяйте OLAP-нагрузку между узлами сети таким образом, чтобы получившаяся в результате топология соответствовала требованиям к производительности.
Рекомендации по построению топологии:
Определите основные OLAP-процессы и приложения, а также ограничения по времени выполнения стандартных операций.
Подготовьте диаграмму перемещения данных между хранилищами.
Убедитесь, что сеть и хранилища обеспечивают достаточную пропускную способность для выполнения стандартных операций с рекомендуемым запасом в 30%.
Выберите узлы сети, которые будут использоваться для обработки большей части OLAP-нагрузки. Убедитесь, что эти узлы имеют достаточно вычислительных ресурсов для выполнения стандартных операций в рамках требуемых ограничений по времени с рекомендуемым запасом в 30%.
Убедитесь в отсутствии узких мест. При их наличии рассмотрите выделение дополнительных вычислительных ресурсов или изменение топологии.