[jira] [Commented] (CASSANDRA-1657) support in-memory column families

["Hanson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055955#comment-14055955 ] 

Hanson commented on CASSANDRA-1657:
-----------------------------------

> I wonder if AOF from redis fits our needs well. It is durable 
> http://redis.io/topics/persistence
It shall be AOF + RDB from Redis for durability.
Similar to the In-Memory option provided in the commercial version of Cassandra from DataStax Enterprise 4.0:
http://www.datastax.com/documentation/datastax_enterprise/4.0/datastax_enterprise/inMemory.html
Which is commitLogs + SSTables as snapshot for durability.
The memTables are still kept in memory even after they are flushed into SSTables as snapshot, and old commitLogs can be removed once corresponding memTables are flushed into SSTables.
That means the Compaction is done in memory (introduced a new compaction strategy “MemoryOnlyStrategy”, instead of doing compaction to SSTables on disk.

TimesTen In-Memory DB also does similar:
todoLogs + Checkpoints for durability.
Where todoLogs equals to Cassandra’s commitLogs, and Checkpoints equals to Cassandra’s SSTables as snapshot of memTables.




> support in-memory column families
> ---------------------------------
>
>                 Key: CASSANDRA-1657
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1657
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Peter Schuller
>            Assignee: Edward Capriolo
>            Priority: Minor
>
> Some workloads are such that you absolutely depend on column families being in-memory for performance, yet you most definitely want all the things that Cassandra offers in terms of replication, consistency, durability etc.
> In order to semi-deterministically ensure acceptable performance for such data, Cassandra could support in-memory column families. Such an in-memory column family would imply that mlock() be used on sstables for this column family. On start-up and on compaction completion, they could be mmap():ed with MAP_POPULATE (Linux specific) or else just mmap():ed + mlock():ed in such a way as to otherwise guarantee it is in-memory (such as userland traversal of the entire file).



--
This message was sent by Atlassian JIRA
(v6.2#6252)