Multitenancy

Multitenancy

What’s already there

• 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

What’s to be done

V1: Disk quotas and rate limiting

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.

• Disk quotas
• Rate limiting

V2: ???

• Adjusting limits on the fly without restarting servers
• Per-customer backup metadata
• Client side rate limiting?
• Centralized notification system
  • Use Javamail to send out email upon violations

“Rocket Science”

• Limiting memory usage: difficult to do in Java (for in-process cache), but also very difficult as there is a great deal of data stored outside of the Voldemort sever heap (OS page cache)
• Advanced rate limiting
  • QoS/admission control (token/bucket algorithm) vs. limits? Might be too impractical