Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@accumulo.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 dminer@clearedgeit.com does not designate 209.85.128.52 as permitted sender)
Subject: Re: ISAM file location vs. read performance
References: 
 <CAFu4t2hVjRxmaYiU2cB9dTrtG4JYEx1UJOUmapoBUM-G52Q_OQ@mail.gmail.com>
 <CADczPYTtv6V4DmNs_BK64Ograbxn9Pik1J3=kCu=s0QGHY11tg@mail.gmail.com>
 <CAFu4t2i6SaexcM5WMahgVftVF+x=a70q3v_ppJDvu4JtDK01sA@mail.gmail.com>
 <CAMz+DuvCb5eE8M3SY8xU9V2hF+kc0hDPcnXpMu7drOukuV3OSg@mail.gmail.com>
 <CAGHyZ6Kf8m0LPe3J8U7xY=bTCpjnAY=GQzb0cEh+GiVXoChyaw@mail.gmail.com>
 <52D32849.5090500@gmail.com>
From: Donald Miner <dminer@clearedgeit.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <52D32849.5090500@gmail.com>
Message-Id: <13A9718A-F829-4DFE-ACD6-C5195FF4C253@clearedgeit.com>
Date: Sun, 12 Jan 2014 19:26:32 -0500
To: "user@accumulo.apache.org" <user@accumulo.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

HDFS-385 ( https://issues.apache.org/jira/plugins/servlet/mobile#issue/HDFS-=
385 ) is for custom pluggable block placement policies and there has been so=
me talk (i think) about improving mean time to recovering and data locality i=
n hbase.

Basically this would allow accumulo to have a policy for its blocks and cont=
rol its own destiny... Instead of things like the rebalancer screwing things=
 up.

I honestly don't know much else about this. Just thought it might be relevan=
t to the conversation.=20

> On Jan 12, 2014, at 6:42 PM, Josh Elser <josh.elser@gmail.com> wrote:
>=20
>=20
>=20
>> On 1/12/14, 6:17 PM, Sean Busbey wrote:
>> On Sun, Jan 12, 2014 at 4:42 PM, William Slacum
>> <wilhelm.von.cloud@accumulo.net <mailto:wilhelm.von.cloud@accumulo.net>>
>> wrote:
>>=20
>>    Some data on short circuit reads would be great to have.
>>=20
>>=20
>> What kind of data are you looking for? Just HDFS read rates? or
>> specifically Accumulo when set up to make use of it?
>=20
> I believe what Bill means, and what I'm also curious about, is specificall=
y the impact on performance for Accumulo's workload: a merged read over mult=
iple files. An easy test might be to create multiple RFiles (1 to 10 files?)=
 which contain interspersed data. Test some sort of random-read and random-s=
eek+sequential-read workloads, from 1 to 10 RFiles, and with shortcircuit re=
ads on an off.
>=20
> Perhaps a slightly more accurate test would be to up the compaction ratio o=
n a table, and then bulk import them to a single table, and then just use th=
e regular client API.
>=20
>>    I'm unsure of how correct the "compaction leading to eventual
>>    locality" postulation is. It seems, to me at least, that in the case
>>    of a multi-block file, the file system would eventually try to
>>    distribute those blocks rather than leave them all on a single host.
>>=20
>>=20
>>=20
>>=20
>> I know in HBase set ups, it's common to either disable the HDFS Balancer
>> or just disable for a namespace containing the part of the filesystem
>> that handles HBase. Otherwise, when the blocks are moved off to other
>> hosts you get performance degradation until compaction can happen again.
>> I would expect the same thing ought to be done for Accumulo.
>=20
> AFAIK, HBase also does a lot more in regards to assigning Tablets in regar=
ds to the blocks that serve them, no? To my knowledge, Accumulo doesn't do a=
nything like this. I don't want users to think that disabling the HDFS balan=
cer is a good idea for Accumulo unless we have actual evidence.