8

350 万のレコード (読み取り専用) が実際に MySQL DB に格納されており、パフォーマンス上の理由から Redis に引き出したいと考えています。実際、私はこのようなものを Redis に保存することができました:

1 {"type":"Country","slug":"albania","name_fr":"Albanie","name_en":"Albania"}
2 {"type":"Country","slug":"armenia","name_fr":"Arménie","name_en":"Armenia"}
...

ここで使用するキーは従来の MySQL ID です。そのため、Ruby の接着剤を使用して、この既存のアプリで壊れるものをできるだけ少なくすることができます (これは深刻な問題です)。

問題は、値の部分で「アルメニア」というキーワードで検索を実行する必要がある場合です。2つの方法しかないようです：

Redis インデックスを乗算するか:

  • id => JSON 値 (上記参照)
  • slug => id (基本的な検索トリックを実行できる、スラッグに基づく逆インデックス)
  • 最後に、この投稿に示すように、オートコンプリート専用の別の巨大なインデックス: http://oldblog.antirez.com/post/autocomplete-with-redis.html

私はsunspotか全文検索エンジンのどちらかを使っています(残念ながら、実際にはMySQLと結びつきが強すぎるThinkingSphinxを使っています:-(

それで、あなたは何をしますか？単一のテーブルを MySQL から Redis に移行することは良い考えだと思いますか? これらの巨大な Redis キー/値が 16GB RAM サーバーで使用できるメモリ フットプリントが心配です。

同様の Redis の使用法に関するフィードバックはありますか?

4

3 に答える 3

2

これがRedisに関する私の見解です。基本的には、最近使用されていないデータ (LRU) のみを格納するように構成できるメモリ内キャッシュと考えています。これは、私のユースケースで果たすために私が作成した役割であり、そのロジックは、ユースケースについて考えるのに役立つ可能性があります.

現在、Redisを使用して、別のDBのデータに裏打ちされた、いくつかの複雑なクエリ(遅い)に基づいて検索エンジンの結果をキャッシュしています(あなたのケースと同様)。そのため、Redis はクエリに応答するためのキャッシュ ストレージとして機能します。すべてのクエリは、Redis でデータが提供されるか、Redis でキャッシュ ミスの場合は DB で提供されます。したがって、Redis は DB を置き換えるのではなく、私の場合はキャッシュを介した単なる拡張であることに注意してください。Redis の追加は将来のスケーラビリティを支援するはずだったので、これは私の特定のユース ケースに適合します。アイデアは、最近のデータへの繰り返しアクセス (私の場合、ユーザーが繰り返しクエリを実行した場合) を Redis で処理し、DB の負荷を軽減できるというものです。

基本的に、私の Redis スキーマは、上で概説したインデックスの複製のように見えました。セットと sortedSets を使用して、redis キーの「バッチ / セット」を作成しました。それぞれが、特定の redis キーの下に格納された特定のクエリ結果を指していました。DB には、まだ完全なデータ セットとインデックスがありました。

データ セットが RAM に収まる場合は、「テーブル ダンプ」を Redis に実行して、MySQL の必要性を取り除くことができます。この「テーブル」が将来的に拡大する場合、永続的な Redis ストレージを計画し、データの成長の可能性を計画している限り、これが機能することがわかります。

したがって、実際のユースケースとRedisがスタックにどのように適合するか、およびDBが提供する負荷に応じて、上記で概説したオプションの両方を実行する必要がある可能性を排除しないでください(私の場合)。

お役に立てれば！

于 2013-06-16T20:56:29.170 に答える