Good point Milind. (RE: Client-side AOP) I was thinking server-side to stay with the trigger concept, but we could just as easily intercept on the client-side. We'd just need to make sure that all clients got the AOP code injected. (including all of our map/reduce jobs)
If we get the point-cut right (using the Cassandra.Iface), we could probably make it portable. People could drop it in client-side or server-side. -brian On Jan 22, 2012, at 9:45 AM, Milind Parikh wrote: > 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... >> > > -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://weblogs.java.net/blog/boneill42/ blog: http://brianoneill.blogspot.com/
