Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of sebastiancohnen@googlemail.com
 designates 74.125.82.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=sYMHhsepMmx+fnRejuKMd7Z4IWNh0Tt7qzu2vwNBeKBYvtbWhjQ9okPMfz8Unb0Gix
         Zd+Agu0RqJqk52s4CqJvWxQXUskMXrbym1HH6HnPtTc+NKvekt5hyBy1quWfslq+hnzF
         4GlwB6QzGvCVnzyWpBT5Gs3d+0b0torDRAtfo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: CouchDB and Hadoop_
From: Sebastian Cohnen <sebastiancohnen@googlemail.com>
In-Reply-To: 
 <A926055927E1404BB6D679FDF8C40CDB9B007DDE02@exchange0.ad.qbrick.com>
Date: Fri, 16 Apr 2010 15:40:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CFF84BC-DE85-446A-8CF0-9E9DD1B4FAF6@googlemail.com>
References: <4BC7AC4B.1050401@gmail.com>
 <g2mc32d31441004160112u8babd6ccwb8407e83d825595a@mail.gmail.com>
 <A926055927E1404BB6D679FDF8C40CDB9B007DDE02@exchange0.ad.qbrick.com>
To: user@couchdb.apache.org

Why would someone possibly do that? CouchDB can do many things really =
well, and replication is one of these things. It's dead simple to set up =
and just works...

On 16.04.2010, at 15:29, Fredrik Widlund wrote:

>=20
>=20
> Are the files reopened for each write etc? If locking works glusterfs =
for example could be a nice solution for the replication. Each write =
would be atomically written to all instances, and reads would be local =
(using AFR with preferred servers).
>=20
> Kind regards,
> Fredrik Widlund
>=20
>=20
> -----Original Message-----
> From: Suhail Ahmed [mailto:suhailski@gmail.com]
> Sent: den 16 april 2010 10:13
> To: user@couchdb.apache.org
> Subject: Re: CouchDB and Hadoop
>=20
> Sure It can be done but for me the whole Java to Erlang layer would be =
a
> mess since they are so different. The better way to go about doing =
this
> would to be implement a distributed file system like Hadoop underneath =
Couch
> for same effect.
>=20
> On Fri, Apr 16, 2010 at 1:16 AM, Steve-Mustafa Ismail Mustafa <
> m.i.mustafa@gmail.com> wrote:
>=20
>> I swear, I spent over an hour going through the mailing list trying =
to find
>> an answer.
>>=20
>> I know that CouchDB is a document oriented DB and I know that Hadoop =
is a
>> File System and that both implement Map/Reduce.  But is it possible =
to have
>> them stacked with Hadoop being the FS in use and CouchDB being the =
DB? This
>> way, wouldn't you get the distributed/clustered FS abilities of =
Hadoop in
>> addition to the powerful retrieval abilities of CouchDB?
>>=20
>> If its not possible, and I suspect that it is so, _why_? Don't they =
operate
>> on two seperate levels? Wouldn't CouchDB sort of replace HBase?
>>=20
>> Thanks in advance for any and all replies
>>=20
>=20