こんにちは。 id:Pocke です。 今日は activerecord-originator という gem を作ったので紹介します。 github.com なにこれ Active Record が発行するSQLの各部分に、それがどこで作られたものかをコメントとして入れ込む gem です。 理解するには実例を見るのが早いでしょう。次のログはArticlesController#indexで実行されるクエリの例です。 Article Load (0.1ms) SELECT "articles".* FROM "articles" WHERE "articles"."status" = ? /* app/models/article.rb:3:in `published' */ AND "articles"."category_id" = ? /* app/controllers/artic
こんにちは、バックエンドエンジニアのjoeです。主にAPIを担当しています。 VASILYのAPIでは、速度向上のためにModelオブジェクトをキャッシュしています。 最近、Modelキャッシュの仕組みを実装したので、その実装方法を紹介します。また、既存ライブラリとの比較についても書きたいと思います。 Modelキャッシュとは Modelキャッシュを簡単に言うと、下記の結果をキャッシュすることです。 > Item.find(1) => #<Item:0x007fdfe398a678> このように、1レコード単位のActiveRecordをキャッシュすることを本記事ではModelキャッシュと呼びます。ActiveRecordをキャッシュすることで、データベースへの読み込み回数を減らし、レスポンス速度を向上させることができます。 既存ライブラリの紹介と問題点 Modelキャッシュを実現できるG
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Prefer returning chainable ActiveRecord objects | Boring Rails: Skip the bullshit and ship fast 原文公開日: 2021/03/18 著者: Matt Swanson サイト: Boring Rails Active Recordで優秀な点のひとつは、クエリインターフェイスが以下のようにチェイン可能（chainable）である点です。 Post.includes(:comments) .where(published: true) .where(author: Current.user) .order(:name) この強みを活用してコードを柔軟にするために、データにクエリをかけるときは常にチェイン可能なオブジェクトを返すようにしましょう
Rails Developers Meetup 2018で「ActiveRecordデータ処理アンチパターン」というタイトルで発表してきました。 発表資料発表概要ActiveRecordはWebエンジニア達が嫌う（？）SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。 本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。 ※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。 事前に公開したエントリ発表資料に出てくる最初の事例はこちらがベースの事例となっています。 今月末のR
tl;dr Railsではコネクションプール数を設定していても、1スレッド辺り1コネクションしか持ちません。 発端 アカツキではRails + Unicorn + Nginx + MySQLの構成をAWSで運用しており、c3.4xlargeのインスタンス上で1台辺り64のUnicornワーカープロセスが実行される設定になっています。 ソーシャルゲームでは時にたくさんのアプリケーションサーバを並列稼働される必要がでてきます。特に年末年始の時期は平時の2-3倍のトラフィックが予想され、アプリケーションサーバを最大100台で稼働させる必要がありました。 Railsのdatabase.ymlのpool設定は5だったので、単純に考えると最大 100台 * 64プロセス * 5接続 = 32,000個の接続が常時貼られるのでは？MySQLのmax_connectionsの設定は大丈夫か？という議論があ
Active Record に like がない理由を見つけたのでメモっとく。 Rails 4 で not が追加されたとき like と not_like も追加される予定だった。実際のところコミットされた後にロールバックされた。 そのロールバックに対してのコメントが紛糾したわけだが、DHH がロールバックした理由を4つあげている。 Here are the design considerations that I had when we decided to roll this back: 1) It's an odd mismatch of SQL and Ruby with the % sign for designating the order. 2) It opens the door for wanting to expand this line of DSL further
MySQL 5.6からTIME, DATETIME, TIMESTAMPがマイクロ秒精度をサポートしました。 MySQL 5.6 Reference Manual :: 11.3.6 Fractional Seconds in Time Values で、ドキュメントにはちゃんとroundされるけどこれはSQL標準に従う挙動だからエラーとかワーニングは出ないよってさらっと書いてあるんですが、5.5では小数点以下は切り捨てだったんでマイクロ秒を付けてクエリ投げてた場合ハマりポイントになってます。 MySQL Bugs: #68760: Datetime rounding problem ActiveRecordにおけるDATETIMEのマイクロ秒サポート ここからはジョーカーさんのRails-4.2+MySQL-5.6での時刻オブジェクトのミリ秒の扱いについてへのアンサーエントリになるんです
MySQLは5.6系から時刻系のデータ型がミリ秒を持てるようになった。 やっとかよって感じですが。 最近持てるようになったので、Railsでは4.1まではMySQLに対してクエリを投げる時はミリ秒以下は問答無用で切り捨ててクエリを構築していた。 しかし、4.2betaが出る辺りで、MySQLにミリ秒対応のクエリを送るPRがマージされた。 MySQL 5.6 Fractional Seconds by arthurnn · Pull Request #14359 · rails/rails 既にMySQL側のカラムがミリ秒精度を持っている場合は特に問題は起きない。 けど、RailsでMySQL使っててRailsのバージョン上げようかって時に、そんなことはほぼ無いだろうと思う。 その場合、ちょっと面倒なことになる。 MySQL5.6がミリ秒以下の値を受け取った場合、精度が足りない部分は四捨五入
Rails 4.0からActiveRecordにstrict_modeが導入され、デフォルトでは接続時にsql_mode = STRICT_ALL_TABLESをセットするようになりました。 これは、既に運用されているDBに接続する等なんらかの理由でMySQL側で適切な設定が行えていない場合有用な動作ですが、そうでない場合、サーバー側の設定を鑑みずにクライアント側が設定を上書きするべきではないでしょう。 そのため、database.ymlでstrict: falseと設定することでこの動作を無効にすることができましたが、Rails 4.2.0ではこの動作が変更され、strict: falseのときはstrictでない状態にするためsql_mode = ''をセットするようになりました。 MySQLのデフォルトのsql_modeに依存して既に通っていたはずのテストが通らなかったりすることがあ
インフラストラクチャー部の成田（@mirakui）です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか？ ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC
TL;DR: AdequateRecord is a set of patches that adds cache stuff to make ActiveRecord 2x faster I’ve been working on speeding up Active Record, and I’d like to share what I’ve been working on! First, here is a graph: This graph shows the number of times you can call Model.find(id) and Model.find_by_name(name) per second on each stable branch of Rails. Since it is “iterations per second”, a higher v
2010年06月25日00:18 Ruby ActiveRecordのソースコードを読む ハマったのがきっかけで ActiveRecord 2.3.5 のソースコードを少し読んだので簡単にまとめてみます。なお、ActiveRecord では 2.2 からコネクションプーリングが導入されています。 コネクションプーリングとは？ データベースにアクセスする時、アクセスのたびに接続(コネクション)を確立するのではなく、あらかじめ一定数のコネクションを確立しておき、それを使い回す手法。データベースアクセスの負荷を減らすために用いられる。 それを踏まえつつ、検索をする場合の処理を追っていきます。例えば Hoge.find(:all, ...) とかしたらどうなるんでしょうか。 あ、その前に ActiveRecord 使うときって establish_connection が必ず呼ばれます。Rails
サーバを使ったiPhoneアプリを作りたかったので、簡単にサーバ側作れないか調べてみました。結論として結構簡単に出来る事が分かったのでメモメモ。 参考にした記事 Sinatra＋ActiveRecord＋SQLite3で，軽量なWeb-DB連携例 | tamo's blog 大分参考にさせて頂きました。ありがとうございます！ 仕事ではMySQLを使う事が多いので、SQLite3ではなくMySQLを使う事にしました。 手順 Ruby,MySQLをインストール データベースを作成 Gemfileを作成とインストール database.ymlを作成 Rubyファイルを作成 実行 動作確認 1. Ruby,MySQLをインストール 結構な量になったので別記事にまとめました。ここが一番面倒(´Д｀) - Ruby,MySQLの環境を構築する(Mac版) #MySQL #Mac #Ruby #home
行ロックとは 行ロックとは、テーブルの同一レコードに対して、複数同時に更新できないように制限する仕組みのことです。 Ruby on RailsのActiveRecordには２種類のロック方法があります。 楽観的ロック（Rails依存） 悲観的ロック（DBMS依存） それぞれの違いや使い方について解説していきたいと思います。 楽観的ロック 楽観的ロックとは、DBMSの機能に頼らずロックバージョンをレコードに保存しておくことで、取得時と変更時にロックバージョンに変更がないか確認し、変更があった場合は例外を発生させる方法です。 ロックするタイミング データ更新時 データを複数同時に取得することができるが、途中で更新されていた場合は、更新できない 仕組み テーブルにlock_versionフィールドを追加する lock_versionが書き換わっていたらActiveRecord::StaleObj
Continuing exploring ActiveRecord without Rails, I thought I’d look into using Migrations without Rails. Once again, why? You already are using ActiveRecord without Rails Versionable instances of how your database looked like Database agnostic You forget how to crack out SQL code (happens to me, maybe too much ORM) You want migrations in non Ruby Projects boredom One thing I’d like to emphasize is
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
