Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of yuzhihong@gmail.com
 designates 209.85.212.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAG2rwuP_+mk_vcS94HsTFUJ8TQCUcbNpftrtnZ9j1bC1z--4QQ@mail.gmail.com>
References: 
 <CAG2rwuOCcoCk5NSVmzEecmCqg0n6eNEV9+rbS9KAyD6TV1Fa-g@mail.gmail.com>
	<CAGpTDNdH_BT1eBG4c-ZSrH0zgCo324ZE1z_OJSY8-UwqRKbk8w@mail.gmail.com>
	<CAG2rwuP_+mk_vcS94HsTFUJ8TQCUcbNpftrtnZ9j1bC1z--4QQ@mail.gmail.com>
Date: Tue, 22 Jan 2013 11:05:29 -0800
Message-ID: 
 <CALte62zkFZeJ4SvjpVQYMpQrtx+oWZhtvGiy1ixd9okXEfGR7A@mail.gmail.com>
Subject: Re: write throughput in cassandra, understanding hbase
From: Ted Yu <yuzhihong@gmail.com>
To: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=047d7ba97e88ed543f04d3e54260

--047d7ba97e88ed543f04d3e54260
Content-Type: text/plain; charset=ISO-8859-1

The graph cited below was more than 1 year old.

FYI

On Tue, Jan 22, 2013 at 11:01 AM, S Ahmed <sahmed1020@gmail.com> wrote:

> Just to be clear, I realize benchmarks are not always the best way to gauge
> performance etc. since there are many factors involved, but I have
> generally seen a big diff in write throughput between the two (of the
> bencharks that I have read).
>
> For example:
> http://www.cubrid.org/blog/dev-platform/nosql-benchmarking/(chart:
> http://www.cubrid.org/wp-content/uploads/2011/09/db-test-results.png)
>
>
>
>
>
> On Tue, Jan 22, 2013 at 1:46 PM, Jean-Daniel Cryans <jdcryans@apache.org
> >wrote:
>
> > On Tue, Jan 22, 2013 at 10:38 AM, S Ahmed <sahmed1020@gmail.com> wrote:
> > > I've read articles online where I see cassandra doing like 20K writers
> > per
> > > second, and hbase around 2-3K.
> >
> > Numbers with 0 context don't mean much, if at all.
> >
> > >
> > > I understand both systems have their strenghts, but I am curious as to
> > what
> > > is holding hbase from reaching similiar results?
> > >
> > > Is it HDFS that is the issue?  Or hbase does certain things (to its
> > > advantage) that slows the write path down?
> >
> > Our writes are generally quite fast, I think at the moment some
> > improvements can be made at the client level. I did some tests last
> > year and I could get better throughput with the asynchbase client
> > compared to the normal Java client because the former has call queues
> > per region server. Both tests were using the same region servers,
> > uploading the same data set.
> >
> > J-D
> >
>

--047d7ba97e88ed543f04d3e54260--