You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jason Fager (JIRA)" <ji...@apache.org> on 2013/09/03 21:49:52 UTC

[jira] [Created] (CASSANDRA-5974) Symlink Keys

Jason Fager created CASSANDRA-5974:
--------------------------------------

             Summary: Symlink Keys
                 Key: CASSANDRA-5974
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5974
             Project: Cassandra
          Issue Type: New Feature
            Reporter: Jason Fager
            Priority: Minor


Floated this on irc, was told to open a ticket here:

We have a use case where a 3rd party sends us their id, we do a read to look up our internal id, and then turn around and do a write against that internal id.  We'd save a round trip if we could just do the write to our internal id via the external id; i.e., if we could treat the external id as a sort of symlink for our internal id.

This use case doesn't seem like a great fit for secondary indexing, as there are potentially many external ids for each internal id, but only ever 1 internal id for each external id.  Another suggestion on irc was to use triggers; I haven't sat down to figure out if/how that would work, but I think the restriction against counter columns makes a trigger-based approach less than ideal.

As a vague sketch of how I'd see this working, a symlink row would be distributed just like any other row, but would forward any operations on it to the real row.  If the symlink rowkey lands on a different node than the real rowkey, there's an extra network hop, but this is still an improvement over the current case (client > lookup_node > client -> real_node vs client -> symlink_node -> real_node).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira