[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddhi Mehta updated PHOENIX-5044: -- Labels: phoenix-hardening (was: ) > 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 > Labels: phoenix-hardening > 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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5044: --- Attachment: 5044-looksee-v3.txt > 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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5044: --- Description: 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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] was: 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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] > 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.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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5044: --- Attachment: 5044-looksee-v2.txt > 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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5044: --- Attachment: (was: 5044-looksee-v2.txt) > 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.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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5044: --- Attachment: 5044-looksee-v2.txt > 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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5044: --- Description: 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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] was: 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. (Not that server side reads - aggregation, filters, etc - are still insanely valuable and not affected by this) Let's discuss. [~tdsilva], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] > 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 > > 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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5044: --- Attachment: 5044-looksee.txt > 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.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], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5044: --- Description: 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. (Not that server side reads - aggregation, filters, etc - are still insanely valuable and not affected by this) Let's discuss. [~tdsilva], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] was: This is for *discussion*. 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. (Not that server side reads - aggregation, filters, etc - are still insanely valuable and not affected by this) Let's discuss. [~tdsilva], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] > 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 > > 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. > (Not that server side reads - aggregation, filters, etc - are still insanely > valuable and not affected by this) > Let's discuss. > [~tdsilva], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
