http://www.edwardcapriolo.com/roller/edwardcapriolo/entry/whytf_would_i_need_with
On Tue, Feb 26, 2013 at 12:28 PM, Javier Sotelo <[email protected]> wrote: > Thanks Dean, very helpful info. > > Javier > > > On Tue, Feb 26, 2013 at 7:33 AM, Hiller, Dean <[email protected]> wrote: >> >> Oh, and 50 CF's should be fine. >> >> Dean >> >> From: Javier Sotelo >> <[email protected]<mailto:[email protected]>> >> Reply-To: "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>> >> Date: Tuesday, February 26, 2013 12:27 AM >> To: "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>> >> Subject: Re: Data Model - Additional Column Families or one CF? >> >> Aaron, >> >> Would 50 CFs be pushing it? According to >> http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-improved-memory-and-disk-space-management, >> "This has been tested to work across hundreds or even thousands of >> ColumnFamilies." >> >> What is the bottleneck, IO? >> >> Thanks, >> Javier >> >> >> On Sun, Feb 24, 2013 at 5:51 PM, Adam Venturella >> <[email protected]<mailto:[email protected]>> wrote: >> >> Thanks Aaron, this was a big help! >> >> — >> Sent from Mailbox<https://bit.ly/SZvoJe> for iPhone >> >> >> >> On Thu, Feb 21, 2013 at 9:27 AM, aaron morton >> <[email protected]<mailto:[email protected]>> wrote: >> >> If you have a limited / known number (say < 30) of types, I would create >> a CF for each of them. >> >> If the number of types is unknown or very large I would have one CF with >> the row key you described. >> >> Generally I avoid data models that require new CF's as the data grows. >> Additionally having different CF's allows you to use different cache >> settings, compactions settings and even storage mediums. >> >> Cheers >> >> ----------------- >> Aaron Morton >> Freelance Cassandra Developer >> New Zealand >> >> @aaronmorton >> http://www.thelastpickle.com >> >> On 21/02/2013, at 7:43 AM, Adam Venturella >> <[email protected]<mailto:[email protected]>> wrote: >> >> My data needs only require me to store JSON, and I can handle this in 1 >> column family by prefixing row keys with a type, for example: >> >> comments:{message_id} >> >> Where comments: represents the prefix and {message_id} represents some row >> key to a message object in the same column family. >> >> In this case comments:{message_id} would be a wide row using comment >> creation time and descending clustering order to sort the messages as they >> are added. >> >> My question is, would I be better off splitting comments into their own >> Column Family or is storing them in with the Messages Column Family >> sufficient, they are all messages after all. >> >> Or do Column Families really just provide a nice organizational front for >> data. I'm just storing JSON. >> >> >> >> >> >
