Re: Multi-Tenant Data Architecture
Re: Multi-Tenant Data Architecture
- Subject: Re: Multi-Tenant Data Architecture
- From: Henrique Prange <email@hidden>
- Date: Thu, 24 Sep 2009 00:43:28 -0300
Hi Chuck,
Chuck Hill wrote:
Not so easy when you have more than 20 different instances (and
counting) running on JavaMonitor. :p
20 does not seem like that many to manage.
Yeah. I'm worried about the future. 100+ instances can become a problem
to manage.
Cons:
- more instances to administer
That is our main concern. Today we have 20 instances, but this number
is likely to increase considerably in near future.
If it grows to 40, are you planning on having each instance host all
40? I'd look into EOF stack size if you are thinking of having 40 in
one JVM and there is a significant amount of data per tenant. That
might work out to a lot of RAM per instance and so few instances per
machine. It is just something to keep in mind.
You are right and I don't have the exact math for this problem. I
believe one solution will not fit all situations. Some tenants will
require an entire instance because of the amount of data. But most
tenants will not require many resources. Of course, this is based on an
empirical analysis. I still have to measure in different situations to
determine these magical numbers (number of tenants per instance,
required amount of RAM and etc).
Writing a bug free multi-tenant application with shared data is time
consuming and expensive. In the case of this specific application is
also too risky. Also, a shared database make the backup/restore
process very difficult. You can backup everything easily, but how to
revert the data for a single tenant?
The backup / restore is a good point. Managing many EOF stacks and
ensuring that one tenant does not see another tenants information might
be just as complex in either scenario.
Yeah. Whatever solution we chose, I'm convinced it is not a trivial matter.
Cheers,
Henrique
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden