параллельные запросы к отдельным таблицам (одной и той же базе данных) в PostgreSQL

Question

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

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

Пожалуйста, помогите!

Answer 1

Хорошо, давайте возьмем самый простой случай.

На диске хранятся две большие таблицы.

Вы выполняете два запроса к этим двум отдельным таблицам.

Но, хотя они представляют собой две отдельные логические таблицы, представленные БД, на самом деле они используют один и тот же диск.

Таким образом, поскольку каждый отдельный процесс postgres читает каждую таблицу, головка диска катается и танцует взад и вперед, пытаясь обработать данные, и, таким образом, каждый процесс борется друг с другом на диске, едином общем ресурсе.

Это похоже на банк с двумя окнами кассира и двумя линиями, но только один кассир сзади выполняет всю работу.

Это не учитывает других факторов, которые могут повлиять на замедление или ускорение вашего запроса. Просто базовый пример одного случая, который может произойти.

Answer 2

Здесь нужно учитывать несколько вещей.

Во-первых, существует огромная разница между последовательным и случайным дисковым вводом / выводом. При случайном вводе / выводе с диска операционная система не помогает с предварительной выборкой, а с последовательным доступом. Таким образом, при последовательном чтении операционная система будет загружать гораздо больше данных, чем мы первоначально читали, и мы доберемся до нее, пока операционная система извлекает данные из другой таблицы для другого запроса. При произвольном доступе вы получаете описанный эффект, но при произвольном доступе вы все равно ждете перемещения головок дисков без проблем с параллелизмом, потому что вы выполняете случайное чтение.

Второе, что нужно иметь в виду, это то, что разные планы запросов имеют разные профили ввода / вывода. Если мы вытаскиваем, скажем, 10% страниц таблицы с диска, и у нас есть индекс, мы можем выбрать последовательную загрузку индекса, а затем пройти в логическом порядке, чтобы найти наши записи (пока диск работает для другого запроса), а затем принять накладные расходы, чтобы просто получить несколько страниц произвольного доступа с диска. Это, конечно, связано с ожиданием движения голов, и могут возникнуть или не возникнуть проблемы с параллелизмом, которые могут усугубить ситуацию. Таким образом, вполне возможно, что запрос 1 выполнит сканирование индекса, а запрос 2 выполнит последовательное сканирование и извлечет большую часть необходимых данных, пока запрос 1 обрабатывает индекс. Тогда, может быть, вы получите некоторые из проблем, которые описывает Уилл, но, вероятно, не так много.

Последняя вещь, и это действительно важно, это кэширование. Базы данных, как правило, кэшируют много записей, потому что это полностью исключает дисковый ввод-вывод. Так что в этом случае у вас может быть что-то совсем другое Запрос 1 может работать из памяти или в основном из памяти, тогда как запрос 2 может попасть на диск. В общем, если у вас достаточно памяти, чтобы большая часть интересующих вас данных удобно помещалась в памяти, и оставалось место для других частей программного обеспечения, таких как ядро, то ни одна из возможных проблем с дисковым вводом-выводом не будет реальной проблемой и единственный раз, когда вы, как правило, попадете на диск, будет зафиксировать сегменты WAL.

Так что ответ "это зависит". Это зависит от вашей системы. Это зависит от вашей оперативной памяти и размера данных. Это зависит от ваших жестких дисков и операционной системы. Это зависит от конкретных запросов. Это зависит от других моделей использования. Это зависит.