On 17 January 2011 22:36, Steven Mac <ugs...@hotmail.com> wrote: > Sure, consider stock data, where the stock symbol is the row key. The stock > data consists of a rather stable part and a very volatile part, both of > which would be a super column. The stable super column would contain > subcolumns such as company name, address, and some annual or quarterly data. > The volatile super column would contain periodic stock data, such as current > price, last trade times, volumes, buyers, sellers, etc. > > The volatile super columns would be updated every few minutes, many rows at > once using a single batch_mutate. The data would be read using a get on a > single row key, returning both supercolumns and all subcolumns. > > The data could also be split over two column families, one for the stable > part and one for the volatile part. The updates would be the same, while a > read would require two get operations.
I'm not seeing why you need to use supercolumns for this at all. Standard columns would seem just fine in this case (as long as you have good naming for your columns) And you probably only need one column family... but people more expert than me could advise better... I guess the question I have is why you feel the solution should involve supercolumns -Stephen > > Regards, Steven. > > ________________________________ > Date: Mon, 17 Jan 2011 12:20:46 -0800 > Subject: Re: Super CF or two CFs? > From: davevi...@gmail.com > To: user@cassandra.apache.org > > can you give an example of the data and how you'd access it? > what would your expected columns (and/or supercolumns) be? > > Dave Viner > On Mon, Jan 17, 2011 at 11:05 AM, Steven Mac <ugs...@hotmail.com> wrote: > > How can I best map an object containing two maps, one of which is updated > very frequently and the other only occasionally? > > a) As one super CF, which each map in a separate supercolumn and the map > entries being the subcolumns? > b) As two CFs, one for each map. > > I'd like to discuss the why behind a choice, in order to learn about the > impact of a design choice on performance, SStable size/disk usage, > compactions, etc. > > Regards, Steven. > > PS: Objects will always be read as a whole. >