Multi tenant support

[ederuiter]

Would you consider adding multi tenant support to dragonflydb?

Use case

We are currently running separate redis instances for each website/application we host on our kubernetes clusters (>100 sites). Most of these sites are have a fairly low volume of traffic. This is sub-optimal for several reasons:

• extra pod per website
• memory usage
• currently we have no HA setup for all websites as this would further increase the number of pods + memory significantly

We would love to have a setup where we have a single redis (compatible) "cluster" (HA setup) that could be used by all websites (tenants).

see https://community.keydb.dev/t/multi-tenancy-support/78 for more discussion on the feature

Implementation idea:

The idea is that each user gets mapped to a namespace. Each namespace has it's own set of virtual databases (0..max_db_per_ns).
The combination of namespace + dbnum will map to a physical database, but this will be transparant to the user/application.

Besides the databases also the scripts + pubsub channels (and any other global resource) need to be namespaced, so a user in namespace A cannot affect anything of any other namespace.

Background:

I have proposed and implemented multi tenant support for keydb: Snapchat/KeyDB#374, but as their development has significantly slowed down and my PR is not yet merged after ~2 years, I am exploring other options to get this to a mainline redis compatible implementation.

If there is interest in adding this to dragonflydb I want to work on this

[romange]

A recent discussion about this:
#1415 (comment)

[romange]

Interesting proposal. Could you outline what a feature would look like in terms of authorization before we start implementing this?
In other words, how Dragonfly would map a connection to a specific namespace without introducing breaking changes to client libraries' code. Also, this, of course, should be optional by default (but this won't be a problem).

Another interesting question - how SAVE/BGSAVE/INFO would look like? would we silo those as well?

[ederuiter]

I has been a while since I have looked at my code .. so I am a little fuzzy on the details .. but the idea is to have it working with all existing applications/libraries.

What I did for keydb is that I extended the ACL SETUSER command to accept a namespace with this syntax ::<namespace name>
This namespace is stored like any other acl attribute so when the user logs in this namespace is selected (if set, otherwise the default namespace is used).

I also added another command: SELECTNS <namespace name> this is an admin only command that lets you switch your connection to another namespace.

And for replication I added another command ALLOCATE <namespace name> <virtual db id> <physical db id> . This was needed since the allocation of databases is done dynamically; databases are allocated on first use .. so for example a user is allowed to have 16 databases; but if the application only ever selects database 0 .. only that one is allocated. Allowing you to basically overprovision the physical databases.

The rest of the changes is mostly adding an abstraction layer between the server state so instead of having something like:
serverstate->dbs[selectedDb] you'd have something like: serverstate->namespaces[selectedNs]->dbs[selectedDb]

For the rdb SAVE/BGSAVE I added a few extra aux fields:

• namespace (name of the namespace)
• lua-namespace (name of the namespace specifically for lua, mainly to keep parsing simple)
• namespace-db-id (to restore the virtual => physical database mapping)

For the INFO command; I don't really have an opinion on that; the only thing I added (I think) was (per connection):

• the physical database id (in brackets after the virtual one)
• the current namespace name

The only thing that was on my wish list that I could not really easily implement in keydb was a per namespace memory limit. From what I have seen from the dragonflydb code, I think it might be feasible .. but not sure atm