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
