2年位Railsでコールセンターアプリ的なものを作っていました。 大したことは書けませんが、この2年間で思ったことなんかを徒然と書いてみます。 その前に どんなチームか？ 電話する人たち:数十名 その人達のリーダー:5-10名程度 開発者:1-3人 デザイナがいないならWrapbootstrap https://wrapbootstrap.com/ デザイナはいないので自分たちでどうにかする必要がありました。 のでwrapbootstrap。 18ドル払うだけで多機能で色んな画面用のテンプレが揃ってるって素晴らしいですね。 複数人で作っても同じようなデザインに落ち着くこと 使う人達もデザインが良いと喜んでくれること（別部署に羨ましいって言われた） 大体社内ツールで使うようなデザインがそろってるので開発が早く進められること 当時はAce Adminを使うことにしました。 カラフルで明るい印象
こんにちは、鈴木です。 Rails の便利なライブラリをシリーズでご紹介してみたいと思います。 今回は「N+1 問題」を検出してくれるライブラリ、bullet です。 bullet (http://github.com/flyerhzm/bullet) N+1 問題 N+1 問題とは、OR マッパーを使用しているときに発生しがちな問題です。 何かの一覧画面を作成しているときに、 一覧に表示するデータを取得するために SELECT を 1 回実行（N レコード返される） 各データの関連データを取得するために SELECT を N 回実行 データベースアクセス（SELECT）が合計 N+1 回も実行される（JOIN して 1 回の SQL で取得した方が効率的） というものです。 具体的なコードで考えてみましょう。 例として店舗の一覧画面を作成しているとします。 関係するモデルは以下の通りです
最近会社でHibernateのN+1問題事例を調べてたんですが、ActiveRecordでも当然のように起こりますね。 BOOKSテーブルが、1対NでREVIEWSテーブルと関連を持っています。（BOOKSが1、REVEWSがN） 以下のコードでは、BOOKSテーブルを全件検索して、それに関連するREVIEWSテーブルのレコードを取得して、REVIEWSテーブルのBODYカラムを出力する。 Book.all.each { |book| book.reviews.each { |review| puts review.body } } このコードではBOOKSテーブルに対して1回のSQLが発行され、REVIEWSテーブルに対してはBOOKSテーブルのレコード数分のSQLが発行されます。N+1問題です。BOOKSテーブルとREVIEWSテーブルの多重度に関係なく、親テーブルを複数検索して、子テ
これは明らかに遅く非効率だ。この問題はEager Loadingというテクニックを使うことで解決できる。もし最初の注文クエリの一部として後で必要となる顧客とのアソシエーションをすべてロードしておけば、Customerに対するアクセスはただのプロパティへのアクセスになる。こうすれば後のデータベースクエリは不要になり、N+1問題も起こらない。 LightSpeedでは、そのEager Load設定をTrueに変更することで（もしくは手書きコードのエンティティにEagerLoadAttributeを適用することで）、アソシエーションのEager Loadを可能にする。Eager Loadされるアソシエーションをもつエンティティをクエリすると、LightSpeedは追加のSQLを生成して、‘プライマリ’エンティティと同じように関連したエンティティを取得する。 Order.Customerアソシエー
N+1問題とは SQLクエリが 「データ量N + 1回 」走ってしまい、取得するデータが多くなるにつれて（Nの回数が増えるにつれて）パフォーマンスを低下させてしまう問題です。 次のように、何度もクエリが走ってしまい、その度に0.1msほどかかってしまってます。 Processing by PostsController#index as HTML Post Load (0.2ms) SELECT "posts".* FROM "posts" User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 1]] User Load (0.1ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id",
N+1というからほわっつ？ってなって、1+Nって言われると理解しやすいと思った。 このページ非常にわかりやすい。 http://www.techscore.com/blog/2012/12/25/railsライブラリ紹介-n1問題を検出する「bullet」/ 上のページでいう、PrefectureとShopが一対多の関係になっているときに、Shopの方から、eachの中でshop.prefecture.name みたいにすると、shopの数だけprefecture探すSQL文が発行されることになる。 このページ（参考）では、N+1問題をシンプルに、「全レコードの取得に一つ＋各レコード分だけ SQL を発行してしまう問題」と定義していて、要はただこれだけの問題だと感じた。 例えば100万レコードあったら100万回SQL発行されるのかって考えると、さすがにだれでもやばみ感じると思う。 実際にサ
Kodougu では、SQL の Select における N+1 問題を回避することが重要になってきます。 N+1 問題とは、Tree 状の情報を DB から読み出す際、全レコードの取得に一つ＋各レコード分だけ SQL を発行してしまう問題です。出来の良い O/R マッパーを使っているとよく引っかかります。 Kodougu のようなモデリングツールだと、この問題には非常によく出くわします。例えば、図上の要素を全て取得してから、要素に関係する関連の一覧を取得するなどを行うような場合です。Rails の ActiveRecord は気軽に DB にアクセスできてしまいますから。以下のコードでは、要素から出て行く関係線の一覧を取得しています。以下のようなコードを書いてしまうと、図を一枚描くたびに要素数分の SQL が発行されてしまいます。 [code: @elements = Element.f
前回のおさらい 前回の記事では、データベースに対してLINQメソッド式を使ってクエリを実行する方法について解説しました。多数の条件が指定された場合でも、メソッドチェーン式にメソッドを積み重ねることで簡単に実装できることを確認できました。 今回は、LINQが実際にはどんなSQLに変換されているのかを確認します。また、遅延ローディングの有無によってどのように処理が変わるかを意識し、パフォーマンス問題を解決する方法について解説します。なお、前回作成したサンプルを今回も引き続き使用します。 出力されるSQLを確認してみよう 前回の解説通り、Entity Frameworkは、LINQのクエリ式やメソッド式を、最終的にSQLへと変換してデータベース上で実行しています。この変換は透過的に行われるため、プログラマはLINQを記述する際にSQLをそれほど意識する必要がありません。しかし、データベースプログ
2. copyright © 2014 kuwata-lab.com all rights reserved まえがき 現在、アプリケーション開発の現場では O/R Mapper (ORM) が普及しています。今後 も ORM を使った開発は、増えることはあっても減ることはないでしょう。 しかし ORM は、アプリケーション開発者にとっては便利でも、DB 管理者 (DBA) か らみたらトラブルの種でもあります。それが特にパフォーマンスに関する問題であるこ とが多いため、開発者と DBA が対立することも珍しくありません。 とはいえ、ORM による問題はすでに解決策が用意されている場合があります。本当の 問題は、すでに存在する解決策があまり知られていないことではないでしょうか。 そこで本発表では、ORM によってどのような問題が起こりやすいか、どう解決・予防 すればいいか、そして ORM
asin: 4797363827 title: “[Rails高速化] ページキャッシュ、N+1対策、SQLチューニング” category: Rails 🐯 tags: [Rails, Ruby, Gem]『Cookpadではユーザーへのレスポンスタイム 200ms/reqを目標にしている』に感銘を受けて書き始めたこの記事ですが、『パフォーマンス・チューニングやオススメGem in 「Rails勉強会@東京 第88回」』でいろいろ教えてもらったり、最近関わっているサイトのリニュアールで試行錯誤したので、忘備録も兼ねて記事をアップデートします！ 🚕 目次(1) N+1問題の対策 (2) Railsのキャッシュについて (3) 開発中ならrack_mini_profiler (4) 運用中なら断然NewRelicがおすすめ (5) mysqlの簡単チューニング 🚌 (1) N + 1問
ORM使ってて、便利で余裕キメてたらn+1問題を起こしてた。 n+1問題とは 1回目 のselectで、あるテーブルのレコードの集合を取ってきて、更にまた別のテーブルから先ほど取得したレコードデータ使用して n回 selectクエリを発行してしまう現象だ。 うまく説明出来ないので下の具体例書いてみた 解決策(今回の事案の場合) JOIN使ってクエリを一回にまとめる WHERE IN使ってクエリを2回にまとめる のどちらかの対処でクエリ減らす努力をするべきだった。 具体的にどうやってしまったか friendテーブルからplayerのフレンドのレコードの集合を1回引っ張ってきて、そのレコードからまたplayerテーブルへ、フレンドのplayerデータをn回取りに行っている。 sub _get_friends_info { # 自分のフレンド関係データ(player, target)のレコードの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
