Date: Wed, 15 Aug 2012 07:02:55 -0700 (PDT)
From: maibeck <nicholasbec...@gmail.com>
To: bigcouch-user@googlegroups.com
Message-Id: <bc5a2b31-9681-4786-af51-a0d0deae1b5d@googlegroups.com>
In-Reply-To: <7c16c178-5b4d-489f-97ad-c32e52fa85ac@googlegroups.com>
References: <7c16c178-5b4d-489f-97ad-c32e52fa85ac@googlegroups.com>
Subject: Re: Production usage of BigCouch and the Future?
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_306_8353647.1345039375804"

------=_Part_306_8353647.1345039375804
Content-Type: multipart/alternative; 
	boundary="----=_Part_307_8009584.1345039375804"

------=_Part_307_8009584.1345039375804
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I cannot recommend going to production using the current release (0.4.0). 
 There are still some major bugs that need to be addressed in order to 
create a stable environment ready for production.  

The biggest issue for us was that views would often need to be rebuilt from 
scratch.  View generation can take hours/days to complete with large data 
sets, which in a couple cases took down our applications for days at a 
time.  We weren't ever able to consistently repeat the behavior, but it 
seemed to occur under high load, or after the server/service was restarted.

Cloudant's hosted platform appears to be quite stable, and has some 
additional features not found in bigcouch, namely chained map-reduce. 
 I would recommend using Cloudant if you're considering taking the bigcouch 
path.


On Tuesday, August 14, 2012 8:18:37 AM UTC-6, Behrad Zari wrote:
>
> Howdy Big! Couchers,
>
> We are estimating to deal with large-scale couchdb views (about more than 
> hundred Gigs of couchdb indexes) in production.
> (Which I don't think is a feasible size on a single couchdb on one 
> machine, because of limited machine memory !?)
> To provide index partitioning, we are thinking of BigCouch, which is 
> lovely fork of Couchdb, but I'm not sure about the future!?
> I've read links but have not found any roadmap or planned merge! Since we 
> are planing for a critical system in production, I wonder
> if using BigCouch will be risky or not?
>
> Thank you in advance,
>

------=_Part_307_8009584.1345039375804
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I cannot recommend going to production using the current release (0.4.0). &=
nbsp;There are still some major bugs that need to be addressed in order to =
create a stable environment ready for production. &nbsp;<div><br></div><div=
>The biggest issue for us was that views would often need to be rebuilt fro=
m scratch. &nbsp;View generation can take hours/days to complete with large=
 data sets, which in a couple cases took down our applications for days at =
a time. &nbsp;We weren't ever able to consistently repeat the behavior, but=
 it seemed to occur under high load, or after the server/service was restar=
ted.<div><div><div><br></div><div>Cloudant's hosted platform appears to be =
quite stable, and has some additional features not found in bigcouch, namel=
y chained map-reduce. &nbsp;I&nbsp;would recommend using Cloudant if you're=
 considering taking the bigcouch path.</div><div><br></div><div><br>On Tues=
day, August 14, 2012 8:18:37 AM UTC-6, Behrad Zari wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Howdy Big! Couchers,<div><br><div>We are estima=
ting to deal with large-scale couchdb views (about more than hundred Gigs o=
f couchdb indexes) in production.</div><div>(Which I don't think is a feasi=
ble size on a single couchdb on one machine, because of limited machine mem=
ory !?)</div><div>To provide index partitioning, we are thinking of BigCouc=
h, which is lovely fork of Couchdb, but I'm not sure about the future!?</di=
v><div>I've read links but have not found any roadmap or planned merge! Sin=
ce we are planing for a critical system in production, I wonder</div><div>i=
f using BigCouch will be risky or not?</div><div><br></div><div>Thank you i=
n advance,</div></div></blockquote></div></div></div></div>
------=_Part_307_8009584.1345039375804--

------=_Part_306_8353647.1345039375804--