Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 4 Jul 2012 14:22:26 +0100
From: Martin Hewitt <martin@thenoi.se>
To: user@couchdb.apache.org
Message-ID: <747D4081314B46DF9434CBEE99F0D0A0@thenoi.se>
In-Reply-To: <DE5590288EF04311B66C0EF97ECB7C3B@cloudant.com>
References: 
 <CAJyA5491rp6ePMiRhZy3bKAcXZ9QrgAuCPsND5LeYmbHuEhxag@mail.gmail.com>
 <A402D876-5F4E-4121-88FA-D5174D009310@gmail.com>
 <CAKNVnzzsK8e+FcwZVVJO+qYFuFv-Osj62xj0T3yhpy_ZUBFZ0g@mail.gmail.com>
 <DE5590288EF04311B66C0EF97ECB7C3B@cloudant.com>
Subject: Re: Scaling writes?
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4ff44392_542289ec_2c64"

--4ff44392_542289ec_2c64
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We've just moved away from BigCouch, it's definitely moved to the 1.1.x b=
ranch, but not any further. =20

Martin


On Wednesday, 4 July 2012 at 14:11, Simon Metson wrote:

> IIRC it's currently built of v1.0.2 =20
> =20
> =20
> On Wednesday, 4 July 2012 at 13:49, Gabriel Mancini wrote:
> =20
> > Hi Guys any one knows if bigcouch works on couchdb 1.2 =3F
> > =20
> > On Wed, Jul 4, 2012 at 3:11 AM, Mathias Leppich <mleppich=40muhqu.de =
(mailto:mleppich=40muhqu.de)> wrote:
> > =20
> > > Already had a look on BigCouch=3F http://bigcouch.cloudant.com/
> > > =20
> > > - Mathias
> > > =20
> > > On Jul 4, 2012, at 3:21 , Michael Parker wrote:
> > > =20
> > > > Given that CouchDB is a multi-master system, it seems that reads =
scale
> > > > gracefully while writes do not -- because N reads among k nodes c=
an be
> > > > spread as N/k reads per node, while N writes among k nodes requir=
es
> > > > each of the nodes to perform all N writes.
> > > > =20
> > > > So what's the best practice on scaling writes=3F Clearly each nod=
e
> > > > should not be responsible for performing all N writes and we woul=
d
> > > > want to partition the data storage. I was thinking of consistent
> > > > hashing, but that requires some logic to merge results from views=
. My
> > > > best idea so far is to partition documents based on their type, a=
nd
> > > > all documents of a given type exist in the same partition.
> > > > =20
> > > > Is http://guide.couchdb.org/draft/clustering.html current, or is =
there
> > > > something else I should be looking at=3F Anyone have any success =
stories
> > > > to share=3F
> > > > =20
> > > > Guidance would be much appreciated=21 Thanks=21
> > > > =20
> > > > - Mike
> > > > =20
> > > =20
> > > =20
> > =20
> > =20
> > =20
> > -- =20
> > Gabriel Mancini de Campos
> > Arquiteto de Solu=C3=A7=C3=B5es
> > =20
> > +55 (11) 9449-1706
> > gabriel.mancini=40gmail.com (mailto:gabriel.mancini=40gmail.com)
> > S=C3=A3o Paulo - SP - Brasil
> > =20
> > =20
> > =20
> =20
> =20
> =20


--4ff44392_542289ec_2c64--