lasdf1234 commented on PR #12241: URL: https://github.com/apache/gravitino/pull/12241#issuecomment-5130161926
> > > Thanks for writing this down. The stateless/self-describing `plan-task` direction looks workable for multi-replica deployments because a task issued by one Gravitino instance can be decoded and re-planned by another instance without node-local state. > > > Could you add a short section that makes the multi-replica behavior and constraints explicit? > > > The main risk I see is not correctness of decoding across nodes, but load amplification. With the scan plan cache disabled by default, or with only node-local caches, `/plan` may run on replica A while concurrent `/tasks` requests land on replicas B/C/D. Each cache miss then re-plans the full pinned snapshot, reads manifests again, sorts the full task list, and only then slices one batch. For large tables this could multiply planning/object-store load across replicas. It would be useful to document the expected production posture here, for example whether operators should enable a cache, whether a shared cache is expected later, and whether any rate/concurrency limits are needed. > > > I also think the determinism requirement needs one more sentence of proof. The design depends on `(data file location, start, length)` being a true total order across independent re-plans on different nodes. If Iceberg can ever produce two semantically distinct file scan tasks with the same triple, different replicas could slice batches differently. Either the document should cite why that cannot happen, or the implementation should add another deterministic tie-breaker and a test for it. > > > One related point: if we later decide to make `plan-task` signed/HMACed to distinguish "issued by this server" from a forged but well-formed string, the signing key must be shared across all replicas. Without a shared secret, signing would reintroduce the same cross-replica failure mode that this design avoids. > > > > > > He opened another PR and enabled the cache. > > My main concern is multiple node deployment. If it's a batch scenario involving multiple nodes, the issue is mainly about performance (in my opinion, this is inevitable). Do you think there is a problem with accuracy? -- 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]
