Can we support seek for a reverse scan?

[Toshihiro Suzuki <br...@gmail.com>]

Hi folks,

We are facing “IllegalStateException: requestSeek cannot be called on ReversedKeyValueHeap" when using a reverse scan and the loadColumnFamiliesOnDemand optimization is enabled. As ReversedKeyValueHeap doesn't support requestSeek, it seems like the IllegalStateException occurs. I have already filed this issue to HBASE-20219, please see it for the details.

I tried to add a server-side check to forbid such scans, but as James mentioned in the Jira, this would have negative implications on performance.

I think the best solution is to make ReversedKeyValueHeap support seek if we can. What do you guys think about the feasibility of this?

Thanks,
Toshihiro Suzuki

Re: Can we support seek for a reverse scan?

[Toshihiro Suzuki <br...@gmail.com>]

Thank you for your reply, Stack. And Sorry for my late reply. Actually I overlooked your reply..

> I tried to add a server-side check to forbid such scans, but as James
> mentioned in the Jira, this would have negative implications on performance.
> 
> Which 'performance' I wonder?


I’m sorry I didn't explain it clearly enough.
Originally, I faced the issue when using Phoenix, which is explained by PHOENIX-4658. When running the SELECT query In the Jira, Phoenix tries to do a reverse scan and the loadColumnFamiliesOnDemand optimization, and then the IllegalStateException occurs. To avoid the IllegalStateException when running such a query, we have to disable the loadColumnFamiliesOnDemand optimization, but it can imply performance nagativly for some cases.

> It'd be a big job given plumbing for going in reverse is just absent
> (Reverse Scan is just a fake on top of forward Scanning; it is not even
> complete just reversing on rows, not on columns in a row...). You'd add
> reverse on indices in blocks and the notion of 'previous' to Scanners and
> Streams. It'd be slow given buffering and seeks 'naturally' are aimed in
> the forward direction.


I understood that we need to add and modify a lot of code to support seek for a reverse scan.

Thanks,
Toshihiro Suzuki

> On Apr 1, 2018, at 14:27, Stack <st...@duboce.net> wrote:
> 
> On Wed, Mar 28, 2018 at 11:31 PM, Toshihiro Suzuki <br...@gmail.com>
> wrote:
> 
>> Hi folks,
>> 
>> We are facing “IllegalStateException: requestSeek cannot be called on
>> ReversedKeyValueHeap" when using a reverse scan and the
>> loadColumnFamiliesOnDemand optimization is enabled. As ReversedKeyValueHeap
>> doesn't support requestSeek, it seems like the IllegalStateException
>> occurs. I have already filed this issue to HBASE-20219, please see it for
>> the details.
>> 
>> Yeah, that seems right given how reverse is 'implemented' (or, to be more
> correct, not implemented).
> 
> 
> 
>> I tried to add a server-side check to forbid such scans, but as James
>> mentioned in the Jira, this would have negative implications on performance.
>> 
>> Which 'performance' I wonder?
> 
> 
> 
>> I think the best solution is to make ReversedKeyValueHeap support seek if
>> we can. What do you guys think about the feasibility of this?
>> 
> 
> 
> It'd be a big job given plumbing for going in reverse is just absent
> (Reverse Scan is just a fake on top of forward Scanning; it is not even
> complete just reversing on rows, not on columns in a row...). You'd add
> reverse on indices in blocks and the notion of 'previous' to Scanners and
> Streams. It'd be slow given buffering and seeks 'naturally' are aimed in
> the forward direction.
> 
> Thanks,
> 
> S
> 
> 
> 
>> Thanks,
>> Toshihiro Suzuki
>> 
>> 

Re: Can we support seek for a reverse scan?

[Stack <st...@duboce.net>]

On Wed, Mar 28, 2018 at 11:31 PM, Toshihiro Suzuki <br...@gmail.com>
wrote:

> Hi folks,
>
> We are facing “IllegalStateException: requestSeek cannot be called on
> ReversedKeyValueHeap" when using a reverse scan and the
> loadColumnFamiliesOnDemand optimization is enabled. As ReversedKeyValueHeap
> doesn't support requestSeek, it seems like the IllegalStateException
> occurs. I have already filed this issue to HBASE-20219, please see it for
> the details.
>
> Yeah, that seems right given how reverse is 'implemented' (or, to be more
correct, not implemented).



> I tried to add a server-side check to forbid such scans, but as James
> mentioned in the Jira, this would have negative implications on performance.
>
>  Which 'performance' I wonder?



> I think the best solution is to make ReversedKeyValueHeap support seek if
> we can. What do you guys think about the feasibility of this?
>


It'd be a big job given plumbing for going in reverse is just absent
(Reverse Scan is just a fake on top of forward Scanning; it is not even
complete just reversing on rows, not on columns in a row...). You'd add
reverse on indices in blocks and the notion of 'previous' to Scanners and
Streams. It'd be slow given buffering and seeks 'naturally' are aimed in
the forward direction.

Thanks,

S



> Thanks,
> Toshihiro Suzuki
>
>