My bad ~s/X:X-Value/Y:Y-Value/ after rereading the SELECT. /*********************** sent from my android...please pardon occasional typos as I respond @ the speed of thought ************************/
On Jan 22, 2012 6:40 AM, "Milind Parikh" <milindpar...@gmail.com> wrote: The composite-key approach with counters would work very well in this case. It will also obviate the concern of not knowing the exact column names apriori...although for efficiencies, you might to look at maintaining a secondary cachelike cf for lookup.... Depending on your data patterns(not to hit 2b columns) and actual queries, you could store each Zs as one row and composite key on Z - value + X:X-value and then as counter-column. Other optimizations may be possible. If you're using AOP, as I read it, there's really no need to intercept your own writes at the C* level; instead do it (use aop)at the client level. Your migration also needs to be attended to and might need a MR first and AOP intercepted writes. Hth Milind /*********************** sent from my android...please pardon occasional typos as I respond @ the speed of thought ************************/ > > On Jan 22, 2012 4:42 AM, "Brian O'Neill" <boneil...@gmail.com> wrote: > > > Thanks for all the ideas... > > Since we can't predict all the values, we actually cut to Oracle... > > > > > On Jan 21, 2012, at 8:35 AM, Eric Czech wrote: > > > Hi Brian, > > > We're trying to do the exact same...
