cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8345) Client notifications should carry the entire delta of the information that changed
Date Fri, 21 Nov 2014 12:39:33 GMT


Aleksey Yeschenko commented on CASSANDRA-8345:

Fair enough.

Another issue is schema versioning. This change would necessarily require us to modify internal
schema representation in lock-step with native protocol versions (and support serializing
schema changes for the previous native protocol versions), which is a heavy burden.

We should really just make drivers fetch as little of the new schema as they possibly can
- then you get the same total bandwidth per update and only pay a bit more in the extra roundtrip

And don't worry about C* handling those queries - it can handle them.

> 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