Also, if you are concerned that your updates are being scattered through multiple files, there is a metric exposed via JMX that can tell you how many SSTables your reads need to hit: see the (Recent)SSTablePerRead histogram on each column family.
Many write patterns won't be affected by the existing implementation, but constant updates to rows will lower your performance until a solution to #1608 is available. On Sat, Apr 9, 2011 at 7:22 PM, Stu Hood <stuh...@gmail.com> wrote: > Sorry, I meant to say #2319: > https://issues.apache.org/jira/browse/CASSANDRA-2319 > > > On Sat, Apr 9, 2011 at 6:04 PM, Stu Hood <stuh...@gmail.com> wrote: > >> If an SSTable contains an update for a row (row, not just column), we need >> to read from it. See #1608 for some of the ideas that have been floated on >> how to improve this situation: the core ones are 1. partitioning local data >> so that the the number of files involved in a read is smaller, 2. adding >> support for "superceding" data in older files so that they can be skipped. >> #2316 will provide the beginning of a solution to this problem for wide >> rows. >> >> >> On Sat, Apr 9, 2011 at 5:52 PM, mcasandra <mohitanch...@gmail.com> wrote: >> >>> That I understand but my basic quesiton was how does it know that there >>> are >>> multiple updates that have occurred on the same column? and how does it >>> efficiently knows which sstable have these updates? >>> >>> -- >>> View this message in context: >>> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Columns-values-integer-need-frequent-updates-increments-tp6251464p6258033.html >>> Sent from the cassandra-u...@incubator.apache.org mailing list archive >>> at Nabble.com. >>> >> >> >
