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: [email protected] > To: [email protected] > 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: [email protected] > > From: [email protected] > > 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 <[email protected]> > > Date: Thu, 27 Feb 2014 12:57:54 > > To: <[email protected]> > > Reply-To: [email protected] > > 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 > >
