はじめに

今回も、昨日の面接でいただいた話から広げていきます。

アプリの課題

面接の技術的な質問にて…

users_controller.rb

def show
  @users = User.all
end

（あくまでも、例です）

ActiveRecodeの「all」を使っているけど、
「もし、ユーザーが１万人に増えて、処理が遅くなるとしたら、どうする？」

その時の考え

正直、今まで考えたことがありませんでした。
学習してきた中で、データベースの操作を表すCRUDがあって、
特に条件を付けずに、情報を取ってくるときは、allと安易に理解していました。

改めて復習してみる

CRUDとは…
C(create)
R(read)
U(update)
D(delete)
の頭文字で、データベース操作を表しています。

今まで使っていた、各操作の代表的なものは、

C(create)


user = User.create

新しく情報を作成するときに使っていました。
コントローラーでcreateのメソッド内で使うことが多くありました。

U(update)

便宜上、こちらを先に…


user = User.find(id:1)
user.name = Qiita
user.save

R(read)


users = User.all

保存された情報を表示させるようなときに使っていました。
ビューでeach文を使って数に応じて表示させたり、フォームのプルダウンで選択できるようにしたりする場面が主でした。

D(delete)


user = User.find(params[:id])
user.destroy

必要なくなった情報を削除したいときに使います。
ちなみにfindはR(read)です。

なぜ、allでは処理が遅くなるのか…

改めて、この問題を考えるためには、ActiveRecodeとは何かを考えます。
私の認識としては、
SQL文を直接書かずとも、Railsが勝手に書いて、処理をしてくれるもの
です。
つまり、面接での質問の意図と処理が遅くなるとは、
~~「めっちゃSQL文が生成されているけど、本当に全部必要？」~~
「必要のない情報も呼び出してるけど、全部必要？」
ってことだと考えます。
「はい、必要ではない場合もあると思います。」
大まかに言うと同じだと思うのですが、
具体的に言うと、
Amazonで例えるなら…
全ての商品をいちいち表示してないですよね。きっとそんなことしたら、商品の数だけSQL文が生成され、×(かける)ユーザーの数となり、素人でも処理が遅くなることが想像できます。
これを抑えることができないか？
と、いうことです。
このままAmazonを例にすると答えが導き出せそうです。
実際にAmazonではどうしているか。
パッと思い浮かぶ解決方法は2つあります。
- 検索でヒットした情報のみを表示させている。
- 表示も一度ではなく、ページを分けている。(1ページに◯件まで)
これはヒントになりそうです。

自分のアプリケーションにも取り入れることができないか。他の方法はないか、もう少し考えてみたいと思います。

最後に

現場では、処理の速度や情報が大量になったときを想定して、設計していることを知ることができた面接でした。
やっぱり、エンジニアってすげぇって話です。
続きは、また明日。