> Do you understand you are assuming there have been no compactions, > which would be extremely bad practice given this number of SSTables? > A major compaction, as would be best practice given this volume, would > result in 1 SSTable per CF per node. One. Similarly, you are > assuming the update is only on the last replica checked, but the > system is going to read and write the first replica (the node that > actually has that range based on its token) first in almost all > situations. > > Not worst case? If 'we' are coming up with arbitrarily bad > situations, why not assume 1 row per SSTable, lots of tombstones, in > addition to no compactions? Why not assume RF=100? Why not assume > node failures right in the middle of your query? The interesting > question is not 'how bad can this get if you configure and operate > things really badly?', but 'how bad can this get if you configure and > operate things according to best practices?'. >
Agreed. Doing a worst case complexity analysis is tricky because a) you need to know what best practices are and b) you have to know when using best practices what is the worst case "snapshot" of a healthy cluster to analyze. For example, major compactions happen periodically and so iops should degrade all the way up until the next major compaction. It's a very interesting question though and I would love to see this pursued further. Scott
