[
https://issues.apache.org/jira/browse/CASSANDRA-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko resolved CASSANDRA-8543.
------------------------------------------
Resolution: Not a Problem
> Allow custom code to control behavior of reading and compaction
> ---------------------------------------------------------------
>
> Key: CASSANDRA-8543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8543
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Pavol Slamka
> Priority: Minor
>
> When storing series data in blob objects because of speed improvements, it is
> sometimes neccessary to change only few values of a single blob (say few
> integers out of 1024 integers). Right now one could rewrite these using
> compare and set and versioning - read blob and version, change few values,
> write whole updated blob and incremented version if version did not change,
> repeat the whole process otherwise (optimistic approach). However compare and
> set brings some overhead. Let's try to leave out compare and set, and instead
> reading and updating, let's write only "blank" blob with only few values set.
> Blank blob contains special blank placeholder data such as NULL or max value
> of int or similar. Since this write in fact only appends new SStable record,
> we did not overwrite the old data yet. That happens during read or
> compaction. But if we provided custom read, and custom compaction, which
> would not replace the blob with a new "sparse blank" blob, but rather would
> replace values in first blob (first sstable record) with only "non blank"
> values from second blob (second sstable record), we would achieve fast
> partial blob update without compare and set on a last write wins basis. Is
> such approach feasible? Would it be possible to customize Cassandra so that
> custom code for compaction and data reading could be provided for a column
> (blob)?
> There may be other better solutions, but speedwise, this seems best to me.
> Sorry for any mistakes, I am new to Cassandra.
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
