You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Aroj George <ar...@gmail.com> on 2011/04/15 18:45:34 UTC
Multi-tenancy in Couch
Hi,
What's the best way to implement multi-tenancy in couch?
In the sql world you could choose to do either a tenant id key in every
table or separate schemas for each tenant or even separate database
instances...
Similarly in couch i guess you can store each tenant's document in a
separate database. This seems a very simple option.
But then is there a max limit on the number of databases we can create in
couch?
The other option, not too hard either, is to have the tenant id as the first
key in all the views and use the startkey to filter out the tenants.
Will greatly appreciate if you can share your thoughts on which approach is
ideal and will scale better.
Or if there are more approaches that I have not thought off.
Rgds,
Aroj
Re: Multi-tenancy in Couch
Posted by Owen Marshall <om...@facilityone.com>.
On 04/16/2011 08:43 AM, Jan Lehnardt wrote:
> - If you need to get some aggregated query results from multiple databases
> some extra work is required (but there's open source precedents, see
> couchdb-lounge, or BigCouch e.g.), but this is definitely supported.
Hi Jan,
By this, do you mean a person *could* use techniques from
lounge/BigCouch to accomplish this, or do you mean that it has already
been done before?
I'd be very interested in hearing opinions and experiences here. My
previous thoughts involved performing the MapReduce on all the databases
I was interested in, and then:
* using a ton of client glue to bring the results together, or
* throwing everything into a "containing" CouchDB, reindexing, and
requerying.
Best,
--
Owen Marshall
FacilityONE
omarshall@facilityone.com | (502) 805-2126
Re: Multi-tenancy in Couch
Posted by Jan Lehnardt <ja...@apache.org>.
On 16 Apr 2011, at 08:01, Aroj George wrote:
> Thanks a lot guys for all the replies, that was great help. It's great to
> see such an active forum :-)
>
> One thing I like about the one database per tenant approach is that it can
> allow me to scale by
> routing some of the large clients to separate database instances itself.
>
> So the only thing left to ask, as I am quite new to couch,
> are there any caveats to watch out for when going for this approach?
First, major +1 on the responses, thanks everybody :)
Caveats:
- If you need to get some aggregated query results from multiple databases
some extra work is required (but there's open source precedents, see
couchdb-lounge, or BigCouch e.g.), but this is definitely supported.
- Having lots of databases and views in them for each user an then having
a high number of active users will lead to a lot of file descriptors
being used. While in CouchDB that is no problem, you do want to look
into OS and kernel limits on this and make sure you know your system's
limits and have alerting in place that gives you enough time to add
more or bigger hardware.
Neither are big enough reasons to not recommend this approach, just something
to keep in mind.
Cheers
Jan
--
>
> Rgds,
> Aroj
>
>
> On Fri, Apr 15, 2011 at 11:06 PM, Marcos Oliveira <ma...@gmail.com>wrote:
>
>> I agree with the each tenant a database approach.
>>
>> We have one system in production using this strategy and works pretty
>> well. The thing we had to do was create a authorization layer on our
>> app to guarantee that each tenant would make requests to the right
>> database.
>>
>> - Marcos
>>
>> On Fri, Apr 15, 2011 at 9:59 AM, Zachary Zolton
>> <za...@gmail.com> wrote:
>>> Giving a database to each tenant is a fine way to silo data.
>>>
>>> As to the number of databases, see this thread:
>>> http://comments.gmane.org/gmane.comp.db.couchdb.user/12160
>>>
>>> –Zach
>>>
>>> On Fri, Apr 15, 2011 at 11:45 AM, Aroj George <ar...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> What's the best way to implement multi-tenancy in couch?
>>>>
>>>> In the sql world you could choose to do either a tenant id key in every
>>>> table or separate schemas for each tenant or even separate database
>>>> instances...
>>>>
>>>> Similarly in couch i guess you can store each tenant's document in a
>>>> separate database. This seems a very simple option.
>>>> But then is there a max limit on the number of databases we can create
>> in
>>>> couch?
>>>>
>>>> The other option, not too hard either, is to have the tenant id as the
>> first
>>>> key in all the views and use the startkey to filter out the tenants.
>>>>
>>>> Will greatly appreciate if you can share your thoughts on which approach
>> is
>>>> ideal and will scale better.
>>>> Or if there are more approaches that I have not thought off.
>>>>
>>>> Rgds,
>>>> Aroj
>>>>
>>>
>>
Re: Multi-tenancy in Couch
Posted by Aroj George <ar...@gmail.com>.
Thanks a lot guys for all the replies, that was great help. It's great to
see such an active forum :-)
One thing I like about the one database per tenant approach is that it can
allow me to scale by
routing some of the large clients to separate database instances itself.
So the only thing left to ask, as I am quite new to couch,
are there any caveats to watch out for when going for this approach?
Rgds,
Aroj
On Fri, Apr 15, 2011 at 11:06 PM, Marcos Oliveira <ma...@gmail.com>wrote:
> I agree with the each tenant a database approach.
>
> We have one system in production using this strategy and works pretty
> well. The thing we had to do was create a authorization layer on our
> app to guarantee that each tenant would make requests to the right
> database.
>
> - Marcos
>
> On Fri, Apr 15, 2011 at 9:59 AM, Zachary Zolton
> <za...@gmail.com> wrote:
> > Giving a database to each tenant is a fine way to silo data.
> >
> > As to the number of databases, see this thread:
> > http://comments.gmane.org/gmane.comp.db.couchdb.user/12160
> >
> > –Zach
> >
> > On Fri, Apr 15, 2011 at 11:45 AM, Aroj George <ar...@gmail.com> wrote:
> >> Hi,
> >>
> >> What's the best way to implement multi-tenancy in couch?
> >>
> >> In the sql world you could choose to do either a tenant id key in every
> >> table or separate schemas for each tenant or even separate database
> >> instances...
> >>
> >> Similarly in couch i guess you can store each tenant's document in a
> >> separate database. This seems a very simple option.
> >> But then is there a max limit on the number of databases we can create
> in
> >> couch?
> >>
> >> The other option, not too hard either, is to have the tenant id as the
> first
> >> key in all the views and use the startkey to filter out the tenants.
> >>
> >> Will greatly appreciate if you can share your thoughts on which approach
> is
> >> ideal and will scale better.
> >> Or if there are more approaches that I have not thought off.
> >>
> >> Rgds,
> >> Aroj
> >>
> >
>
Re: Multi-tenancy in Couch
Posted by Marcos Oliveira <ma...@gmail.com>.
I agree with the each tenant a database approach.
We have one system in production using this strategy and works pretty
well. The thing we had to do was create a authorization layer on our
app to guarantee that each tenant would make requests to the right
database.
- Marcos
On Fri, Apr 15, 2011 at 9:59 AM, Zachary Zolton
<za...@gmail.com> wrote:
> Giving a database to each tenant is a fine way to silo data.
>
> As to the number of databases, see this thread:
> http://comments.gmane.org/gmane.comp.db.couchdb.user/12160
>
> –Zach
>
> On Fri, Apr 15, 2011 at 11:45 AM, Aroj George <ar...@gmail.com> wrote:
>> Hi,
>>
>> What's the best way to implement multi-tenancy in couch?
>>
>> In the sql world you could choose to do either a tenant id key in every
>> table or separate schemas for each tenant or even separate database
>> instances...
>>
>> Similarly in couch i guess you can store each tenant's document in a
>> separate database. This seems a very simple option.
>> But then is there a max limit on the number of databases we can create in
>> couch?
>>
>> The other option, not too hard either, is to have the tenant id as the first
>> key in all the views and use the startkey to filter out the tenants.
>>
>> Will greatly appreciate if you can share your thoughts on which approach is
>> ideal and will scale better.
>> Or if there are more approaches that I have not thought off.
>>
>> Rgds,
>> Aroj
>>
>
Re: Multi-tenancy in Couch
Posted by Sean Copenhaver <se...@gmail.com>.
I think there is work being done on user permissions per database. That
would support the idea as well since you could isolate which users even had
access in couch.
On Fri, Apr 15, 2011 at 12:59 PM, Zachary Zolton
<za...@gmail.com>wrote:
> Giving a database to each tenant is a fine way to silo data.
>
> As to the number of databases, see this thread:
> http://comments.gmane.org/gmane.comp.db.couchdb.user/12160
>
> –Zach
>
> On Fri, Apr 15, 2011 at 11:45 AM, Aroj George <ar...@gmail.com> wrote:
> > Hi,
> >
> > What's the best way to implement multi-tenancy in couch?
> >
> > In the sql world you could choose to do either a tenant id key in every
> > table or separate schemas for each tenant or even separate database
> > instances...
> >
> > Similarly in couch i guess you can store each tenant's document in a
> > separate database. This seems a very simple option.
> > But then is there a max limit on the number of databases we can create in
> > couch?
> >
> > The other option, not too hard either, is to have the tenant id as the
> first
> > key in all the views and use the startkey to filter out the tenants.
> >
> > Will greatly appreciate if you can share your thoughts on which approach
> is
> > ideal and will scale better.
> > Or if there are more approaches that I have not thought off.
> >
> > Rgds,
> > Aroj
> >
>
--
“The limits of language are the limits of one's world. “ -Ludwig von
Wittgenstein
Re: Multi-tenancy in Couch
Posted by Zachary Zolton <za...@gmail.com>.
Giving a database to each tenant is a fine way to silo data.
As to the number of databases, see this thread:
http://comments.gmane.org/gmane.comp.db.couchdb.user/12160
–Zach
On Fri, Apr 15, 2011 at 11:45 AM, Aroj George <ar...@gmail.com> wrote:
> Hi,
>
> What's the best way to implement multi-tenancy in couch?
>
> In the sql world you could choose to do either a tenant id key in every
> table or separate schemas for each tenant or even separate database
> instances...
>
> Similarly in couch i guess you can store each tenant's document in a
> separate database. This seems a very simple option.
> But then is there a max limit on the number of databases we can create in
> couch?
>
> The other option, not too hard either, is to have the tenant id as the first
> key in all the views and use the startkey to filter out the tenants.
>
> Will greatly appreciate if you can share your thoughts on which approach is
> ideal and will scale better.
> Or if there are more approaches that I have not thought off.
>
> Rgds,
> Aroj
>
Re: Multi-tenancy in Couch
Posted by Jay Zamboni <jz...@vretina.com>.
I am actually looking at CouchDb for a multi-tenant product as well. I am
still pretty new to it, but I was looking at using the directory structure
in the couchDB name to handle the multi-tenancy in an organized way. My end
product will have many companies, and each company with multiple users.
Each user will then have a collection of documents. I would have a
database for each users documents that is something like this: (Note, the
database name contains the "/" character and this tells the OS to create
subdirectories)
"/CompanyA/user1/documents"
"/CompanyA/user2/documents"
"/CompanyA/user3/documents"
"/CompanyB/user4/documents"
"/CompanyC/user5/documents"
"/CompanyC/user6/documents"
I hope to have a very large number of users so I wanted to use the directory
structure to not only break things apart logically, but so that I don't end
of with a directory containing a million database files. I am expecting
that the limitation on the number of databases is very high, but I am
interested to hear if someone has run into any bottle necks when using a
large number of databases. For our application I only expect a low
percentage of databases to be active on any given day.
Using the "/" in the database name has been a little more troublesome than I
expected. I did get my apache setup configured to handle this, but I was
also using Divan for some of my proof of concept, and I am not sure if Divan
can handle this or not. Divan is not a requirement for us, it was just
convenient for our POC.
Jay
On Fri, Apr 15, 2011 at 9:45 AM, Aroj George <ar...@gmail.com> wrote:
> Hi,
>
> What's the best way to implement multi-tenancy in couch?
>
> In the sql world you could choose to do either a tenant id key in every
> table or separate schemas for each tenant or even separate database
> instances...
>
> Similarly in couch i guess you can store each tenant's document in a
> separate database. This seems a very simple option.
> But then is there a max limit on the number of databases we can create in
> couch?
>
> The other option, not too hard either, is to have the tenant id as the
> first
> key in all the views and use the startkey to filter out the tenants.
>
> Will greatly appreciate if you can share your thoughts on which approach is
> ideal and will scale better.
> Or if there are more approaches that I have not thought off.
>
> Rgds,
> Aroj
>