If your sessions are fairly long-lived (more like hours instead of minutes) and you crank up a suitable row cache and make sure your db is consistent (via quorum read/writes or write:all, read:1) - sure, why not? Especially if you're already familiar with Cassandra; possibly even have a deployed instance already for your web app. Adding new components to the mix is always a sure way to get some headscratching going. For a small team who does not want to spend too much time on configuring yet another database, Cassandra would probably work well as a session store. And you would get cross-datacenter reliability too.
However, you might want to use 0.7 and expiring columns; otherwise cleaning up is going to be boring. /Janne On Feb 1, 2011, at 22:24 , Sasha Dolgy wrote: > > What I'm still unclear about, and where I think this is suitable, is > Cassandra being used as a data warehouse for current and past sessions tied > to a user. Yes, other things are great for session management, but I want to > provide near real time session information to my users ... quick and simple > and i want to use cassandra ... surely i can't be that bad for thinking this > is a good idea? > > -sd > > On Tue, Feb 1, 2011 at 9:20 PM, Kallin Nagelberg <kallin.nagelb...@gmail.com> > wrote: > nvm on the persistence, it seems like it does support it: > > 'Since version 1.1 the safer alternative is an append-only file (a > journal) that is written as operations modifying the dataset in memory > are processed. Redis is able to rewrite the append-only file in the > background in order to avoid an indefinite growth of the journal.' > > This thread probably shouldn't digress too much from Cassandra's > suitability for session management though..
