Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 5 Feb 2016 09:32:39 +0000 (UTC)
From: "Duo Zhang (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12911749.1447124202000.309753.1454664759979@Atlassian.JIRA>
In-Reply-To: <JIRA.12911749.1447124202000@Atlassian.JIRA>
References: <JIRA.12911749.1447124202000@Atlassian.JIRA>
 <JIRA.12911749.1447124202700@arcas>
Subject: [jira] [Commented] (HBASE-14790) Implement a new DFSOutputStream
 for logging WAL only
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Duo Zhang commented on HBASE-14790:
-----------------------------------

I have got a 5 regionservers test cluster and run pe tool with async enabled or disabled several times.
The total throughput is same, and the .999 is a little smaller with async enabled. I think this is what we expect :)

This is only a simple test, not the final result. Will be back after spring festival.

Thanks.

> Implement a new DFSOutputStream for logging WAL only
> ----------------------------------------------------
>
>                 Key: HBASE-14790
>                 URL: https://issues.apache.org/jira/browse/HBASE-14790
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Duo Zhang
>
> The original {{DFSOutputStream}} is very powerful and aims to serve all purposes. But in fact, we do not need most of the features if we only want to log WAL. For example, we do not need pipeline recovery since we could just close the old logger and open a new one. And also, we do not need to write multiple blocks since we could also open a new logger if the old file is too large.
> And the most important thing is that, it is hard to handle all the corner cases to avoid data loss or data inconsistency(such as HBASE-14004) when using original DFSOutputStream due to its complicated logic. And the complicated logic also force us to use some magical tricks to increase performance. For example, we need to use multiple threads to call {{hflush}} when logging, and now we use 5 threads. But why 5 not 10 or 100?
> So here, I propose we should implement our own {{DFSOutputStream}} when logging WAL. For correctness, and also for performance.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)