Ruby
 Computer >> コンピューター >  >> プログラミング >> Ruby

Rails でソリッド キャッシュをマスターする:高度なキャッシュ戦略でパフォーマンスを向上させる

キャッシュの概念はコンピューター サイエンスにおいて重要な概念であり、Web アプリの構築に直接関連しています。大まかに言えば、キャッシュは、メモリ ルックアップがデータベース クエリよりも高速で、計算量が少ないという事実を利用します。繰り返し実行される可能性のあるデータベース クエリがある場合、結果をキャッシュにキャッシュすると、その実行フローが高速化されます。 Rails アプリケーションも例外ではなく、Redis などのメモリベースのキャッシュを使用してデータをキャッシュし、アプリケーションのパフォーマンスを向上させることがよくあります。

Rails でソリッド キャッシュをマスターする:高度なキャッシュ戦略でパフォーマンスを向上させる

データベース キャッシュを使用するという考えは非生産的に聞こえるかもしれません。それでも、Rails の Solid Cache のような低速のデータベース ベースのキャッシュを使用すると、直感に反してアプリケーションの速度が向上する可能性があります。これは、より安価なストレージにより、より多くのものを長期間キャッシュできるためです。 Rails 7.1 では、Solid Cache が導入され、データベースを利用したアプリケーション キャッシュが Rails アプリケーションにとって便利なオプションになりました。

Rails キャッシュの仕組み

Ruby on Rails でのキャッシュは、アプリケーションのパフォーマンスを最適化するための重要な部分です。開発者がパフォーマンスを向上させるために使用できるキャッシュには、ページ キャッシュ、アクション キャッシュ、フラグメント キャッシュ、低レベル キャッシュ、SQL キャッシュなど、いくつかの種類があります。この記事では、低レベルのキャッシュについて主に説明します。低レベルのキャッシュは簡単で、構成可能な cache_store と互換性があるためです。 .

Rails フレームワークの大きな部分である ActiveSupport を使用すると、cache_store 経由でキャッシュを操作し、設定することができます。 。 config/environments/ で 、cache_store の選択など、さまざまな構成で各環境名を持つファイルがあります。

cache_store 値の設定

Redis は非常に人気のあるキャッシュ ストアであり、業界全体で広く採用されています。アプリケーションが運用環境でキャッシュに Redis を使用している場合、config/environments/production.rb に Ruby の次の行が表示されます。 :

config.cache_store = :redis_cache_store

Redis が使用されるのは、これがメモリ キャッシュであり、メモリは従来、ディスク アクセスやデータベース クエリよりも読み取りアクセス時間がはるかに速いためです。

Rails でのデータベース クエリのキャッシュ

低レベルのキャッシュを使用して、頻繁に変更されないデータを返す高価なデータベース クエリの結果を保存している可能性があります。次のようになります:

Rails.cache.fetch("courses", expires_in: 12.hours) do
 Courses.all
end

Redis をキャッシュ ストアとして使用している場合、このコードはまずキー「courses」に過去 12 時間の値があるかどうかを確認します。存在する場合、コード ブロックは実行されずにその値が返されます。キャッシュにその値がない場合、それは「キャッシュミス」と呼ばれます。キャッシュ ミスが発生すると、インタープリターがブロックを実行し、結果をキャッシュに保存してから結果を返します。

Rails Solid Cache とは何ですか?

上で説明したキャッシュ パターンでは、メモリ アクセスが API 呼び出しやデータベース クエリなどよりも高速であるため、パフォーマンス上の利点が得られます。ただしメモリは高価です。 、したがって制限されます。メモリには限りがあるため、キャッシュに保存する内容とその期間を最小限に抑える必要があります。キャッシュ内のメモリがすぐに不足してしまうため、すべてを無期限にキャッシュすることはできません。キャッシュによるパフォーマンス上の利点はすべてトレードオフによって決まります。時間のかかるタスクを繰り返す必要がないように、一部の内容をしばらくの間キャッシュします。

Rails 7.1 リリースには、ActiveRecord::Cache::Store のオプションである Solid Cache が付属していました。 キャッシュ ストアに SQL データベースを使用します。キャッシュからの各読み取りは遅くなりますが、技術の進歩と多くのデータベースの組み込みメモリ キャッシュのおかげで、この差は依然として有益です。

SQL データベースをキャッシュ ストアとして使用すると、さらに低コストで何倍ものストレージが得られ、アプリケーションでさらに多くのデータを長期間キャッシュできるようになります。 Basecamp チームは、直感に反するように思えるかもしれませんが、これによってアプリケーションがどのように高速化されたかについて記事を書きました。

Solid Cache を使用する必要があるのはどのような場合ですか?

