[
https://issues.apache.org/jira/browse/CASSANDRA-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046102#comment-13046102
]
Peter Schuller commented on CASSANDRA-2749:
-------------------------------------------
+1 on that. We have been discussing the same thing, for the same purpose. The
only kink is that you don't want to do something like having a per-cf setting
that is tied to local node details like paths. But simply placing CF:s in a
named subdirectory (similar to the pg tablespace) which can, on a per-node
basis, by a symlink or a mountpoint, avoids that.
This means there's no problem doing a rolling re-configuration of a cluster,
and there is no need to realize before hand that you might want to move some
particular CF and do something like assign it to a tablespace (to get the level
of indirection). It all just works by default, and you can move CF:s at any
time on any node without co-ordination other than the node being down for a bit.
I can foresee it being easier to accidentally start a node which seems to work
but has some CF:s be completely empty, because Cassandra won't be able to
distinguish between an actual empty CF and a directory that wasn't mounted (or
a symlink pointing to a non-mounted directory). Something simple like creating
a marker of some kind on CF creation might help with that; on start-up CF:s
that are missing the marker could be rejected. But - I suppose this is overkill
at least initially.
> fine-grained control over data directories
> ------------------------------------------
>
> Key: CASSANDRA-2749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2749
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Priority: Minor
>
> Currently Cassandra supports multiple data directories but no way to control
> what sstables are placed where. Particularly for systems with mixed SSDs and
> rotational disks, it would be nice to pin frequently accessed columnfamilies
> to the SSDs.
> Postgresql does this with tablespaces
> (http://www.postgresql.org/docs/9.0/static/manage-ag-tablespaces.html) but we
> should probably avoid using that name because of confusing similarity to
> "keyspaces."
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
