Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1721451759.1236387056040.JavaMail.jira@brutus>
Date: Fri, 6 Mar 2009 16:50:56 -0800 (PST)
From: "Ben Maurer (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Updated: (HADOOP-5369) Small tweaks to reduce MapFile index
 size
In-Reply-To: <858760207.1235853972753.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HADOOP-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ben Maurer updated HADOOP-5369:
-------------------------------

    Attachment: smaller_mapfile.patch

Another hbase triggered bug -- midKey appeared to throw an exception if the file was empty, however, the code (count - 1) / 2 turned in to -1/2, which in java is zero. Because the arrays were never resized, it ended up just returning null. I've restored this behavior (as users were depending on it), documented and tested it.

> Small tweaks to reduce MapFile index size
> -----------------------------------------
>
>                 Key: HADOOP-5369
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5369
>             Project: Hadoop Core
>          Issue Type: Improvement
>            Reporter: Ben Maurer
>            Assignee: Ben Maurer
>             Fix For: 0.21.0
>
>         Attachments: mapfile.patch, smaller_mapfile.patch, smaller_mapfile.patch, smaller_mapfile.patch
>
>
> Two minor tweaks can help reduce the memory overhead of the MapFile index a bit:
> 1) Because the index file is a sequence file, it's length is not known. That means the index is built using the standard "mulitply the size of the buffer on overflow" with a factor of 3/2. With small keys, the slack in the index can be substantial. This patch has a constant upper bound on the amount of slack allowed.
> 2) In block compressed map files the index file often has entries with the same offset (because the compressed block had more than index interval keys). The entries with identical offsets do not help MapFile do random access any faster. This patch eliminates these types of entries from new map files, and ignores them while reading old map files. This patch greatly helped with memory usage on a compressed hbase table.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.