How many Buckets?
- Max. possible number of Buckets
- Logical data separation
- Load separation
- Physical data separation
Max. possible number of Buckets
Logical Data Separation
- Session Management Service: Create/validate session tokens for authorization purposes
- Chat Service: Send/retrieve messages from/to users
- Primary Index: Only emit a key of a KV-pair as the key into the View index
- Secondary Index: Emit a property of the value of a KV-pair as the key into the View index
- Materialized View: Emit a key and a value into the View index
CREATE INDEX def_name_type ON travel-sample(`name`) WHERE(`_type` = “User”)
So you win control regarding the indexing load separation by deciding which node serves which index.
Physical Data Separation
- Data Serving
A physical data separation is also possible per bucket. Couchbase allows you to specify separated data and index directories. So it is already possible to keep the GSI-s or Views on faster SSD-s whereby (indeed dependent on performance requirements) your data can be stored on bigger slower disks. Each bucket is reflected as one folder on disk. So it’s also possible to mount a specific bucket folders to a specific disks, which provides you a physical per bucket data separation.
- One tenant per cluster: This would be suitable if you provide Couchbase as a Service. Then your customers have full access to Couchbase and they implement their own services/applications on top of it. In this case a cluster per tenant makes sense because the cluster needs to be scaled out dependent on the performance requirements of your customer’s services/applications.
- One tenant per bucket: As explained, there are two reasons why it is often not an option. The first one is the answer to the question above. The second one is the max. number of buckets per cluster.
- One tenant per name space: As explained your application often already models multi-tenancy. So you can model a kind of name space per tenant by using key prefixes. ( Each document is stored as a KV-Pair in Couchbase. ) So every key which belongs to a specific tenant id belongs to a specific tenant. If an user with an email address of ‘firstname.lastname@example.org’ would log in, then he would only have access to documents those have the prefix ‘nosqkgeek.org’. The key pattern for a message would be ‘$tenant::$type::$id’, so for instance ‘nosqlgeek.org::msg::234234234’.