> in terms of our high-rate write load cassandra1.0.11 is about 3 (three!!) > times slower than cassandra-0.7.8 We've not had any reports of a performance drop off. All tests so far have show improvements in both read and write performance.
> I agree, such digests save some network IO, but they seem to be very bad in > terms of CPU and disk IO. The sha1 is created so we can diagnose corruptions in the -Data component of the SSTables. They are not used to save network IO. It is calculated while streaming the Memtable to disk so has no impact on disk IO. While not the fasted algorithm I would assume it's CPU overhead in this case is minimal. > there's already relatively small Bloom filter file, which can be used for > saving network traffic instead of sha1 digest. Bloom filters are used to test if a row key may exist in an SSTable. > any explanation ? If you can provide some more information on your use case we may be able to help. Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 30/08/2012, at 5:18 AM, Илья Шипицин <chipits...@gmail.com> wrote: > in terms of our high-rate write load cassandra1.0.11 is about 3 (three!!) > times slower than cassandra-0.7.8 > after some investigation carried out I noticed files with "sha1" extension > (which are missing for Cassandra-0.7.8) > > in maybeWriteDigest() function I see no option fot switching sha1 digests off. > > I agree, such digests save some network IO, but they seem to be very bad in > terms of CPU and disk IO. > why to use one more digest (which have to be calculated), there's already > relatively small Bloom filter file, which can be used for saving network > traffic instead of sha1 digest. > > any explanation ? > > Ilya Shipitsin
