Stupid cell phone. I would say no. If you design around row cache and your data access patterns change, the original assertions may be invalidated and the performance might be worst then the simple design.
On Mon, Oct 21, 2013 at 12:03 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote: > I would say no. If you design around row cache and your data acceas > patterns change your assertions will be invalidates and your performance > may be worst over time. > > I would use the kiss here. Keep it a smple usng one column family. > Experiement with size teired vs leveled compaction. > > On Thursday, October 17, 2013, Jan Algermissen <jan.algermis...@nordsc.com> > wrote: > > Hi, > > > > my rows consist of ~70 columns each, some containing small values, some > containing larger amounts of content (think "small documents"). > > > > My data is occasionally updated and read several times per day as > complete paging through all rows. > > > > The updates usually affect only about 10% of the small value columns. > > > > Speed of the full paging is of most interest to users. > > > > Given the very different volatility of the per-row data, do you think my > read speed would dramatically improve by splitting the less frequently > changes and the very frequently changed columns into two CFs? So I can > enable the row cache for the seldom changing, larger sized portion of the > data? > > > > Or would the effect likely by rather marginal? > > > > Jan
