[jira] [Commented] (CASSANDRA-8460) Make it possible to move non-compacting sstables to slow/big storage in DTCS

["Lerh Chuan Low (JIRA)" <ji...@apache.org>]

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

Lerh Chuan Low commented on CASSANDRA-8460:
-------------------------------------------

[~rustyrazorblade], 

About {{disk_failure_policy}}, that I am not aware so I'll have to look into it. With my current patch up to where it is now, there are also other things like Scrubber, streaming which I have yet to get to. Thanks for the heads up! If such an implication is necessary then maybe we will have to enforce it in the code. 

About LVM Cache, I spent some time following the man page and trying it out with Cassandra stress. I had spun up a few EC2 clusters. They were all using a raid array of 800GB each; one was SSD backed, another was magnetic HDD backed, and the final one was magnetic HDD backed with 100GB of LVM writethrough cache. I inserted ~200GB of data using cassandra-stress, waited for compactions to finish and then attempted a mixed (random) workload...the LVM performed even worse than HDD. I guess this was to be expected because the cache works best for hot data that is frequently read. 

I did briefly attempt a mixed workload where the queries are always trying to select the same data as much as possible (so {{gaussian(1..500M, 250000000, 1000)}}), and there wasn't any noticeable difference between the LVM and HDD backed cluster. 

Not sure if you have used LVMCache with a workload before that worked out for you and you'd be willing to share details about it...? 

Just thinking about it further, the cache is also very slightly different than the original proposal. The cache duplicates the data; making Cassandra understand archiving does not. There's also a slight bonus at least from the scenario for AWS, the cache consumes the IOPS of the volumes due to the duplication (or amplifying) of read and writes back and from the cache.

Any thoughts? (And thank you for your input once again :)) My clusters are still running so happy to try a few configurations if you have any to suggest, for now I'm just going to refresh myself on the code and look into getting it more presentable if someone else swings by and is willing to give their thoughts. 

> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org