Оптимизация запросов PostgreSQL

Антипаттерн "слишком много слишком мелких запросов" наблюдается уже несколько десятилетий. Примерно 20 лет назад одному из авторов пришлось проанализировать приложение, которому требовалось 5-7 минут для создания HTML-формы, содержащей около 100 полей. Код приложения был идеально структурирован, небольшие методы сопровождались комментариями и были отлично отформатированы. Однако трассировка базы данных показала, что для создания этой формы приложение выдавало около 16 000 запросов - больше, чем символов в самой форме. Дальнейший анализ показал, что несколько тысяч запросов исходили от метода GetObjectIdByName. За каждым из этих вызовов следовал запрос от метода GetNameByObjectId, который вызывался из другой части приложения, вероятно написанной другим разработчиком. Значения name были уникальными; следовательно, второй вызов всегда возвращал параметр первого. Один запрос, извлекающий все данные, необходимые для построения формы, вернул результат менее чем за 200 миллисекунд.

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

Несовершенство доминирующих практик разработки хорошо известно профессионалам. Почему же они распространены?

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

Добро пожаловать в мир ORM

Желание изолировать язык базы данных (например, SQL) от разработчиков приложений и таким образом упростить им задачу (а также уменьшить потребности в навыках работы с базами данных) приводит к появлению программного обеспечения, преобразующего функции базы данных в объектные методы.

Стефан Фаро описывает ситуацию, называемую "проблемой списка покупок".

Предположим, у вас есть список покупок для продуктового магазина. В реальной жизни вы садитесь в машину, едете в магазин, покупаете все продукты из своего списка, кладёте их в багажник, едете домой, заносите их в дом и кладёте в холодильник. А теперь представьте, что вместо этого вы едете в магазин, заходите и берёте только первый продукт из своего списка, едете домой, кладёте его в холодильник и снова отправляетесь в магазин! И продолжаете повторять ту же самую последовательность действий для каждого пункта из вашего списка.

Звучит нелепо? Да, но именно этим и занимаются многие приложения, взаимодействуя с базами данных.

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

Некоторые из этих предложений действительно могут улучшить ситуацию. Но даже если бы можно было сократить время покупок на 30%, это улучшение нельзя сравнивать с успехом, которого можно достичь с помощью одного простого улучшения процесса: купить все продукты за одну поездку.

Как перенести проблему со списком покупок на поведение приложения? Большинство проблем с производительностью вызваны слишком большим количеством слишком мелких запросов.