> - Serializing data is not an option, because I would like to have possibility > to access data using console fair enough, but I would do some tests to see the difference in performance and disk space
> - Using Cassandra to build something like "HTTP session store" with short TTL > is not an anti-pattern ? Heavy delete work loads, such as a queue, is more of a problem. You may have to may some extra attention to disk space, because it not clean up instantly. But I would not go so far to say anti-pattern. - There is really no way to tell Cassandra, that particular Key Space should be stored "mostly" in RAM and only asynchronous backup on HDD (JMS has something like that)? See the durable_writes option for create keyspace in the CLI. Turn if off and the commit log is not used, writes will only be committed to disk when the memtable is flushed. Have fun. ----------------- Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com On 12/10/2011, at 7:28 PM, Maciej Miklas wrote: > - RF is 1. We have few KeySpaces, only this one is not replicated - this data > is not that very important. In case of error customer will have to execute > process again. But again, I would like to persist it. > - Serializing data is not an option, because I would like to have possibility > to access data using console > - I will keep row cache - you are right, there is no guarantee, that my data > is still in Memtable > > I will get my hardware soon (3 servers) and we will see ;) In this worst case > I will switch my session storage to memcached, and leave all other data in > Cassandra (no TTL, or very long) > > Another questions: > - Using Cassandra to build something like "HTTP session store" with short TTL > is not an anti-pattern ? > - There is really no way to tell Cassandra, that particular Key Space should > be stored "mostly" in RAM and only asynchronous backup on HDD (JMS has > something like that)? > > > Thanks, > Maciej >
