I just want to clarify the point about the "In-Memory" datastore. From a user perspective, the proposal captured so far in Github (issue 75) does not differ from the current "in-memory" store. But it has a lot of advantages.
Just to enumerate a few advantages to switch to an embedded Cassandar server:
- No development time spent updating a highly experimental data store that has no design similarities with a "partioned row store" engine
- Predictable memory consumption; the memory store had an unbounded upper limit on the memory usage
- Tuneable data retention - the memory data store was erased on server restart, the embedded Cassandra can be configured to do anything
- No user configuration required to have the project running out-of-box; but possible to expose additional configuration as necessary (such as data retention)
- Predictable performance between the two operational modes; the current "in-memory" store has no resemblance to a true production deployment with an external Cassandra.
The goal for 0.2.6 is to lay a strong foundation for the embedded Cassandra. Additional configuration options and advanced features would be part of subsequent releases.
IMO this in-memory database discussion is hidden under release planning so probably nobody will read it. It should probably be its own topic NOT nested under 'Release 0.2.6 Planning' but its own topic.