読者です 読者をやめる 読者になる 読者になる

猫の魔法

主にruby系の技術メモを記載

個人的メモ:Rails AntiPatterns(18)

Chapter 9 Databases

  • railsはORMマッパーによって、DBの事を意識せずに済むように設計されているが、それでも気にしなければいけない点はある

AntiPattern: Messy Migrations

  • railsはmigrationによってDBへ直接変更を加えなくてもよくなっているが、時間が立つとこのmigration機能自体が厄介な問題を引き起こす可能性がある。

Solution: Never Modify the up Method on a Committed Migration

  • migrationはリモート環境で実行したら絶対に変更してはならない。
  • すでに配布されているmigrationスクリプトを変更すると、他の開発者とのバッティングを起こすだけでなく、DB自体の破壊につながる。
  • そのような自体にならないように、ローカルでよくmigrationを検証する必要がある。
  • その為にはdb:migrationだけでなく、db:migration:redoも実施し、問題が無いかを確認したほうが良い。
  • db:migration:redoはdownメソッドを実行した後にもう一度migrationを適用する
    • ★ネットで調べると、rollbackの代わりに使ってるみたいだが、本当にmigrationを再適用してるのか不明。あとで試す。
    • ★これの意図は一度downしてからもう一度upさせることで、双方のスクリプト正しく動くかをローカルdr確認できて安心という意図っぽい。

Solution: Never Use External Code in a Migrationの手前まで読了

関連

個人的メモ:Rails AntiPatterns(17)

Solution: Move Processing into Background Jobs

  • 処理時間がwebでの応答に不適切なくらい掛かる場合はcronやキューイングといった。バックグラウンドJobの仕組みを検討した方がいい

  • cronの場合スクリプトを別に作ってそれを動かす。

    • 例えば、テーブルのカウントをするのに毎回3分かかるような処理があるなら、事情が許すならcronで30分置きにカウントした結果を別のテーブルに格納する方がパフォーマンスの向上に繋がる。

    • cronは簡単だが、対象をcronスクリプト側で特定しなければならない。可能性であればキューイングを検討する方がいい

  • キューイングは画面からcsvをダウンロードする機能のような、バックグラウンドで纏まった処理をしなければならない物に向いている。

  • キューイングの機能としてはdelayed_jobとResqueが有名。

    • Redisを使っているのでなければdelayed_jobを使った方がいい。
      • Rails 4.2からはActive Jobがあるので、普通はそっちを使う。
  • キューイングやcronはは便利な機能だが、使い過ぎるとシステムが複雑になる。節度を持って使う事

    • ★ 関係ないが「exercise restraint」で「抑止力を働かす」というのが面白い

Chapter9 Databasesの手間まで読了

関連

個人的メモ:Rails AntiPatterns(一覧) - 猫の魔法

個人的メモ:Rails AntiPatterns(16)

忙し過ぎて時間が空いてしまった。

CHAPTER 8 Scaling and Deploying

AntiPattern: Painful Performance

  • 単純なパフォーマンスの問題を防ぐ為の事例を紹介する。

Solution: Don’t Do in Ruby What You Can Do in SQL

  • RubySQLで出来る事をやらせないようにする
  • レコードの総件数を求める方法は3つ考えられるが、どれも裏側の動きが異なる
@article.comments.count 
@article.comments.length
@article.comments.size
  • 一つ目の例は、DBのcount関数を実行する。
  • 二つ目の例は、lengthがActiveRecordの関連で無い為、すべてのレコードをDBから取得する
  • 三つ目の例はすでにレコードがロードされていればそれを使い、そうでない場合はDBのcountを使う。
  • ケースに応じて使い分ける事が重要。

  • SQLを上手く使えていないパターンとして以下の2パターンがある。

    • SQLで実現する方法を知っているがRubyで書いてしまう。
      • 例えば下記のような例(コードは抜粋)
@account = Account.find(3) 
@users = @account.users.sort { |a,b| a.name.downcase <=> b.name.downcase }.first(5)
  • 上記のコードよりも下のコードの方が、処理をよりDBに移譲できる為パフォーマンスを高められる
@users = @account.users.order('LCASE(name)').limit(5)
  • SQLで実現する方法を知らない為Rubyで書いてしまう。
    • 例えば下記のような例(コードは抜粋)
class User < ActiveRecord::Base
 has_many :comments has_many :articles, :through => :comments

 def collaborators 
   articles.collect { |a| a.users }.flatten.uniq.reject {|u| u == self } 
 end 
end
  • 上記よりも、下記の方がより処理をDBに任せる事が出来る。
    • このパターンはflattenを使うような処理になってしまっている場合に置き換えが出来る事が多い
    • ★?の部分は、順番に配列の第2,第3要素が入る。
class User < ActiveRecord::Base
 has_many :comments
 has_many :articles, :through => :comments
 
 def collaborators User.select("DISTINCT users.*").
        joins(:comments => [:user, {:article => :comments}]).
           where(["articles.id in ? AND users.id != ?", self.article_ids, self.id]) 
 end 
end

Solution: Move Processing into Background jobsの前まで読了。

関連

個人的メモ:Rails AntiPatterns(一覧) - 猫の魔法

個人的メモ:Rails AntiPatterns(15)

