forked from voldemort/voldemort
-
Notifications
You must be signed in to change notification settings - Fork 2
Multitenancy
afeinberg edited this page Jul 29, 2011
·
5 revisions
- Voldemort already supports multiple stores per cluster, and supports keeping a separate on-disk B+Tree for each store. In essence, this is already a form of multitenancy
- Read-only cluster is a great success story for multitenancy
Implemented. Disk quotas ready to be rolled out (but it makes no sense to roll them out separately from rate limiting), rate limiting pending further integration testing.
These are yet to be implemented. Some are rather straight forward, but others require more design as well as cost/benefit analysis (are they really required?)
- Adjusting limits on the fly without restarting servers
- Per-customer backup metadata/tools to view it
- Centralized notification system
- Use Javamail to send out email upon soft limit violations
- Client side rate limiting?
- Migrating stores betweeen clusters without any downtime or data loss (difficult, but HIGH benefit)
- Advanced rate limiting
- QoS/admission control (token/bucket algorithm) vs. limits? Might be too impractical
- Limiting memory usage: difficult to do in Java (for in-process cache), but also very difficult in general as there is a great deal of data stored outside of the Voldemort sever heap (OS page cache).