[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hadoop-dev
Subject:    [jira] Commented: (HADOOP-2291) [hbase] Add row count estimator
From:       "Edward Yoon (JIRA)" <jira () apache ! org>
Date:       2007-12-31 10:46:43
Message-ID: 13877141.1199098003257.JavaMail.jira () brutus
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/HADOOP-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12555077 \
] 

Edward Yoon commented on HADOOP-2291:
-------------------------------------

Thanks comments, stack.
Now I test it with HADOOP-2480 (real log data table).
Please wait.


> [hbase] Add row count estimator
> -------------------------------
> 
> Key: HADOOP-2291
> URL: https://issues.apache.org/jira/browse/HADOOP-2291
> Project: Hadoop
> Issue Type: New Feature
> Components: contrib/hbase
> Reporter: stack
> Assignee: Edward Yoon
> Priority: Minor
> Attachments: 2291_v01.patch, Keying.java
> 
> 
> Internally we have a little tool that will do a rough estimate of how many rows \
> there are in a dataHbase.  It keeps getting larger and larger partitions running \
> scanners until it turns up > N occupied rows.  Once it has a number > N, it \
> multiples by the partition size to get an approximate row count.   This issue is \
> about generalizing this feature so it could sit in the general hbase install.  It \
> would look something like: {code}
> long getApproximateRowCount(final Text startRow, final Text endRow, final long \
> minimumCountPerPartition, final long maximumPartitionSize) {code}
> Larger minimumCountPerPartition and maximumPartitionSize values would make the \
> count more accurate but would mean the method ran longer.

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


[prev in list] [next in list] [prev in thread] [next in thread]