Mohammed, to add to previous answers, EBS is network attached, with SSD or without it , you access your disk via network constrained by network bandwidth and latency, if you really need to improve IO performance try switching to ephemeral storage (also called instance storage) which is physically attached to EC2 instance, and is as good as native disk IO goes.
On Tue, Sep 16, 2014 at 11:39 PM, James Briggs <james.bri...@yahoo.com> wrote: > To expand on what Robert said, Cassandra is a log-structured database: > > - writes are append operations, so both correctly configured disk volumes > and SSD are fast at that > - reads could be helped by SSD if they're not in cache (ie. on disk) > - but compaction is definitely helped by SSD with large data loads > (compaction is the trade-off for fast writes) > > Thanks, James Briggs. > -- > Cassandra/MySQL DBA. Available in San Jose area or remote. > Mailbox dimensions: 10"x12"x14" > > ------------------------------ > *From:* Robert Coli <rc...@eventbrite.com> > *To:* "user@cassandra.apache.org" <user@cassandra.apache.org> > *Sent:* Tuesday, September 16, 2014 5:42 PM > *Subject:* Re: no change observed in read latency after switching from > EBS to SSD storage > > > > On Tue, Sep 16, 2014 at 5:35 PM, Mohammed Guller <moham...@glassbeam.com> > wrote: > > Does anyone have insight as to why we don't see any performance impact on > the reads going from EBS to SSD? > > > What does it say when you enable tracing on this CQL query? > > 10 seconds is a really long time to access anything in Cassandra. There > is, generally speaking, a reason why the default timeouts are lower than > this. > > My conjecture is that the data in question was previously being served > from the page cache and is now being served from SSD. You have, in > switching from EBS-plus-page-cache to SSD successfully proved that SSD and > RAM are both very fast. There is also a strong suggestion that whatever > access pattern you are using is not bounded by disk performance. > > =Rob > > > >
