mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2024-01-19 02:48:24 +00:00
Created Filer Redis Setup (markdown)
parent
00c7ee63ae
commit
e5e01e480a
26
Filer-Redis-Setup.md
Normal file
26
Filer-Redis-Setup.md
Normal file
|
@ -0,0 +1,26 @@
|
|||
Currently there are two Redis implementations, i.g., `redis2` and `redis3`. What is the difference?
|
||||
|
||||
# Storing directory list
|
||||
|
||||
Since Redis is a key-value store, the directory list could not be efficiently iterated by scanning the keys. So the directory list is stored as a [sorted set](https://redis.io/topics/data-types#sorted-sets) in `redis2`:
|
||||
```
|
||||
<directory_path>: <sorted set of names>
|
||||
```
|
||||
|
||||
The sorted set in Redis is fairly efficient. Storing 100K ~ 1 million entries is still fairly fast. In most of the cases, your use case should work very well with a directory this size.
|
||||
|
||||
# Super Large Directories
|
||||
|
||||
In some cases, the directory may have 10s of millions or billions of files or sub directories. The directory list would be too big to fit into one Redis entry. For `redis2`, you can specify which folder is super large, and avoid storing this fat list of names, but giving up the directory listing capability.
|
||||
|
||||
This is where `redis3` can help. The internal data structure is:
|
||||
|
||||
```
|
||||
<directory_path>: <skip list>
|
||||
<skip list item 1>: <sorted set>
|
||||
<skip list item 2>: <sorted set>
|
||||
...
|
||||
```
|
||||
The directory list is stored as a skip list, and the child names are spread into the list items.
|
||||
|
||||
This prevents each Redis entry from being too large and slower to access.
|
Loading…
Reference in a new issue