ColumnFamilies vs composite rows in one table.

2010-03-05 Thread Erik Holstad
What are the benefits of using multiple ColumnFamilies compared to using a composite row name? Example: You have messages that you want to index on sent and to. So you can either have ColumnFamilyFrom:userTo:{userFrom-messageid} ColumnFamilyTo:userFrom:{userTo-messageid} or something like

Re: ColumnFamilies vs composite rows in one table.

2010-03-05 Thread David Strauss
On 2010-03-05 18:04, Erik Holstad wrote: What are the benefits of using multiple ColumnFamilies compared to using a composite row name? Just for terminology's sake, I'll note that rows have keys, not names. Only columns and supercolumns have names. I'm not the top expert here by any means, but

Re: ColumnFamilies vs composite rows in one table.

2010-03-05 Thread David Strauss
On 2010-03-05 18:30, David Strauss wrote: On 2010-03-05 18:04, Erik Holstad wrote: So you can either have ColumnFamilyFrom:userTo:{userFrom-messageid} ColumnFamilyTo:userFrom:{userTo-messageid} or something like ColumnFamily:user_to:{user1_messageId, user2_messageId}

Re: ColumnFamilies vs composite rows in one table.

2010-03-05 Thread Jonathan Ellis
Generally, you want to have different types of data in different CFs so you can tune them separately (key / row caches). Mixing different row types in one CF also makes doing get_slice_range scans difficult. On Fri, Mar 5, 2010 at 12:04 PM, Erik Holstad erikhols...@gmail.com wrote: What are the