[
https://issues.apache.org/jira/browse/HBASE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592753#comment-13592753
]
Nick Dimiduk commented on HBASE-7743:
-------------------------------------
bq. I could see it going away if we emitted Key and comparator was KeyValues's
Key comparator.
This quote is from [~stack] on HBASE-7747. Can you follow-up on this comment.
Is KeyValue$KeyComparator the correct comparator to use for a Hadoop secondary
sort before generating an HFile or Mutation instances per row?
KeyValueSortReducer uses KeyValue.COMPARATOR which is an instance of
KeyValue$KVComparator.
> Replace *SortReducers with Hadoop Secondary Sort
> ------------------------------------------------
>
> Key: HBASE-7743
> URL: https://issues.apache.org/jira/browse/HBASE-7743
> Project: HBase
> Issue Type: Improvement
> Components: mapreduce, Performance
> Reporter: Nick Dimiduk
>
> The mapreduce package provides two Reducer implementations,
> KeyValueSortReducer and PutSortReducer, which are used by Import, ImportTsv,
> and WALPlayer in conjunction with the HFileOutputFormat. Both of these
> implementations make use of a TreeSet to sort values matching a key. This
> reducer will OOM when rows are large.
> A better solution would be to implement secondary sort of the values. That
> way hadoop sorts the records, spilling to disk when necessary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
