Railsアプリの処理を100倍以上に高速化して得られた知見 | Recruit Tech Blog

はじめまして。2019年4月から妊娠・出産アプリ『Babyプラス』の開発チームにJOINした濱田です。 『Babyプラス』のバックエンドはRailsで実装されているのですが、とあるCSV生成処理がとても遅かったので100倍以上に高速化しました。この過程でRailsアプリの処理高速化に関する以下の知見が得られたので、具体例を交えて共有します。この知見は、ActiveRecordを使用してMySQLなどのRDBMSからデータ抽出をする様々な場面で活用できると思います。 いわゆる「N+1問題」を起こさないのは基本 「ActiveRecordインスタンスの生成コスト」はそれなりに高い pluckはjoinsと組み合わせることで他テーブルのカラム値も取得できる 前提: DBスキーマとデータ規模 今回の処理高速化に関わるモデルのDBスキーマとデータ規模は以下の通りです。なお、これらは本エントリ向けに少

[tumo300-500]

タイトル「ActiveRecord の〜」でもよさそう

[mumei-0]

“いわゆる「N+1問題」を起こさないのは基本 「ActiveRecordインスタンスの生成コスト」はそれなりに高い”

[nekonenene]

ActiveRecord インスタンスの生成コストが思いのほか大きいし、join, pluck で解決する手法が鮮やか

[tmtms]

ActiveRecord 難しいそうだなー。Sequel なら簡単なのに。

[Makeneko]

ActiveRecordの欠点を上手に回避し、利点を享受出来れば、生SQL書くより生産性は高いように思います。（ただし生成されたSQLは確認する派）

[gachapining]

内容と関係ないけどブログタイトル表示のアニメーションがかっこいい

[petitviolet]

生SQLはそれはそれでダルいマッピングを書きまくらないといけないので辛い

[daichirata]

Goやらなんやら色々使ったけど、何だかんだActiveRecordは良く出来てる

[hirorock]

データベースへのアクセスを見直す pluck

[ozw-sei]

こういうことで悩みたくないから、ORM極力使いたくない

[rryu]

9000個のActiveRecordオブジェクトの生成を省くと1秒以上速くなる。CSV生成処理でそこまで追い込むかは微妙なところ。

[opiyotan]

このpluckの使い方は想像もつかなかったなーすごい！！