Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 14121 invoked from network); 1 Nov 2010 20:56:12 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Nov 2010 20:56:11 -0000 Received: (qmail 3513 invoked by uid 500); 1 Nov 2010 20:56:41 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 3481 invoked by uid 500); 1 Nov 2010 20:56:41 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 3473 invoked by uid 99); 1 Nov 2010 20:56:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Nov 2010 20:56:41 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [212.227.126.186] (HELO moutng.kundenserver.de) (212.227.126.186) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Nov 2010 20:56:36 +0000 Received: from [192.168.178.22] (p5DCF1B71.dip.t-dialin.net [93.207.27.113]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MOVOL-1PG4EK0tgD-006NLN; Mon, 01 Nov 2010 21:56:13 +0100 Message-ID: <4CCF296C.6050309@makkiato.de> Date: Mon, 01 Nov 2010 21:56:12 +0100 From: Gregor Frey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: Sharing design documents between DBs References: <4CCE684E.6040600@makkiato.de> <12CF5A9C-0FE3-4BED-A51B-05DB34294CC7@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:7dXLoPBhtQR53hsVC4hbGfUE/u6N7WNQKEfV/Xe1gBr jmuUBBgbT+CFCD3Vc5wu3PnUTxljN2NNREGqvEKiLbWlAWx3rH 4VezSUCNekCYg5xP5TC4jsd/wjQc+nftElSr+ilMAqI8m05KZp vGaPC0hz6YajsalzgLNunS8XUYUR4IOrbOUdDnWRzirWEARPOf gtzORFcKq2XuE3DmpQfwg== Thanks for the very interesting discussion! Benjamin's proposal to distinguish between the replication of "app dbs" on different hosts and replicating the design documents between "customer dbs" on the same machine and CouchDB instance reduces the http-traffic and supports scaling over many machines. Nevertheless I wonder why, if I really want the design documents to be identical for all customers - and this is what multi-tenancy demands - I must replicate the app documents to every db on the same instance. The ability to replicate to different instances greatly provides for scalability. But wouldn't it be much simpler to operate and would consume less resources (don't forget the file-I/O!) if all the dbs on one instance could share the same application documents? Ciao Gregor On 01.11.2010 18:46, Benjamin Young wrote: > Martin, > > I'm not sure what your setup is, but if you had an "app" database (the > authoritative db for the _design doc you want to share with customers) on > the same instance of CouchDB with the customer's db's, then your replication > requests would all be local--no IP connections what so ever. > > To do that in a multi-instance scenario, you could simply have the app db's > continuously replicate between the instances, and locally replication to the > customer db's on each particular instance. Or, if you don't want to use > replication between your instances, you could push your changes into the > "app" db's on each of the instances. In either case, you'd only be > generating HTTP traffic on the pushing of the app and/or replication of the > "app" db's between the machines--so, very low network overhead in either > case. > > Later, > Benjamin > > On Mon, Nov 1, 2010 at 11:10 AM, Martin Highamwrote: > > >> 'Continuous' replication to thousands of databases means thousands of >> permanent IP connections. The alternative is that you write a script that >> fires off replication requests in sequence for all your databases to >> perform >> the update. As you say, this shouldn't occur often. >> >> Martin >> >> On 1 November 2010 14:48, Benjamin Young wrote: >> >> >>> Martin, >>> >>> Why not? It's only going to be sending changes. Unless you're constantly >>> updating your app installation or those changes are massive, you >>> >> shouldn't >> >>> run into any trouble. >>> >>> Your other option is the "middle-ware" setup, but then you'd loose the >>> power >>> of application replication. >>> >>> Thoughts? >>> >>> Later, >>> Benjamin >>> >>> On Mon, Nov 1, 2010 at 10:30 AM, Martin Higham>> >>>> wrote: >>>> >>> >>>> Until you have one DB per user and then you're looking at replicating >>>> >> the >> >>>> design doc to many thousands of databases and continuous replication >>>> doesn't >>>> make sense >>>> >>>> Martin >>>> >>>> On 1 November 2010 14:11, Benjamin Young >>>> >> wrote: >> >>>> >>>>> Hey Gregor, >>>>> >>>>> If you setup continuous replication between your various customer >>>>> >> db's >> >>>> and >>>> >>>>> your primary application database (which would likely only contain >>>>> >> the >> >>>> main >>>> >>>>> app's design doc), then publication of the app would automatically be >>>>> "rolled out" to the various customer db's. Because these DB's would >>>>> >> be >> >>>>> "standalone" versions of the app, they could even be on multiple >>>>> >> hosts >> >>>>> running CouchDB, so you'd remove the single point of failure problem >>>>> >>> that >>> >>>>> most web-apps have--as they run (often) through a single server for >>>>> >> all >> >>>>> customers. >>>>> >>>>> Personally, that mode of "multi-tenant" app (via replication) is >>>>> >> pretty >> >>>>> exciting, and opens up new ways of dealing with load and application >>>>> distribution. Get's the mind reeling, or maybe that's the coffee I >>>>> >> just >> >>>>> finished... :) >>>>> >>>>> Later, Gregor, >>>>> Benjamin >>>>> >>>>> On Mon, Nov 1, 2010 at 6:49 AM, Jan Lehnardt wrote: >>>>> >>>>> >>>>>> Hi Gregor, >>>>>> >>>>>> On 1 Nov 2010, at 08:12, Gregor Frey wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> when I followed the discussion about the setup of CouchDB in a >>>>>>> >>> hosted >>> >>>>>> environment, I wondered whether it would be possible to share the >>>>>> application level software between multiple databases. This would >>>>>> >>>> enable >>>> >>>>> a >>>>> >>>>>> real multi-tenant set-up. Otherwise you must duplicate the >>>>>> >>> application >>> >>>>> with >>>>> >>>>>> each new tenant. >>>>>> >>>>>>> Does anybody know whether and how CouchDB supports application >>>>>>> >>>> sharing? >>>> >>>>>> CouchDB does not support application or document sharing over >>>>>> >>>> databases. >>>> >>>>>> But nothing stops you from gradually replicating a new design doc >>>>>> >>> (the >>> >>>>>> application) to every database. >>>>>> >>>>>> Cheers >>>>>> Jan >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >