more keys vs more hash keys

[benjamin...@gmail.com]

Hi all：

    I have a storage solution about object data.

    solution 1: using userId as a key

              hset "users:"&UserId name username sex userSex .. and so on .(it may have potencial extends fields)

   solution 2:using constent "users" as a key

              hset "users" userId&name userName userId&sex userSex .... and so on .

  Case 1: check an user exist or not.

         for solution1 , there may be other keys while searching "users:"userId. So the first solution will be a little slow in check exist userId.

         and we can use separated db to separate the users keys from other domains. however ,multiple db is not a idea for redis clustering

 Case 2: set a user to expired on some day

          for solution1 , we can set expire to one user. that is a good idea.

          the solution2 will do some other method to achive this.

 Case 3:  Memory usage

          the key size is a little bigger for the solution 2.

 Case 4: delete a user

          abviously the solution 1 is good than the solution 2. one command is ok .

 Case 5: eval command

          for some situation  . we need run eval command .

         and eval insist to pass the keys to the scripts. how ever , I pass no keys and with keys . all the redis stoped while scrips running.

Can anyone help to choose a better way for that?

         two rules: faster and less memory

[JaryurChang]

solution 1 is better

first of all,it takes more code and efforts to maintain fields of different user,besides if you want to take all fields of one user,there's no other way except travelling all these fields,

and every field in solution 2 has a userId included which is not necessory

if u want reduce memory usage, something else will help compared to solution 2

like 

1.make the key and fields smaller like u:123 uname:Jack

在 2018年4月19日星期四 UTC+8下午12:11:51，benjamin...@gmail.com写道：

在 2018年4月19日星期四 UTC+8下午12:11:51，benjamin...@gmail.com写道：

[benjamin...@gmail.com]

I think so too.

How about the concurrency operating?

 user operation may have conflict .

for example: multiple client modify the value of same userdata.

we can lock/watch a key. while we can't watch/lock a hash key.

Is that right?