cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bulat Shakirzyanov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8345) Client notifications should carry the entire delta of the information that changed
Date Thu, 20 Nov 2014 21:34:34 GMT


Bulat Shakirzyanov commented on CASSANDRA-8345:

Each driver receives notifications only from a single node, why would it need to reconcile,
isn't the notification pushed from the node after schema has been reconciled?

> Client notifications should carry the entire delta of the information that changed
> ----------------------------------------------------------------------------------
>                 Key: CASSANDRA-8345
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Michaël Figuière
>              Labels: protocolv4
> 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

View raw message