Multi-tenancy models

[Christophe]

Hi,

I will develop a SaaS application, and I learn about Multi-tenancy
models. I found 3 models (here http://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/?ca=drs-
Multi-tenancy models parts with pictures) :
1 - Separate application and separate databases
2 - One shared application and separate databases
3 - One shared application and one shared database

What is the best model for you?
You have advice on implementation of SaaS architecture with Play!
Famework?

[Pascal Voitot Dev]

I'd say it really on your context and needs! if you want to separate data for any reason (security, confidentiality...)

Anyway, I reminded this article about one server + one DB for all tenants (just users here but it can be done for real tenants)

http://www.lunatech-research.com/archives/2011/03/04/play-framework-writing-multitenancy-application-hibernate-filters

regards
Pascal

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[Christophe]

thanks for the link.

If someone has already deployed a SaaS application, I am also
interested in a feedback :)

On 24 oct, 15:37, Pascal Voitot Dev <pascal.voitot....@gmail.com>
wrote:

> I'd say it really on your context and needs! if you want to separate data
> for any reason (security, confidentiality...)
>
> Anyway, I reminded this article about one server + one DB for all tenants
> (just users here but it can be done for real tenants)
>

> http://www.lunatech-research.com/archives/2011/03/04/play-framework-w...
>
> regards
> Pascal

