johnny2002 edited a comment on issue #1720: URL: https://github.com/apache/shardingsphere-elasticjob/issues/1720#issuecomment-727673999
> > > > Detail reason for we need this feathure: > > > > We have a large system that has large data, so we have to use unitized architecture. > > > > So one job instance in specific unit can only execute specific sharding data. > > > > e.g. > > > > JobInstance-unit1 can only handle data sharding No.1 > > > > JobInstance-unit2 can only handle data sharding No.2 > > > > and so on > > > > > > > > > As you said that your system is partition architecture, why not treat them as different jobs? > > > > > > Then there will be 1000 jobs need to config one by one. and also hard to monitor. > > I don't quite understand your scenarios. Maybe you can just configure different job names while keeping other configuration consistent. I think configuring 1000 job names is as simple as configuring 1000 job instance id. Coorperating with Tracing module, you can immediately locate the problem by job name if any partition failed. 32 job names by 32 instance names, that's 1024 Job Instances, compare to configure 1024 job names, do you think which is simpler? Another protential problem is that if we seperate one job to many jobs, then the configuration may be inconsistent. Even though We can configure 1000 job names, we still need to distinguish main and backup job instance. Our complete sharding strategy is that: Firstly, assign sub-job1 to instance1(main), if job instance1 crashed, then assign to instance2(backup) ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
