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