[ https://issues.apache.org/jira/browse/HBASE-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125118#comment-13125118 ]
Jonathan Hsieh commented on HBASE-4489: --------------------------------------- @Dave Part of me really just would prefer decouple rollingSplit from the presplit min/max value selection -- maybe change this in to two programs -- a custom presplit table generator program that handles key bounds, and a separate rollingSplit program that just splits based on given key ranges. I thought that there was agreement that we would keep MD5StringSplit as default for 0.90. It looks like the default was changed to UniformSplit from MD5StringSplit in both patches. While I generally agree with your point #3, it is a in 0.90 and would be a compatibility problem for anyone who depends on it. Would it make sense to change the default in trunk/0.92 (I'm fine with that) but leave 0.90.x as is? Nice functional test. Did you consider just doing a unit test on the split algorithm along with the cluster spinning functional test? I believe HBaseAdmin.create(HTableDescriptor htd,byte startKeys[][]) is well tested and would make the non @Ignored portions quicker. I can see how you need this setup for testing rollingSplit. Interesting div 0 bug. More testing, less surprises! Any reason why in testCreatePressplitTable you go to -0x71, 0x81 .. -0x11 instead of just going to 0x8f, 0x9f .. 0xff? Though more verbose, I think it is easier to read and follow if you use "positive" hex and cast all of them with (byte), or write out single longs and convert? > Better key splitting in RegionSplitter > -------------------------------------- > > Key: HBASE-4489 > URL: https://issues.apache.org/jira/browse/HBASE-4489 > Project: HBase > Issue Type: Improvement > Affects Versions: 0.90.4 > Reporter: Dave Revell > Assignee: Dave Revell > Attachments: HBASE-4489-branch0.90-v1.patch, > HBASE-4489-branch0.90-v2.patch, HBASE-4489-trunk-v1.patch, > HBASE-4489-trunk-v2.patch > > > The RegionSplitter utility allows users to create a pre-split table from the > command line or do a rolling split on an existing table. It supports > pluggable split algorithms that implement the SplitAlgorithm interface. The > only/default SplitAlgorithm is one that assumes keys fall in the range from > ASCII string "00000000" to ASCII string "7FFFFFFF". This is not a sane > default, and seems useless to most users. Users are likely to be surprised by > the fact that all the region splits occur in in the byte range of ASCII > characters. > A better default split algorithm would be one that evenly divides the space > of all bytes, which is what this patch does. Making a table with five regions > would split at \x33\x33..., \x66\x66...., \x99\x99..., \xCC\xCC..., and > \xFF\xFF. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira