hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-707) High-load import of data into single table/family never triggers split
Date Thu, 26 Jun 2008 00:50:46 GMT

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

stack commented on HBASE-707:
-----------------------------

Thanks for confirming patch Jon. The ISE is because your clocks are way skewed.   Will fix
that over in HBASE-710  I'll commit this patch later tonight.

> High-load import of data into single table/family never triggers split
> ----------------------------------------------------------------------
>
>                 Key: HBASE-707
>                 URL: https://issues.apache.org/jira/browse/HBASE-707
>             Project: Hadoop HBase
>          Issue Type: Bug
>    Affects Versions: 0.1.3
>         Environment: Linux 2.6.25-14.fc9.x86_64, Fedora Core 9
>            Reporter: Jonathan Gray
>             Fix For: 0.1.3
>
>         Attachments: 707.patch
>
>
> Importing a heavy amount of data into a single table and family.
> One column in that family (the same fam:col for every row) contains a frequently large
amount of UTF-8 data.  This column grows and grows but never causes a region split.
> Currently there is a single mapfile containing nearly 10GB.
> Eventually this has caused regions to crash with OOME, as described in HBASE-706
> Table in question:
> hql > describe items;
> +-----------------------------------------------------------------------------+
> | Column Family Descriptor                                                    |
> +-----------------------------------------------------------------------------+
> | name: cfrecs, max versions: 2, compression: NONE, in memory: false, max leng|
> | th: 2147483647, bloom filter: none                                          |
> +-----------------------------------------------------------------------------+
> | name: clusters, max versions: 2, compression: NONE, in memory: false, max le|
> | ngth: 2147483647, bloom filter: none                                        |
> +-----------------------------------------------------------------------------+
> | name: content, max versions: 2, compression: NONE, in memory: false, max len|
> | gth: 2147483647, bloom filter: none                                         |
> +-----------------------------------------------------------------------------+
> | name: readby, max versions: 2, compression: NONE, in memory: false, max leng|
> | th: 2147483647, bloom filter: none                                          |
> +-----------------------------------------------------------------------------+
> | name: receivedby, max versions: 2, compression: NONE, in memory: false, max |
> | length: 2147483647, bloom filter: none                                      |
> +-----------------------------------------------------------------------------+
> | name: savedby, max versions: 2, compression: NONE, in memory: false, max len|
> | gth: 2147483647, bloom filter: none                                         |
> +-----------------------------------------------------------------------------+
> | name: sentby, max versions: 2, compression: NONE, in memory: false, max leng|
> | th: 2147483647, bloom filter: none                                          |
> +-----------------------------------------------------------------------------+
> 7 columnfamily(s) in set. (0.34 sec)

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


Mime
View raw message