graphql — оптимизация запросов к базе данных

[joniks]

Универсальное и простое решение это использовать библиотеку DataLoader.js от всеми любимой компании FaceBook.

[apapacy]

Дполнил тест примером с использованием библиотеки dataloader

[VolCh]

Вот, кстати, никогда не понимал безусловного стремления обходиться одним запросом к базе. Ладно когда связи 0..1:0..1, но как где-то N появляется, то в 99% случаев гораздо лучше сделать два или три запроса, чем городить многоэтажные выборки, особенно если база сама нужный граф сформировать не может.

[maxzh83]

Часто бывает, что потом количество записей возрастает и вместо двух или трех запросов, будет 20-30 или 200-300.

[Moxa]

У нас примерно 200 запросов на старте приложения, страница открывается за полторы секунды

[VolCh]

Я не о ситуации 1+N запросов, где N — число записей в результате первого запроса. Я о ситуации 1 запрос на таблицу/коллекцию, вместо объединения их на стороне базы средствами типа join

[AstarothAst]

Поддерживаю. сам перешел к подобному подходу, когда база стала не просто узким местом, но причиной реальных тормозов.
А потом вообще стал использовать in-memory хранилища, а в БД только персистинг. Отзывчивость возросла в разы. Потребление памяти, правда, тоже :D

[apapacy]

Первый профит от одного запроса данные выбираются в одной транзакции то есть будут согласованы. Второй то что запросы если мы говорим о selext n+1растут в геометрической прогрессии и при этом очередная порция запросом идёт подряд. Например мы выбрали 1000 студентов запрос относительно лёгкий. Далее мы одним мвзом отправляет 1000 запрсовичтобы получить связанную инфу и база немного начинает подвисать

[VolCh]

Первый — согласен. Второй — чуть выше написал, я не про 1+N

[azhi]

В эликсировской библиотеке absinthe есть фича «batch resolution», которая очень хорошо решает эту проблему.
Если вкратце: процесс определения значений запрашиваемых полей разбивается на этапы. Добавлен хелпер, который позволяет перенести вычисление запрашиваемого поля на следующий этап. Хелпер так же принимает функцию, которая будет проводить вычисление поля на следующем этапе, и вызывает ее с аггрегированной информацией предыдущего этапа. Т.е. по примеру из статьи: на первом этапе id всех авторов аггрегируются в массив, на втором этапе этот массив передается в функцию которая делает запрос в таблицу книг и возвращает для каждого автора список книг.
Но самому без поддержки со стороны graphql библиотеки такое организовать не получится.