Rick Branson created CASSANDRA-5527:
---------------------------------------
Summary: Deletion by Secondary Key
Key: CASSANDRA-5527
URL: https://issues.apache.org/jira/browse/CASSANDRA-5527
Project: Cassandra
Issue Type: Improvement
Reporter: Rick Branson
Given Cassandra's popularity as a time ordered list store, the inability to do
deletes by anything other than the primary key without re-implementing
tombstones in the application is a bit of an achilles heel for many use cases.
It's a data modeling problem that seems to come up quite often, and given that
we now have the CQL3 abstraction layer sitting on top of the storage engine, I
think there's an opportunity to take this burden off of the application layer.
I've spent several weeks thinking about this problem within the context of
Cassandra, and I think I've come up with a reasonable proposal.
It would involve addition of a secondary key facility to CQL3 tables:
CREATE TABLE timeline (
timeline_id uuid,
entry_id timeuuid,
entry_key blob,
entry_payload blob,
PRIMARY KEY (timeline_id, entry_id),
KEY (timeline_id, entry_key)
);
Secondary keys would be required to share the same partition key with the
primary key. They would be included to support deletion by secondary key
operations:
DELETE FROM timeline WHERE timeline_id = <X> and entry_key = <Y>;
Underneath, the storage engine row would contain additional secondary key
tombstones. Secondary key deletion would be read-free, requiring a single
tombstone write. The cost of reads would necessarily go up. Queries would need
to be modified to perform an additional step to find any matching secondary key
tombstones and perform the regular convergence process. The secondary key
tombstones should be cleaned up by the regular tombstone GC process.
While I didn't want to complicate this idea too much, it might be also worth
having a discussion around supporting secondary key queries as well, or at
least making the schema compatible with potential future support (maybe rename
KEY to DELETABLE KEY or something).
--
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
