O que é o problema das queries N+1? – sql banco-de-dados terminologia

Pergunta:


Sempre que trabalhamos com algum ORM, é comum cair no problema das queries N+1. É algo sobre performance, chamado até de antipattern.

Mas o que é realmente esse problema, por que ele acontece, quais suas principais causas e como, na teoria, resolvê-los?

Já ouvi também que para resolver, é só praticar o eager loading. Mas até que ponto ele é benéfico e capaz de resolver esse problema?

Autor da pergunta vnbrs

Maniero

O problema não é exclusivo de ORMs, embora muitos o acham porque é um problema comum, mas não inerente a eles. E não acreditam na capacidade das pessoas fazerem errado manualmente :).

O ORM aparece mais porque uma implementação ingênua forcará o problema ocorrer sempre.

Alias não é um problema só do ORM em si, mas de modelar objetos com dados relacionados. Ou usa um banco de dados com um modelo não relacional, que tem lá seus problemas, ou adota-se o modelo relacional na aplicação.

Ainda assim dá pra fazer alguma coisa quando mistura os dois modelos.

O problema é comum quando tem um objeto e outros N relacionados, daí o nome N + 1 que é o “pai” desses N. O problema fica claro quando a consulta pega o dado principal, vamos dizer que seja uma nota fiscal, e depois vai pegar as linhas de itens que compõe a nota. Ficar indo buscar dados individualmente no banco de dados pode se tornar um custo muito alto, ainda mais na arquitetura mal pensada que muitas pessoas fazem (alguns por necessidade).

Geralmente pelo menos o 1 + 1 é necessário, que é um falha da comunicação dos modelos relacionais (não do modelo, mas sim da forma com eles se comunicam nas implementações atuais, o que considero um erro, e em vez de consertarem isto, criaram outro modelo pior, é a história da nossa área, resolvem um problema com outro problema, mas nada que outro problema não possa resolver este também).

Alias, é por isso mesmo que alguns pessoas gostam de usar um DB NoSQL como proxy do relacional. Novamente, aumenta-se a complexidade da solução porque o ferramenta tem problemas fáceis de resolver, mas ninguém o faz.

Mas neste caso se o tamanho é grande não será um grande problema.

O problema do eager loading é que pode trazer informações que sequer vai usar. Mas depende muito do problema, tem casos que isto é raro acontecer, tem outros que mesmo que aconteça não faz nem cócegas, e em muitos casos o fato de vir mais do que precisa gera um overhead tão pequeno que uma simples consulta extra já será pior, ou seja um 1 + 2 já pode ser pior. Imagine ler uma única nota fiscal e ele trazer todas as linhas de todas notas fiscais para evitar o N + 1, desperdício total.

Este é o problema de soluções automatizadas ou de programadores que não entendem o que estão fazendo e adotam soluções de forma automática. A solução real é entender o que ocorrerá naquele caso e decidir o que é mais interessante. Mesmo manualmente é complicado atender todos os casos, depende da consulta. O ORM pode ter um mecanismo que tenta “adivinhar” qual é a melhor estratégia.

Em muitos casos traz-se muita repetição de informação pela maneira como se convencionou trabalhar com dados tabulares, geralmente usa-se o JOIN.

Na maioria das vezes trazer tudo de uma vez costuma ser mais interessante que trazer um a um.

Por falta de uma solução melhor seria algo como:

SELECT * FROM Nf
SELECT * FROM NfItem

Se tiver 1000 notas e em média exatamente 10 itens por nota, haverá 11 mil linhas ao todo, com 2 consultas, uma grande e outra enorme.

Em oposição da forma N+1:

SELECT * FROM Nf
SELECT * FROM NfItem WHERE NfNumero == Nf.Numero
SELECT * FROM NfItem WHERE NfNumero == Nf.Numero
SELECT * FROM NfItem WHERE NfNumero == Nf.Numero
SELECT * FROM NfItem WHERE NfNumero == Nf.Numero
.
.
.
Tantos quantos forem a quantidade de notas fiscais existentes.

Aqui também terá 11 mil linhas, mas com 1000 consultas pequenas e 1 grande.

O código é bem abstrato, só para ilustrar.

