[
https://issues.apache.org/jira/browse/CASSANDRA-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219994#comment-14219994
]
Aleksey Yeschenko commented on CASSANDRA-8345:
----------------------------------------------
CASSANDRA-6038 is supposed to do something like this for the schema push
protocol. However doing this for the native protocol is not trivial at all - in
a useful way, anyway.
The issue here is that schema changes can happen to different nodes, and thus
events can also be triggered by different nodes, and out of their logical
order. Internally, we rely on the change timestamps (and timestamps in the
system schema tables) for reconciliation.
So for this to work, the drivers would have to replicate that same
reconciliation logic.
What we could do safely is for ALTER TABLE client notifications specify whether
the change was made to params or two columns, so that you'd only have to fetch
updated info from one table (pre-3.0 either schema_columnfamilies or
schema_columns). But I'm not sure it improves things enough to warrant a change
there.
> 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
> 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
(v6.3.4#6332)
