Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 47302 invoked from network); 15 Jun 2010 18:58:25 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 15 Jun 2010 18:58:25 -0000 Received: (qmail 52567 invoked by uid 500); 15 Jun 2010 18:58:25 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 52386 invoked by uid 500); 15 Jun 2010 18:58:24 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 52378 invoked by uid 99); 15 Jun 2010 18:58:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jun 2010 18:58:24 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.216.180 as permitted sender) Received: from [209.85.216.180] (HELO mail-qy0-f180.google.com) (209.85.216.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jun 2010 18:58:18 +0000 Received: by qyk31 with SMTP id 31so1144938qyk.11 for ; Tue, 15 Jun 2010 11:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=kC0S4jm65wxtqvaiGaiSqVpgYxDTUw6itdATj71a9Tw=; b=r5dbY6jOJSweHREP3RQfOV2sEPh+s3iokwQxWH9c8Qovi1YY/19GNXGjGk49NYlwdR jElvD0iEXoNPTatDOF+y8kUQM+ch5Zf6EWxIV5jjo91SDcBh8Y+IJpgyYQdQFjb79FVr VxW35kl/G3SENWprhnpElcV5TQp+CNLpcyOEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mn4j0QFOFoTyQKjTv7KTt7WbqUFgOG5m6htFhIf1hOjbyUoW4Xln40mmPcoCiNbj6O HFOKH0TTLRW137p5IfQEODlShx71Tmf19VNGz7d704TSp92OR6Yqlq52weA3M9guNlks YtV1/VQB0wUT7n1tVKhO0qb9cUrv1AWtUMEGM= MIME-Version: 1.0 Received: by 10.224.71.222 with SMTP id i30mr3399254qaj.285.1276628275923; Tue, 15 Jun 2010 11:57:55 -0700 (PDT) Received: by 10.229.235.9 with HTTP; Tue, 15 Jun 2010 11:57:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jun 2010 11:57:55 -0700 Message-ID: Subject: Re: CouchDB Partitioning Proposal From: Randall Leeds To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Jun 9, 2010 at 02:29, Rob Stewart wro= te: > Hi Randall, > > With a response time like that, efficiency is your strong point. Clearly that was somewhere below my mean response time ;) > Next, you suggest potential like solution as Cassandra and Dynamo. I'd te= nd > to agree, as these are stable distributed systems. On saying that, Cassan= dra > doesn't use Erlang (as a Java implementation), though it adopted the > flexible column layout from Google's BigTable. I've also had a look at > MongoDB, which is a C++ implementation, but with similar goals as CouchDB > (document-oriented database). They are currently working on database > partitioning, though it's in its alpha stages, in version 1.5.3. I imagin= e > that MongoDB could be a good design guide for CouchDB in the future shoul= d > its sharding implementation matures. I wasn't trying to suggest you use Cassandra. I was trying to point to different approaches to sharding/clustering used by other projects and expressing an interest in seeing a Dynamo-style clustering of Couch. > In a slightly unrelated note, can I point you to a paper published in > February, 2010 - =E2=80=9CKey/Value Datastores Comparison in AppScale=E2= =80=9D. Briefly, > AppScale is a open source drop-in replacement for Google's App Engine, an= d > provides API's to Cloud based web applications (typicall), and at the > backend that have plugged in their app API's to the API's of 7 distribute= d > databases (including Cassandra and MongoDB). What are the chances of > attaching CouchDB to the AppScale API's ? Haven't had a chance to look yet, but that sounds like a pretty nice idea. > > > My final point is Scalaris. (Google =E2=80=9CReliable Transactional P2P K= ey/Value > Store=E2=80=9D). Like CouchDB, it is a P2P datastore, implemented in Erla= ng. Appears > to be similar in design and implementation to CouchDB, to me? It uses Cho= rd# > to storing and retreiving key/values in nodes. It seemingly has support f= or > Heterogeneous hardware clusters, and it currently uses an in-memory > disctionary for database stores, though using Mnesia has been suggested I'm always surprised Scalaris doesn't come up more. I really like the approach it takes. I don't hear much about it being used in the wild. Have you any experience with it? > > Is that enough, to generate discussion, Randall ? > Heh. I dunno. What else do you want to talk about? What are you thinking about doing next? -Randall