Cassandra was designed for spinning disks - commitlogs are (mostly) append-only, linear writes. sstables are written exactly once, again with linear writes. The index for finding the positions in sstables to start reads is cached in RAM (and when it's not cached, it's a linear read through a file). Most reads for sstables are linear seeks. Cassandra tries to optimize for fewest possible sstable reads (using things like bloom filters and compaction strategies that optimize for fewer files touched per read - STCS row lifting, and LCS in general). Some day we may have b/b+ tree indices, which will not be linear reads, but right now everything is linear.
All of that said: SSDs ARE faster, and you're not always CPU bound. You'll get better latencies when you do have to go to disk if you're using SSDs, but you can CERTAINLY make spinning disks work. On Thu, Sep 28, 2017 at 11:19 PM, Peng Xiao <2535...@qq.com> wrote: > Hi there, > we are struggling on hardware selection,we all know that ssd is good,and > Datastax suggests us to use ssd,as Cassandra is a CPU bound db,we are > considering to use sata disk,we noticed that the normal IO throughput is > 7MB/s. > > Could anyone give some advice? > > Thanks, > Peng Xiao > >
