Планирование запроса PostgreSQL, работающего с greenplum DB
-
21-12-2019 - |
Вопрос
У меня есть таблица, которая должна заполняться каждый час данными, извлекаемыми из Greenplum.Эта таблица хранится на сервере Greenplum.
Итак, что я хочу знать, так это то, какой метод (скрипт python, планировщик Windows или что-нибудь еще) подойдет для моих данных (которые, я предполагаю, могут достигать 60 ГБ или более), которые следует использовать для планирования запроса (написанного на PostgreSQL), который будет выполняться каждый час.
Может кто-нибудь прикрепить пример кода для того же самого?
Решение
Вам захочется провести параллель COPY
диапазонов данных из Greenplum в PostgreSQL.Убедитесь, что PostgreSQL настроен на быструю загрузку данных.Если возможно, используйте UNLOGGED
таблица;в противном случае используйте wal_level = 'minimal'
по крайней мере.
Количество параллельных рабочих элементов больше всего зависит от подсистемы ввода-вывода сервера PostgreSQL.Протестируйте и посмотрите.
Я бы рекомендовал использовать Python с psycopg2 и copy_expert
функция наведения курсора.Видишь документы.Используйте многопроцессорную обработку с каналом для совместного использования файлоподобного объекта между reader и writer worker, при этом reader подключен к greenplum, а writer - к PostgreSQL.
Таким образом, эффективно каждый работник делает что-то немного похожее на следующий псевдокод оболочки:
psql -h greenplum-box \
-c "COPY (SELECT * FROM mytable WHERE id BETWEEN 1 AND 10000) TO stdin" \
| \
psql -h postgres-box \
-c "COPY myttable FROM stdin";
(но вы соединяете их с помощью pyscopg2, copy_export
, многопроцессорность и канал).
После этого выполните всю обычную работу по быстрой загрузке, например, создайте индексы.Видишь как ускорить производительность вставки в PostgreSQL.
Если у вас есть свободное место на диске, создайте таблицу типа dataload_temp
, заполните его, затем в одной транзакции удалите старый и переименуйте новый в имя старого.Таким образом, сбои минимальны.
В качестве альтернативы взгляните на pg_bulkload
для автономной (но не потоковой) массовой загрузки данных.