Стратегии загрузки связанных данных из РСУБД
Во многих случаях запрашивая данные из реляционной БД, мы хотим получать их не из одной таблицы, а из нескольких.
Предположим, у нас есть две связанные таблицы A и B, мы делаем запрос к таблице A на получение данных и хотим получить соответствующие записи из таблицы B. Чтобы добиться этого, у нас есть несколько способов. Какой именно способ использовать, зависит от количества данных и вида отношений.
1. Ленивая подгрузка (проблема N+1). Получим записи из таблицы A, мы проходимся по ним циклом и для каждой из них делаем отдельный запрос в таблицу B. Это очень неэффективная стратегия, ведь к 1 запросу к таблице A мы добавляем ещё N запросов в таблицу B. Однако эта стратегия будет фактически использована, если при использовании ORM вы не загрузили сразу явным образом связанные данные. Однако она в какой-то степени может упростить работу, если мы по ходу обработки выясняем какие данные нам нужны. Скорее всего, её стоит избегать.
2. Joined load (select_related в Django). Данные из обеих таблиц получаются за один запрос с помощью join и получения колонок из обеих таблиц. Если для каждой записи таблицы A может соответствовать много записей таблицы B (отношение один-ко-многим), то в результате такого запроса каждый элемент из таблицы А будет получен много раз. Во-первых, эти дубли придется обработать на стороне вашей программы (ORM может предоставлять инструменты), а во-вторых это приводит к увеличению размера выборки. Если же у нас одной записи в таблице А может соответствовать только одна запись в таблице B, причем они могут повторяться (отношение многие-к-одному), то такой запрос может привести к повторному получению данных в таблице B, что снова увеличивает размер выборки. Особенно будьте осторожны, когда записи в одной из таблиц содержат Blob.
3. Select in load (prefetch_related в Django). После получения данных из таблицы A генерируется второй запрос на получение записей из таблицы B с передачей ключей для поиска записей. То есть, запрос вида select * from B where someid in (...). В этом случае мы не грузим дубли данных, однако отправка второго запроса может оказаться дольше чем загрузка за один прием. Также стоит быть аккуратным при реализации этой стратегии вручную и передачей большого количества id: в некоторых СУБД потребуется разделять этот список на части и делать больше одного дополнительного запроса.
4. Subquery load. Также для получения записей из связанной таблицы генерирует второй запрос. Похожа на select-in load, но вместо прямой передачи списка id, дублируется первый запрос как подзапрос для их получения. Может пригодиться в каких-то особенных случаях, когда повторное получение id в базе дешевле, чем пересылка полного списка.
5. Array/Json agg (как правило, не реализована в ORM). Похоже на joined load, но вместо увеличения числа колонок и строк, с помощью агрегирующих функций мы получаем массивы/json-поля с данными связанных таблиц. Так же может привести к дублированию данных в случае отношения многие-к-одному. Требует поддержку json/array полей от СУБД. Иногда используется для формирования в БД структуры, пригодной для отправки дальше, что является антипаттерном.
Дополнительные материалы:
* https://docs.sqlalchemy.org/en/20/orm/queryguide/relationships.html
* https://medium.com/@clementgrimault/optimize-the-way-you-fetch-relationships-with-postgresql-7711fe6457d2
* https://docs.djangoproject.com/en/4.1/ref/models/querysets/#select-related
* https://hygraph.com/blog/graphql-n-1-problem
Во многих случаях запрашивая данные из реляционной БД, мы хотим получать их не из одной таблицы, а из нескольких.
Предположим, у нас есть две связанные таблицы A и B, мы делаем запрос к таблице A на получение данных и хотим получить соответствующие записи из таблицы B. Чтобы добиться этого, у нас есть несколько способов. Какой именно способ использовать, зависит от количества данных и вида отношений.
1. Ленивая подгрузка (проблема N+1). Получим записи из таблицы A, мы проходимся по ним циклом и для каждой из них делаем отдельный запрос в таблицу B. Это очень неэффективная стратегия, ведь к 1 запросу к таблице A мы добавляем ещё N запросов в таблицу B. Однако эта стратегия будет фактически использована, если при использовании ORM вы не загрузили сразу явным образом связанные данные. Однако она в какой-то степени может упростить работу, если мы по ходу обработки выясняем какие данные нам нужны. Скорее всего, её стоит избегать.
2. Joined load (select_related в Django). Данные из обеих таблиц получаются за один запрос с помощью join и получения колонок из обеих таблиц. Если для каждой записи таблицы A может соответствовать много записей таблицы B (отношение один-ко-многим), то в результате такого запроса каждый элемент из таблицы А будет получен много раз. Во-первых, эти дубли придется обработать на стороне вашей программы (ORM может предоставлять инструменты), а во-вторых это приводит к увеличению размера выборки. Если же у нас одной записи в таблице А может соответствовать только одна запись в таблице B, причем они могут повторяться (отношение многие-к-одному), то такой запрос может привести к повторному получению данных в таблице B, что снова увеличивает размер выборки. Особенно будьте осторожны, когда записи в одной из таблиц содержат Blob.
3. Select in load (prefetch_related в Django). После получения данных из таблицы A генерируется второй запрос на получение записей из таблицы B с передачей ключей для поиска записей. То есть, запрос вида select * from B where someid in (...). В этом случае мы не грузим дубли данных, однако отправка второго запроса может оказаться дольше чем загрузка за один прием. Также стоит быть аккуратным при реализации этой стратегии вручную и передачей большого количества id: в некоторых СУБД потребуется разделять этот список на части и делать больше одного дополнительного запроса.
4. Subquery load. Также для получения записей из связанной таблицы генерирует второй запрос. Похожа на select-in load, но вместо прямой передачи списка id, дублируется первый запрос как подзапрос для их получения. Может пригодиться в каких-то особенных случаях, когда повторное получение id в базе дешевле, чем пересылка полного списка.
5. Array/Json agg (как правило, не реализована в ORM). Похоже на joined load, но вместо увеличения числа колонок и строк, с помощью агрегирующих функций мы получаем массивы/json-поля с данными связанных таблиц. Так же может привести к дублированию данных в случае отношения многие-к-одному. Требует поддержку json/array полей от СУБД. Иногда используется для формирования в БД структуры, пригодной для отправки дальше, что является антипаттерном.
Дополнительные материалы:
* https://docs.sqlalchemy.org/en/20/orm/queryguide/relationships.html
* https://medium.com/@clementgrimault/optimize-the-way-you-fetch-relationships-with-postgresql-7711fe6457d2
* https://docs.djangoproject.com/en/4.1/ref/models/querysets/#select-related
* https://hygraph.com/blog/graphql-n-1-problem