<p>The merge compaction behavior and strategy used by Google Cloud Bigtable is currently not tunable by end users via the Cloud Bigtable APIs, although the underlying system which backs the Cloud Bigtable product is dynamic and tunable by our engineering and operations teams. </p>

<p>Here's a somewhat recent paper on different approaches to merge compaction algorithms which have been explored in Bigtable: </p>

<p>Online Bigtable merge compaction
<a href="https://arxiv.org/pdf/1407.3008.pdf" rel="nofollow noreferrer">https://arxiv.org/pdf/1407.3008.pdf</a></p>

<p>We employ a number of proprietary approaches to dynamically adjusting and tuning merge compaction behavior. If you do have more specific questions related to your use of the system or are experiencing issues with merge compaction behavior you can of course feel free to file a support case. </p>
Does BigTable use Tiered or Leveled LSM-tree compaction?
<p>Google BigTable is a system that uses LSM-tree as its core data structure for storage. LSM-tree can use different merge strategies. The two most common ones are (1) leveled merging which is more read-optimized, and (2) tiered merging which is more write-optimized. These merge strategies can further be configured by adjusting the size ratio between adjacent levels. </p>

<p>I have not been able to find anywhere what is BigTable's default behavior in these respects, and whether it can be tuned or not. As a result, it is hard to understand it's default performance properties and how to adapt them to different workloads. </p>

<p>With tiered merging, a level of LSM-tree gathers runs until it reaches capacity. It then merges these runs and flushes the resulting run to the next larger level. There are at most O(T * log_T(N)) runs at each level, and write cost is O(log_T(N) / B), where N is the data size, B is the block size, and T is the size ratio between levels. </p>

<p>With leveled merging, there is one run at each level of LSM-tree. A merge takes place as soon as a new run comes into the level, and if the level exceeds capacity the resulting run is flushed to the next larger level. There are at most O(log_T(N)) runs at each level, and write cost is O((T * log_T(N)) / B). </p>

<p>As a result, these schemes have different read/write performance properties. However, I have been unable to find sources on whether Google's BigTable uses leveled or tiered merging, and what is the default size ratio T? Also, are these aspects of the system fixed, or are they tunable? </p>