The problem/use-case that the feature addresses
We may have many caches, sometimes there are many levels or caches scattered in different places, so we need a structure to maintain it.
Description of the feature
The structure of Zset is natural and orderly. I think it is easy to build a directory structure, like this: zset -> {zset_key1,zset_1_key2} and zset_key1 - > {zset_key1_key1,zset_key1_key2} .
Alternatives you've considered
Therefore, we only need to modify the structure of Zset to complete the directory structure, and add a pointer on each node of Zset to point to the next level. In this way, we can quickly address using a specific data format, such as set_ 1.set_ 2. If you need to show the details of the directory structure, you can also use simple traversal. Redis can embed a current directory structure to help us quickly sort out the cache. It can also provide this structure to facilitate us to maintain the cache information.
Additional information
If you have any questions, please feel free to contact me
Comment From: zuiderkwast
Are you talking about directories in a file system or just nested zset? "Directory structure" usually refers to file system directories.
Redis doesn't have any nested types (yet). The output of e.g. ZRANGE is a flat structure, but if could be nested, should the output be nested also?
Can you give some examples of command and response of ZADD, ZRANGE, etc. where the key is the toplevel zset and the sub-zset, respectively?
Comment From: ZKOOOO
Yes, it's a bit similar to the file system, but my idea is to use nested Zset to implement it. At present, many of our distributed systems often need to backtrack when storing redis data. For example, nested systems are used to store the keys under a machine or even a module.
If we use a command like zadd, if the data structure is xxx1.xxx2 value, it needs to be added correspondingly like xxx1 - > xxx2 - > {value}. When we use zrange, we can only query the data under the current level. If we use "zrangeAllLevels", we can display the data at all levels. Of course, we can also add some restrictions to avoid excessive query. we can also customize the directory structure. Just like the file system, we can clearly know which system our cache is stored in or where other contents containing the directory structure are located. For example, we can store the relationship between the database and tables in mysql, so that we can dynamically find the database and tables for some dynamic queries.
These are just my preliminary thoughts, which need to be further refined.
Thanks
Comment From: sundb
@ZKOOOO In my opinion, zset is not a suitable data structure for a direction. zset's ordering is dependent on score, but direction does not need a score, and if it were me, I would use a tree to implement a direction, not ziplsit or skiplist.
Comment From: ZKOOOO
@ZKOOOO In my opinion, zset is not a suitable data structure for a direction. zset's ordering is dependent on score, but direction does not need a score, and if it were me, I would use a tree to implement a direction, not ziplsit or skiplist.
First, explain the use of scores in the directory. For example, my directory needs to be arranged in a certain order, just as we number each machine or number each module. If we add a pointer to each level of Zset, it is actually like a tree. Each level of the tree will have a lot of content, which can be easily traversed.
Comment From: ZKOOOO
It is more like the structure of a book than a catalogue
Comment From: zuiderkwast
Redis has no nested datastructures. It is by design. If you need it, it can be implemented as a module.