[
https://issues.apache.org/jira/browse/CASSANDRA-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220853#comment-14220853
]
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 cost.
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: 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)
