[jira] [Updated] (HBASE-4102) atomicAppend: A put that appends to the latest version of a cell; i.e. reads current value then adds the bytes offered by the client to the tail and writes out a new entr
[ https://issues.apache.org/jira/browse/HBASE-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4102: - Assignee: Lars Hofhansl This seems like a simple useful addition. Should this be in 0.92 or 0.94? > atomicAppend: A put that appends to the latest version of a cell; i.e. reads > current value then adds the bytes offered by the client to the tail and > writes out a new entry > --- > > Key: HBASE-4102 > URL: https://issues.apache.org/jira/browse/HBASE-4102 > Project: HBase > Issue Type: New Feature >Reporter: stack >Assignee: Lars Hofhansl > > Its come up a few times that clients want to add to an existing cell rather > than make a new cell each time. At our place, the frontend keeps a list of > urls a user has visited -- their md5s -- and updates it as user progresses. > Rather than read, modify client-side, then write new value back to hbase, it > would be sweet if could do it all in one operation in hbase server. TSDB > aims to be space efficient. Rather than pay the cost of the KV wrapper per > metric, it would rather have a KV for an interval an in this KV have a value > that is all the metrics for the period. > It could be done as a coprocessor but this feels more like a fundamental > feature. > Benoît suggests that atomicAppend take a flag to indicate whether or not the > client wants to see the resulting cell; often a client won't want to see the > result and in this case, why pay the price formulating and delivering a > response that client just drops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4102) atomicAppend: A put that appends to the latest version of a cell; i.e. reads current value then adds the bytes offered by the client to the tail and writes out a new entr
[ https://issues.apache.org/jira/browse/HBASE-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4102: - Attachment: 4102.txt Here's a first patch. I hopefully minimized the copying and creation of byte[] in the regionserver. I added a new constructor to KeyValue to be able to create an empty but pre-sized KeyValue that can be filled later. There's a lot of boilerplate that is very similar between Put, Increment, and now Append. Could think about factoring some more of it out. > atomicAppend: A put that appends to the latest version of a cell; i.e. reads > current value then adds the bytes offered by the client to the tail and > writes out a new entry > --- > > Key: HBASE-4102 > URL: https://issues.apache.org/jira/browse/HBASE-4102 > Project: HBase > Issue Type: New Feature >Reporter: stack >Assignee: Lars Hofhansl > Attachments: 4102.txt > > > Its come up a few times that clients want to add to an existing cell rather > than make a new cell each time. At our place, the frontend keeps a list of > urls a user has visited -- their md5s -- and updates it as user progresses. > Rather than read, modify client-side, then write new value back to hbase, it > would be sweet if could do it all in one operation in hbase server. TSDB > aims to be space efficient. Rather than pay the cost of the KV wrapper per > metric, it would rather have a KV for an interval an in this KV have a value > that is all the metrics for the period. > It could be done as a coprocessor but this feels more like a fundamental > feature. > Benoît suggests that atomicAppend take a flag to indicate whether or not the > client wants to see the resulting cell; often a client won't want to see the > result and in this case, why pay the price formulating and delivering a > response that client just drops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4102) atomicAppend: A put that appends to the latest version of a cell; i.e. reads current value then adds the bytes offered by the client to the tail and writes out a new entr
[ https://issues.apache.org/jira/browse/HBASE-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4102: - Attachment: 4102-v1.txt Thanks Ted... New change addressing all your points. > atomicAppend: A put that appends to the latest version of a cell; i.e. reads > current value then adds the bytes offered by the client to the tail and > writes out a new entry > --- > > Key: HBASE-4102 > URL: https://issues.apache.org/jira/browse/HBASE-4102 > Project: HBase > Issue Type: New Feature >Reporter: stack >Assignee: Lars Hofhansl > Attachments: 4102-v1.txt, 4102.txt > > > Its come up a few times that clients want to add to an existing cell rather > than make a new cell each time. At our place, the frontend keeps a list of > urls a user has visited -- their md5s -- and updates it as user progresses. > Rather than read, modify client-side, then write new value back to hbase, it > would be sweet if could do it all in one operation in hbase server. TSDB > aims to be space efficient. Rather than pay the cost of the KV wrapper per > metric, it would rather have a KV for an interval an in this KV have a value > that is all the metrics for the period. > It could be done as a coprocessor but this feels more like a fundamental > feature. > Benoît suggests that atomicAppend take a flag to indicate whether or not the > client wants to see the resulting cell; often a client won't want to see the > result and in this case, why pay the price formulating and delivering a > response that client just drops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4102) atomicAppend: A put that appends to the latest version of a cell; i.e. reads current value then adds the bytes offered by the client to the tail and writes out a new entr
[ https://issues.apache.org/jira/browse/HBASE-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4102: - Fix Version/s: 0.94.0 > atomicAppend: A put that appends to the latest version of a cell; i.e. reads > current value then adds the bytes offered by the client to the tail and > writes out a new entry > --- > > Key: HBASE-4102 > URL: https://issues.apache.org/jira/browse/HBASE-4102 > Project: HBase > Issue Type: New Feature >Reporter: stack >Assignee: Lars Hofhansl > Fix For: 0.94.0 > > Attachments: 4102-v1.txt, 4102.txt > > > Its come up a few times that clients want to add to an existing cell rather > than make a new cell each time. At our place, the frontend keeps a list of > urls a user has visited -- their md5s -- and updates it as user progresses. > Rather than read, modify client-side, then write new value back to hbase, it > would be sweet if could do it all in one operation in hbase server. TSDB > aims to be space efficient. Rather than pay the cost of the KV wrapper per > metric, it would rather have a KV for an interval an in this KV have a value > that is all the metrics for the period. > It could be done as a coprocessor but this feels more like a fundamental > feature. > Benoît suggests that atomicAppend take a flag to indicate whether or not the > client wants to see the resulting cell; often a client won't want to see the > result and in this case, why pay the price formulating and delivering a > response that client just drops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
