速度が必要な場合は、構造体または「キャッシュ」をredisに保存するときに、できる限り準備する必要があります。製品をHSETに保存する場合 、このHSETの「製品データ」メンバーの横にカテゴリカウンター（カテゴリごとに1つ）を追加します 、HINCRBYを使用できます カウンターをインクリメント/デクリメントします。
一般的に（ニーズに合わせてRedisキャッシュを設計する）：不要なデータを取得しないようにする必要があります。
集約されたレポートの保存（/更新/削除）と取得には、Luaスクリプトを使用することをお勧めします。 LuaスクリプトはRedisサーバーで実行されます。 ServiceStackはそれらをサポートします（SCRIPT LOAD + EVALSHA または単にEVAL ）、BookSleeve C＃クライアントモジュール（これを使用しており、少し高速です。'faster' ）を試すこともできます。 ：優れたredis-dataデザインが最初に来るのは当然です）。BookSleeveC＃クライアントは、マルチスレッドのredisパイプラインに焦点を当てています。これは、大規模なデータセットを処理するときにおそらく必要なものです。 ServiceStackでもパイプライン化が可能である必要があります。
カテゴリと製品のIDが整数の場合は、これをZSETと組み合わせることもできます。 、IDをスコアフィールドとして使用できます。 ZRANGEBYSCOREを使用 「レコード」を直接取得できます。この手法は、IDが15桁以下を使用し、「スコア」の小数部分を使用しない限り安全です。したがって、IDは-999999999999999から999999999999999の範囲内にとどまる必要があります。注：これらの制限は、Redisサーバーが実際にスコア（フロート）をredis文字列表現として内部に保存するために存在します。
これがお役に立てば幸いです、TW