On Feb 22, 2010, at 12:19 AM, ext Jonathan Ellis wrote:

>>  2) is the row key model I suggested above the best approach in Cassandra, 
>> or is there something better? My testing so far has been using 
>> get_range_slice with a ColumnParent of just the CF and SlicePredicate 
>> listing the columns I want (though really I want all columns, is there a 
>> shorthand for that?)
> Cassandra deals fine with millions of columns per row, and allows
> prefix queries on columns too.  So an alternate model would be to have
> userX as row key, and column keys "A:1, A:2, A:3, ..., B:1, B:2, B:3,
> ...".  This will be marginally faster than splitting by row, and has
> the added advantage of not requiring OPP.
> You could use supercolumns here too (where the supercolumn name is the
> thing type).  If you always want to retrieve all things of type A at a
> time per user, then that is a more natural fit.  (Otherwise, the lack
> of subcolumn indexing could be a performance gotcha for you:
> http://issues.apache.org/jira/browse/CASSANDRA-598).

Would you say the supercolumn approach is faster than scanning rows? Any 
particular advantages or disadvantages to writing to a bunch of supercolumns at 
once (e.g. in one user row), vs. writing to a bunch of rows at once (with the 
same key prefix, i.e. close together in an order-preserved store)?

>>  3) schema changes (i.e. adding a new CF)... seems like currently you take 
>> the whole cluster down to accomplish this... is that likely to change in the 
>> future?
> You have to take each node down, but a rolling restart is fine.  No
> reason for the whole cluster to be down at once.

OK, that's not a big deal.

Extremely helpful... thanks for the response!


Reply via email to