Package org.apache.accumulo.core.spi.compaction

Interface CompactionPlanner

All Known Implementing Classes:
DefaultCompactionPlanner
public interface CompactionPlanner
Plans compaction work for a compaction service.
Since:
2.1.0
See Also:

  • Method Details

    • 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 by CompactionPlanner.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.

      1. The candidate set passed to makePlan contains the files [F1,F2,F3,F4] and kind is CHOP
      2. The planner returns a job to compact files [F1,F2] on executor E1
      3. 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.

      1. The candidate set passed to makePlan contains the files [F1,F2,F3,F4] and kind is USER
      2. The planner returns a job to compact files [F1,F2] on executor E1
      3. 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: