Storing a large object(in terms of size) is not a good practice. You may read it from here. One of the problem is network. You need to send 50MB payload to a redis server in a single call. Also if you save them as one big object, then while retrieving, updating it (a single field, element etc), you need to get 50 MB back from server and parse it to get a single field, update it back end send back to server. That's a serious problem in terms of network.
Instead of redis strings
, you may prefer sorted sets
or lists
depending on your use case. If you are going to store them with timestamps and get the range of events between these timestamps, then sorted sets
may be an ideal solution for you. It's good for pagination etc. One of the crucial drawback is the complexity of adding a new element is O(log(N))
.
lists
may also provide a good playground for your case. You may use LPUSH
/RPUSH
to add new events to your list, and since Redis lists
are implemented with linked lists
, both adding a message to the beginning or end of the list is same, O(1)
, which is great.
Whenever an event happens, you either call ZADD
or RPUSH
/LPUSH
to send the events to redis. If you need to query those to you may use available functions such as ZRANGEBYSCORE
or LRANGE
depending on your choice.
While designing your keys you may use an identifier such as user-id just like you mentioned in the comments. You will not have the problems with lists/sorted sets like you will have in strings
. But choosing which one is most suitable for your depends on your use case for reads/writes or business rules.
Here some useful links to read;
Redis data types intro
Redis data types
Redis labs documentation about data types