#はじめに
今回も、昨日の面接でいただいた話から広げていきます。
#アプリの課題
面接の技術的な質問にて…
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ページに◯件まで)
これはヒントになりそうです。
自分のアプリケーションにも取り入れることができないか。他の方法はないか、もう少し考えてみたいと思います。
##最後に
現場では、処理の速度や情報が大量になったときを想定して、設計していることを知ることができた面接でした。
やっぱり、エンジニアってすげぇって話です。
続きは、また明日。