Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 54285 invoked from network); 24 Nov 2009 14:41:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Nov 2009 14:41:46 -0000 Received: (qmail 84527 invoked by uid 500); 24 Nov 2009 14:41:46 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 84508 invoked by uid 500); 24 Nov 2009 14:41:46 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 84499 invoked by uid 99); 24 Nov 2009 14:41:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Nov 2009 14:41:46 +0000 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gcdcu-cassandra-user@m.gmane.org designates 80.91.229.12 as permitted sender) Received: from [80.91.229.12] (HELO lo.gmane.org) (80.91.229.12) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Nov 2009 14:41:37 +0000 Received: from list by lo.gmane.org with local (Exim 4.50) id 1NCwZs-0005ij-GV for cassandra-user@incubator.apache.org; Tue, 24 Nov 2009 15:41:12 +0100 Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Nov 2009 15:41:12 +0100 Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Nov 2009 15:41:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: cassandra-user@incubator.apache.org From: Ted Zlatanov Subject: Re: cassandra over hbase Date: Tue, 24 Nov 2009 08:40:46 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Lines: 24 Message-ID: <877htg0yvl.fsf@lifelogs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:0Z5C/Km3xuQk3g55XyD8RYKbP5w= Sender: news X-Virus-Checked: Checked by ClamAV on apache.org On Mon, 23 Nov 2009 11:58:08 -0800 Jun Rao wrote: JR> After chatting with some Facebook guys, we realized that one potential JR> benefit from using HDFS is that the recovery from losing partial data in a JR> node is more efficient. Suppose that one lost a single disk at a node. HDFS JR> can quickly rebuild the blocks on the failed disk in parallel. This is a JR> bit hard to do in cassandra, since we can't easily find the data on the JR> failed disk from another node. This is an architectural issue, right? IIUC Cassandra simply doesn't care about disks. I think that's a plus, actually, because it simplifies the code and filesystems in my experience are better left up to the OS. For instance, we're evaluating Lustre and for many specific reasons it's significantly better for our needs than HDFS, so HDFS would be a tough sell. JR> So, when this happens, the whole node probably has to be taken out JR> and bootstrapped. The same problem exists when a single sstable file JR> is corrupted. I think recovering a single sstable is a useful thing, and it seems like a better problem to solve. Ted