Interface CompactionPlanner
-
- All Known Implementing Classes:
DefaultCompactionPlanner
public interface CompactionPlanner
Plans compaction work for a compaction service.- Since:
- 2.1.0
- See Also:
org.apache.accumulo.core.spi.compaction
-
-
Nested Class Summary
Nested Classes Modifier and Type Interface Description static interface
CompactionPlanner.InitParameters
This interface exists so the API can evolve and additional parameters can be passed to the method in the future.static interface
CompactionPlanner.PlanningParameters
This interface exists so the API can evolve and additional parameters can be passed to the method in the future.
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description void
init(CompactionPlanner.InitParameters params)
CompactionPlan
makePlan(CompactionPlanner.PlanningParameters params)
Plan what work a compaction service should do.
-
-
-
Method Detail
-
init
void init(CompactionPlanner.InitParameters params)
-
makePlan
CompactionPlan makePlan(CompactionPlanner.PlanningParameters params)
Plan what work a compaction service should do. The kind of compaction returned by
CompactionPlanner.PlanningParameters.getKind()
determines what must be done with the files returned byCompactionPlanner.PlanningParameters.getCandidates()
. The following are the expectations for the candidates for each kind.- CompactionKind.SYSTEM The planner is not required to do anything with the candidates and can choose to compact zero or more of them. The candidates may represent a subset of all the files in the case where a user compaction is in progress or other compactions are running.
- CompactionKind.USER and CompactionKind.SELECTED. The planner is required to eventually compact all candidates. Its ok to return a compaction plan that compacts a subset. When the planner compacts a subset, it will eventually be called again later. When it is called later the candidates will contain the files it did not compact and the results of any previous compactions it scheduled. The planner must eventually compact all of the files in the candidate set down to a single file. The compaction service will keep calling the planner until it does.
- CompactionKind.CHOP. The planner is required to eventually compact all candidates. One major difference with USER compactions is this kind is not required to compact all files to a single file. It is ok to return a compaction plan that compacts a subset of the candidates. When the planner compacts a subset, it will eventually be called later. When it is called later the candidates will contain the files it did not compact.
For a chop compaction assume the following happens.
- The candidate set passed to makePlan contains the files
[F1,F2,F3,F4]
and kind is CHOP - The planner returns a job to compact files
[F1,F2]
on executor E1 - The compaction runs compacting
[F1,F2]
into file[F5]
For the case above, eventually the planner will called again with a candidate set of
[F3,F4]
and it must eventually compact those two files.For a user and selector compaction assume the same thing happens, it will result in a slightly different outcome.
- The candidate set passed to makePlan contains the files
[F1,F2,F3,F4]
and kind is USER - The planner returns a job to compact files
[F1,F2]
on executor E1 - The compaction runs compacting
[F1,F2]
into file[F5]
For the case above, eventually the planner will called again with a candidate set of
[F3,F4,F5]
and it must eventually compact those three files to one. The difference with CHOP compactions is that the result of intermediate compactions are included in the candidate set.When a planner returns a compactions plan, task will be queued on executors. Previously queued task that do not match the latest plan are removed. The planner is called periodically, whenever a new file is added, and whenever a compaction finishes.
Use
CompactionPlanner.PlanningParameters.createPlanBuilder()
to build the plan this function returns.- See Also:
CompactionKind
-
-