Home
À 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:
|
1 |
project = Project.find_by_name(params[:name]) |
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.
|
1 2 3 4 5 |
class IndexProjectsOnName < ActiveRecord::Migration def change add_index :projects, :name end end |
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:
|
1 2 |
User.find_by_username("ronanlopes") User.find_by_email("lopesronanufsj@gmail.com") |
vão ser beneficiadas com a adição de índices nas coluna username e email:
|
1 2 |
add_index :users, :username add_index :users, :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:
|
1 2 3 4 5 6 7 |
class Project < ActiveRecord::Base has_many :branches end class Branch < ActiveRecord::Base belongs_to :project end |
Você deve adicionar o índice na chave estrangeira, project_id:
|
1 |
add_index :branches, :project_id |
Para associações polimórficas, o dono do projeto pode ser um usuário ou organização:
|
1 2 3 4 5 6 7 8 9 10 11 |
class Organization < ActiveRecord::Base has_many :projects, :as => :owner end class User < ActiveRecord::Base has_many :projects, :as => :owner end class Project < ActiveRecord::Base belongs_to :owner, :polymorphic => true end |
Nesse caso, precisamos criar um índice duplo, que considere as duas colunas:
|
1 2 3 4 5 6 |
# Errado: Não otimiza as consultas add_index :projects, :owner_id add_index :projects, :owner_type # Correto: Criando o índice levando em consideração a dupla de colunas add_index :projects, [:owner_id, :owner_type] |
Índices para valores ordenados
Qualquer ordenação frequente baseada em uma coluna também requer um índice dedicado. Por exemplo, a consulta:
|
1 |
Project.order(:updated_at).take(10) |
pode ser otimizada da mesma forma que demonstrado nos demais casos:
|
1 |
add_index :updated_at |
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
1 Comentário
Sannytet
11 de dezembro de 2018 at 15:15Nice posts! 🙂
___
Sanny