3

Little Book of Redisでは、ユーザーIDをメールアドレスで検索して、ユーザーハッシュをユーザーIDで検索し、完全なユーザーオブジェクトを取得する方法について説明しています。これは事実上、電子メールアドレスによるユーザーのインデックスです。次のような新しいユーザーを挿入するたびに、ルックアップハッシュに追加する必要があります。

set users:9001 "{id: 9001, email: leto@dune.gov, ...}"
hset users:lookup:email leto@dune.gov 9001

この操作には、必要な電子メールフィールドの値を引き出すためにRedisが実行する必要のあるハッシュ内の非表示のルックアップが含まれているようです。何千ものメールフィールドが存在する可能性があり、そのうちの1つだけを求めています。

このようにインデックスキーでメールを使用するのはどうですか？

set users:9001 "{id: 9001, email: leto@dune.gov, ...}"
set users:lookup:email:leto@dune.gov 9001

これはRedisのLittleBookで提案されていないため、ベストプラクティスではないと思います。

最初の方法が優れている理由を誰かが説明できますか？それらは事実上同じですか？

ありがとう、私はRedisを学んでいます。

4

1 に答える 1

5

私が見ているように、それぞれの方法には独自の長所と短所があります。

ハッシュメソッド：

  • すべての電子メール（キー）またはID（値）のリストをかなり迅速に取得できます（O（N）、ここでNはマップ内のエントリの数です）
  • エントリの数が少ない場合は、メモリ効率が非常に高くなります（ただし、実際のユースケースには適用できない可能性があります）。
  • エントリは2^32-1に制限されています（地球上の大多数の人々がアプリケーションを使用することを計画していない限り、ここでも問題にはならない可能性があります）
  • redisは1つではなく2つのO（1）ルックアップを実行する必要があるため、少し遅くなります...わずかな違い（目立つ場合）。
  • それらはすべて同じredisインスタンスにあるため、シャードフレンドリーではありません。

重要な方法：

  • エントリー数に制限はありません
  • それがなるのと同じくらい速く
  • を使用してすべてのユーザーのリストを取得することのみが可能ですKEY。これはO（n）です（データベース内の各エントリに対して-ライブ環境では大したことはありません）
  • シャードフレンドリー

これらは私が考えることができるすべての違いです。何らかの理由ですべてのユーザーを一覧表示する必要がない限り、キーメソッドに傾倒する傾向があります。これは、より単純で、シャーディングを使用すると拡張性が向上するためです。

余談ですが、フィールドをハッシュに格納する方がメモリ効率が高い可能性があるため、回避できる場合は、JSONデータをユーザーデータとして格納しない可能性があります。また、ブロブ全体ではなく、特定のポイントが本当に必要なフィールドを取得して設定することもできます。トランザクションなしでアトミックにハッシュをインクリメントすることも可能であり、これは便利です。しかし、それはすべてデータに依存します...大きなネストされた構造がある場合は、多数の異なるネイティブ構造を作成してそれらをリンクするよりも、シリアル化してそこにスローする方が簡単な場合があります。

于 2013-03-13T22:21:47.240 に答える