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

Jon Haddad commented on CASSANDRA-8460:
---------------------------------------

Taking a look at this ticket, I've got a concern, and I'd like to suggest an 
alternative.  

Juggling multiple disks has been a bit of a pain so far and still has some 
weird behavior.  We're a little better now that we split by token ranges, but 
there's still (IIRC) a point in time where the failure of a single disk can 
resurrect some data which had just been tombstoned.  If this is fixed, 
apologies, but I haven't seen it.  I'm not quite sure that adding complexity to 
this already long lasting pain point is going to help the project overall.

As an alternative, it's already possible to more or less get this behavior in a 
fashion that works with _every_ compaction strategy.  LVM (Linux only) is 
already ubiquitous.  Using lvmcache (backed by dmcache) already provides the 
ability to put your cold data on the slower spinning disks and leverage SSD for 
fast operations.  The benefit here is that you can keep a lot of your hot data 
on the fast drive and LVM will automatically handle making room for the newer 
files.  A second benefit is that you are not exposing yourself to the above 
mentioned issues with JBOD.  



> Make it possible to move non-compacting sstables to slow/big storage in DTCS
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-8460
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8460
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Marcus Eriksson
>            Assignee: Lerh Chuan Low
>            Priority: Major
>              Labels: doc-impacting, dtcs
>             Fix For: 4.x
>
>
> It would be nice if we could configure DTCS to have a set of extra data 
> directories where we move the sstables once they are older than 
> max_sstable_age_days. 
> This would enable users to have a quick, small SSD for hot, new data, and big 
> spinning disks for data that is rarely read and never compacted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to