[
https://issues.apache.org/jira/browse/PHOENIX-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-113:
---------------------------------
Attachment: useKeyValueBuilderOnServer.patch
Moved KeyValueBuilder stuff into index package (as that's what it's original
purpose was for anyway - to help with the memory bloat).
Clone mutation if necessary.
> Enable usage of ClientKeyValue on for indexing on server
> --------------------------------------------------------
>
> Key: PHOENIX-113
> URL: https://issues.apache.org/jira/browse/PHOENIX-113
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: James Taylor
> Fix For: 3.0.0
>
> Attachments: phoenix-113-sketch.txt, useKeyValueBuilderOnServer.patch
>
>
> Modify code to go through KeyValueBuilder where necessary. Adding abstraction
> for having different KVComparator on each KeyValueBuilder impl.
> Still doesn't work on the server-side due to memstore needing a backing
> buffer for the KeyValue.
> According to [~jesse_yates], the options are:
> 1. Update the ClientKeyValues on the way out via a new hook in the codec,
> e.g. "preWriteToIndexTable(List<Mutation>, byte[] indexTable)",
> Wrap all the clientkvs in something like an ImmutableClientKeyValue that does
> the right thing for getBuffer, getOffset, etc, but without doing all the
> copying. This may be easier to just do as modifications to ClientKeyValue,
> but seems easier to start as a new class first
> 2. Automatically check all the mutations being written in the
> ParallelIndexWriter for being clientKeyvalues
> A bit more painful than the above, since you could short circuit there, but
> easier in terms of code complexity
> 3. Check to see if the write is going to a local region and then transform
> the ClientKeyValues when necessary
> Most difficult as it reaches down into the guts of the coprocessor logic for
> determining region location. Unfortunately, it is already being done by the
> CoprocessorHConnection, but we would need to recreate it for us before it
> hits the HTable.
> You could do it by creating a CoprocessorHConnection and then wrapping that
> in a ClientKeyValueCheckingHConnection and then passing that into the
> constructor for HTable creation.
> This is even more onerous as that constructor is only available on an HTable
> directly, not via the CoprocessorEnvironment, meaning we have to manually
> close tables. We have pretty good exception wrapping, so its not terrible to
> implement, but still a pain to do.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