>
> On Mon, Oct 24, 2011 at 3:13 PM, Christophe <christo.ribe...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > I will develop a SaaS application, and I learn about Multi-tenancy
> > models. I found 3 models (here

> >http://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/?c...

[Christophe]

thanks for your feedback.

why do you use MongoDB now ?

On 25 oct, 03:09, sun <goo...@suncom.de> wrote:
> I have 2 multitenant apps, one with Java and H2 that works with
> Hibernate filters like Erik Bakker describes in his blog. The other
> app is in development and runs on Java and MongoDB.
>
> If I ever have so many tenants that my DB server runs out of resources
> I can  distribute my databases with the Hibernate sharding plugin or
> the native MongoDB sharding feature.
>
> To which application server a tenant request goes I can configure in a
> front-end HTTP server.
>
> So with Play we can do something like lazy tenanting, the Multi-
> tenancy model can be switched easily in a productive application.

[Adam]

We are currently using the shared app shared database model with Play,
similar to what is described in the lunatech article. There is
actually another multi-tenant model called 'shared database separate
schema' however not all databases support multiple schemas within the
same database.

From what we could tell, it's not possible to reliably implement the
shared app separate database model or the separate schema model with
play. There is a multi-db plugin however it was mentioned on this
mailing list that it doesn't work with 1.2 and it's not recommended
for prod use.

When using filters make sure to double check the security around
accessing objects as the findById methods on the models do not utilise
the filters (filters are only applied to queries).

We also tried having separate applications and separate databases
however that can be very resource intensive as you have to startup
multiple JVMs for each app. We did manage to automate the entire
setup process, including segregating applications into separate unix
accounts. However we decided it wasn't worth it and it proved too
costly for a large number of applications.

On Oct 25, 12:13 am, Christophe <christo.ribe...@gmail.com> wrote:
> Hi,
>
> I will develop a SaaS application, and I learn about Multi-tenancy

> models. I found 3 models (herehttp://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/?c...

[Drew]

Christophe,

There are trade offs with all the approaches, you just need to see
which ones you can live with. (I'm sure I'm missing some points, but
this should be a good starter)

Case 1, Separate application and separate databases:
Pros:
- You get easy scalability. You don't need to think about sharding
later on, since you are starting sharded.
- In addition, you can easily use different hardware per client. Let's
say if a client gets REALLY big, you can put them in their own
environment, their own replication tree, etc.
- You can install the app at the client's datacenter
- You can upgrade each client separately
- You can even host each client at different geographical location
(closer to the client)

Cons:
- This model won't work if you need to have relations between multiple
tenants
- You need to manage multiple databases and application servers
- You will end up with many different versions of app and dbs
- Bug reports won't be uniform because of the versions, so fixes need
to be applied to each version in production


Case 2, One shared application and separate databases (I'm assuming
you would want to keep the same schema on all databases):
Pros:
- Just like #1, you get easy scalability. You don't need to think
about sharding later on, since you are starting sharded.
- Just like #1, you can easily use different hardware per client
database.
- Just like #1, you can host each client's database at different
geographical location (closer to the client)

Cons:
- This model won't work if you need to have relations between multiple
tenants
- You need to manage multiple databases
- You can't effectively use this if you use JPA, since JPA
implementations create an EntityManager per database (this could waste
a lot of memory)


Case 3, One shared application and one shared database:
Pros:
- Only one monster to tame
- Uniform database and app versions
- Can have relationships between tenants

Cons:
- It's harder to scale, you need to do the sharding at application
level
- You're putting all your eggs (data) in one basket


As you see, there are tradeoffs with each approach. You need to really
think about your apps requirements and plan accordingly. At the end of
the day, the writes are always the bottleneck, so you need to play a
divide and conquer with the writes. The more you can divide logically,
the easier it will be to scale the system. I would say take a look at
the CAP theorem too, http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

HTH,

Drew

On Oct 24, 6:13 am, Christophe <christo.ribe...@gmail.com> wrote:
> Hi,
>
> I will develop a SaaS application, and I learn about Multi-tenancy

> models. I found 3 models (herehttp://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/?c...

[Christophe]

thx Drew :) Your summary is very helpful.

you know if it's simple, with hibernate and Play!, to manage the case:
One shared application and one shared database(but with separate
schemas) ?

> the CAP theorem too,http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

[Ricardo Nascimento]

Hello,

I don't think it's difficult for case 3 to scale with Play share nothing architecture.

[Drew]

What do you mean by one shared database and separate schemas?
If you mean one physical database server with multiple databases on it
(each with it's own schema) then I don't think you can use Hibernate
or any other JPA ORM pratically since you would have to have multiple
sets of models with their own mappings.

[tmueller]

Hi Drew,

Great review of the three possible setups for a SaaS app.

I am in the process of gathering information for a project and one of
the requirements is to have a separate DB for each tenant. So based on
your write-up it would be scenario #2.

Is there a way when logging into the application I could hit a central
DB to get the login/server credentials for the app and use that so the
person can the hit the proper DB?

Thoughts?

> the CAP theorem too,http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

[Christophe]

with PostgreSQL, it's possible to have one db with multiple schemas
(The default is "public").
In my mind I thought to create a schema by the tenant (at least be a
separation of data by tenant), but i'm not sure if it's a good
solution.

I read this method in this article, but it is web application with
RoR : http://blog.jerodsanto.net/2011/07/building-multi-tenant-rails-apps-with-postgresql-schemas/

[Drew]

@tmueller
Sure, a lot of people do that. One central database where only the
account information is stored and then one separate database per user.
Once the user logs in, you know what database to connect for the
user's data. But again, there are trade offs with this approach too.


@Christophe
I see, I guess that can help you initially separate the data per
tenant and make the future move them to their own database/hard
easier. I originally thought you meant the definition just like the
linked article mentions ("Schema" is such a terrible name for this
feature. When most people hear the term "schema" they think of a data
definition of some sort. )

On Oct 27, 5:00 am, Christophe <christo.ribe...@gmail.com> wrote:
> with PostgreSQL, it's possible to have one db with multiple schemas
> (The default is "public").
> In my mind I thought to create a schema by the tenant (at least be a
> separation of data by tenant), but i'm not sure if it's a good
> solution.
>
> I read this method in this article, but it is web application with

> RoR :http://blog.jerodsanto.net/2011/07/building-multi-tenant-rails-apps-w...

[tmueller]

Hi Drew,

So this approach wouldn't be an issue with JPA correct? Have you seen
any articles on how to do this type approach with Play/JPA where users
use the same code base but different databases? I'm new to Play and
still very wet behind the ears.

Thanks

[Drew]

@Christope
It shouldn't be an issue as long as all your schemas stay exactly the
same. I haven't done this personally but I think the only issue you're
going to have is you're going to have a JPA EntityManager per schema.
See http://www.playframework.org/modules/multidb

Take a look at the following line:

public static Map<String, EntityManagerFactory> factoryMap = new
HashMap<String, EntityManagerFactory>();

in https://github.com/dcardon/play-multidb/blob/master/src/play/db/jpa/MJPAPlugin.java

HTH,

Drew

[Christophe]

I do not know in detail the mechanism of hibernate cache, but have
several entityManager is a good solution on the performance?

In the article with RoR, it uses a "set_path" with postgresql. I don't
know if it's possible to do the same with hibernate (but I found
nothing on the web at the moment). If so, there would be one
entityManager for all tenants, and put a "filter" on the choice of the
schema (like the RoR method, with the "set_path" before a query).

the module multidb is already used in prod? I read that it was not
recommended (for now) in a prod context.

On 28 oct, 03:18, Drew <d...@venarc.com> wrote:
> @Christope
> It shouldn't be an issue as long as all your schemas stay exactly the
> same. I haven't done this personally but I think the only issue you're
> going to have is you're going to have a JPA EntityManager per schema.

> Seehttp://www.playframework.org/modules/multidb

>
> Take a look at  the following line:
>
>   public static Map<String, EntityManagerFactory> factoryMap = new
> HashMap<String, EntityManagerFactory>();
>

> inhttps://github.com/dcardon/play-multidb/blob/master/src/play/db/jpa/M...