From couchdb-user-return-455-apmail-incubator-couchdb-user-archive=incubator.apache.org@incubator.apache.org Fri May 30 14:06:45 2008 Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 83130 invoked from network); 30 May 2008 14:06:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 May 2008 14:06:45 -0000 Received: (qmail 51360 invoked by uid 500); 30 May 2008 14:06:48 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 51143 invoked by uid 500); 30 May 2008 14:06:47 -0000 Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-user@incubator.apache.org Delivered-To: mailing list couchdb-user@incubator.apache.org Received: (qmail 51132 invoked by uid 99); 30 May 2008 14:06:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 May 2008 07:06:47 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.132.241 as permitted sender) Received: from [209.85.132.241] (HELO an-out-0708.google.com) (209.85.132.241) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 May 2008 14:05:59 +0000 Received: by an-out-0708.google.com with SMTP id b38so46252ana.83 for ; Fri, 30 May 2008 07:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=EJmTTrAgL52r6RNfcgat8tScAw+/Z925wlIkJOAlU7w=; b=k3FzKJhPg3irHhJ6CURZ3Zx/Bj37ct1+m7RKf6XZVSh05mjb3nXM1W00aucBhcH5plZxnHcR4mCoL9XBkBVVRZoL3ixNkfV1XzAaA/GZYLNQj+UpMQyCm3uIjySqiDIKI6kriw5kZB4ZbIxT4rVTKA7QdBj4gUIlX9CoWVnlU7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HW0DWvCgKhwaInYaMv30etnf67uNsc0JB9uTtllUKqBSZ6vumfhscTCI5ZQ/v40lT90OsbxMCG8y1TaeouRqPvZmpiTZkecaD4/yKhbOpFOpqP9oQScvMKOZmZQucZfntn0CQvXHstNQEACWQSoNavZQbEraLHhAW6mTRNI+23g= Received: by 10.100.251.11 with SMTP id y11mr9052112anh.114.1212156375625; Fri, 30 May 2008 07:06:15 -0700 (PDT) Received: by 10.100.126.15 with HTTP; Fri, 30 May 2008 07:06:15 -0700 (PDT) Message-ID: Date: Fri, 30 May 2008 10:06:15 -0400 From: "Paul Davis" To: couchdb-user@incubator.apache.org Subject: Re: Couch performance In-Reply-To: <622cacf50805300701u29d5257fy355b8d7f820e7cbc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <622cacf50805300701u29d5257fy355b8d7f820e7cbc@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Simon, I haven't seen any numbers on attachments yet, but one thing you may run up against is that attachments currently have to be Base64 encoded. Upgrading the attachment API to handle raw data is in the works, but I haven't the slightest when it'll land. HTH, Paul Davis On 5/30/08, Simon Kapeniak wrote: > Hello, > I'd like to ask what is expected performance of CouchDB in case of heavy > binary data attachments. Scenario I'd like to evaluate CouchDB for, implies > little different usage then web based application or such, which as I > understand involves dozens of small chunkcs requests rather then constant > access to big files. > > I wonder what are possible issues with that: I want to save, lets say, a > 1000 of binary files with about 1-20MB each. Many of them will have a number > of versions (ten). There won't be too many simultaneous requests, but rather > constant access of 1 to 20 clients per minute asking about single file, or > some of them (less) also sequence of attachments. > > In general, under one project, my database should handle a few TB of data > generated during a period of ~60 days, allowing access to that data (with a > rate of ~500MB per minut) for something like 10-20 people in total? > > Are there any issues I don't see now? What are possible problems introduced > by such application? Thanks for any comments! > > Cheers, > Simon. >