GraphQL と N+1 SQL 問題と dataloader - Qiita
この記事ではハイパフォーマンスな GraphQL サーバを実装するのに避けて通れない N+1 SQL 問題について解説します。 TL;DR GraphQL は resolver を個別にかつ再帰的に実行していくため、 RDB のリレーションを効率的に先読みすることができません。そのため一般的に遅延読み込みを行います。 Facebook 社は GraphQL で遅延読み込みするために dataloader という npm パッケージを公開しており、各種言語にその移植版のライブラリが存在しているので、それを使って N+1 SQL 問題を抑制しましょう。 （復習）N+1 SQL 問題とは N+1 問題は「1 つの SQL で N 件のレコードをフェッチしたあと、それぞれ対して関連するレコードを個別にフェッチするのに N つの SQL を発行している」状態を指す言葉です。言葉で書いてもよく分からな
RailsのArelを調査してみた - Qiita
RailsのActiveRecordで想定通りのSQLクエリが発行されずに辛い思いをしたので、SQLまわりのソースコードを読んでいたらArelというものに当たりました。 どうやらこれがrailsっぽくSQLクエリを書ける機能を提供しているようなので、勉強したことをまとめます。あまり細かいことは気にせずに、Arelを読み解く上での基礎を理解することが目標です。 ソースコードをちゃんと読んだ経験が少ないのでとんちんかんなこと書いてないか不安ですが、温かい目で見てもらえればと思います。 間違っている箇所あればコメント欄よりお願いします。 Arelとは ArelはActiveRecordの内側でwhereやselectのメソッドチェーンからSQLを生成する役割を担っています。またDBによってSQLの文法が若干違ったりしますが、その差異を吸収してくれるのもArelです。 rubygemsによるとAr
ActiveRecordに限界を感じArelでサブクエリを頑張って書いてみた - Qiita
はじめに railsを触り始めて4ヶ月が経ち、「ActiveRecordってSQLを知らなくても書けるってすごいなぁ」 と思っていた自分に変化が訪れました。その変化とは、「何でActiveRecordって全部纏めちゃうんだよ。。。」 という気持ちが芽生えたことです。 今私が扱っている案件では、「複数のテーブルから、ある条件のレコードの件数を、タイムアウトなしで取得したい」 という状態になっています。 一例ではありますが、以下のようなサブクエリを使用しないscopeを複数チェーンして、各条件の件数を取得していました。 scope :select_page_views_count, -> do left_joins(:page_views) .select("COUNT(DISTINCT page_views.id) AS page_views_count") .group("#{table_
ActiveRecord の or は merge とセットで使え - Qiita
Model.where(A) .merge(Model.where(B).or(Model.where(C)).or(Model.where(D))) .merge(Model.where(E).or(Model.where(F))) merge() を使うと、 or() の部分をグルーピングすることができます。 SQLの条件組み立ては and で条件を絞り込んでいくのが基本ですから、 or の部分はまとめて and でつないでいきましょう。 or() はどこでグルーピングがどこに入るのか予測不可能なことが多いですが、merge() と併用するとグルーピングを明示的に制御できるようになります。
ActiveRecordの #or を使うときは、こう考えると良さそう - nisshieeのブログ
Rails5で追加された #or について。 （どうでもいいけど、このメソッド、ググラビリティ低すぎぃ） 社内で話してたら、Twitterで会話されてた。 @kamipo https://t.co/UQaAbt7M7T これrails 5.1でも .or(where(...)) が括弧で囲まれないんだけどバグちゃうの？— FUJI Goro (@__gfx__) 2017年7月3日 つまりこう考えれば良いということか。 ↓ 「whereを AND だと思ったうえで、メソッドのチェーン順に従う。」 と思えば良いのか。 Model .where(A) .where(B).or(C) は改行のせいでgroupingが存在している気になるけど、字句解析結果は結局のところこう↓ Model.where(A).where(B).or(C) これを、チェーン順に解釈すれば確かに A and B or C
Ruby on Rails で NOT IN な SQL をかく。 | そんなこと覚えてない
Rails 4 で NOT な条件をもつ WHERE 句 が非常に書きやすくなりました。 Rails 4 なら NOT IN な SQL も簡単に書けます。 User.where.not( name: ["hoge","goro"] ) 条件にリストを渡せばよいです。SQLは以下のようになります。 SELECT "users".* FROM "users" WHERE ("users"."name" NOT IN ('hoge', 'goro')) サブクエリも使えます。これが便利すぎて困る。 query = User.select(:name) User.where.not name: query SELECT "users".* FROM "users" WHERE ("users"."name" NOT IN (SELECT name FROM "users")) Rails 3 の
ActiveRecord の with_lock に先人の知恵を学ぶ - Qiita
はじめに 先日、ActiveRecord の with_lock (lock!) を調べていた時に良くできているなあ、勉強になるなあと思ったので、その辺のことを書いてみたいと思います。 なお、以下の内容は、Rails 5.2.2 及び、PostgreSQL 10.7を前提にしていることをお断りしておきます。 with_lock とは Rails Guide の Pessimistic Locking に with_lock を使ったサンプルコードが登場します。要は、データ更新時に悲観的ロックをかけてくれるというものです。 SQLレベルでざっくりいうと、 SELECT ... FOR UPDATE をしてから UPDATE できるようになるということですね。 ただ、with_lock の前にモデルが変更されていた場合、どうなるのかちょっと気になりましたので、APIを調べてみました。 コードレ
SQLファイルによるRails DBスキーマ管理
Railsではdb:migrateすると、デフォルトでdb/schema.rbを生成しますが、SQLでスキーマ情報を管理することも可能です。下記のようにconfig/application.rb内でactive_record.schema_formatを:sqlと設定することで可能になります（デフォルト値は:ruby）。 # config/application.rb module RailsApp class Application < Rails::Application config.active_record.schema_format = :sql end end これでdb/migrateするとデフォルトのschema.rbではなく、db/structure.sqlというSQLファイルを吐きます。 structure.sqlをロードする生成されたstructure.sqlファイ
Railsのデータロック - Qiita
begin ActiveRecord::Base.transaction do . . raise 'ロールバックします' end p 'コミット' # トランザクション処理を確定 rescue => e p 'ロールバック' # トランザクション処理を戻す end transactionブロックの中で登録・更新処理を行う場合は、saveやupdateではなく、save!, update!を使用する。 transactionブロックの中で複数のモデルの更新を行った後に例外を発生させると、全部のモデルがロールバックする。 楽観的ロック 「競合は多分起きないだろう」という前提で、データの取得時には何もせず、更新時に競合をチェックする方法。 レコードのバージョン管理を行うため、テーブルにlock_versionカラムを追加する。その際、デフォルト値を0にする。 lock_versionはレコード
Rails: 闇雲にインデックスを付けてはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Don't index the kitchen sink! 原文公開日: 2015/07/09 著者: Jeroen Weeink サイト: Crafting Ruby 最近、使われてないインデックスを外す作業を行ってたのですが、やってみると出るわ出るわ。そのほとんどは、逆関連付けの不要なモデルのJOINの一部でした。次の例で考えてみましょう。 class ShoppingCart < ActiveRecord::Base has_many :shopping_cart_products has_many :products, through: :shopping_cart_products end class ShoppingCartProduct < ActiveRecord::Base belongs_to :shoppin
Railsエンジニアなら知っておきたい！RDBでindex作成を検討するときってどんなとき？ - Qiita
はじめに 前回に引き続き、またまたDBネタです(^o^) 前回：Railsエンジニアなら最低限これだけは知っておきたいSQLのJOINの動き 今回は、インデックスについてです。インデックスにはいくつか種類がありますが、 RDBで一般的に使われるB-treeインデックスについて書いていきます。 いきなりですが、インデックスは深い！かなり深い！バイカル湖くらい深いです。 ある程度の指針的なものはありますが、インデックスをどう設計するかの見極めは状況によって変わってくるようです。クエリの実行頻度、テーブルサイズ、カーディナリティ（カラム内のデータの種類の多さ）などなど。。 なので今回は、こんなときはインデックス作成を検討した方がいいというパターンだけザッとまとめる感じで行きたいと思います。 なお、今回の記事作成にあたっては、以下の本を参考にさせて頂きました。 そもそも的なところから分かりやすく書
Rails: JOINすべきかどうか、それが問題だ — #includesの振舞いを理解する（翻訳）
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: To join or not to join? An act of #includes 原文 公開日: 2017/08/07 著者: Tiago Farias 原文ではシェークスピアの古典劇『ハムレット』のセリフが多数引用されています。引用されたセリフのリンクをマウスオーバーするとシェークスピアの原文がポップアップします。 actの基本的な意味は「演技（する）」「（舞台の）場面」であり、タイトルはこれにかかっています。 2017/09/25: 初版公開 2021/09/22: 更新 訳注 k0kubunさんの以下の記事も合わせて読むことをおすすめします。Rails 5以降は#left_outer_joins（またはエイリアスの#left_joins)が使えます。また、#includesがActiveRecord::Baseを生成す
ActiveRecord4でこんなSQLクエリどう書くの？ Merge編 | Webシステム開発／教育ソリューションのタイムインターメディア
ActiveRecord4でこんなSQLクエリどう書くの？ Merge編 #activerecord#rails#ruby 2013年 10月 24日 nishio 「このデータ取得するのにSQLではこういう風に書けばいいんだけど、ActiveRecordでは一体どう書けばいいの？」 毎回この課題に悩まされています。 特に業務アプリの場合、とてつもなく複雑なSQLを投げる場合があります。 ものすごい数のテーブルをjoinして、existsで条件みて、union allして。。。 なんていう処理がでてくると、さすがにActiveRecordやDatamapperを使ってクエリを組み立てるのをあきらめて、直接SQLを書いてしまうことがあります。 でも、できればActiveRecordを使ってスマートにSQLを組み立てたいものです。 scopeで書いておけば、処理も使い回せますしね。 ということ
Rails ActiveRecord Relation (Arel), composition and Query Objects
Given User has_many :articles in Ruby on Rails you can write something like: User .first .articles .where(published: true) .where(tags: ['ruby']) This is possible thanks to ActiveRecord::Relation. This use to be separate project known as Arel but since Rails 3 it was adopted by Rails core (Rails Associations). In this article we will have a look on some of my favorite tricks in Arel / ActiveRecord
ActiveRecord and EXISTS() subqueries
Real world example: We have models Order and Payment. Orders have many payments, so client could try another form of payment if first try failed for whatever reason. class Order < ActiveRecord::Base has_many :payments end class Payment belongs_to :order scope :paid, -> { where(state: %W[authorized charged]) } end problem: How to fetch only “paid” orders? In this case, orders having at least one pa
ActiveRecordのarel_tableから作れる条件式まとめ - Qiita
$VERBOSE = true require "active_record" ActiveRecord::VERSION::STRING # => "6.0.0" ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:") ActiveRecord::Migration.verbose = false ActiveRecord::Schema.define do create_table :users do |t| end end class User < ActiveRecord::Base; end def _(v) v.to_sql.remove('"', "users.") end User.arel_table[:x].instance_eval do _ eq(nil) #
Arelでクエリを書くのはやめた方が良い5つの理由
はじめに：Arelって何？ みなさん、Arel（アレル）ってご存知ですか？ ArelはActive Recordの内部で使用されるSQL生成ライブラリです。 Railsのクエリの書き方をググると、ときどきArelを使った実装例が見つかるので、見たことがある、もしくは何度か使ったことがある、という人もいると思います。 Arelをよく知らない人のために、Arelの利用例をちょっと見てみましょう。 たとえば「コメント文中に、"ruby"が含まれるユーザープロフィールを検索したい」という場合、Rails標準のクエリインターフェースを使うと条件部分のSQLを文字列で書く必要があります。（PostgreSQL環境を想定） Profile.where( "profiles.comment ILIKE ?", "%ruby%" ).to_sql #=> SELECT "profiles".* # FROM
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to Create Postgres Indexes Concurrently in ActiveRecord Migrations
doruby.jp
Random "SELECT 1" query in all requests on rails