Разъяснение параллелизма в PostgreSQL + Rails - PullRequest
Новая
       18

Разъяснение параллелизма в PostgreSQL + Rails

1 голос
/ 07 февраля 2012

Я создаю фоновую работу, которая обновляет статистику пользователей для веб-приложения. Работа в настоящее время занимает 55-60 секунд, и я обеспокоен тем, что произойдет, если пользователь попытается загрузить свою страницу статистики в то же время, когда выполняется задание.

Из того, что я читал о PostgreSQL и параллелизме, если два клиента пытаются получить доступ к одной и той же строке (одно обновление и одно чтение), и я не запускаю явно какие-либо транзакции, первая просто должна дождаться второй, чтобы закончить.

Так что, если я правильно понимаю, единственный удар по производительности, который я могу понести, это бесконечно малый шанс того, что пользователь попытается загрузить свою страницу статистики в тот же момент, когда обновляется строка. Не похоже, чтобы вся таблица статистики была заблокирована во время 55-60 секундной работы, если только я не должен был явно настроить Postgres для этого, верно?

Это правильная интерпретация? Есть ли другие факторы, по которым я скучаю?

(я упоминаю часть Rails на случай, если она имеет какое-либо отношение к описанному выше сценарию)

(также: версия PostgreSQL - 9.0.4)

1 Ответ

2 голосов
/ 07 февраля 2012

Зависит от уровня изоляции транзакции.Если у меня есть ваше дело - вы говорите о Dirty Read, избегая задержки.И ДА, Грязное чтение невозможно, если вы используете уровень изоляции по умолчанию.Читатель будет ждать записи только тогда, когда он попытается получить ту же строку, которая обновляется.

Read Committed - уровень изоляции по умолчанию в PostgreSQL.Когда транзакция выполняется на этом уровне изоляции, запрос SELECT видит только данные, зафиксированные до начала запроса;

спецификации ISOLATION

...