cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2749) fine-grained control over data directories
Date Thu, 15 Dec 2011 17:46:31 GMT

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

Jonathan Ellis commented on CASSANDRA-2749:
-------------------------------------------

bq. we cannot stream between two nodes, one using separate cf directory

I don't see any reason to continue to support the old-style directory layout.  That adds complexity
(operationally as well as in the code) for no benefit that I can think of.  I think we should
migrate from old layout to new on the first startup under 1.1.

bq. regarding keyspaces in file names, sure, why not, guess having a header with this info
in the file is out of the question, then the only meta data we have is the file name, right?
A problem could be if we want to do CASSANDRA-1983 later, that would increase the file name
length even more

I'm on the fence here -- on the one hand having ks + cf in the filename simplifies some things.
 On the other hand, we allow arbitrary-length KS + CF names (up to 64K iirc) so UUID aside
we're already in trouble on ext3/ext4, xfs, and ntfs, which all support max filename length
of ~256.  I'm starting to think we should move these into the metadata component instead of
the filename.
                
> 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
>             Fix For: 1.1
>
>         Attachments: 0001-Make-it-possible-to-put-column-families-in-subdirect.patch,
0001-add-new-directory-layout.patch, 0001-non-backwards-compatible-patch-for-2749-putting-cfs-.patch.gz,
0002-fix-unit-tests.patch, 2749.tar.gz, 2749_backwards_compatible_v1.patch, 2749_backwards_compatible_v2.patch,
2749_backwards_compatible_v3.patch, 2749_backwards_compatible_v4.patch, 2749_backwards_compatible_v4_rebase1.patch,
2749_not_backwards.tar.gz, 2749_proper.tar.gz
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message