[
https://issues.apache.org/jira/browse/CASSANDRA-21661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick McFadin updated CASSANDRA-21661:
----------------------------------------
Description:
h2. What
DistributedSchema's constructor builds a flat
ImmutableMap<TableId,TableMetadata>
over every table in every keyspace, then validate() walks them again. It runs
twice per DDL – once in AlterSchema, once via Transformer.build ->
withLastModified. Keyspaces already maintains that mapping internally and
already
exposes getTableOrViewNullable(id), so it is a rebuild of data the constructor
was
just handed.
h2. Change
Delete keyspacesToTableMap and the field it populated; point the single reader
at
keyspaces.getTableOrViewNullable(id). Net -11/+1 lines, no API change.
validate() is left alone deliberately: its allocation is per-keyspace, not
per-table (the Preconditions.checkArgument calls bind Guava's 3-Object overload,
not varargs). The after-numbers confirm it – they do not move when the table
count grows 8x.
h2. Result
Per withLastModified call:
||fixture||400 tables||3200 tables||growth||
|before, 10 keyspaces|27,288 B|182,808 B|6.7x|
|before, 1 keyspace|22,812 B|179,825 B|7.9x|
|after, 10 keyspaces|2,032 B|2,032 B|1.0x|
|after, 1 keyspace|401 B|376 B|0.9x|
h2. One behavior not preserved
ImmutableMap.Builder.build() threw on duplicate keys, implicitly asserting no
two
keyspaces share a TableId. Keyspaces' BTreeMap collapses such a duplicate
silently, so that check is gone. Not restored here: Keyspaces had already
collapsed it before DistributedSchema saw it, every other TCM lookup already
went
through the collapsed map, and a set-based check would reintroduce the
allocation
this removes. Right home is an O(1) guard in Keyspaces.withTablesViews. No
existing test covers it. Recorded as a decision, not a silent loss.
h2. Tests
New DistributedSchemaScalingTest: 2 allocation assertions, 5 correctness guards
including views reachable by their own id (the old map came from
tablesAndViews(),
so delegation must not narrow to base tables). Verified red without the fix.
Regression: schema 28 suites/137 tests, tcm 13/55, 0 failures. checkstyle clean.
was:
h2. What
DistributedSchema's constructor builds a flat
ImmutableMap<TableId,TableMetadata>
over every table in every keyspace, then validate() walks them again. It runs
twice per DDL -- once in AlterSchema, once via Transformer.build ->
withLastModified. Keyspaces already maintains that mapping internally and
already
exposes getTableOrViewNullable(id), so it is a rebuild of data the constructor
was
just handed.
h2. Change
Delete keyspacesToTableMap and the field it populated; point the single reader
at
keyspaces.getTableOrViewNullable(id). Net -11/+1 lines, no API change.
validate() is left alone deliberately: its allocation is per-keyspace, not
per-table (the Preconditions.checkArgument calls bind Guava's 3-Object overload,
not varargs). The after-numbers confirm it -- they do not move when the table
count grows 8x.
h2. Result
Per withLastModified call:
|| fixture || 400 tables || 3200 tables || growth ||
| before, 10 keyspaces | 27,288 B | 182,808 B | 6.7x |
| before, 1 keyspace | 22,812 B | 179,825 B | 7.9x |
| after, 10 keyspaces | 2,032 B | 2,032 B | 1.0x |
| after, 1 keyspace | 401 B | 376 B | 0.9x |
h2. One behaviour not preserved
ImmutableMap.Builder.build() threw on duplicate keys, implicitly asserting no
two
keyspaces share a TableId. Keyspaces' BTreeMap collapses such a duplicate
silently, so that check is gone. Not restored here: Keyspaces had already
collapsed it before DistributedSchema saw it, every other TCM lookup already
went
through the collapsed map, and a set-based check would reintroduce the
allocation
this removes. Right home is an O(1) guard in Keyspaces.withTablesViews. No
existing test covers it. Recorded as a decision, not a silent loss.
h2. Tests
New DistributedSchemaScalingTest: 2 allocation assertions, 5 correctness guards
including views reachable by their own id (the old map came from
tablesAndViews(),
so delegation must not narrow to base tables). Verified red without the fix.
Regression: schema 28 suites/137 tests, tcm 13/55, 0 failures. checkstyle clean.
> Stop rebuilding a map of every table on each DistributedSchema construction
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-21661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21661
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
> Reporter: Patrick McFadin
> Assignee: Patrick McFadin
> Priority: Normal
>
> h2. What
> DistributedSchema's constructor builds a flat
> ImmutableMap<TableId,TableMetadata>
> over every table in every keyspace, then validate() walks them again. It runs
> twice per DDL – once in AlterSchema, once via Transformer.build ->
> withLastModified. Keyspaces already maintains that mapping internally and
> already
> exposes getTableOrViewNullable(id), so it is a rebuild of data the
> constructor was
> just handed.
> h2. Change
> Delete keyspacesToTableMap and the field it populated; point the single
> reader at
> keyspaces.getTableOrViewNullable(id). Net -11/+1 lines, no API change.
> validate() is left alone deliberately: its allocation is per-keyspace, not
> per-table (the Preconditions.checkArgument calls bind Guava's 3-Object
> overload,
> not varargs). The after-numbers confirm it – they do not move when the table
> count grows 8x.
> h2. Result
> Per withLastModified call:
> ||fixture||400 tables||3200 tables||growth||
> |before, 10 keyspaces|27,288 B|182,808 B|6.7x|
> |before, 1 keyspace|22,812 B|179,825 B|7.9x|
> |after, 10 keyspaces|2,032 B|2,032 B|1.0x|
> |after, 1 keyspace|401 B|376 B|0.9x|
> h2. One behavior not preserved
> ImmutableMap.Builder.build() threw on duplicate keys, implicitly asserting no
> two
> keyspaces share a TableId. Keyspaces' BTreeMap collapses such a duplicate
> silently, so that check is gone. Not restored here: Keyspaces had already
> collapsed it before DistributedSchema saw it, every other TCM lookup already
> went
> through the collapsed map, and a set-based check would reintroduce the
> allocation
> this removes. Right home is an O(1) guard in Keyspaces.withTablesViews. No
> existing test covers it. Recorded as a decision, not a silent loss.
> h2. Tests
> New DistributedSchemaScalingTest: 2 allocation assertions, 5 correctness
> guards
> including views reachable by their own id (the old map came from
> tablesAndViews(),
> so delegation must not narrow to base tables). Verified red without the fix.
> Regression: schema 28 suites/137 tests, tcm 13/55, 0 failures. checkstyle
> clean.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
