From dev-return-10143-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Jun 09 09:29:59 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 9296 invoked from network); 9 Jun 2010 09:29:59 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Jun 2010 09:29:59 -0000 Received: (qmail 60542 invoked by uid 500); 9 Jun 2010 09:29:58 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 60446 invoked by uid 500); 9 Jun 2010 09:29:56 -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 60438 invoked by uid 99); 9 Jun 2010 09:29:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jun 2010 09:29:56 +0000 X-ASF-Spam-Status: No, hits=4.4 required=10.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of robstewart57@googlemail.com designates 209.85.161.52 as permitted sender) Received: from [209.85.161.52] (HELO mail-fx0-f52.google.com) (209.85.161.52) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jun 2010 09:29:49 +0000 Received: by fxm4 with SMTP id 4so348815fxm.11 for ; Wed, 09 Jun 2010 02:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=cENLmZ6KKZ6eB+wZSyzfU9VhBHFMA52JF68WQ81M2p0=; b=YKTSZwsjMqqXbi1Od5dSOUHKYMSP7RVIWm0VLSU5+KcH7nfAa3YitWoP7cRqwWtZYM p7se0kBWhX1/epBRCSZQZ0S72mhgJThGXKBvbcyVNvqxCUME6nzQwL/u4Lsyvl1owPog 8v3QM/7WDbsRZbjrj5ef80BpOKboC7DbHV884= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=X3phDg+/3DaYb13gZ9Qm2oYx5ifmUDiiiLotdrszN07H81GaUtcY9Ee8G/16pVlH4N DblruTZRbzfxmlrLlsOwndkqe0f6M0l2fgHgjWZtm9WZUHO72Ak9HtLrpzXeMnJukBnr 44hqQcNI8pO8hOgmLF5vHp1U9xYWkOaDEsLeo= Received: by 10.102.14.5 with SMTP id 5mr5850518mun.33.1276075769187; Wed, 09 Jun 2010 02:29:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.221.12 with HTTP; Wed, 9 Jun 2010 02:29:09 -0700 (PDT) From: Rob Stewart Date: Wed, 9 Jun 2010 10:29:09 +0100 Message-ID: Subject: Re: CouchDB Partitioning Proposal To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016363b9ac4edcfd50488958a98 X-Virus-Checked: Checked by ClamAV on apache.org --0016363b9ac4edcfd50488958a98 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Randall, With a response time like that, efficiency is your strong point. First of all, seeing as through there are a number of =93solutions=94, it's clear that there are positives to come from a fully distributed CouchDB database. So I am not put off by that. Next, you suggest potential like solution as Cassandra and Dynamo. I'd tend to agree, as these are stable distributed systems. On saying that, Cassandr= a 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 imagine that MongoDB could be a good design guide for CouchDB in the future should its sharding implementation matures. In a slightly unrelated note, can I point you to a paper published in February, 2010 - =93Key/Value Datastores Comparison in AppScale=94. Briefly= , AppScale is a open source drop-in replacement for Google's App Engine, and 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 distributed databases (including Cassandra and MongoDB). What are the chances of attaching CouchDB to the AppScale API's ? My final point is Scalaris. (Google =93Reliable Transactional P2P Key/Value Store=94). Like CouchDB, it is a P2P datastore, implemented in Erlang. Appe= ars to be similar in design and implementation to CouchDB, to me? It uses Chord= # to storing and retreiving key/values in nodes. It seemingly has support for Heterogeneous hardware clusters, and it currently uses an in-memory disctionary for database stores, though using Mnesia has been suggested. Is that enough, to generate discussion, Randall ? Rob Stewart --0016363b9ac4edcfd50488958a98--