Heroku でホストされている PostgreSQL データベースにシリアル化された YAML 構成を解析する必要があります。
必要なデータを含むテーブルには、現時点で約 250 万行ありますが、かなり急速にサイズが大きくなる可能性があります。
YAML-Data 自体には、いくつかのハッシュといくつかの小さな配列を含む単純な構成データのみが含まれています。
これも heroku でホストされる Rails アプリ内から、可能な限り最速の方法で YAML データを取得できる必要があります。データを取得する最良の方法は何ですか?
データベースを走査し、その場で YAML データをデシリアライズするだけで十分でしょうか? それとも、逆シリアル化された構成データを格納する新しいテーブルを作成する必要がありますか? また、PostgreSQL はこの種のタスクに対して十分に高速でしょうか、それとも別のデータベースを調べる必要がありますか? 例えばnosql？
わお。まず、PostgreSQLは非常に高速なリレーショナルデータベースです。しかし、YAMLをテキストとしてデータベースに保存することに何の問題もありませんが、実際に行っているのは（私が思うに）構造化データ（YAML）を単一のフィールドに保存することです。データが定期的に構造化されている場合、つまりほとんどの場合、同じフィールドと値が含まれている場合は、構造化データとしてリレーショナルデータベースに保存する必要があります。それが大まかに構造化されたデータである場合、キー値ストアメカニズム（ある種のNoSQLデータベース、またはそれに関してはファイルシステム）は確かに検討する価値があるかもしれません。
データベースをトラバースし、レコードのセット全体（すべて2.5Mで増加している）を逆シリアル化する場合は、それらをすでにメモリに保存しているので、（Railsでサポートされているキャッシュストアの1つ）のようなツールがmemcached良い解決策になる可能性があります。PostgreSQLは、データを格納するのにおそらく問題ありません。ただし、データが巨大でない限り、最近では250万レコードはそれほど多くありません。また、全表スキャンを実行しても、制限要因にはならない可能性が高くなります。CPUの可能性が高くなります。 YAMLをルビーハッシュ/配列に逆シリアル化するヒット。
しかし、本当に一度にすべての250万以上のレコードがメモリに必要ですか？必要に応じてフェッチしてみませんか？「可能な限り最速の方法」と言うとき、答えは何が速くなければならないかによって異なります。アプリが読み込まれるまで数秒待ってから、そこから自分でデータを管理する場合（おそらく、変更が発生したときに変更を保存し、ロックや同時実行性などを処理します）、そうです、メモリは行く。メモリ内で最も頻繁に使用される2500のレコードが本当に必要な場合は、標準の遅延ロードキャッシング戦略の管理が非常に簡単になる可能性があります。
実装に関しては、かなり一般的なアーキテクチャと設計の質問をしていると思います。私や他の誰かが、あなたの制約が何であるか、何であるか、そして何であるかについてのより完全な説明なしに決定的な答えを提供できるとは思いません。質問を編集して、より多くのコンテキストと詳細を提供してください。おそらく、より具体的な回答を得ることができるでしょう。