cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavol Slamka (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8543) Allow custom code to control behavior of reading and compaction
Date Mon, 29 Dec 2014 16:47:13 GMT


Pavol Slamka commented on CASSANDRA-8543:

Thank you very much for your hints!

> Allow custom code to control behavior of reading and compaction
> ---------------------------------------------------------------
>                 Key: CASSANDRA-8543
>                 URL:
>             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

View raw message