Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 5446 invoked from network); 21 Dec 2010 13:13:28 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Dec 2010 13:13:28 -0000 Received: (qmail 72952 invoked by uid 500); 21 Dec 2010 13:13:27 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 72799 invoked by uid 500); 21 Dec 2010 13:13:26 -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 72790 invoked by uid 99); 21 Dec 2010 13:13:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Dec 2010 13:13:26 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mike@cloudant.com designates 209.85.212.172 as permitted sender) Received: from [209.85.212.172] (HELO mail-px0-f172.google.com) (209.85.212.172) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Dec 2010 13:13:19 +0000 Received: by pxi6 with SMTP id 6so1076511pxi.31 for ; Tue, 21 Dec 2010 05:12:59 -0800 (PST) Received: by 10.142.193.5 with SMTP id q5mr4498673wff.12.1292937178048; Tue, 21 Dec 2010 05:12:58 -0800 (PST) Received: from [10.15.9.223] ([166.205.143.201]) by mx.google.com with ESMTPS id w14sm7519327wfd.6.2010.12.21.05.12.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Dec 2010 05:12:56 -0800 (PST) Message-Id: From: Mike Miller To: "user@couchdb.apache.org" In-Reply-To: <4D107979.5030805@bclary.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Subject: Re: CouchDB becoming unusable as Database/Views increase in size. Date: Tue, 21 Dec 2010 05:12:43 -0800 References: <4D107979.5030805@bclary.com> Hi, bigcouch was built to address those exact needs. -Mike On Dec 21, 2010, at 1:55 AM, Bob Clary wrote: > Hi all, > > I've been using CouchDB to track the results of testing Firefox and > have found that as the database and view sizes have increased > CouchDB is becoming less and less viable as a solution going > forward. I don't wish to switch to a different database at this time > but may not have a choice. > > Let me say that I have looked at Jira and found others with similar > issues although issues have mostly been resolved as invalid or > already fixed. I do admit that I have a hard time navigating Jira, > so it is entirely possible I've missed already filed issues. I am > not sending this email in a threatening fashion that I've seen many > times in bugzilla where a user says "Fix this or I'm leaving!", but > in a plea for some help in finding, filing or fixing the appropriate > Jira issues which need attention. > > My database currently has a compacted size of about 37G and contains > a bit over 9 million documents. You can see examples of the view > documents in the error log I attached to >. > > I am currently using CouchDB 1.0.1 on Centos5 64bit vm with 2CPU and > 4G RAM running Erlang R14B and configured to use the 64bit js-devel > libraries. I temporarily tried to use CouchDB 1.0.x to pick up the > fix for which > was causing me problems but had to revert to 1.0.1 due to crashes > upon view compaction completion. > > Currently, my main issues are: > > Slow View generation: Recreating views from scratch is very slow. It > can take me over 24 hours to recreate some of the larger views. > Combined with the need to immediately compact them (see Large > Initial View sizes) recreating views can take my application offline > for users for more than a day. Trying to switch to 1.0.x and back > and having to regenerate views after out of space conditions has led > to my application being unavailable for most of a week. > > Large Initial View sizes: Several of my views are initially created > with sizes which are 10-20 times the size of the compacted view. For > example, I have one view which when initially created can take 95G > but when compacted uses less than 5G. This has caused several out of > disk space conditions when I've had to regenerate views for the > database. I know commodity disks are relatively cheap these days, > but due to my current hosting environment I am using relatively > expensive networked storage. Asking for sufficient storage for my > expected database size was difficult enough, but asking for 10 or > more times that amount just to deal with temporary explosive view > sizes is probably a non-starter. > > CouchDB 1.0.x: My experience with attempting to use the 1.0.x branch > was a failure due to the crashing immediately upon view compaction > completion which caused the views to begin indexing from scratch. > > I would appreciate it if you would let me know if some of these are > known issues which have already been filed in Jira or if it would be > helpful to file new issues and what additional information I can > provide to help get these issues resolved. > > I can also help in making newer releases of SpiderMonkey 1.7 > available and to help get SpiderMonkey 1.8 and later released if > that will help the JavaScript performance issues CouchDB may be > facing. > > bc >