[
https://issues.apache.org/jira/browse/CASSANDRA-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392035#comment-16392035
]
Lerh Chuan Low edited comment on CASSANDRA-8460 at 3/8/18 10:45 PM:
--------------------------------------------------------------------
Sure. In the commands below {{/dev/md0}} is my RAID and {{/dev/xvdf}} is my SSD
volume.
{code}
sudo pvcreate /dev/md0
sudo vgcreate VolGroupArray /dev/md0 /dev/xvdf
sudo lvcreate -n SadOldCache -L 99900M VolGroupArray /dev/xvdf
sudo lvcreate -n SadOldCacheMeta -L 100M VolGroupArray /dev/xvdf
sudo lvconvert --type cache-pool --poolmetadata VolGroupArray/SadOldCacheMeta
VolGroupArray/SadOldCache
sudo lvcreate -l 100%FREE -n RaidHDD VolGroupArray /dev/md0
sudo lvs -a vg
sudo lvs -a VolGroupArray
sudo lvconvert --type cache --cachepool VolGroupArray/SadOldCache
VolGroupArray/RaidHDD
sudo vgchange -ay
{code}
Regarding using a TWCS workload, C* stress doesn't play very well with
timestamps and TWCS in general unless I'm missing something. I've currently got
to a point of using UDFs (minutesAgo is my UDF) because arithmetic operators
are not supported until 4.0, and using a query spec something along those lines
{code}
queries:
putindata:
cql: insert into twcstest (id, time, metric) VALUES (?, toTimestamp(now()),
?)
simple1:
cql: select * from twcstest where id = ? and time <= toTimestamp(now()) and
time >= minutesAgo(5) LIMIT 288
fields: samerow
{code}
I would have thought though, that using a very pointy Gaussian such as this
{{gaussian(1..500M, 250000000, 1000)}} would be a fair enough reflection of the
right load because it will still predominantly select the same data due to an
extremely low stdev of 1000 (Mean of 250M, stdev of 1000). I can re-run the
benchmarks just to get more samples.
was (Author: lerh low):
Sure. In the commands below {{/dev/md0}} is my RAID and {{/dev/xvdf}} is my SSD
volume.
{code}
sudo pvcreate /dev/md0
sudo vgcreate VolGroupArray /dev/md0 /dev/xvdf
sudo lvcreate -n SadOldCache -L 99900M VolGroupArray /dev/xvdf
sudo lvcreate -n SadOldCacheMeta -L 100M VolGroupArray /dev/xvdf
sudo lvconvert --type cache-pool --poolmetadata VolGroupArray/SadOldCacheMeta
VolGroupArray/SadOldCache
sudo lvcreate -l 100%FREE -n RaidHDD VolGroupArray /dev/md0
sudo lvs -a vg
sudo lvs -a VolGroupArray
sudo lvconvert --type cache --cachepool VolGroupArray/SadOldCache
VolGroupArray/RaidHDD
sudo vgchange -ay
{code}
> 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: [email protected]
For additional commands, e-mail: [email protected]
