[
https://issues.apache.org/jira/browse/HBASE-13450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14510579#comment-14510579
]
Anoop Sam John commented on HBASE-13450:
----------------------------------------
{code}
public static int binarySearch(byte[][] arr, byte[] key, int offset, int
length) {
return binarySearch(arr, key, offset, length, Bytes.BYTES_RAWCOMPARATOR);
}
{code}
So while doing HBASE-10800 You will conevrt the calling method to take
CellComparator? Then this method impl also will change?
{code}
* @deprecated {@link Bytes#binarySearch(byte[][], byte[], int, int)}
@Deprecated
public static int binarySearch(byte [][]arr, byte []key, int offset,
int length, RawComparator<?> comparator) {
{code}
This method is used from BlockIndexReader with a KVComparator. Yes we have to
compare as KV key not as plain bytes. So all such places has to use the API
which takes CellComparator? May be we have to direct that also in @deprecated?
bq.public static int binarySearch(byte[][] arr, Cell key, Comparator<Cell>
comparator) {
Can we go more generic way?
{code}
public static <T> int binarySearch(T[] arr, T key, Comparator<T> comparator) {
int low = 0;
int high = arr.length - 1;
while (low <= high) {
int mid = (low + high) >>> 1;
// we have to compare in this order, because the comparator order
// has special logic when the 'left side' is a special key.
int cmp = comparator.compare(key, arr[mid]);
// key lives above the midpoint
if (cmp > 0)
low = mid + 1;
// key lives below the midpoint
else if (cmp < 0)
high = mid - 1;
// BAM. how often does this really happen?
else
return mid;
}
return -(low + 1);
}
{code}
The point is when you are going to have key as Cell, pass an array of Cells.
Similarly and array of byte[] can be compared against a single byte[] key. The
former might be useful in block index area and later in some bloom area? Not
sure
{quote}
if (comparatorClassName.equals(KeyValue.RAW_COMPARATOR.getClass().getName())) {
572 // Return null for Bytes.BYTES_RAWCOMPARATOR
573 return null;
574 }
{quote}
Similar way you want to return null for
{code}
else if
(comparatorClassName.equals(KeyValue.RAW_COMPARATOR.getLegacyKeyComparatorName()))
{
comparatorClassName = KeyValue.RAW_COMPARATOR.getClass().getName();
}
{code}
> Purge RawBytescomparator from the writers and readers after HBASE-10800
> -----------------------------------------------------------------------
>
> Key: HBASE-13450
> URL: https://issues.apache.org/jira/browse/HBASE-13450
> Project: HBase
> Issue Type: Sub-task
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-13450.patch, HBASE-13450_2.patch,
> HBASE-13450_3.patch, HBASE-13450_4.patch
>
>
> Currently KeyValue.RAW_COMPARATOR is written in the Trailer of the HFiles.
> Ideally this need not be persisted to the trailer of the Hfiles because only
> the ROW bloom and the meta index blocks uses this. Currently RAW_COMPARATOR
> is also of type KVComparator.
> HBASE-10800 would introduce CellComparator and would expect only cells to be
> compared. We cannot have RAW_COMPARATOR a type of CellComparator. Hence it
> is better to avoid writing the RAW_COMPARATOR to the FFT and whereever we
> need RAW_COMPARATOR we will directly use it as Bytes.BYTES_RAWCOMPARATOR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)