CHAPTER 8 Scaling and Deploying

AntiPattern: Sluggish SQL

Solution: Reassess Your Domain Model

  • 高度に正規化されたテーブルはテーブル間の結合によってパフォーマンスの問題を起こしやすい。
  • 単純に結合させるのではなく必要な要素をrails側で取得するようにするとパフォーマンスを改善する事が出来る。
    • ★UserがPrefとCityと関連がある場合、下記のように取る事で負荷が減らせる場合がある。
search_pref = Pref.find_by_name('Kanagawa') 
search_city = City.find_by_name('Yokohama')
User.where(pref: search_pref,city: search_city)
  • 大きなサイズのテーブルになる事が分かっているなら、テーブル自体非正規化した方がパフォーマンスを向上出来る。

AntiPattern:Painful Performanceの前まで読了。

関連

個人的メモ:Rails AntiPatterns(一覧) - 猫の魔法

個人的メモ:Rails AntiPatterns(14)

CHAPTER 8 Scaling and Deploying

AntiPattern: Sluggish SQL

  • パフォーマンス最もネックになるのはDB。indexの貼り方と副問い合わせを使った方がいいシチュエーション、ドメインモデルを使った方がいいシチュエーションを考える。

Solution: Add Indexes

  • 主キーは自動的にインデックスが貼られる
  • 外部キーについても基本は自動的にインデックスが貼られる。
  • 検索で複数のカラムを主キーとして扱うような場合は、複合indexを貼ることを検討する。

    • ★内容的には1対多の多側テーブルが他にも多側になる外部キー存在する場合の話をしているが、途中から複合indexの話に読めた。
  • uniqu識別子が付いているカラムにはインデックスをつけると早くなる。

  • STIを使ってる場合、typeカラムには継承先のクラス名が入る。このtypeにはインデックスを貼ったほうがいい。
    • STIは初めて知った。オブジェクトの継承関係をDBにもたす事で、継承元のcontrollerのみ書けばよくなる仕組みのよう*1
  • その他のカラムも検索とかで使用しているならインデックスを貼ってみるとよい。

    • ★後でも書いてあるが、インデックスを貼りまくるとupdateやinsertが極端に遅くなる。特にローが多いテーブルはインデックスの追加に慎重になった方がいいというのが個人的な考え。
  • 状態を管理するカラム、フラグ的なカラムも場合によってはインデックスを貼った方がいい。

    • ★普通インデックスはインデックスを貼るカラムの値がより離散していた方が効果が高い。なのでフラグカラムにインデックスを貼るとか正気かと思ったが、そのカラムが検索に使われていて、圧倒的に少ない方の値ならという話だった(それでも個人的にはSQL的にアンチパターンだと思うが)
  • created_atのような日付カラムもそれを使ってorder byをしていて且つwhere句に使ってるならインデックスを貼るといい
  • インデックスを貼りすぎるとupdateやinsertが遅くなる
  • どのカラムにindexをつけるかは、継続的に調査する必要がある。railsプラグインであるLimerick Rakeなどを使うか、DB自体の機能で遅いクエリを取得する機能を使うと良い。

Solution: Reassess Your Domain Modelの手前まで読了

### 関連

個人的メモ:Rails AntiPatterns(一覧) - 猫の魔法

個人的メモ:Rails AntiPatterns(13)

今日はあまり進まず。

CHAPTER 8 Scaling and Deploying

AntiPattern: Disappearing Assets

  • Capistranoなどのデプロイツールを使ってアプリをリリースする際にユーザの添付ファイルなど、関係ないファイルもデプロイ対象になる
  • Capisrranoの設定で回避出来る。

Solution: Make Use of the System Directory

  • CapistranoのsharedディレクトリはRAILS_ROOT/public/systemを向いているのでそこにファイルを配置すればよい。
    • ★意味が分かってない。そもそもCapistranoの2から3で大きな変更があったようなので今も通用する話なのか要調査。

AntiPattern: Sluggish SQLの手前まで読了

関連

個人的メモ:Rails AntiPatterns(一覧) - 猫の魔法

個人的メモ:Rails AntiPatterns(12)

CHAPTER 8 Scaling and Deploying

  • ソフト作った後保守にも非常に労力が掛かる。
  • この章ではスケーリングについての問題を考える

AntiPattern: Scaling Roadblocks

  • 不必要なスケーリングを考慮する必要はないが、簡単に出来る方法でスケーリングを確保する方法を考える

Solution: Build to Scale from the Start

  • データの保管は設定ファイルで簡単にスケーリング出来るよい例
  • 添付ファイル取り扱うPaperclipというプラグインは保存場所としてクラウドを設定出来る
  • linuxファイルシステムはその構造上32000までのファイルしか1つのディレクトリに入れられない(ext3の話。ext4や、xfsはこの上限に当たらない)
    • ファイル名の1文字をディレクトリに当てることで上記の制約回避出来る。これはPaperclipの設定で設定する事が出来る。(例: 0901というファイルなら0/9/0/の下に1というファイルを作る)
      • ディレクトリ毎に保存するストレージを変えることでスケーラビリティ確保できる。

AntiPattern: Disappearing Assetsの手前まで読了

関連

個人的メモ:Rails AntiPatterns(一覧) - 猫の魔法