DEV Community: Lucas Araújo

Entendendo e Resolvendo o Problema N+1 com Ruby on Rails

Lucas Araújo — Wed, 24 May 2023 03:05:01 +0000

Na jornada para se tornar um desenvolvedor Rails, é inevitável encontrar certos desafios que fazem você parar, pensar e até mesmo refatorar o código que você pensava estar pronto para produção. Um desses desafios é o fatídico problema N+1, uma armadilha comum de desempenho que tem o potencial de desacelerar a sua aplicação Rails.

Entender esse problema é essencial para qualquer desenvolvedor Rails, pois ele está ligado à forma como o ActiveRecord, o ORM padrão utilizado pelo Rails, manipula as associações entre os modelos. Quando mal gerenciado, este problema pode resultar em uma quantidade excessiva de consultas ao banco de dados, prejudicando a performance do seu aplicativo.

Entendendo N+1

O N+1 é um padrão comum de ineficiência de desempenho que ocorre ao trabalhar com bancos de dados relacionais, como PostgreSQL ou MySQL. Essa questão ocorre quando estamos recuperando objetos associados em uma relação de um para muitos (one-to-many) ou muitos para muitos (many-to-many). Por exemplo, suponha que você tenha modelos de User e Post, e cada User tem muitos Posts. Se você quisesse carregar todos os usuários e seus respectivos posts, você pode acabar criando um cenário de problema N+1 sem perceber.

Imaginando que que você queira mostrar todos os posts de cada usuário. Você pode ser tentado a fazer algo assim:

User.all.each do |user|
  puts user.posts
end

Mas vamos destrinchar com calma o que esse código esta fazendo:

Quando você executa User.all.each, o Rails realiza uma consulta SQL para buscar todos os usuários. Isso representa a primeira consulta SQL, ou o "1" no problema "N+1".

User Load (6.9ms)  SELECT "users".* FROM "users"

No momento em que você executa user.posts.each dentro do loop, o Rails tem que buscar os posts para o usuário atual. Isso representa uma consulta SQL adicional para cada usuário. Esta consulta é executada para cada um dos seus usuários e são as consultas "N" no problema "N+1".

