gianm commented on code in PR #17935: URL: https://github.com/apache/druid/pull/17935#discussion_r2054560953
########## server/src/main/java/org/apache/druid/metadata/segment/SqlSegmentsMetadataManagerV2.java: ########## @@ -0,0 +1,178 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.druid.metadata.segment; + +import com.fasterxml.jackson.databind.ObjectMapper; +import com.google.common.base.Supplier; +import org.apache.druid.client.DataSourcesSnapshot; +import org.apache.druid.guice.ManageLifecycle; +import org.apache.druid.java.util.common.lifecycle.LifecycleStart; +import org.apache.druid.java.util.common.lifecycle.LifecycleStop; +import org.apache.druid.java.util.common.logger.Logger; +import org.apache.druid.java.util.emitter.service.ServiceEmitter; +import org.apache.druid.metadata.MetadataStorageTablesConfig; +import org.apache.druid.metadata.SQLMetadataConnector; +import org.apache.druid.metadata.SegmentsMetadataManager; +import org.apache.druid.metadata.SegmentsMetadataManagerConfig; +import org.apache.druid.metadata.SqlSegmentsMetadataManager; +import org.apache.druid.metadata.segment.cache.SegmentMetadataCache; +import org.apache.druid.segment.metadata.CentralizedDatasourceSchemaConfig; +import org.apache.druid.segment.metadata.SegmentSchemaCache; +import org.apache.druid.server.coordinator.DruidCompactionConfig; + +/** + * Implementation V2 of {@link SegmentsMetadataManager}, that can use the + * segments cached in {@link SegmentMetadataCache} to build a {@link DataSourcesSnapshot}. + * <p> + * This class acts as a wrapper over {@link SqlSegmentsMetadataManager} and the + * {@link SegmentMetadataCache}. If the cache is enabled, an additional poll is + * not done and the segments already present in the cache are used to build the + * snapshot. If the {@link SegmentMetadataCache} is disabled, the polling is + * delegated to the legacy implementation in {@link SqlSegmentsMetadataManager}. + * <p> + * The Coordinator always uses the snapshot to perform various segment management + * duties such as loading, balancing, etc. + * The Overlord uses the snapshot only when compaction supervisors are enabled. + * Thus, when running the Overlord as a standalone service (i.e. not combined + * with the Coordinator), {@link #startPollingDatabasePeriodically()} and + * {@link #stopPollingDatabasePeriodically()} are called based on the current + * state of {@link DruidCompactionConfig#isUseSupervisors()}. + */ +@ManageLifecycle +public class SqlSegmentsMetadataManagerV2 implements SegmentsMetadataManager +{ + private static final Logger log = new Logger(SqlSegmentsMetadataManagerV2.class); + + private final SegmentsMetadataManager delegate; + private final SegmentMetadataCache segmentMetadataCache; + private final SegmentsMetadataManagerConfig managerConfig; + private final CentralizedDatasourceSchemaConfig schemaConfig; + + public SqlSegmentsMetadataManagerV2( + SegmentMetadataCache segmentMetadataCache, + SegmentSchemaCache segmentSchemaCache, + SQLMetadataConnector connector, + Supplier<SegmentsMetadataManagerConfig> managerConfig, + Supplier<MetadataStorageTablesConfig> tablesConfig, + CentralizedDatasourceSchemaConfig centralizedDatasourceSchemaConfig, + ServiceEmitter serviceEmitter, + ObjectMapper jsonMapper + ) + { + this.delegate = new SqlSegmentsMetadataManager( + jsonMapper, + managerConfig, tablesConfig, connector, segmentSchemaCache, + centralizedDatasourceSchemaConfig, serviceEmitter + ); + this.managerConfig = managerConfig.get(); + this.segmentMetadataCache = segmentMetadataCache; + this.schemaConfig = centralizedDatasourceSchemaConfig; + } + + /** + * @return true if segment metadata cache is enabled and segment schema cache + * is not enabled. Segment metadata cache currently does not handle segment + * schema updates. + */ + private boolean useCacheToBuildTimeline() + { + return segmentMetadataCache.isEnabled() && !schemaConfig.isEnabled(); Review Comment: I guess the `!schemaConfig.isEnabled()` escape hatch is here to maintain compatibility with `druid.centralizedDatasourceSchema.enabled = true`. Otherwise the schemas would not be polled. IMO, in the short term, it should be an error to specify `druid.centralizedDatasourceSchema.enabled = true` when the incremental cache is enabled. Otherwise people will potentially enable both features and wonder why the incremental cache isn't working. In the long term, how would these two features coexist? ########## docs/configuration/index.md: ########## @@ -925,6 +925,7 @@ These Coordinator static configurations can be defined in the `coordinator/runti |--------|-----------|-------| |`druid.manager.config.pollDuration`|How often the manager polls the config table for updates.|`PT1M`| |`druid.manager.segments.pollDuration`|The duration between polls the Coordinator does for updates to the set of active segments. Generally defines the amount of lag time it can take for the Coordinator to notice new segments.|`PT1M`| +|`druid.manager.segments.useCache`|(Experimental) Denotes the usage mode of the segment metadata cache. The cache provides a performance improvement over the polling mechanism currently employed by the Coordinator by retrieving payloads of only updated segments. Possible cache modes are: (a) `never`: Cache is disabled. (b) `always`: Reads are always done from the cache. Service start-up will be blocked until cache has synced with the metadata store at least once. Transactions will block until cache has synced with the metadata store at least once after becoming leader. (c) `ifSynced`: Reads are done from the cache only if it has already synced with the metadata store. This mode does not block service start-up but blocks read transactions.|`never`| Review Comment: The name of the property seems misleading to me. The Coordinator always has a cache of segment payloads. This property is really determining which implementation will be used: new (incremental) or old (polling). IMO it's clearer to call it `druid.manager.segments.useIncrementalCache`. The descriptions of the modes also seem like they may be misleading. IIRC, the Coordinator's current segment payload caching mechanism also has this feature where it blocks Coordinator duties and certain HTTP APIs until at least one sync has happened. Also what does "transactions" mean for the Coordinator? I think it's more clear what it means for the Overlord, but I don't really think of the Coordinator as something transaction-based. It's more of something that runs automated background work to manage the cluster. Looking at the implementation a bit, it seems like for both `always` and `ifSynced`, the Coordinator duties will be blocked on sync of the cache. This is good; it's what I would have expected, and it's consistent with current Coordinator behavior. But I wonder what the point is of having both options for the Coordinator in that case. Is there a scenario that operators should prefer `ifSynced` vs `always`? Could you please review the text with this in mind and propose something new? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
