Sure….. I'm willing to concede that Cassandra isn't for anyone but why make it worse than it has to be?
Why 8 bytes? Why not 64 bytes? I imagine even in your situation a 8x boost in storage would not be nice ;) The point is that replication in Cassandra only needs timestamps to handle out of order writes … for values that are idempotent, this isn't necessary. The order doesn't matter. Adding support for Cassandra to support variable width resolution (1ms is probably too high for most uses) and to turn timestamps off on a per tablespace basis could be really handy. Kevin On Sat, Sep 3, 2011 at 7:56 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > maybe not all nosql applications fit cassandra. > > the whole core logic of how cassandra is eventually consistent is because > of the per column timestamps... if they are a pain for you consider storing > eg as a small number of fat columns rather than many skinny ones... either > that or look at a different database for your use case. ;-) > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 3 Sep 2011 16:01, "Kevin Burton" <bur...@spinn3r.com> wrote: > -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* Skype: *burtonator* Skype-in: *(415) 871-0687*