Experimente fritar um filete de batata de cada vez e um monte de filete de uma vez. O primeiro termina rápido individualmente, mas o todo fica trágico, o segundo demora mais, mas quando terminar está tudo pronto. Só é um problema se descobrir que tinha vendido só 3 filetes, e fritou o pacote.

Mas o que é realmente esse problema

A melhor forma de explicar este problema é com um exemplo.

Imagine que você tem uma tabela Pessoa e uma tabela Endereco. Cada pessoa tem vários endereços, consolidando uma relação de um para muitos (1-N).

E agora você deseja pegar os endereços de várias pessoas. Normalmente, vemos a seguinte consulta utilizando o ORM de sua preferência (vou usar a notação JPQL do JPA):

public List<Pessoa> consultarPessoas() {
    String jpql = "select * from Pessoa";
    return em.createQuery(jpql).getResultList();
}

E, em seguida, você itera por cada Pessoa para pegar os seus endereços:

List<Pessoa> pessoas = consultarPessoas():
for (Pessoa pessoa : pessoas) {
    List<Endereco> enderecos = pessoa.getEnderecos();
}

Imaginando um LAZY entre pessoa e endereços, teremos o seguinte SQL para cada pessoa ao chamar o método pessoa.getEnderecos():

SELECT * from Endereco where pessoa_id = :id;

, por que ele acontece,

O problema ocorre porque para pegar os endereços das pessoas você pega primeiro a pessoa e depois busca os endereços de cada. Imaginando que a consulta anterior nos retornou 5 pessoas, a quantidade de SQLs gerados será algo assim:

 SELECT * from pessoa
 SELECT * from endereco where pessoa_id = 1;
 SELECT * from endereco where pessoa_id = 2;
 SELECT * from endereco where pessoa_id = 3;
 SELECT * from endereco where pessoa_id = 4;
 SELECT * from endereco where pessoa_id = 5;

Ou seja, 1 select de pessoa com N select para endereços, o famoso N + 1 .

quais suas principais causas

Normalmente ela é causada pelo uso inadequado dos ORMs. É preciso entender o que o ORM faz por trás dos bastidores. Embora eles estejam aí para facilitar nossa vida, eles precisam ser usados com sabedoria. Por serem muito permissivos de forma geral, resultados inesperados podem ser causados no mal uso da ferramenta.

e como, na teoria, resolvê-los?

No exemplo que dei anteriormente, seu objetivo era pegar os endereços de várias pessoas. Se forem os endereços de todas as pessoas do banco de dados, você precisa apenas fazer:

 SELECT * from Endereco

Mas se quiser aplicar um filtro para trazer aquelas 5 pessoas, isto pode ser feito evitando aquelas várias consultas com um JPQL diferente, partindo da tabela Endereco também:

 SELECT * from Endereco where pessoa_id IN (1,2,3,4,5);

Já ouvi também que para resolver, é só praticar o eager loading. Mas até que ponto ele é benéfico e capaz de resolver esse problema?

O EAGER loading é uma alternativa, pois o SQL gerado seria algo assim:

select p.id, p.nome, end.id, end.rua, end.pessoa_id from pessoa p JOIN endereco end ON end.pessoa_id = p.id

Contudo, o EAGER é um problema se adicionado entre o relacionamento de Pessoa e Endereço no seu ORM, pois toda vez que você buscar uma pessoa, os endereços também virão juntos. Acredite, você não quer isto como comportamento padrão do seu sistema. Os principais problemas de performance que vi em aplicações que envolviam o uso de algum ORM eram causados por isto.

Alguns ORMs tem a alternativa de usar o FETCH opcionalmente em uma consulta, assim você pode “ligar” o EAGER quando quiser. No JPQL, ficaria assim:

SELECT * from pessoa JOIN FETCH pessoa.enderecos

Resultando no mesmo SQL que citei anteriormente.

Porém, existe uma séria limitação com FETCH e EAGER se você tentar aplicar algum tipo de paginação na consulta. Usando EAGER ou FETCH isto não é possível de ser aplicado no próprio SQL gerado, e para ter uma consulta com este mesmo efeito (trazer pessoas e endereços na mesma consulta) você precisará apelar uma consulta nativa e/ou usar funções nativas (como o DENSE_RANK) do banco de dados.

Fonte

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *