In Redis, List represents a collection of string elements sorted according to the order of insertion. SET, on the other hand, is a collection of unique and unsorted string elements. So, the key difference between the two is that SET doesn't allow duplicity and doesn't preserve order. However, there are other variants of SETs such as Sorted SETS which let you decide how you want to store the elements (e.g. sort according to timestamp).
Let's say, you want to create feeds for your users. You will need to store the post ids in a key in Redis. In this case, you strictly don't want duplicate posts and each post id is unique. So, it's a good idea to make this key a SET in order to ensure that there isn't any duplicity. Further, you can make this a sorted set so that you can decide which posts rank higher in the feed.
Now imagine you are creating a user timeline where you push most recent activity to the user's timeline. In this case LIST may be a good choice.
In terms of Time Complexity, inserting in the head or tail of a List will be O(1) no matter how big the List is (Constant time complexity) because Redis Lists are internally Linked Lists. But accessing an element in the middle of a huge list may take some time. It's basically a O(n) operation.
SETs, on the other hand, have O(1) complexity for adding, deleting and checking existence of elements.
Thanks for your reply.
I'm writting bachelor work about "The usage of Redis on heavily loaded PHP website" and i should compare Redis data types and from Redis documentation i missed some summary, pros and cons about data types.
Sandeep Panda
co-founder, Hashnode
In Redis, List represents a collection of string elements sorted according to the order of insertion. SET, on the other hand, is a collection of unique and unsorted string elements. So, the key difference between the two is that SET doesn't allow duplicity and doesn't preserve order. However, there are other variants of SETs such as Sorted SETS which let you decide how you want to store the elements (e.g. sort according to timestamp).
Let's say, you want to create feeds for your users. You will need to store the post ids in a key in Redis. In this case, you strictly don't want duplicate posts and each post id is unique. So, it's a good idea to make this key a SET in order to ensure that there isn't any duplicity. Further, you can make this a sorted set so that you can decide which posts rank higher in the feed.
Now imagine you are creating a user timeline where you push most recent activity to the user's timeline. In this case LIST may be a good choice.
In terms of Time Complexity, inserting in the head or tail of a List will be O(1) no matter how big the List is (Constant time complexity) because Redis Lists are internally Linked Lists. But accessing an element in the middle of a huge list may take some time. It's basically a O(n) operation.
SETs, on the other hand, have O(1) complexity for adding, deleting and checking existence of elements.
To know more, I recommend reading this guide.