ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ejaz Ahmed <ejaz_ah...@outlook.com>
Subject RE: OFBiz Multi-tenancy
Date Thu, 27 Feb 2014 15:17:25 GMT
I was not aware that mail man forbids html display. This table is distorted in plain text emails.
It can be viewed here:

http://cloudcomputing.sys-con.com/node/1610582
 

Regards:

Ejaz Ahmed





> From: ejaz_ahmed@outlook.com
> To: user@ofbiz.apache.org
> Subject: RE: OFBiz Multi-tenancy
> Date: Thu, 27 Feb 2014 15:08:55 +0000
> 
> It would be better to create a JIRA issue for this requirement gathering.
> 
> Pierre,
> 
> There are many articles on separate db-separate schema vs shared db-separate schema vs
>  shared db-shared schema approach. Here is an extract from http://cloudcomputing.sys-con.com/node/1610582
> 
> 
> Attribute
> 
> 
> 
> Separate Database
> 
> 
> 
> Separate Schema
> 
> 
> 
> Separate Rows
> 
> 
> 
> 
> 
> Tenants are large enterprise customers who could store large amounts of data in TB or
100s of GB
> 
> 
> 
> Good
> 
> 
> 
> Fair
> 
> 
> 
> Poor
> 
> 
> 
> 
> 
> Tenants are individual consumers  with low or moderate storage of data like a  social
networking site
> 
> 
> 
> Poor
> 
> 
> 
> Fair
> 
> 
> 
> Good
> 
> 
> 
> 
> 
> Rapid provisioning is the key, risk of losing business exists  if the
>  response is not quick, customers select the service on the fly
> 
> 
> 
> Fair
> 
> 
> 
> Fair
> 
> 
> 
> Good
> 
> 
> 
> 
> 
> Customers can opt out of  (Cancel ) service at a faster rate and  space reclamation is
not a concern
> 
> 
> 
> Good
> 
> 
> 
> Good
> 
> 
> 
> Fair
> 
> 
> 
> 
> 
> Customer can opt out of (Cancel) service at a faster rate and space reclamation is a
concern
> 
> 
> 
> Good
> 
> 
> 
> Good
> 
> 
> 
> Poor
> 
> 
> 
> 
> 
> The business logic of your SaaS application is highly customized with respect to the
Tenant
> 
> 
> 
> Good
> 
> 
> 
> Good
> 
> 
> 
> Poor
> 
> 
> 
> 
> 
> Application is prone to database locks
> 
> 
> 
> Good
> 
> 
> 
> Fair
> 
> 
> 
> Poor
> 
> 
> 
> 
> 
> Security and Legal Requirements require data separation, even if the application controls
it
> 
> 
> 
> Good
> 
> 
> 
> Fair
> 
> 
> 
> Poor
> 
> 
> 
> 
> 
> Performance tuning is a concern and reports performance should be based on the volume
of data
> 
> 
> 
> Good
> 
> 
> 
> Fair
> 
> 
> 
> Poor
> 
> 
> 
> 
> 
> Administration and maintenance of Schema and  database code is a concern
> 
> 
> 
> Poor
> 
> 
> 
> Poor
> 
> 
> 
> Good
> 
> 
> 
> 
> 
> Scalability is a concern
> 
> 
> 
> Good
> 
> 
> 
> Fair
> 
> 
> 
> Poor
> 
> 
> 
> 
> 
> Frequent Changes to the Application Possible
> 
> 
> 
> Poor
> 
> 
> 
> Poor
> 
> 
> 
> Good
> 
> 
> 
> 
> 
> Data is mission critical and Point In Time Recovery is needed in case of a crash
> 
> 
> 
> Good
> 
> 
> 
> Fair
> 
> 
> 
> Poor
> 
> Looking at above VS chart, it is clear that separate database is going to fit the requirements
of ofbiz.
> 
> 
> Regards:
> 
> Ejaz Ahmed
> 
> 
> 
> 
> 
> > Subject: Re: OFBiz Multi-tenancy
> > To: user@ofbiz.apache.org
> > From: c.schinzer@gmail.com
> > Date: Thu, 27 Feb 2014 12:31:06 +0000
> > 
> > Just my 0.02 here:
> > 
> > My understanding is still that the delegator handling might not be robust enough
on OOTB OFBiz. When it comes to backend access every too often I have issues to see proper
data or even logging in. Respective JIRA is open.
> > 
> > Multiple DB needs to be the solution. Such is also leveraging a depend-nothing concept
better than shared DB. Sharding multiple OFBiz instances to manage the traffic will be also
easier, not speaking about upgradding ti dedicated instances etc.
> > 
> > Re postgres I feel tenant-level backups into XML using OFBiz on-board tools might
anyways be more efficient. The subset of entities that are populated into OFBiz by Tenant
use are pretty clear.
> > 
> > Regards
> > 
> > 
> > Carsten
> > 
> > Gesendet von unterwegs mit BlackBerry® Webmail.
> > 
> > -----Original Message-----
> > From: Pierre Smits <pierre.smits@gmail.com>
> > Date: Thu, 27 Feb 2014 12:57:54 
> > To: <user@ofbiz.apache.org>
> > Reply-To: user@ofbiz.apache.org
> > Subject: Re: OFBiz Multi-tenancy
> > 
> > Hi all,
> > 
> > Thank you for submitting links to documents related to the subject.
> > 
> > Of course, for each the criteria might vary and weigh differently, and the
> > options available in current feature set of OFBiz are limited.
> > 
> > But in whole, the cost of operations are key. These cost of operations not
> > only include the hardware and software cost, but also the effort of
> > maintaining the environment. While setting up a new tenant is easy, and
> > maintaining the happy flow (uptime and backup), the crucial factors in this
> > are the performance of the persistence engine and recovery cost in case of
> > unexpected data loss.
> > As many (on the internet) seem to be agreeing on the recovery cost in the
> > case of a shared database-shared schema approach can be expected to be high
> > due to the intricacies of the beast as opposed to a 'separate
> > database-separate schema' setup.
> > 
> > Yes, multiple databases might lead to a performance overhead and higher
> > maintenance cost, but a side-by-side comparison of the various aspects of
> > each approach (separate db-separate schema vs shared db-separate schema vs
> > shared db-shared schema) is something that would surely help in assessing
> > what would be the best approach in various scenarios.
> > 
> > If that would be available, then a sound roadmap could be devised for this
> > subject.
> > 
> > Regards,
> > 
> > 
> > Pierre Smits
> > 
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> 
>  		 	   		  
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message