You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

AsterixDB supports a number of merge policies based on full merges [1]. In full merges, disk components are ordered based on recency and are always merged in full.


Concurrent Merge Policy (default)

The concurrent merge policy is the default merge policy for the current master. It has four important parameters:

  • minMergeComponentCount: the mimimum disk components per merge

  • maxMergeComponentCount: the maximum disk components per merge

  • maxComponentConut: the maximum number of disk components allowed before stopping flushes
  • size ratio: explained below.

Suppose we have a list of disk components D1, D2, ..., DN ordered from oldest to newest. The basic idea for this merge policy is to merge as many disk components as possible at once (not exceeding maxMergeComponentCount) but uses the size ratio to make optimal trade-offs. It will trigger as a merge as follows:

  • Start with the oldest disk component D1. Look at the longest younger disk component sequence D2, D3, ..., DK. If the length of D2, D3,...,DK >= minMergeComponentCount and the total size of D2, D3, ..., DK * sizeRatio >= the size of D1, trigger a merge of D1, D2, ..., DK.
  • If the merge cannot be triggered for D1, then report the above step for D2.

The size ratio controlls some interesting performance trade-offs. By setting the size ratio < 1, 



[1] Chen Luo, Michael J. Carey. LSM-based Storage Techniques: A Survey, https://arxiv.org/abs/1812.07527.

  • No labels