Heroku の基本的な本番レベルのデータベースは、400Mb のキャッシュを実装しています。私は 2 つの dyno を実行している本番サイトと、読み取りと書き込みがかなり重いワーカーを持っています。データベースが私のアプリのボトルネックです。
検索はデータベース全体で実行されるため、データベースへの書き込みは多くのクエリを無効にします。
私の質問は、9 ドルのスターターと 50 ドルの第 1 レベルの本番データベースの間で価格が大幅に跳ね上がっていることを考えると、移行によってパフォーマンスが大幅に向上する可能性があるでしょうか?
ここで「より速い」というのは奇妙な指標です。これは CPU のようなものを意味しますが、特に大量の書き込みを行っていない場合、CPU はデータベースの大きな要因とは限りません。Basic データベースのキャッシュは 0 MB です。すべてのクエリがディスクにヒットします。これと比較すると、400MB のキャッシュでも驚くほどに見えます。おおよそのデータセット サイズを調べます。一般的な経験則は、データセットがキャッシュに収まるようにすることです。Postgres はこのキャッシュ自体を管理し、最も参照されるデータを最適化します。
最終的に、Heroku Postgres は生のパフォーマンスを売りません。プロダクション層の利点は複数ありますが、いくつか例を挙げると、インメモリ キャッシュ、フォーク/フォローのサポート、500 の利用可能な接続、99.95% の予想稼働時間です。
実稼働層のプランにアップグレードするとパフォーマンスが向上することは間違いありませんが、データベースの使用方法に依存するため、「3 倍高速」または同等であると主張することはほぼ不可能です。
これは確かに急なステップです。問題は、ボトルネックがどれほど深刻かということです。40 ドルの追加費用がかかりますが、アプリが再びスムーズに動作するようになれば、収益も増える可能性があります。もちろん、他のホスティング サービスを検討することもできますが、個人的には Heroku が一番気に入っています (ただし、より安価なオプションが利用可能です)。その上、あなたはすでに Heroku に精通しています。Heroku devcenter には、さまざまな計画に関する詳細情報があります。
https://devcenter.heroku.com/articles/heroku-postgres-plans :
生産計画
非本番アプリケーション、または最小限のデータ ストレージ、パフォーマンス、または可用性の要件を持つアプリケーションは、行の要件に応じて、dev と basic の 2 つのスターター レベル プランのいずれかを選択できます。ただし、運用アプリケーション、または運用層データベース プランの機能を必要とするアプリには、選択できるさまざまなプランがあります。これらのプランは、主にメモリ内データ キャッシュのサイズによって異なります。
キャッシュサイズ
各運用層プランのキャッシュ サイズは、Postgres に割り当てられる RAM の合計量を構成します。各接続やその他のタスクを管理するために少量の RAM が使用されますが、Postgres はこの RAM のほとんどすべてをキャッシュに利用します。
Postgres は常にデータのキャッシュを管理します。つまり、書き込んだ行、作成したインデックス、および Postgres が保持するメタデータです。クエリに必要なデータがすべてそのキャッシュにある場合、パフォーマンスは非常に高速です。キャッシュされたデータから作成されたクエリは、多くの場合、完全なデータ セットから作成されたクエリよりも 100 ～ 1000 倍高速です。
よく設計された高性能の Web アプリケーションでは、クエリの 99% 以上がキャッシュから提供されます。
逆に、ディスクにフォールバックする必要がある場合は、少なくとも 1 桁遅くなります。さらに、大きなデータ型を持つ列 (大きなテキスト列など) は、TOAST を介してアウトオブラインに格納されるため、大量の TOAST データへのアクセスは遅くなる可能性があります。