(Серебряная) пуля для задачи N + 1

Rails — это один из самых популярных вариантов построения минимально жизнеспособных продуктов (MVP). Вы можете загружать, создавать прототипы и выпускать приложения с такой легкостью, что Rails является выбором многих разработчиков по умолчанию для MVP.

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

Одна потенциальная область улучшения — это запросы, которые ваше приложение отправляет в базу данных. Сократите количество запросов, увеличьте производительность вашего приложения.

Большинство приложений Rails имеют данные, распределенные по многим моделям с ассоциациями между ними, используя ORM для доступа. ORM могут помочь вам устранить несоответствие импедансов между реляционными базами данных и объектно-ориентированными моделями, что, надеюсь, сделает вашу жизнь проще. Но незнание некоторых из их подводных камней может значительно снизить производительность вашего приложения. Одна из таких ловушек — проблема выбора N + 1.

Что такое проблема с N + 1?

Эта проблема возникает, когда код должен загрузить дочерние элементы отношения родитель-потомок («многие» в «один ко многим»). В большинстве ORM по умолчанию включена отложенная загрузка, поэтому выдаются запросы для родительской записи, а затем один запрос для КАЖДОЙ дочерней записи. Как и следовало ожидать, выполнение N + 1 запросов вместо одного запроса приведет к заполнению базы данных запросами, чего мы можем и должны избегать.

Рассмотрим простое приложение для блога, в котором есть много статей, опубликованных разными авторами:

#Articles model
class Article < ActiveRecord::Base
  belongs_to :author
end

#Authors model
class Author < ActiveRecord::Base
  has_many :posts
end

Мы хотим перечислить 5 последних статей на боковой панели статьи вместе с их заголовком и именем автора.

Это может быть достигнуто с помощью следующего

 #In our controller
@recent_articles = Article.order(published_at: :desc).limit(5)

#in our view file
@recent_articles.each do |article|
    Title: <%= article.title %> 
    Author:<%= article.author.name %>
end

Приведенный выше код отправит 6 (5 + 1) запросов в базу данных, 1 для извлечения 5 последних статей и затем 5 для их соответствующих авторов. В приведенном выше случае, поскольку мы ограничиваем количество запросов до 5, мы не увидим, чтобы эта проблема сильно влияла на производительность нашего приложения. Однако для запросов с большим пределом это может быть фатальным.

Каждый запрос имеет немного накладных расходов. Гораздо быстрее выдать 1 запрос, который возвращает 100 результатов, чем выдать 100 запросов, каждый из которых возвращает 1 результат. Это особенно верно, если ваша база данных находится на другом компьютере, который, скажем, находится в сети на расстоянии 1-2 мс. Здесь, выдача 100 запросов последовательно имеет минимальную стоимость 100-200 мс, даже если они могут быть мгновенно удовлетворены MySQL.

Решение — стремительная загрузка

Стремительная загрузка — это механизм загрузки связанных записей объектов, возвращаемых Model.find В приведенном выше примере, если мы используем загрузку с нетерпением для получения данных, сведения об авторе будут загружены вместе со статьями.

В Rails ActiveRecord имеет метод под названием includes

Давайте проведем рефакторинг нашего кода, чтобы усилить ассоциацию загрузки.

 #In our controller
#Using includes(:authors) will include authors model.
@recent_articles = Article.order(published_at: :desc).includes(:authors).limit(5)

#in our view file
@recent_articles.each do |article|
    Title: <%= article.title %> 
    Author:<%= article.author.name %>
end

Как быстрая загрузка может предотвратить проблему с N + 1?

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

 Article Load (0.9ms) SELECT 'articles'.* FROM 'articles'
Author Load (0.4ms) SELECT 'authors'.* FROM 'authors' WHERE 'authors'.'id' = ? ORDER BY 'authors'.'id' ASC LIMIT 1 [["id", 1]]
Author Load (0.3ms) SELECT 'authors'.* FROM 'authors' WHERE 'authors'.'id' = ? ORDER BY 'authors'.'id' ASC LIMIT 1 [["id", 2]]
Author Load (0.4ms) SELECT 'authors'.* FROM 'authors' WHERE 'authors'.'id' = ? ORDER BY 'authors'.'id' ASC LIMIT 1 [["id", 3]]
Author Load (0.3ms) SELECT 'authors'.* FROM 'authors' WHERE 'authors'.'id' = ? ORDER BY 'authors'.'id' ASC LIMIT 1 [["id", 4]]    
Author Load (0.4ms) SELECT 'authors'.* FROM 'authors' WHERE 'authors'.'id' = ? ORDER BY 'authors'.'id' ASC LIMIT 1 [["id", 5]]

 Article Load (0.4ms) SELECT 'articles'.* FROM 'articles'
Author Load (0.4ms) SELECT 'authors'.* FROM 'authors' WHERE 'authors'.'id' IN (1,2,3,4,5)

 group :development do
  gem 'bullet'
end

 config.after_initialize do
  #Enable bullet in your application
  Bullet.enable = true
end

 Bullet.alert = true

 Bullet.console = true

 Bullet.rails_logger = true

 Bullet.bullet_logger = true

 Bullet.growl = true