I was curious and did some digging. 400k is the max read IOPs on the 1-device instance types, 3M IOPS is for the 8-device instance types.
From: Reid Pinchback <rpinchb...@tripadvisor.com> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> Date: Friday, February 14, 2020 at 11:24 AM To: "user@cassandra.apache.org" <user@cassandra.apache.org> Subject: Re: AWS I3.XLARGE retiring instances advices Message from External Sender I’ve seen claims of 3M IOPS on reads for AWS, not sure about writes. I think you just need a recent enough kernel to not get in the way of doing multiqueue operations against the NVMe device. Erick, a question purely as a point of curiosity. The entire model of a commit log, historically (speaking in RDBS terms), depended on a notion of stable store. The idea being that if your data volume lost recent writes, the failure mode there would be independent of writes to the volume holding the commit log, so that replay of the commit log could generally be depended on to recover the missing data. I’d be curious what the C* expert viewpoint on that would be, with the commit log and data on the same volume. From: Sergio <lapostadiser...@gmail.com> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> Date: Thursday, February 13, 2020 at 10:46 PM To: "user@cassandra.apache.org" <user@cassandra.apache.org> Subject: Re: AWS I3.XLARGE retiring instances advices A little off-topic but personally I would co-locate the commitlog on the same 950GB NVMe SSD as the data files. You would get a much better write performance from the nodes compared to EBS and they shouldn't hurt your reads since the NVMe disks have very high IOPS. I think they can sustain 400K+ IOPS (don't quote me). I'm sure others will comment if they have a different experience. And of course, YMMV. Cheers!
