phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-5044) Remove server side mutation code from Phoenix
Date Wed, 05 Dec 2018 00:52:00 GMT


Lars Hofhansl commented on PHOENIX-5044:

There's some evidence that the server DELETE slowness might be an interaction of SEEK's and
DELETE's at the same time from the same SCAN (lot's of time being spent in seeks as seen in
the profiler).
I saw improvements when I switched the block encoding to ROW_INDEX_V1. I'm going to look into
that, too.

> Remove server side mutation code from Phoenix
> ---------------------------------------------
>                 Key: PHOENIX-5044
>                 URL:
>             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], [], [~jamestaylor], [~vincentpoon], [~gjacoby]

This message was sent by Atlassian JIRA

View raw message