alokob:
As Lars mentioned, for scan with RowFilter approach, set start and stop
rows properly so that the number of rows to scan is limited.
Probably you can play with both approaches using sample data to find out
which one is faster.
Cheers
On Wed, Feb 4, 2015 at 10:07 PM, lars hofhansl wrote:
Hello ,
as per what I read about hbase I found that enabling bloom filters actually
improve random read performance. My question is do we need to enable bloom
filters explicitly or they are enabled by default. We are using Hbase 0.98.
Any input in this regard is appreciated , thanks.
--
View
Thanks Lars.
Total number of records we are expecting is in the range of 5-10 millions ,
and as the records which we are willing to fetch from Hbase are result of
search result so there is no notion of start or end row. So depending on
you note with the scan approach I assume it will always be sl
Take a look at 86.4 under http://hbase.apache.org/book.html#perf.schema
Cheers
On Thu, Feb 5, 2015 at 12:28 AM, alokob wrote:
> Hello ,
>
> as per what I read about hbase I found that enabling bloom filters actually
> improve random read performance. My question is do we need to enable bloom
>
Really thankful for Ted's points.
Yes, the tight time range will cause scan to be very slow to fill the cache.
I will investigate the hbase-5032 further, will report to you if there are
some progresses and improvements.
Thank you!
-Bing
2015-02-05 11:34 GMT+08:00 Ted Yu :
> bq. set a sparse T
Ted thanks.
Yes I am going to try both the options.
--
View this message in context:
http://apache-hbase.679495.n3.nabble.com/Hbase-multiget-vs-scan-with-RowFilter-tp4068066p4068136.html
Sent from the HBase User mailing list archive at Nabble.com.
hi,
For test purpose, we're trying to export a test hbase table and import it
into a minicluster using org.apache.hadoop.hbase.mapreduce.Export
and org.apache.hadoop.hbase.mapreduce.Import.
The thing is, there was four regions in our original htable, but after
Importing, the imported htable has on
