[
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 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.
> 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
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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]
