Indexes have another important advantage over multiple denormalized column families. If you make the copies yourself, eventually the copies will diverge from the base "true" column family due to routine occasional failures. You'll probably want to find and fix these inconsistencies.
If you're using built-in indexes, you won't have this problem and you can save some effort. -Dave On Feb 12, 2011 7:16 AM, "Bill de hÓra" <b...@dehora.net> wrote: > On Sat, 2011-02-12 at 14:03 +0100, Filip Nguyen wrote: > > >> Why the secondary indexes are even present in Cassandra? I thought the >> point is that development in Cassandra is query driven, that when you >> want to search and fetch for example by birth date you should create >> new ColumnFamilly... > > > > Yes and no. Systems like Cassandra are designed such that you should > write the data out as you want to read it in (because writes are cheap). > However most systems will want to access data via a few other criteria. > For example a blogging system that supports tags will need to list your > blog entries by date and by tag equally efficiently . As you say, you > can spin up a new ColumnFamilly for that, but it's such a common need > that Cassandra 0.7 supports it directly and saves developers having to > manage indexes by hand (under the hood, a 0.7 index is a 'private' CF). > This for me is one of the features that really sets Cassandra apart - > scaling and indexing data at the same time is hard, and very few systems > do both well. > > Bill
