cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Jirsa (JIRA)" <>
Subject [jira] [Issue Comment Deleted] (CASSANDRA-9779) Append-only optimization
Date Thu, 23 Jun 2016 04:53:16 GMT


Jeff Jirsa updated CASSANDRA-9779:
    Comment: was deleted

(was: {quote}
 I'm wondering if given DTCS and other optimization we have internally this really bring that
much to the table.

I've been watching this ticket primarily because if 'append only' tables exist, it should
be possible to special case {{CompactionController.getFullyExpiredSSTables}} so that DTCS/TWCS
can drop tables with timestamp overlaps (sstable expired blockers), which would be significantly
more efficient than trying to split out read-repaired cells during compaction a la CASSANDRA-10496


> Append-only optimization
> ------------------------
>                 Key: CASSANDRA-9779
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: CQL
>            Reporter: Jonathan Ellis
>             Fix For: 3.x
> Many common workloads are append-only: that is, they insert new rows but do not update
existing ones.  However, Cassandra has no way to infer this and so it must treat all tables
as if they may experience updates in the future.
> If we added syntax to tell Cassandra about this ({{WITH INSERTS ONLY}} for instance)
then we could do a number of optimizations:
> - Compaction would only need to worry about defragmenting partitions, not rows.  We could
default to DTCS or similar.
> - CollationController could stop scanning sstables as soon as it finds a matching row
> - Most importantly, materialized views wouldn't need to worry about deleting prior values,
which would eliminate the majority of the MV overhead

This message was sent by Atlassian JIRA

View raw message