cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michaël Figuière (JIRA) <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-8345) Client notifications should carry the entire delta of the information that changed
Date Wed, 19 Nov 2014 21:07:33 GMT
Michaël Figuière created CASSANDRA-8345:
-------------------------------------------

             Summary: Client notifications should carry the entire delta of the information
that changed
                 Key: CASSANDRA-8345
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8345
             Project: Cassandra
          Issue Type: Improvement
            Reporter: Michaël Figuière


Currently when the schema changes, a {{SCHEMA_CHANGE}} notification is sent to the client
to let it know that a modification happened in a specific table or keyspace. If the client
register for these notifications, this is likely that it actually cares to have an up to date
version of this information, so the next step is logically for the client to query the {{system}}
keyspace to retrieve the latest version of the schema for the particular element that was
mentioned in the notification.

The same thing happen with the {{TOPOLOGY_CHANGE}} notification as the client will follow
up with a query to retrieve the details that changed in the {{system.peers}} table.

It would be interesting to send the entire delta of the information that changed within the
notification. I see several advantages with this:
* This would ensure that the data that are sent to the client are as small as possible as
such a delta will always be smaller than the resultset that would eventually be received for
a formal query on the {{system}} keyspace.
* This avoid the Cassandra node to receive plenty of query after it issue a notification but
rather to prepare a delta once and send it to everybody.
* This should improve the overall behaviour when dealing with very large schemas with frequent
changes (typically due to a tentative of implementing multitenancy through separate keyspaces),
as it has been observed that the the notifications and subsequent queries traffic can become
non negligible in this case.
* This would eventually simplify the driver design by removing the need for an extra asynchronous
operation to follow up with, although the benefit of this point will be real only once the
previous versions of the protocols are far behind.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message