All for Joomla All for Webmasters
Ruby On Rails

Ruby On Rails: seu banco de dados está indexado corretamente?

À medida que sua aplicação Rails cresce, é comum esbarrar em problemas de performance, com requisições lentas e que utilizam o máximo do CPU do seu servidor. Se você está utilizando as junções do ActiveRecord corretamente e evita o problema de N+1 consultas, por que sua aplicação está ficando mais lenta? Há alguma forma de otimizar a performance da sua aplicação ou Rails simplesmente não é escalável?

O que deixa sua aplicação Rails mais lenta?

Dentre as muitas razões possíveis para lentidão de uma aplicação, as consultas ao banco geralmente são as principais responsáveis pela perda de performance. Além do problema de N+1 consultas, o carregamento excessivo de dados para a memória, falta de valores cacheados e ausência de tabelas indexadas são os principais vilões das consultas lentas.

Indexar a sua tabela em chaves estrangeiras e colunas que são muito utilizadas (por pesquisa ou ordenação) faz uma grande diferença. A ausência do índice é um problema que não é notável mesmo para tabela com milhares de registros. Porém, quando esse número atinge a casa dos milhões, as consultas na tabela se tornam angustiantemente lentas.

A função dos índices

Quando você cria uma coluna no seu banco, é primordial considerar a possibilidade de precisar de pesquisar e recuperar registros da sua tabela com base nessa coluna. Vamos considerar, por exemplo, um model Projeto, com um atributo nome. Quando um usuário visita a aplicação, a primeira coisa que precisamos fazer no controller é buscar o projeto pelo nome:

Sem um índice, seu Sistema Gerenciador de Banco de Dados teria que checar cada registro na tabela de projetos, até encontrar o registro procurado. Entretanto, se nós adicionarmos o índice à tabela, a mesma consulta vai executar consideravelmente mais rápido.

Uma forma intuitiva de pensar nos índices é imaginar o índice remissivo de um livro. Se você quer encontrar uma palavra contida no livro, você pode ler o livro todo procurando pela palavra, ou abrir a seção de índices ordenada alfabeticamente com um indicador das páginas em que ela se encontra.

O que precisa ser indexado?

Uma boa regra do dedão para decidir sobre a criação de índices é verificar tudo que é referenciado em cláusulas WHERE, HAVING ou ORDER BY das suas consultas.

Índices para consultas de cláusula única

Qualquer consulta baseada no valor de uma única coluna indica a necessidade de indexação. Por exemplo, as consultas:

vão ser beneficiadas com a adição de índices nas coluna username e email:

Índices para chaves estrangeiras

Se você tem relações belongs_to ou has_many, é recomendado indexar as chaves estrangeiras para otimizar consultas que considerem a relação. Por exemplo, se você tem branches (ramificações) que pertencem ao projeto:

Você deve adicionar o índice na chave estrangeira, project_id:

Para associações polimórficas, o dono do projeto pode ser um usuário ou organização:

Nesse caso, precisamos criar um índice duplo, que considere as duas colunas:

Índices para valores ordenados

Qualquer ordenação frequente baseada em uma coluna também requer um índice dedicado. Por exemplo, a consulta:

pode ser otimizada da mesma forma que demonstrado nos demais casos:

Eu devo usar índices sempre?

O uso de índices pode melhorar consideravelmente a performance de suas consultas, mas seu uso negligenciado pode ter um custo alto e até mesmo tornar sua aplicação mais lenta. Por exemplo, tabelas que tem registros que são constantemente removidos podem impactar negativamente o seu banco, já que além da remoção do registro, é necessária a remoção do índice. O uso de índices também requer mais armazenamento para sua operação. Tenha em mente que em aplicações com grande volumes de dados, essas decisões têm grande impacto e, na dúvida, baseie-se em medições e casos de uso reais.

 


Fonte: https://semaphoreci.com/blog/2017/05/09/faster-rails-is-your-database-properly-indexed.html

Você Também Pode Gostar

Nenhum Comentário

Deixe uma Resposta