Description of the feature

MINCRBY[FLOAT] key increment [key increment ...]
HMINCRBY[FLOAT] key field increment [field increment ...]

Alternatives you've considered

The operation of m is essentially the user's desire to reduce multiple interactions with the server under the premise of ensuring atomicity. Although the lua command can also meet the above requirements, it means that users need to learn lua.

Comment From: madolson

We might also want zmincrby key field increment [field increment ...] would complete the set of commands missing this.

Comment From: gkorland

@yangbodong22011 did you consider instead of using LUS using MULTI? As for the network round trip pipeline should get similar results.

Comment From: oranagra

I don't think we want to add an M variant to every command in the book.

I think it makes sense to add them to read commands which can return an array. And especially to commands working on multiple fields of the same key (e.g. SMISMEMBER). i.e. HMGET <key> <field> <field> makes more sense to me than MHGET <key> <field> <key> <field> The later can be achieved with a similar effort in a simple pipelined MULTI-EXEC.

For write commands that work on multiple fields of the same key, there's no need for an M variant, since we can just make the command variadic (i.e. HINCRBY <key> <field> <incr> <field> <incr>) since it doesn't change the response type (would be the number of fields changed). And like read commands, (for write commands too), working on multiple keys, MINCRBY can be achieved with a pipelined MULTI-EXEC at nearly the same cost.

Comment From: yangbodong22011

@gkorland @oranagra Yes, pipeline with MULTI-EXEC can complete the M operation, I agree with this approach.

Therefore, we need to promote the support of various clients for pipelines, especially in cluster mode, such as @gkorland previous work: add pipelined to JedisCluster.

Comment From: yangbodong22011

For write commands that work on multiple fields of the same key, there's no need for an M variant, since we can just make the command variadic (i.e. HINCRBY <key> <field> <incr> <field> <incr>) since it doesn't change the response type (would be the number of fields changed).

I think multiple fields can return the result array after addition, for example:

#> hset hash k1 1 k2 2
2
#> hincrby hash k1 1
2
#> hincrby hash k1 1 k2 1
3
3

Return the value after the increment operation is more meaningful(Can reduce once hget call). But the problem is that when the field is greater than 1, the return value becomes the array type (such as spop).

Comment From: oranagra

ohh, right. i forgot that HINCRBY returns the counter value.. my comment about the command being turned into variadic applies to commands such as HDEL and HSET, but not HINCRBY.

Comment From: yangbodong22011

@oranagra @madolson @gkorland Hello, these commands can support multiple fields, and we can evaluate whether they need to be implemented.

List

  • [ ] LINDEX key index -> LINDEX key index [index ...]

Set

  • [x] SISMEMBER key member -> Implemented as SMISMEMBER command, see #7615.

Hash

  • [ ] HEXISTS key field -> HEXISTS key field [field ...]
  • [ ] HINCRBY key field increment -> HINCRBY key field increment [field increment ...]
  • [ ] HINCRBYFLOAT key field increment -> HINCRBYFLOAT key field increment [field increment ...]
  • [ ] HSTRLEN key field -> HSTRLEN key field [field ...]

Sorted set

  • [ ] ZINCRBY key increment member -> ZINCRBY key increment member [increment member ...]
  • [ ] ZRANK key member -> ZRANK key member [member ...]
  • [ ] ZCOUNT key min max -> ZCOUNT key min max [min max ...]
  • [ ] ZLEXCOUNT key min max -> ZLEXCOUNT key min max [min max ...]
  • [x] ZSCORE key member -> Implemented as ZMSCORE command, see #7593

Some considerations about implementation details:

1) Expand the original command or add a new command?

e.g. HINCRBY key field increment [field increment ...] or HMINCRBY key field increment [field increment ...]

I think it is better to increase HMINCRBY, and antirez also explains it here: https://github.com/redis/redis/issues/846#issuecomment-13283649

2) Where does the need to support these commands come from?

  • User convenience: For users, in fact, the request of the M series can use LUA or pipeline with MULTI-EXEC, but this will make the user code more complicated, and the new command is more convenient in this simple scenario.
  • The completeness and unity of api: The current situation is that some commands are supported, but some commands are not.

Comment From: oranagra

the ones that sound most useful to me are LINDEX, LSET and HEXIST, maybe with the addition of HINCRBY, ZINCRBY.

maybe also some multi-key commands like INCRBY which is listed in your opening post. and MHGET (https://github.com/redis/redis/pull/7347)

I don't think we want to just fill the matrix and add everything, we need to consider usefulness and benefits over the alternative, and how much these were requested in the past. @itamarhaber might be able to assist.

Comment From: soloestoy

The multi-key/multi-field commands discussion has a long history, like #846 #923 .

Personally I don't like the multi-key commands, since it may fail on cluster when the keys are distributed in different slots, and Redis and clients like JedisCluster have to get the keys' position and hash the slots, that need a lot of computing resource.

About multi-field write commands like hmincrby and zmincrby, exactly we can use MULTI/EXEC or LUA to implement, but there are a lot of actual users need it, I can't find a proper reason to refuse it, especially we already implement GETEX and GETDEL.

Comment From: simonprickett

@oranagra +1 for a HMEXISTS command, I'd find that very useful.

Comment From: Distractic

+1 for HMEXISTS !