There are per-forest overheads, and each database needs at least one forest for storage.
With many customers and small amounts of content, consider combining everything in one database. This can help limit resource consumption. Every forest will allocate its own in-memory stands, which use RAM. Larger forests tend to be more efficient with disk space than small ones. So if you have many customers with small amounts of content, it may be best to keep them all in one database and use document-level security for isolation. At the other extreme, with a few large customers it's worth considering a dedicated VM per customer. That way you can make changes involving downtime and they'll only affect one customer. Performance isolation is also more robust. Of course you can also hybridize these approaches. You could start customers in a shared database, and move them to dedicated databases or dedicated VMs as they grow. -- Mike On 7 Jul 2014, at 10:33 , Casey Jordan <[email protected]> wrote: > Thanks guys that is really helpful information. > > Is there any significant performance or resource tradeoffs when choosing > between putting everything in one big database vs splitting it into one for > each "client"? Personally I like the idea of keeping everything as separate > as possible, but if this mean that it had some major tradeoff that would be > good to know. > > > On Mon, Jul 7, 2014 at 1:28 PM, Justin Makeig <[email protected]> > wrote: > Casey, > There are two ways in MarkLogic 7 to query a specific database: Create a > separate app server (HTTP or XDBC) for each database. An app server has a > default database that you can set in configuration. Each query/update > evaluated for that app server runs against that database. Many app servers > can point to one database, but an app server can only be associated with one > database. Another, lower-level means is to use xdmp:eval > <http://docs.marklogic.com/xdmp:eval?q=xdmp:eval> or xdmp:invoke. These allow > you to specify a database at runtime and evaluate specific code against it. I > wouldn't recommend this as a general approach, though. It will make your code > less readable and, in certain scenarios, will prevent MarkLogic from > maximizing some performance optimizations it does under the covers. > > Another approach might be to create protected collections for each "tenant" > within the same database. With MarkLogic's role-based security, you can be > assured that you can completely restrict viewing and editing to very specific > roles. You can take a similar approach to running privileged code with amps. > Take a look at the Security Guide for more details > <http://docs.marklogic.com/guide/admin/security#chapter>. > > Justin > > > > Justin Makeig > Director, Product Management > MarkLogic Corporation > [email protected] > www.marklogic.com > > > > On Jul 7, 2014, at 10:14 AM, Casey Jordan <[email protected]> wrote: > >> Hi all, >> >> I am checking out Mark Logic for the first time and I was interested if >> there is any information around designing a cluster for multi-tenancy? >> >> I assumed that I could create a separate database for each "client" that >> would be using the application, and then segment data that way. However >> right away it became a little unclear to me as to how I query a specific >> database (couldn't find an example of this in the docs), or manage users, >> triggers, schemas etc for a specific database. >> >> I know this is a fairly general question, but any advice would be helpful. >> >> Thanks >> >> -- >> -- >> Casey Jordan >> easyDITA a product of Jorsek LLC >> "CaseyDJordan" on LinkedIn, Twitter & Facebook >> (585) 348 7399 >> easydita.com >> >> >> This message is intended only for the use of the Addressee(s) and may >> contain information that is privileged, confidential, and/or exempt from >> disclosure under applicable law. If you are not the intended recipient, >> please be advised that any disclosure copying, distribution, or use of >> the information contained herein is prohibited. If you have received >> this communication in error, please destroy all copies of the message, >> whether in electronic or hard copy format, as well as attachments, and >> immediately contact the sender by replying to this e-mail or by phone. >> Thank you. >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > > > > -- > -- > Casey Jordan > easyDITA a product of Jorsek LLC > "CaseyDJordan" on LinkedIn, Twitter & Facebook > (585) 348 7399 > easydita.com > > > This message is intended only for the use of the Addressee(s) and may > contain information that is privileged, confidential, and/or exempt from > disclosure under applicable law. If you are not the intended recipient, > please be advised that any disclosure copying, distribution, or use of > the information contained herein is prohibited. If you have received > this communication in error, please destroy all copies of the message, > whether in electronic or hard copy format, as well as attachments, and > immediately contact the sender by replying to this e-mail or by phone. > Thank you. > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
