Comments 10
Еще немного о entityGraph:
Сперва деталь: спринг в этом примере совсем не нужен, только шум добавляет с заметке.
По делу:
Наверное, стоит заметить, что предложенное решение скорее "да", чем "нет" для относительно небольших рекордсетов. Если зачем-то (случаи разные бывают) надо засосать 10к клиентов, у каждого из которых по пять имелов, десять контактов контактов, три телефона, четыре адреса, то перерабатывать такое "одним джоином" становится слишком плохо. Где граница? В каждом проекте/задаче своё.
Я это пишу ровно потому как около года назад вырезал подобное из кода в противоположную сторону.
Интересно, расскажите как в итоге решили доставать такую кучу данных эффективно? Сейчас в работе есть похожая задача. Интересно узнать чужой опыт)
Тут 2 основных пути, насколько мне известно:
1) денормализовать данные под тяжёлые сценарии
2) радикально ускорять чтение — здесь обычно применяют in memory storage типа redis
В моём случае это .net, но смысл тот же.
Ровно, как описал.
Можель данных весьма "вширь" (скорее куст, чем дерево). Для пересчёта состояния всей системы надо зачитать, скажем так всё из базы. Если делать так, как это (было до версии 5 entity framework), то получалась cartesian bomb. Ну и сделал вместо чтения "одном запросом" разбивку на подзапросы. (В обратную сторону от вашего примера). Делов несложно (тот же хайбернейт так делает по умолчанию), но проблема не проявилась сразу: табличка, ещё табличка, ещё табличка.
Из полезного -- я какое-то время отлавливал профайлером бд дубликаты запросов.
Если вы сделали прям в обратную сторону из 1 толстого запроса в 1+N (где N число записей, полученных первым запросом – именно это описывается в начале статьи, как решаемая проблема) мелких, то земля вам пухом...
Вообще-то решается это разбивкой на 1+K запросов, где K – количество связанных таблиц (в примере из статьи это 1 таблица емейлов, стало быть в итоге должно быть два запроса), что в JPA достигается, например, через FetchMode.SUBSELECT
Добавляйте пэджинацию, и вытягивайте данные частями. Будет несколько запросов, но хотя бы нагрузку сможете регулировать.
Тоже долгое время боролся с этой проблемой в своем проекте. В итоге пришел к подходу, в котором кол-во запросов к БД равно кол-ву типов сущностей входящих в состав загружаемых агрегатов. В вашем случае - это два запроса (один извлекает всех клиентов, другой все email связанные с полученными клиентами).
спасибо за статью, всё понятно
Проблема N+1 и как её решить с помощью EntityGraph