Введение

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

Это вторая статья, связанная с пониманием, поиском и устранением проблемы N+1. Первая статья была про стратегии извлечения данных. Эта статья будет про Hibernate proxy. Понимание концепций стратегии извлечения данных и Hibernate прокси, это ключи к пониманию причин, приводящих к N+1. Подробней про N+1, будет рассказано в следующих статьях.

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

N+1 уже набила всем, N+одну оскомину, но до сих пор не теряет актуальность. Со своей стороны, могу сказать, что исключение из кода дополнительных запросов в базу, может значительно ускорить работу вашего приложения.

Разные fetching strategies (стратегии извлечения), могут оказывать сильное влияние на скорость работы приложения, делать его быстрым или наоборот замедлять.

Hibernate определяет четыре стратегии выборки ассоциаций:

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

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

До того, как Hibernate и JPA стали популярны, на разработку каждого запроса тратилось много усилий, потому что вам приходилось явно джойнить (join), таблицы и столбцы, которые вас интересовали. И когда этого было недостаточно, администратор базы данных оптимизировал медленно выполняющиеся запросы.

Во времена JPA запросы JPQL или HQL извлекают сущности вместе с некоторыми связанными с ними отношениями. Это упрощает разработку, поскольку освобождает нас от необходимости вручную выбирать все интересующие нас поля таблицы, кроме того, джойны или другие дополнительные запросы могут генерироваться автоматически. Однако это палка о двух концах. С одной стороны, вы можете реализовывать функционал быстрее, с другой, если ваши автоматически генерируемые SQL-запросы будут неэффективными, общая производительность вашего приложения может значительно снизиться.

На основе статьи Arpendu Kumar Garai "Demystifying Transactions and Exceptions with Spring", от 31 января 2023 года.

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

Транзакция базы данных (СУБД) — это серия из одной или нескольких операций, выполняемых как единая атомарная единица работы. Это означает, что либо все операции в транзакции завершаются успешно, либо ни одна из них не применяется к базе данных. Транзакция может состоять из одной команды, группы команд или любых других действий с базой данных. Любая СУБД, поддерживающая транзакции, должна гарантировать качество ACID для сохранения целостности данных.

ACID (от англ. atomicity, consistency, isolation, durability) — набор требований к транзакционной системе, обеспечивающий наиболее надёжную и предсказуемую её работу.

Основные требования: