[
https://issues.apache.org/jira/browse/HBASE-23279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979240#comment-16979240
]
Viraj Jasani commented on HBASE-23279:
--------------------------------------
[~stack] [~ram_krish]
IMO, there should not be an issue while reading meta entries with ROW_INDEX_V1
encoded meta since I am able to bring up multiple tables with multiple regions
locally with the attached patch i.e. meta and other tables with ROW_INDEX_V1
encoding.
I tried spending some time with meta, e.g splitting other tables, flushing
meta, flushing other tables etc. and there don't seem any issues. meta had
~69-101 entries for 3 tables while I kept splitting tables and flushing meta.
Somehow, not sure why specifically this
UT(TestGetClosestAtOrBefore.testUsingMetaAndBinary()) is failing with
ROW_INDEX_V1 encoded meta entries. If encoding is messing anything, encoded
meta would not have correct region entries right? at least locally flushing
meta should fail?
[~anoop.hbase]
{quote}Ya still good to experiment to know the extra size need because of
encoder. For same data if NONE have say 100 blocks, how many more blocks we
will end up having when it is ROW_INDEX_V1 . Good to know that math.
{quote}
Tried this experiment locally for 900k rows in 3 tables with and without
ROW_INDEX_V1 encoding.
Scan of 3 tables with these encodings:
# ROW_INDEX_V1:
## Size of Blocks: 1.1 GB
## Block Count: 12864
# NONE:
## Size of Blocks: 797.1 MB
## Block Count: 12576
> Switch default block encoding to ROW_INDEX_V1
> ---------------------------------------------
>
> Key: HBASE-23279
> URL: https://issues.apache.org/jira/browse/HBASE-23279
> Project: HBase
> Issue Type: Wish
> Affects Versions: 3.0.0, 2.3.0
> Reporter: Lars Hofhansl
> Assignee: Viraj Jasani
> Priority: Minor
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-23279.master.000.patch,
> HBASE-23279.master.001.patch, HBASE-23279.master.002.patch
>
>
> Currently we set both block encoding and compression to NONE.
> ROW_INDEX_V1 has many advantages and (almost) no disadvantages (the hfiles
> are slightly larger about 3% or so). I think that would a better default than
> NONE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
