Как получить записи из другой базы данных, используя postgres_fdw в postgresql - PullRequest
Новая
       45

Как получить записи из другой базы данных, используя postgres_fdw в postgresql

1 голос
/ 08 июля 2019

В моем случае я подключился к другой базе данных GP, чтобы импортировать данные в мои таблицы PostgreSQL и записывать планировщики Java для ежедневного обновления.Но когда я пытаюсь получать записи каждый день, используя функции SQL, это выдает мне ошибку Greenplum Database does not support REPEATABLE READ transactions.Итак, может кто-нибудь предложить мне, как я могу загружать данные часто от GP до postgres без хлопот изоляции.

Я знал, чтобы выполнить, чтобы обновить таблицы на 

START TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Но, я 'Я не могу использовать то же самое в функциях из-за блоков транзакций.

1 Ответ

0 голосов
/ 17 июля 2019

В отличие от базы данных Oracle, которая использует блокировки и защелки для управления параллелизмом, база данных Greenplum (как и PostgreSQL) поддерживает согласованность данных, используя многоверсионную модель (Multiversion Concurrency Control, MVCC). Это означает, что при запросе базы данных каждая транзакция видит моментальный снимок данных, который защищает транзакцию от просмотра противоречивых данных, которые могут быть вызваны (другими) одновременными обновлениями в одних и тех же строках данных. Это обеспечивает изоляцию транзакции для каждого сеанса базы данных. Короче говоря, читатели не блокируют писателей, а писатели не блокируют читателей. Каждая транзакция видит снимок базы данных, а не блокирует таблицы. Уровни изоляции транзакции

Стандарт SQL определяет четыре уровня изоляции транзакции. В базе данных Greenplum вы можете запросить любой из четырех стандартных уровней изоляции транзакций. Но внутренне существует только два разных уровня изоляции - чтение зафиксировано и сериализуемо:

  1. read commit - Когда транзакция выполняется на этом уровне изоляции, запрос SELECT видит только данные, зафиксированные до начала запроса. Он никогда не видит ни незафиксированные данные, ни изменения, зафиксированные во время выполнения запроса параллельными транзакциями. Однако SELECT видит результаты предыдущих обновлений, выполненных в его собственной транзакции, даже если они еще не зафиксированы. По сути, запрос SELECT видит моментальный снимок базы данных на момент начала выполнения запроса. Обратите внимание, что две последовательные команды SELECT могут видеть разные данные, даже если они находятся в одной транзакции, если другие транзакции фиксируют изменения во время выполнения первого SELECT. Команды UPDATE и DELETE ведут себя так же, как и SELECT, с точки зрения поиска целевых строк. Они найдут только целевые строки, которые были зафиксированы на момент запуска команды. Однако такая целевая строка, возможно, уже была обновлена ​​(или удалена или заблокирована) другой параллельной транзакцией к тому времени, когда она найдена. Частичная изоляция транзакции, обеспечиваемая режимом фиксации чтения, подходит для многих приложений, и этот режим быстр и прост в использовании. Однако для приложений, которые выполняют сложные запросы и обновления, может потребоваться гарантировать более строго согласованное представление базы данных, чем обеспечивает режим фиксации чтения.

  2. serializable - это самая строгая изоляция транзакции. Этот уровень эмулирует выполнение последовательных транзакций, как если бы транзакции выполнялись одна за другой, последовательно, а не одновременно. Приложения, использующие этот уровень, должны быть готовы повторить транзакции из-за ошибок сериализации. Когда транзакция находится на уровне сериализации, запрос SELECT видит только данные, зафиксированные до начала транзакции. Он никогда не видит ни незафиксированные данные, ни изменения, зафиксированные во время выполнения транзакций параллельными транзакциями. Однако SELECT видит результаты предыдущих обновлений, выполненных в его собственной транзакции, даже если они еще не зафиксированы. Последовательные команды SELECT в одной транзакции всегда видят одни и те же данные. Команды UPDATE и DELETE ведут себя так же, как и SELECT, с точки зрения поиска целевых строк. Они найдут только целевые строки, которые были зафиксированы на момент начала транзакции. Однако такая целевая строка, возможно, уже была обновлена ​​(или удалена или заблокирована) другой параллельной транзакцией к тому времени, когда она найдена. В этом случае сериализуемая транзакция будет ожидать, когда первая обновляющая транзакция будет зафиксирована или откатана (если она все еще выполняется). Если первый модуль обновления откатывается назад, то его эффекты сводятся на нет, и сериализуемая транзакция может продолжить обновление первоначально найденной строки. Но если первый модуль обновления фиксирует (и фактически обновил или удалил строку, а не просто заблокировал ее), то сериализуемая транзакция будет откатана.

  3. чтение не принято - обрабатывается так же, как и чтение, зафиксированное в базе данных Greenplum.

  4. повторяемое чтение - рассматривается как сериализуемый в базе данных Greenplum.

Уровень изоляции транзакции по умолчанию в базе данных Greenplum считывается зафиксированным. Чтобы изменить уровень изоляции для транзакции, вы можете объявить уровень изоляции, когда вы НАЧИНАЕТЕ транзакцию, или использовать команду SET TRANSACTION после запуска транзакции.

введите описание ссылки здесь

...