Redis のようなメモリ キャッシュは通常、キャッシュからの読み取りを高速化しますが、Solid Cache はいくつかのシナリオでこれらのオプションに代わる優れた代替手段を提供します。

アプリケーションで大量のデータをキャッシュする必要がある場合、メモリにデータを保存すると、法外なコストがかかる可能性があります。 Solid Cache を使用すると、わずかなコストではるかに大きなキャッシュ サイズを実現できます。

アプリケーションが数ミリ秒のキャッシュ取得時間の追加にそれほど敏感でない場合、Solid Cache はパフォーマンスとコストの優れたバランスを提供します。レイテンシーの増加の可能性を許容できるのであれば、ソリッド キャッシュは良い解決策です。

これとは別に、個別の Redis インスタンスの管理が現実的でないセットアップでは、Solid Cache を使用すると、Redis をサポートする必要がなく、既存のデータベースでキャッシュを処理できるようになり、デプロイメントが簡素化されます。

ソリッド キャッシュのインストール

Solid Cache Readme には、Solid Cache を Rails アプリケーションに導入するための役立つ手順が記載されています。まず、Gemfile に gem を追加します。

gem "solid_cache"

次に、Bundler を使用してインストールします。

bundle install

次に、データベースが Solid Cache で動作するように移行を追加します。次のコマンドを実行します。

bin/rails solid_cache:install:migrations

最後に、生成された移行を実行します。

bin/rails db:migrate

Rails アプリでの Solid Cache の実装

Solid Cache を既存のキャッシュと交換するのは通常は簡単です。環境設定内 (config/environments/production.rb など) cache_store を変更します。 次のように設定します:

config.cache_store = :solid_cache_store

Solid Cache をキャッシュ ストアとして使用し始めるために必要なのはこれだけです。他のすべての ActiveSupport::Cache::Store をサポートします。 構成オプションと、データベース シャーディングやその他の固有のニーズをサポートするための追加オプション。

これは本番環境のキャッシュ ストアのみを変更するため、他の環境でテストする場合は、そこでの値も変更する必要があることに注意してください。

Rails の Solid Cache に切り替えますか?

Rails 7.1 での Solid Cache の導入は、Rails キャッシュ戦略の世界に大きな発展をもたらしました。このソリューションは、アプリケーションのパフォーマンスの最適化に関する新しい視点を提供し、Redis のようなメモリベースのキャッシュに対する従来の好みに挑戦します。

SQL データベースをキャッシュに利用することで、Solid Cache はアプリケーションがより大量のデータを長期間保存できるようになり、メモリ ストレージのコストと容量による制限を克服できます。このアプローチにより、効果的にキャッシュできる量が増えるだけでなく、さらに大きなパフォーマンス上のメリットが得られる可能性もあります。

ただし、切り替えるかどうかはアプリケーションの特定のニーズによって異なります。アプリケーションが高速キャッシュから大きなメリットを得ており、Redis をサポートするインフラストラクチャがある場合は、Solid Cache は必要ない可能性があります。ただし、スタックに別のサービスを追加せずに大量のデータをキャッシュするコスト効率の高い方法を探している場合は、Solid Cache を検討する価値があるかもしれません。 Redis をサポートする必要を避けたいだけの場合でも、アプリには Solid Cache で十分すぎる可能性があります。

この記事を気に入っていただけた場合は、Honeybadger ニュースレターに登録すると、このような Ruby と Rails の記事がさらに受信箱に届きます。


  1. Ruby 4.0:主な機能、リリースのハイライト、およびアップグレード ガイド

    Ruby 4.0 はメジャー リリースであり、大きな互換性を破る変更によるものではなく、コミュニティの 30 周年を記念して Ruby 30 周年 (2025 年 12 月 25 日) にリリースされました。 Ruby が実際にはセマンティック バージョニングに従っていないことを知って驚きました! 代わりに、Matz (Ruby の作成者) は、変更に感銘を受けるとメジャー バージョンを増やします。このバージョンは Ruby の 30 周年を記念し、言語を拡張する機能を導入しています。 Ruby 4 にアップグレードする Rubyist にとって良いニュースは、アップグレードが比較的

  2. Pryでの例外の処理

    あなたが私のようなら、あなたはRailsコンソールをよく使います。そして今では、PryがRailsコンソールに起こる最良のことであることに誰もが同意していると思います...まあ、これまで。 組み込みのこじ開けは、昔ながらのIRBに比べて、例外を除いて作業をはるかに簡単にするいくつかの非常に優れた機能です。 完全なバックトレースを表示 Pry(またはそのことについてはIRB)で例外が発生すると、バックトレースの短縮バージョンが表示されます。通常はこれで十分ですが、常にそうとは限りません。 pryでは、wtf -vコマンドを使用して、最新の例外の完全なバックトレースを確認できます。 -vフラ