Post Load (0.2ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = ?  [["user_id", 1]]

Então, supondo que na sua base de dados possuam 1000 usuários no total, seu aplicativo faz 1001 consultas ao banco de dados para este único pedaço de código. Para um número grande de usuários, isso se torna altamente ineficiente, pois cada consulta ao banco de dados consome tempo e recursos do servidor.

Resolvendo esse problema

O problema N+1 pode ser enfrentado de várias maneiras. Algumas delas incluem a utilização de gems como a 'bullet' ou a 'goldiloader', que são projetadas para ajudar a identificar e corrigir isso. Além do mais, técnicas de otimização de consultas, como 'preload', 'eager_load' e 'joins', também podem ser usadas dependendo do caso específico. No entanto, uma das soluções mais comuns e simples é o uso do 'eager loading'. 'Eager loading' é uma técnica onde nós carregamos todas as associações necessárias de uma só vez de maneira antecipada. Isso é especialmente útil para evitar consultas excessivas ao banco de dados. No Rails, isso é facilitado pelo método includes.

users = User.includes(:posts)
users.each do |user|
  puts user.posts
end

Nesse bloco de código, a chamada User.includes(:posts) instrui o ActiveRecord a carregar todos os usuários e seus respectivos posts em duas consultas separadas. Primeiro, ele executa uma consulta para buscar todos os usuários. Em seguida, com base nos IDs dos usuários retornados, executa uma segunda consulta para buscar todos os posts associados a esses usuários.

Essas consultas são armazenadas na memória, de modo que quando você itera sobre os usuários e seus posts na sequência user.posts, nenhuma consulta adicional é necessária, pois os dados já estão disponíveis.

Isso reduz significativamente o total de consultas, de 1001 para apenas 2, neste caso, independentemente do número de usuários. Portanto, ao utilizar o 'includes' para carregar antecipadamente as associações necessárias, resolvemos eficientemente o problema N+1 e otimizamos a performance da nossa aplicação."

Migrações de dados em Ruby on Rails

Lucas Araújo — Thu, 10 Mar 2022 13:36:54 +0000

Desde o início dessa minha caminhada como desenvolvedor Ruby on Rails, eu venho aprendendo determinadas técnicas e ferramentas que me auxiliam no meu dia a dia. Uma vez no meu trabalho, ocorreu a necessidade de alterar os dados reais no banco de dados de produção. Eu pensei rapidamente e a primeira opção óbvia que vem à mente é usar uma migração do Rails, porém conversando com colegas da minha equipe, fui convencido de que isso não seria uma boa prática e a partir daí busquei entender um pouco mais sobre como migrar dados de maneira correta e mais segura utilizando Ruby on Rails.

Utilizando o sistema de migrações do Rails

Observando o Rails Guide, for Active Record Migration a primeira seção da documentação começa dizendo:

"As migrações são um recurso do Active Record que permite evoluir seu esquema de banco de dados ao longo do tempo. Em vez de escrever modificações de esquema em SQL puro, as migrações permitem que você use uma DSL Ruby para descrever as alterações em suas tabelas."

Claramente, a palavra "dados" em nenhum momento foi citada no parágrafo acima, isso porque, por definição, as migrações do Rails devem ser usadas apenas para alterações do schema e não para alterações de dados reais no banco de dados.

Podemos criar um cenário básico para entendermos um pouco mais sobre isso. Digamos que nós precisamos alterar o estado padrão de um blog qualquer, por exemplo, sendo assim criaríamos um arquivo de migração como este abaixo:

rails generate migration ChangeDefaultState
  invoke  active_record
  create    db/migrate/20220305055147_change_default_state.rb

Nesse arquivo, faríamos a seguinte alteração como essa:

class ChangeDefaultState < ActiveRecord::Migration[5.1]
  def up
    Post.where(state: "Initial").update_all(state: "Active")
  end

  def down
    raise ActiveRecord::IrreversibleMigration
  end
end

Feito isso, está tudo certo! É só executar a migração e esquecer dela... Meses depois aparece uma demanda no seu sistema, onde nós precisamos alterar o nome da tabela posts para articles. Até então é uma tarefa simples de ser executada. Alterando o nome da tabela, renomeando o modelo e pronto, só mandar para produção. Pois bem, agora nós não temos mais um modelo chamado Post. Na próxima vez que você precisar configurar um ambiente de desenvolvimento, você cria seu banco de dados, executa suas migrações e obtém uma falha no seu console: Rails não sabe o que é Post:

$ rails db:migrate
== 20220305056456 AddDefaultState: migrating ==================================
rails aborted!
StandardError: An error has occurred, this and all later migrations canceled:
uninitialized constant AddDefaultState::Post
/Users/lucas/Projects/codes/serious/db/migrate/20220305055147_change_default_state.rb:3:in `change'

A solução para esse tipo de problema, de fato, é rápida: você precisa renomear o modelo na sua migração. Entretanto esse padrão não é a melhor abordagem. Resumidamente,as migrações ficam desatualizadas rapidamente e você não tem uma maneira eficiente de descobrir, além do mais não estaria seguindo a convenção do Rails: os arquivos db/migrate devem migrar apenas as estrutura do banco de dados e não os registros do banco de dados.

Outro detalhe é que o sistema agora depende da conclusão da migração de dados. Isso pode não ser um problema quando seu aplicativo é novo e seu banco de dados é pequeno. Mas e os grandes bancos de dados com milhões de registros? Sua implantação agora terá que esperar que a manipulação de dados seja concluída e isso é apenas pedir problemas, com possíveis migrações suspensas ou com falha. Dito isso, pode-se dizer que incluir os códigos de migração de dados no db:/migrate é uma prática "anti-padrão".

Utilizando Rake Tasks para migrar dados

Um método mais confiável, acessível e eficiente é criar Rake Tasks para migrações de dados. Escrevendo um pouco mais de código nós podemos resolver esse tipo de problema.

namespace :data do
  task :migrations do
    Rake.application.in_namespace(:data) do |namespace|
      namespace.tasks.each do |t|
        next if t.name == "data:migrations"
        puts "Invoking #{t.name}:"
        t.invoke
      end
    end
  end

  task change_default_state: :environment do
    puts "Changing default state for posts"
    Post.where(state: "Initial").update_all(state: "Active")
    puts "Changed default state for posts"
  end

A primeira Task ( rake data:migrations) executará todas as tarefas no data namespace excluindo ela mesma. Isso pode ser um pouco arriscado! então você deve se certificar de que todas as Tasks nesse namespace sejam idempotentes, ou seja, realizadas com sucesso independente do número de vezes que é executada. Você deseja poder executar rake data:migrations o quanto quiser sem arriscar a perda de dados.

A ressalva que temos com essa abordagem é que ela não resolve o problema que mencionamos no primeiro padrão: à medida que o sistema evolui, as Tasks ficarão desatualizadas.

A melhor maneira é criar uma classe adicional. Podemos chamá-loChangeDefaultStateForPosts. Será um objeto Ruby simples que executará a migração de dados. Isso nos ajudará a adicionar cobertura de testes para ele.

class ChangeDefaultStateForPosts
  def self.call
    Post.where(state: "Initial").update_all(state: "Active")
  end
end

Agora que temos uma classe simples e com isso podemos escrever um arquivo de testes para ela.

RSpec.describe ChangeDefaultStateForPosts do
  describe "ChangeDefaultStateForPosts.call" do
    let!(:post) do
      Post.create(state: state)
    end

    context "when post is in 'Initial' state" do
      let(:state) { "Initial" }

      it "changes the state of the Initial" do
        expect do
          ChangeDefaultStateForPosts.call
        end.to change(post, :state)
      end
    end

    context "when post is in another state" do
      let(:state) { "Published" }

      it "doesn't change the state" do
        expect do
          ChangeDefaultStateForPosts.call
        end.not_to change(post, :state)
      end
    end
  end
end

Sendo assim estamos seguros pois a nossa Task sobre a migração de dados é protegidas pelo nosso arquivo de teste. Quando alguém tentar renomear a tabela posts para articles, receberá uma falha no teste. Isso os forçará a atualizar o arquivo de migração de dados.

Caso essa opção seja válida e queira implementar no seu projeto, é bastante recomendado documentar todo esse processo.

Migrações de dados com a `data_migrate`

Como todo desenvolvedor Rails, provavelmente, em algum momento desse artigo, você chegou a se perguntar se talvez existisse uma Gem para fazer esse processo de migração de dados... SIM, nós podemos usar a data_migrate para todas as nossas migrações de dados. Assim como o Rails com a tabela schema_migrations, a data_migrate usa uma tabela especifica chamada data_migrations para acompanhar as migrações novas e as antigas.

Para o problema que estamos tentando resolver, você pode criar uma nova migração de dados como esta:

rails generate data_migration change_default_state_for_posts

Isso adicionará uma nova migração de dados ao diretório db/data. Você precisará definir os métodos up e down:

class ChangeDefaultStateForPosts < ActiveRecord::Migration[5.1]
  def up
    Post.where(state: "Initial").update_all(state: "Active")
  end

  def down
    Post.where(state: "Active").update_all(state: "Initial")
  end
end

E, em seguida, execute e verifique o status com comandos como estes:

rake data:migrate
rake db:migrate:with_data
rake db:rollback:with_data
rake db:migrate:status:with_data

Acredito que a melhor maneira de resolver esse problema é usar a Gem data_migrate. Você escreverá menos código, manterá todas as migrações de dados em um diretório db/data e terá uma boa maneira de acompanhar as alterações de dados.