Mailing-List: contact hbase-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of ning.li.00@gmail.com
 designates 209.85.200.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=X3HMBpWUCMvURbrMiz6EnWssgdi6jR0GalO5vQLFdwKa3YQnFeiq7GYGHUijKfn28z
         qsj8NXkPPRilAgyAXlNYHlCs0EgK/2SEznlRZV00ziKZLYcryjHArHMec8L+OkRtIxCg
         7ukFvaa6RPD6omomDvksteWXeK0hqOt9sfhRk=
Message-ID: <d32473880808261555m389b14bxc50977d56e8538f8@mail.gmail.com>
Date: Tue, 26 Aug 2008 18:55:08 -0400
From: "Ning Li" <ning.li.00@gmail.com>
To: hbase-user@hadoop.apache.org
Subject: Re: Multi get/put
In-Reply-To: <4898C35E.2020405@duboce.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <7e536b1f0807280238n279a91a0n35119f908891b959@mail.gmail.com>
	 <31a243e70807281136y7424e72dtc7d03e08022b09fe@mail.gmail.com>
	 <7e536b1f0807290703j53807528nca009d8698d148b8@mail.gmail.com>
	 <4897727E.4080607@duboce.net>
	 <d32473880808050758p5325ba41ib912f956b55b9364@mail.gmail.com>
	 <4898C35E.2020405@duboce.net>

Some follow-up on the performance issues:

> > PERFORMANCE ISSUES
> > Our preliminary performance experiments show that the performance
> > of building an index is quite reasonable. However, the performance of
> > random reads in HDFS is so poor that the search performance is
> > dramatically worse than that on local file systems.
> >
> What do you mean by 'dramatic' in the above?  This is a sweet feature.  That
> its slow on first implementation is OK.  Are you thinking its so slow, its
> not functional?

On local FS, real disk IO is expensive. Lucene relies on FS cache to
provide high search performance on local FS. Because of this, the
following comparisons are based on warm test results.

The comparison is between the local FS and a one-node HDFS. HDFS
provides high sequential read performance but poor random read
performance mainly because of socket overhead when data is warm.

On HDFS 0.17.1, the search performance is more than an order of
magnitude slower than that on a local FS. Even with reusing socket
connection, the search performance is still about an order of
magnitude slower.

Since this is caused by the socket overhead in HDFS, you see similar
results with random reads on a map file. I used HBase's
MapFilePerformanceEvaluation. The random read performance is a bit
less than 7 times lower than that on a local FS. This is a bit better
than the search performance probably because a random read on a map
file is several almost-sequential reads on the data file in HDFS.

Given the above, would the search performance be acceptable?

PS: I saw on http://wiki.apache.org/hadoop/Hbase/PerformanceEvaluation
that the random read performance on a map file improved quite a bit
from 0.17.1 to 0.18.0. Any insight?