[
https://issues.apache.org/jira/browse/CASSANDRA-21370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-21370:
--------------------------------------------
Description:
Currently we execute DDL statements only one by one, so in case of a complex
schema deployment (especially for a low resource dev environment) we may spend
a lot of time to apply it. With TCM it is possible to run schema changes in
parallel and partially mitigate the issue but still there are downsides for
this approach:
* we cannot run dependent DDLs in parallel (for example UDT creation and
creation of another UDT or table which uses it)
* we still process schemas changes one by one and for every schema change we
flush system schema tables, so in case of slow dev disks it can be quite slow
in general (it can be partially mitigated by introducing internal batching with
a limited delay, like Kafka linger.ms, but still it will require to change
deployment tools to issue DDLs in parallel and do a topology sort of DDL
statements).
The suggestion is to add support of DDL queries batching, when we can send a
list of DDL queries in a single request and process them as a single schema
change transaction.
The current schema management logic already operates with generic schema diffs
so the main effort is to add support for it on CQL processing/parsing layer
actually.
was:
Currently we can execute DDL statements only one by one, so in case of a
complex schema deployment (especially for a low resource dev environment) we
may spend a lot of time to apply it. With TCM it is possible to run schema
changes in parallel and partially mitigate the issue but still there are
downsides for this approach:
* we cannot run dependent DDLs in parallel (for example UDT creation and
creation of another UDT or table which uses it)
* we still process schemas changes one by one and for every schema change we
flush system schema tables, so in case of slow dev disks it can be quite slow
in general
The suggestion is to add support of DDL queries batching, when we can send a
list of DDL queries in a single request and process them as a single schema
change transaction.
The current schema management logic already operates with generic schema diffs
so the main effort is to add support for it on CQL processing/parsing layer
actually.
> DDL statements batching
> -----------------------
>
> Key: CASSANDRA-21370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21370
> Project: Apache Cassandra
> Issue Type: New Feature
> Components: Cluster/Schema, CQL/Interpreter, CQL/Syntax
> Reporter: Dmitry Konstantinov
> Priority: Normal
>
> Currently we execute DDL statements only one by one, so in case of a complex
> schema deployment (especially for a low resource dev environment) we may
> spend a lot of time to apply it. With TCM it is possible to run schema
> changes in parallel and partially mitigate the issue but still there are
> downsides for this approach:
> * we cannot run dependent DDLs in parallel (for example UDT creation and
> creation of another UDT or table which uses it)
> * we still process schemas changes one by one and for every schema change we
> flush system schema tables, so in case of slow dev disks it can be quite slow
> in general (it can be partially mitigated by introducing internal batching
> with a limited delay, like Kafka linger.ms, but still it will require to
> change deployment tools to issue DDLs in parallel and do a topology sort of
> DDL statements).
> The suggestion is to add support of DDL queries batching, when we can send a
> list of DDL queries in a single request and process them as a single schema
> change transaction.
> The current schema management logic already operates with generic schema
> diffs so the main effort is to add support for it on CQL processing/parsing
> layer actually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
