n+1問題の対応あえてn+1にする場合もある！？

開発チームの下田です。
ラクーンホールディングス技術戦略部ではオフライン+オンラインのエンジニア向けイベントを開催しています。connpassで告知するので、ご覧ください。

Raccoon Tech Connect #2 パフォーマンス改善LTでn+1問題について話してきたので、そちらの記事化になります。

n+1問題とは

n+1問題とは、データ取得時に発生するパフォーマンス問題の一種です。RailsのActiveRecordなど、ORマッパーを使用したクエリでよく発生します。最初のSELECTクエリで取得したn行の一覧の1行1行に対して、子テーブルのSELECTを1回以上発行してしまい、クエリの発行回数がn+1回になってしまう問題です。

orders = Order.all.limit(100) # ここで1回SELECT

## 注文に紐づく出荷があるかarrayで返す
orders.map{|order| order.delivery.present?} # n回SELECTが走ってしまう

n+1になりそうなところ

こちらは弊社サービスの受注・発注システムCORECの受注一覧画面です。

受注に対して出荷があるかどうかチェックしたり、取引先名を表示するところでn+1問題が潜んでいます。

簡単にE-R図

ユーザに対して取引先が複数、その取引先に対して注文が複数、注文に対して出荷は1つの出荷にまとめたり、複数の出荷に分割したりするのでn:nです。ということは、ユーザから見たときは注文も出荷も1:nです。

RDBMSは遅い

もちろん環境によりますが、基本的にRDBMSにSELECTで問い合わせると遅いです。だいたい10msはかかります。

1ページに100行 * 関連テーブルが2個があるとき、n+1問題が発生すると201回のクエリになります。

201クエリ * 10ms = 2秒かかります。この程度でも、体感できる遅さです。

n+1問題を解消するフェッチ戦略

n+1問題を解消するには、データベースからまとめて取得すること、つまりフェッチ戦略を考えます。

代表的な方法

JOINしてまとめて取得する(Railsでいうeager_load)
テーブルごとに1回取得する(Railsでいうpreload)

eager_load

子テーブルを先にLEFT JOINしフェッチする戦略です。

eager_loadで気をつけなければならないポイントは、JOINすると直積するということです。

子テーブル1に100行あり、子テーブル2に50行あるとき、同時にJOINすると転送する行数は5000行となります。

行数はもちろん、データ自体も増えます。

上の2つの表が元の表、下がSELECTした結果を表した表です。1行*2行で増えていないように思いますが、赤く塗っている部分が上のマスと全く同じデータになっていて、無駄に取得していることがわかります。行数が指数的に増える * 1行あたりのデータ量も増えるので、eager_loadする場合は転送量の見積が必須です。