[ 
https://issues.apache.org/jira/browse/CASSANDRA-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16320304#comment-16320304
 ] 

Jason Brown commented on CASSANDRA-9067:
----------------------------------------

bq. But as the BloomFilter file doesn't have version support, how could we 
migrate the existing format to the new one?

Because the bloom filter is one of the sstable components, a specific bloom 
filter file is attached to a given sstable. And as each sstable has a version 
(ka, jb, mc, ...), you can add version-specific behavior to 
{{org.apache.cassandra.io.sstable.format.Version}}. 

In {{BigTableVersion}}, say we create a new version ({{na}}) for 4.0. You can 
know that any bloom filter file with anything less than {{na}} will use the old 
serialization format, and anything greater than or equal to {{na}} uses the 
optimized version.  You'll need to keep both serialization paths around in the 
code base, but as new sstables get written out and as old sstables get 
compacted away, eventually users will be on the optimized version.

For an example of how to do this, check out 
[{{BigTableVersion#hasMetadataChecksum}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigFormat.java#L133]
 (CASSANDRA-13321)


> BloomFilter serialization format should not change byte ordering
> ----------------------------------------------------------------
>
>                 Key: CASSANDRA-9067
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9067
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Jay Zhuang
>            Priority: Minor
>             Fix For: 4.x
>
>
> As a follow-up to CASSANDRA-9066 and CASSANDRA-9060, it appears we do some 
> unnecessary byte swapping during the serialization of bloom filters, which 
> makes the logic slower and harder to follow. We should either perform them 
> more efficiently (using Long.reverseBytes) or, preferably, eliminate the 
> conversion altogether since it does not appear to serve any purpose.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to