0

I am implementing a stack data structure using redis-py and Redis list data type. I am not clear on how to handle the case when the corresponding list data type is empty. Default Redis behaviour appears to be that once a list is empty the related key is deleted. The empty list case is hit on Redis for example, when I pop or clear all elements in my stack data structure on the Python end. Basically, my set up is that I have stack object in my code that calls operations on the Redis list. For example, when a client of the stack object does, stack.pop(), the stack object then calls BRPOP on the corresponding list in Redis using redis-py. Also, in my set up, the stack object has key attribute, which is the key of the related list in Redis.

I have thought about 2 possible solutions so far:

  1. Never empty the Redis list completely. At least maintain one element in the list. From the client's perspective a stack is empty if the Redis list only contains 1 element. This approach works, but I mainly dont like it as it involves keeping track of number of elements pushed/popped.

  2. If the list is empty, and the related key is deleted. Upon subsequent push, just create a new list on Redis. This approach also works, but an added complexity here is that I cannot be sure if someone else has created k,v pair on Redis using the same key as that of my stack object.

So, I am basically looking for a way to keep a key with an empty list that does not involve the bookkeeping required in the above two approaches. Thanks.

Waqas
  • 311
  • 1
  • 3
  • 10
  • 2nd solution is the best fit. I don't see any problem with that. You don't have to create a list just do an Lpush or rush it will be created. Similarly if you get a (nil) in your pop the stack is empty and handle it in app logic. I don't understand what you meant by keeping track of keys life. And also redis is basically a no sql database so you must have the control over the keys you put in, you can't say that you don't have control over someone else creating a same key as that of yours – Karthikeyan Gopall Jun 27 '16 at 18:30
  • @KarthikeyanGopall Based on other resources online, it seems that in order to avoid key collision, some sort of naming convention is needed. The control over what keys go in is the output of process (either manual or automated) that one can put in place. It does not seem that Redis gives you this facility, but rather it needs to handled outside of Redis. Also, the tracking key life bit in my question was ambiguous, so I have edited. – Waqas Jun 27 '16 at 21:04

1 Answers1

1

Your 2nd solution is the best Fit.

Yes you have to maintain the naming conventions, this is very basic for any no sql databases or key value store. You must have the control over the keys you put in. If you don't have that control, then over the period of time you don't know which key is used for which purpose. To achieve the same, you can prefix some meaningful string in all the keys you put in.

For example, if i want to store 3 hashmaps for a single user user1 I will do like this

hmset ACTIONS_user1 a 10 b 20 ...
hmset VIEWS_user1 home_page 4 login 10 ...
hmset ALERTS_user1 daily 5 hourly 12 ...

In the above example user1 is dynamically created by the app logic and you append them with a meaningful string representing what that key holds.

In this way you will always have control over the keys you put in and you will never face key collision.

Hope this helps.

Karthikeyan Gopall
  • 5,469
  • 2
  • 19
  • 35
  • My main concern was overridden/invalidation of data associated to particular key. I went with your suggestion, and chose the second approach. The complexity about avoiding collisions should be handled external to my code, which you alluded as well. – Waqas Jul 05 '16 at 20:32
  • Two theoretical points, not intended to take away from your practical advice , but stating for completion (assuming no control over keys): 1) theoretically speaking you may end up with a case where different applications may issue identical HMSET commands, it may be unlikely, but not impossible; 2) two different keys may end up in the same bucket thus causing collision, but Redis makes this transparent to the user. – Waqas Jul 05 '16 at 20:49