[
https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701305#comment-16701305
]
Vincent Poon commented on PHOENIX-5044:
---------------------------------------
I think this makes a lot of sense for DELETE. It'll probably be more
controversial for UPSERT SELECT, as you could potentially have a lot more data
being sent back to the client.
The main reason I would be for this is because it's semantically correct in the
sense that the right APIs would be used, whereas the current implementation on
the server-side is writing from within a scan. This is problematic because you
run into locking issues wherein you've already obtained a read lock, yet
potentially may need a write lock for splits, etc. Also, we can't make use of
existing HBase scanner heartbeats, partial results, etc, since those rely on
calling next() on the scanner repeatedly, whereas all our logic is inside the
preScannerOpen hook.
By moving things to the client, the client uses the scan API to read and the
mutate API to write, and we make use of the scanner features of HBase.
Might be worthwhile reimplementing the way the server-side is done. Maybe
removing the existing code first will force that :)
> Remove server side mutation code from Phoenix
> ---------------------------------------------
>
> Key: PHOENIX-5044
> URL: https://issues.apache.org/jira/browse/PHOENIX-5044
> Project: Phoenix
> Issue Type: Task
> Reporter: Lars Hofhansl
> Priority: Major
> Attachments: 5044-looksee-v2.txt, 5044-looksee.txt
>
>
> This is for *discussion*. Perhaps controversial.
> It generally seems to be a bad idea - if well-intentioned - idea to trigger
> mutations directly from the server. The main causes are UPSERT SELECT for the
> same table and DELETE FROM.
> IMHO, it's generally better to allow the client to handle this. There might
> be larger network overhead, but we get better chunking, better pacing, and
> behavior more in line with how HBase was intended to work.
> In PHOENIX-5026 I introduced a flag to disable server triggered mutations in
> the two cases mentioned above. I now think it's better to just remove the
> server code and also perform these from the client.
> (Note that server side reads - aggregation, filters, etc - are still insanely
> valuable and not affected by this)
> Let's discuss.
> [~tdsilva], [[email protected]], [~jamestaylor], [~vincentpoon], [~gjacoby]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
