Postgres: оператор публикации (или вставка) асинхронная, неблокирующая обработка

Мне интересно, возможно ли, чтобы после вставки набора строк инициировать операцию, которая выполняется асинхронно, не блокируется и не требует информирования отправителя запроса - о результате.

Я работаю с большим количеством событий и могу гарантировать, что логика пост-вставки не даст сбоев — я просто хочу иметь один поток вставки в своих источниках событий, и я хочу, чтобы этот поток продолжал летать без блокировки, и не неся ответственности за какой-либо послеродовой бухгалтерский учет.

Я могу сказать вам, что у меня потенциально может быть 100 таких заданий, выполняющихся одновременно, и каждое задание может работать с 5 таблицами с где-то между 200-1000 вставок в каждой из этих таблиц.

Подсказки в правильном направлении должно быть достаточно.


postgresql events asynchronous concurrency nonblocking
person Hassan Syed    schedule 06.03.2010    source источник
comment
подскажите как вы решили эту проблему? обычно это задача, которую я бы выполнял с помощью dbms_job /schedule в oracle, но мне не хватает этой функции в pg. поэтому я наткнулся на эту очень старую тему, у меня очень похожий вопрос...   -  person christian    schedule 26.07.2011
comment
Я пишу свой собственный механизм обработки данных: D   -  person Hassan Syed    schedule 28.07.2011
comment
Спасибо за информацию. Я использую dblink_send_query прямо сейчас. Но моя проблема в том, что я должен убедиться, что соединение, запускающее триггер, должно быть открыто до завершения каждого запроса dblink.   -  person christian    schedule 11.08.2011

Ответы (3)


arrow_upward
3
arrow_downward

LISTEN/NOTIFY может быть тем, что вам нужно, есть слушатель в отдельном соединении запустите LISTEN notifyname (он может использовать неблокирующий сокет и использовать poll или как работает ваше приложение), и ваш код запустит NOTIFY notifynam e после того, как она будет обработана, но вам понадобится какой-то способ, чтобы ваш поток LISTENing узнал, какая запись была завершена, возможно, с помощью какой-либо таблицы журнала. Также стоит отметить, что libpq поддерживает асинхронный режим (который поддерживается, по крайней мере, DBD::Pg, предположительно и другими драйверами Pg).

person MkV    schedule 09.03.2010

arrow_upward
0
arrow_downward

Я добавлю как-то другой ответ.

Вы можете использовать Redis для временного хранения ваших запросов, а затем вы можете обрабатывать их пакетно каждые X секунд. (по крайней мере, вы можете вставить сразу несколько строк - обычно вы можете сделать намного больше...).

Возможно, пришло время проверить Kafka или Amazon Kinesis. Это более продвинутый сервис, который позволяет вам делать что-то похожее на то, что я упоминал выше.

person knagode    schedule 17.08.2017

arrow_upward
-1
arrow_downward

Поскольку на самом деле вы просто выполняете пакетную обработку большого количества строк, почему бы не позволить заданию cron выполнить пост-обработку строк, когда вы закончите с ними?

Просто отметьте их как необработанные (или перенаправьте их в таблицу обработки с помощью триггера) и обработайте их все сразу, когда закончите.

person Wolph    schedule 06.03.2010
comment
Данные поступают без остановки :/ - person Hassan Syed; 06.03.2010
comment
Как насчет создания cronjob, который заменяет триггер, используемый для вставки каждые n минуты. Таким образом, вы можете писать в новую таблицу каждые n минуты, и после замены триггера вы будете обрабатывать предыдущую таблицу и записывать ее в фактическую таблицу назначения. - person Wolph; 06.03.2010
comment
Это возможность, мне придется обдумать это - возможно, блокировка от клиента и запись непосредственно в целевые таблицы - лучший выбор. По крайней мере, характеристики сложности будут четко определены. - person Hassan Syed; 06.03.2010