Redis のキー値の設計に問題がありますか?

WBOY
リリース: 2016-07-06 13:51:16
オリジナル
949 人が閲覧しました

初心者として、私は最近 Redis キャッシュについて学びました。そして、私の心の中に質問があります:
ユーザー関連の情報を保存するためのユーザー テーブルが mysql にあるとします。テーブルの主なフィールドは、id、ユーザー名、パスワードです。 、電子メール、ニックネーム、生まれ、性別、ステータスなど。今度は、ユーザーデータテーブル内のすべてのデータを Redis データベースサーバーにキャッシュしたいのですが、Redis のキー値はどのように設定すればよいでしょうか。
は次のように設定されます:

リーリー

または、次の形式で設定する必要があります:

リーリー

これら 2 つの形式のうちどちらが優れていますか?どちらがより多くのメモリを節約できますか?
女性の皆様が私の質問に答えていただければ幸いです、ありがとうございます =.=

返信内容:

初心者として、私は最近 Redis キャッシュについて学びました。そして、私の心の中に質問があります:
ユーザー関連の情報を保存するためのユーザー テーブルが mysql にあるとします。テーブルの主なフィールドは、id、ユーザー名、パスワードです。 、電子メール、ニックネーム、生まれ、性別、ステータスなど。今度は、ユーザーデータテーブル内のすべてのデータを Redis データベースサーバーにキャッシュしたいのですが、Redis のキー値はどのように設定すればよいでしょうか。
は次のように設定されます:

リーリー

または、次の形式で設定する必要があります:

リーリー

これら 2 つの形式のうちどちらが優れていますか?どちらがより多くのメモリを節約できますか?
女性の皆様が私の質問に答えていただければ幸いです、ありがとうございます =.=

ハッシュを保存するには、ユーザー ID にプレフィックスを追加して、それをキーとして設定します。
ハッシュ セットには、一般的に使用されるユーザー属性が保存されます。何も考えずにキャッシュするのはちょっと本末転倒です (私にとって何の役に立つのでしょう←_←)... ホット統計を使用して単純なホット ユーザー キャッシュを作成してみてください。

それが機能しない場合は、ハッシュにタイムアウトを設定してください。各ユーザーの情報は、初回ログイン後の一定期間保存されます。これにより、手間が省けます...

さまざまなデータ型とメモリの関係について勉強したことがありません

ビジネス ロジックの観点から、ストレージをどのように設計するかはニーズによって異なります
たとえば、キャッシュはクエリの利便性と情報表示のためだけに使用され、2 番目のオプションを選択し、mysql またはmongodb には関連する操作があります。対応するキャッシュを更新します。ログイン、データ CURD などのロジックを割り当てる必要がある場合は、上記と同じで、String 型の代わりに HMSET などのハッシュを使用することをお勧めします。

最初のものの方が良いです。コーディングせずに特定のものを見つけることができます

個人的には、前者の方が良いと思います。後者の場合、単一の属性を取得または変更するたびにすべてを取得し、他の属性を取得するには json を解析する必要があります。シリアル化および逆シリアル化フォームには追加のコストがかかります。

ほとんどの場合、クエリはすべてのフィールドをクエリする必要はありません。変更される場合、ほとんどの場合は 1 つのフィールドのみが変更されます。

データ テーブルのキャッシュの問題にも遭遇しました。私の解決策は、タスクを完了するために複数のデータ型を使用することです。
まず各データレコードを辞書に保存し、テーブル名+IDを使用して、それを辞書の名前としてMD5で暗号化します

次に、順序付きセットを使用して辞書名と各レコードのソート重みを保存します(ここにはソート要件があります、したがって、順序付きセットを使用します。それ以外の場合は、セットまたはリストを使用できます)

追記: Redis ではクエリなどの操作を実行できないため、必要に応じてコード レベルでフィルターしてから、カテゴリごとにデータを Redis に保存できます。たとえば、データをフィルターして、いくつかの異なる順序付きコレクションに保存します。そして、これらの順序付きセットの名前をリストに保持します


後者。

操作が簡単で、底なし穴現象を回避します。

キャッシュ底なし沼現象


json を使用しないでください。値を取得するのは便利そうですが、キャッシュされたデータが複数の場所で同時に更新されると、説明がつきません。プログラムを書くことに便利も不便もなく、ただ書いたものが信頼できないだけです。

すべてをキャッシュする必要はありません。たとえば、性別は頻繁にアクセスされるものだけをキャッシュする必要があります。

Redis で JSON を使用する方法。 。不可能なわけではなく、redis の価値が十分に活用されていないだけです。

ハッシュ構造を使用します。 2 番目のオプションをお勧めします。データ キャッシュの最初の目的は、変更されるデータについては、通常、変更されるデータを保存するための追加のキャッシュを構築することです。変更されたキャッシュ。

業界の一般的な慣例では、

値を文字列ではなくバイナリ形式で保存します。これによりメモリが節約され、非常に効率的になります。欠点は、プレーン テキストがすでにバイナリ形式であるため、redis-cli を介して読み取ることができないことです。たとえば、あなたは
key=user:[id]
value=このユーザー オブジェクトによって変換されたバイナリ形式

次に Java を使用してこの値を読み取ると、その値が自動的にオブジェクトに変換されます。属性を 1 つずつ設定する必要はありません。

ただし、このように関与すると、ユーザーの他の属性を介して検索することができなくなることに注意してください。他の分野での検索がある場合は、ビジネスを理解する必要があります。 nosql に他のキー値のセットを追加する 冗長性は一般的です

NoSQL は次のようなものです。プログラムを書く人はビジネスを理解しなければ、データ構造の設計はうまくいきません。NoSQL の使用限界は非常に低いですが、それでも設計限界は存在します。
関連ラベル:
ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート