If only 0.01% of the rows are reaching 1GB, then HBase should be able to
handle that... However, there is few things you might want to keep in mind.
1) What is the distribution of those 0.01%? Any risk for most of them to
end up on the same region?
2) How is data ingested into the regions? Is that bulkloads so you can
increase the max region size?
3) How is the data going to grow? Will those 1GB rows become 10GB rows in a
4) Do you have any consistency constraints forcing you to keep the wide
2016-10-17 8:20 GMT-04:00 Sreeram <sreera...@gmail.com>:
> Thank you JMS ! The scenario of row size exceeding 1 GB is anticipated for
> very few rows ( < 0.01 %).
> Hope I can continue with the wide table approach. Do you see a problem ?
> On Mon, Oct 17, 2016 at 4:44 PM, Jean-Marc Spaggiari <
> jean-m...@spaggiari.org> wrote:
>> Hi Sreeram.,
>> HBase will not split a region withing a row. So if a row gets WAY to many
>> columns, its size can grow higher than the configured max region size.
>> Which, of course, is not recommended because your region will serve a
>> single row. If you think your row will become bigger than 1% or your max
>> regionsize, you are better to think about a tall design instead of a wide
>> 2016-10-17 5:31 GMT-04:00 Sreeram <sreera...@gmail.com>:
>> > Hi All,
>> > Please let me know if the maximum size of a HBase row (in terms of
>> > space) will be equal to the configured size of a region?
>> > I understand the parameter hbase.table.max.rowsize to be the maximum
>> > that can be transferred in a single get/scan operation and not related
>> > the actual size of row in HBase.
>> > Is my understanding correct? Kindly let me know.
>> > Regards,
>> > Sreeram