[
https://issues.apache.org/jira/browse/HBASE-23279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16980993#comment-16980993
]
Viraj Jasani commented on HBASE-23279:
--------------------------------------
{quote}Patch looks good generally. Are the changes for the tests necessary
(keeping NONE as encoding) required to have them pass? That would be a bit
scary.
{quote}
This is true. We need those changes and might be problematic. btw
TestMobCompactor doesn't require NONE for all tests to pass but only for one
test: testMinorCompaction(), no of mob file counts(for family1 CF: L324) change
after compaction. May be I should update this specific test case with updated
no of file counts after compaction? *This test fails for ROW_INDEX_V1 and
FAST_DIFF encodings.*
TestHFileWriterV3 changes might need more attention since we get this
ArrayIndexOutOfBoundsException while copying from ByteBuffer to array.
{code:java}
java.lang.ArrayIndexOutOfBoundsExceptionjava.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method) at
org.apache.hadoop.hbase.util.ByteBufferUtils.copyFromBufferToArray(ByteBufferUtils.java:1149)
at org.apache.hadoop.hbase.nio.SingleByteBuff.get(SingleByteBuff.java:216) at
org.apache.hadoop.hbase.nio.SingleByteBuff.get(SingleByteBuff.java:228) at
org.apache.hadoop.hbase.io.hfile.TestHFileWriterV3.writeDataAndReadFromHFile(TestHFileWriterV3.java:257)
at
org.apache.hadoop.hbase.io.hfile.TestHFileWriterV3.testHFileFormatV3Internals(TestHFileWriterV3.java:110)
at
org.apache.hadoop.hbase.io.hfile.TestHFileWriterV3.testHFileFormatV3(TestHFileWriterV3.java:103){code}
However, *the above test fails for all encodings and pass only for NONE.*
TestGetClosestAtOrBefore can be ignored as per previous discussions and also
meta entries don't seem to have any issues locally.
{quote}Also the size difference is unexpectedly high... I guess it depends on
the size of the keys relative to the total size of the Cells, in my tests I've
seen about 3%. I tested with Phoenix
{quote}
I tested with LTT: bin/hbase ltt -tn t1 -write 1:10:300 -num_keys 999999
-families cf1
Typical RowKey length is ~38 with avg 4 cells.
An example:
{code:java}
ffff9979c9699b51cb7cda98e5bf84c2-616604 column=cf3:0,
timestamp=1574530970591, value=6\xDA\xC1\xB0\xA8\xA6\xBF* _\xA5!\x9A
ffff9979c9699b51cb7cda98e5bf84c2-616604 column=cf3:1,
timestamp=1574530970600, value=I\xFB\xBB\xB0H\xF2\x9Eo\x16
ffff9979c9699b51cb7cda98e5bf84c2-616604
column=cf3:increment, timestamp=1574530970613,
value=\xFF\xFF\xFF\xFF\x87\xE9\xDE\x05
ffff9979c9699b51cb7cda98e5bf84c2-616604
column=cf3:mutate_info, timestamp=1574530970613, value=
{code}
> 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,
> HBASE-23279.master.003.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)
