4

redis を使用して、Web アプリケーションのソーシャル ストリームと通知システムを実装しています。私はredisが初めてで、ハッシュとその効率について疑問があります。

この素晴らしいInstagram の投稿を読み 、ストレージを最小限に抑えるために同様のソリューションを実装することを計画しました。

彼らのブログで述べたように、彼らはこれが好きでした

ハッシュ タイプを利用するために、すべてのメディア ID を 1000 のバケットにバケット化します (ID を取得し、1000 で割り、残りを破棄するだけです)。これにより、どのキーに陥るかが決まります。次に、そのキーに存在するハッシュ内で、メディア ID はハッシュ内のルックアップ キーであり、ユーザー ID は値です。たとえば、メディア ID が 1155315 の場合、これはバケット 1155 (1155315 / 1000 = 1155) に分類されることを意味します。

HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
> "939"

そのため、1000 個の個別のキーを持つ代わりに、1000 個のルックアップ キーを持つ 1 つのハッシュに格納しています。私が疑問に思っているのは、ルックアップ キーの値をさらに大きくできない理由です。

例： Media ID of 1155315 will fall into mediabucket:115 by dividing it by 10000 またはそれ以上。

なぜ彼らは 1000 個のルックアップ キーを持つ 1 つのハッシュ バケットで解決するのですか。100000 個のルックアップ キーを持つ 1 つのハッシュ バケットを持つことができないのはなぜですか。それは効率に関係していますか？

私の Web アプリケーションに効率的な方法を実装するための提案が必要です。

PSお願いします！stackoverflow は提案を求めるためのものではないとは言わないでください。また、どこにヘルプがあるのか​​もわかりません。

ありがとう！

4

2 に答える 2

6

はい、それは効率に関連しています。

Redis のコア開発者の 1 人であり、いつも助けてくれる Pieter Noordhuis に意見を求めると、彼は Redis ハッシュを使用することを提案しました。Redis のハッシュは、メモリ内で非常に効率的にエンコードできる辞書です。Redis 設定 'hash-zipmap-max-entries' は、ハッシュが効率的にエンコードされている間に保持できるエントリの最大数を構成します。この設定は 1000 前後が最適であることがわかりました。これ以上高くすると、HSET コマンドによって顕著な CPU アクティビティが発生します。詳細については、zipmap ソース ファイルを参照してください。

小さなハッシュは特別な方法 (zipmap) でエンコードされます。これはメモリ効率が良いですが、操作は O(1) ではなく O(N) になります。したがって、1k フィールドの 100 個の zipmap の代わりに 100k フィールドの 1 つの zipmap を使用すると、メモリの利点は得られませんが、すべての操作は 100 倍遅くなります。

于 2012-07-01T12:18:00.870 に答える
2

基本的に、彼らは 1 つのハッシュに格納される値の数が 1000 を超えないようにしたいと考えています。おそらく、彼らはこの数 (thy set hash-zipmap-max-entries) で適切に機能するように Redis インスタンス構成をセットアップしました。

ハッシュが指定された要素数または要素サイズを超えるたびに、実際のハッシュ テーブルに変換され、メモリの節約が失われます。

-- http://redis.io/topics/memory-optimization

私が理解しているように、あなたの質問は「なぜ正確に1000で、それ以上ではないのですか?」です。それは、スペース効率と速度のどちらかを選択しなければならなかったからです。スペース効率の高い表現には、通常のハッシュとは異なりO(N)、操作が複雑です。N 倍遅くなりますが、必要なメモリは少なくなります。O(1)

彼らはさまざまな値をテストし、1000 が適切な妥協案であることがわかりました。多くのスペースを必要とせず、それでも十分に高速です。

于 2012-07-01T12:22:56.920 に答える