[
https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16708217#comment-16708217
]
Lars Hofhansl commented on PHOENIX-5044:
----------------------------------------
I'll report back when we have deployed this (or rather PHOENIX-5026) into
production.
Here, I'll maintain, though, that I was able to have a simple delete of 16m
small rows (int key, float, float, int) after waiting for 180s. No amount of
distribution in a real cluster is going to fix this when 16m tiny rows can lock
up two (2 regions) handler thread for over 180s and then still fail.
> 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
> Assignee: Lars Hofhansl
> Priority: Major
> Attachments: 5044-looksee-v2.txt, 5044-looksee-v3.txt,
> 5044-looksee.txt
>
>
> This is for *discussion*. Perhaps controversial.
> It generally seems to be a bad - 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)
