Redis数据建模选型：Sorted Set+String与Hash哪个更合适？

Hey there! Let's walk through your problem and figure out which approach makes more sense for long-term maintenance. First, let's recap your core needs:

• Store SQL data (ID+composite date primary key, value) in Redis
• Support fast queries by ID + date range (with default min/max dates if not specified)
• Efficiently update values when the SQL data changes
• Refresh Redis data from SQL using the same ID+date range parameters

Let's Break Down Your Two Options #

Option 1: ZSet + String Key-Value Pairs #

This approach uses a ZSet per ID (key = ID) where members are ID_date strings, and scores are numeric date values (like YYYYMMDD). The actual value is stored in a separate String key (ID_date).

Pros:

• Native date range queries: ZSets are built for ordered data. Using ZRANGEBYSCORE zset:[ID] [start_date_num] [end_date_num] lets you directly fetch all members in your target date range—no messy date generation or filtering in your application code.
• Efficient updates: When a value changes, you only need to run SET [ID_date] [new_value]—no need to modify the ZSet at all (since the member/score doesn't change). This is atomic and fast, even for large datasets.
• Straightforward refreshes: For a given ID and date range, pull the latest data from SQL, then:
  1. Use ZADD zset:[ID] with all the YYYYMMDD scores and ID_date members (ZSet automatically ignores duplicate members, so no extra cleanup needed)
  2. Use MSET to batch-update all corresponding String values in one go.

Cons:

• Two structures to maintain: You need to ensure consistency between the ZSet and String keys. However, this is easily mitigated with Redis transactions or Lua scripts (e.g., wrap delete operations in a transaction to remove both the ZSet member and String key atomically).

Option 2: Hash Tables #

Here, each ID maps to a Hash key, with dates as fields and values as the Hash values.

Pros:

• Single structure: It looks cleaner at first glance, with all data for an ID contained in one Hash.
• Simple updates: HSET hash:[ID] [date] [new_value] is quick and atomic.

Cons:

• Awful date range queries: This is the dealbreaker. Hashes have no built-in support for range queries on fields. To get data for a date range, you'd have to:
  1. Generate every possible date string in the range (e.g., all 365 days for a yearly query)
  2. Use HMGET to fetch values for all those fields
  3. Filter out nil values for dates with no data in your application code
• Edge cases get messy: Handling queries like "all values up to today" requires dynamically generating every date from the earliest possible date to the current day—this is error-prone and inefficient, especially for large date ranges.
• Poor performance for large datasets: If an ID has hundreds/thousands of records, HGETALL to fetch all data and filter in-app will waste bandwidth and memory.

My Recommendation: Go with Option 1 (ZSet + Strings) #

While maintaining two structures sounds like extra work, the benefits far outweigh the costs:

1. Simpler query logic: The ZSet's native range queries eliminate the need for complex date generation and filtering code, which reduces bugs long-term.
2. Better performance: Batch operations (ZRANGEBYSCORE, MSET) are far more efficient than generating hundreds of field names and filtering nils.
3. Manageable consistency: Use Lua scripts or transactions to wrap operations that affect both structures (e.g., deletions) to ensure atomicity. For example, a Lua script can delete the ZSet member and String key in one atomic step.

Bonus Tips for Long-Term Maintenance #

• Standardize date formatting: Stick to YYYYMMDD for numeric scores and ID_YYYYMMDD for String/ZSet member keys—this avoids confusion with different date string formats.
• Batch refresh operations: When refreshing data for an ID and date range, use bulk commands (ZADD, MSET) instead of individual operations to minimize round-trips to Redis.
• Avoid full deletions unless necessary: For full ID refreshes, instead of deleting all ID_* String keys, just DEL zset:[ID], then re-add all members and re-set the String values—this is faster than scanning for and deleting hundreds of String keys.

内容的提问来源于stack exchange，提问作者Evan N.