hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-2821) Keep young storefiles at lower replication
Date Wed, 13 Aug 2014 17:36:13 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095768#comment-14095768
] 

Andrew Purtell edited comment on HBASE-2821 at 8/13/14 5:36 PM:
----------------------------------------------------------------

bq. Interesting I wonder how much replica = 2 saves us with the default HDFS settings (first
copy local rack, 2nd copy other rack, 3rd copy other machine in other rack). We only save
a rack local copy.

Yeah, that's true. The expectation is within a rack we have full bisectional bandwidth from
any server to any other but the ToR switches are oversubscribed. So eliminating the third
replica without changing block placement policy doesn't buy us much (if anything)


was (Author: apurtell):
bq. Interesting I wonder how much replica = 2 saves us with the default HDFS settings (first
copy local rack, 2nd copy other rack, 3rd copy other machine in other rack). We only save
a rack local copy.

Or change policy so first copy local, 2nd copy rack local, 3rd copy other rack, and save on
cross rack traffic. The expectation is within a rack we have full bisectional bandwidth from
any server to any other but the ToR switches are oversubscribed.

> Keep young storefiles at lower replication
> ------------------------------------------
>
>                 Key: HBASE-2821
>                 URL: https://issues.apache.org/jira/browse/HBASE-2821
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: Todd Lipcon
>            Assignee: Andrew Purtell
>             Fix For: 2.0.0
>
>         Attachments: HBASE-2821.patch, lifetime-distribution.png, storefile_age.pl
>
>
> jgray and I were brainstorming some ideas about this:
> In a typical heavy-write scenario, many store files do not last very long. They're flushed
and then within a small number of seconds a compaction runs and they get deleted. For these
"short lifetime" store files, it's less likely that a failure will occur during the window
in which they're valid. So, I think we can consider some optimizations like the following:
> - Flush files at replication count 2. Scan once a minute for any store files in the region
that are older than 2 minutes. If they're found, increase their replication to 3. (alternatively,
queue them to avoid scanning)
> - More dangerous: flush files at replication count 1, but don't count them when figuring
log expiration. So, if they get lost, we force log splitting to recover.
> The performance gain here is that we avoid the network and disk transfer of writing the
third replica for a file that we're just about to delete anyway.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message