You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Align default BanyanDB stage segmentInterval to integer multiples (#13910)
### Improve the efficiency of BanyanDB hot → warm → cold lifecycle stage migration (default config)
Each coarser lifecycle stage's `segmentInterval` should be an integer multiple of the immediately finer (preceding) stage's. BanyanDB segments are epoch-anchored, so when the coarser interval is a multiple of the finer one, every source segment nests entirely inside exactly one target segment and the tier migration stays on the cheap **whole-segment fast path** (byte-copy). A non-multiple interval makes source segments straddle target boundaries, forcing a row-by-row decode-and-re-bucket **slow path** that costs significantly more CPU, IO, and peak memory, and produces more small parts for the background merge loop to compact. It does not affect correctness — only migration efficiency.
This aligns the shipped defaults that previously violated the rule:
| Group | Field | Old → New |
|-------|-------|-----------|
| records | cold `segmentInterval` | 3 → 4 (multiple of warm=2) |
| metricsMinute | cold `segmentInterval` | 5 → 6 (multiple of warm=3) |
| metricsHour | warm `segmentInterval` | 7 → 10 (multiple of hot=5) |
| metricsHour | cold `segmentInterval` | 15 → 20 (multiple of warm=10) |
All adjusted values still satisfy `hot ≤ warm ≤ cold` and `segmentInterval ≤ that stage's ttl`. The other groups already comply and are unchanged.
Copy file name to clipboardExpand all lines: docs/en/banyandb/stages.md
+16-15Lines changed: 16 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,31 +14,32 @@ Each group of records/metrics can be automatically migrated and stored in differ
14
14
If necessary, you also can jump the warm stage, and only use hot and cold stages. Then the data will be moved to the cold stage after the TTL of the hot stage.
15
15
16
16
## Configuration Guidelines
17
-
The lifecycle stages configuration is under each group settings of the `bydb.yml` file, for example, the `metricsMin` group:
17
+
The lifecycle stages configuration is under each group settings of the `bydb.yml` file, for example, the `metricsMinute` group:
1. **shardNum**: The number of shards for the group.
40
40
2. **segmentInterval**: The time interval in days for creating a new data segment.
41
41
- According to the freshness of the data, the `segmentInterval` days should: `hot` < `warm` < `cold`.
42
+
- Each coarser stage's `segmentInterval` should be an **integer multiple** of the immediately finer (preceding) stage's `segmentInterval` (e.g. `hot=5` → `warm=10` → `cold=20`). BanyanDB segments are epoch-anchored, so when the coarser interval is a multiple of the finer one each source segment nests entirely inside one target segment and the hot → warm → cold migration stays on the cheap whole-segment fast path. A non-multiple interval (e.g. `hot=5`, `warm=7`) makes source segments straddle target boundaries, forcing a row-by-row re-bucketing that costs significantly more CPU, IO, and memory. It does not affect correctness, only migration efficiency.
42
43
3. **ttl**: The time-to-live for data within the group, in days.
43
44
4. **enableWarmStage/enableColdStage**: Enable the warm/cold stage for the group.
Copy file name to clipboardExpand all lines: docs/en/changes/changes.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -297,6 +297,7 @@
297
297
* Bump up dependencies to clear CVE alerts on shipped OAP jars: log4j `2.25.3` → `2.25.4`, jackson `2.18.5` → `2.18.6`, kafka-clients `3.4.0` → `3.9.2`, postgresql `42.4.4` → `42.7.11`, commons-compress `1.21` → `1.26.2`.
298
298
* Fix: continuous profiling policy validation now rejects a threshold / count of `0` to match the error messages and rover's `value >= threshold` trigger semantics (a `0` threshold would always trigger). CPU percent and HTTP error rate are tightened from `[0-100]` to `(0-100]`.
299
299
* Fix wrong BanyanDB resource options in record data.
300
+
* Align the default BanyanDB stage `segmentInterval` values so each coarser stage is an integer multiple of the finer one (`records` cold `3` → `4`, `metricsMinute` cold `5` → `6`, `metricsHour` warm `7` → `10` and cold `15` → `20`), keeping hot → warm → cold lifecycle migration on the cheap whole-segment fast path.
300
301
301
302
#### UI
302
303
* Add Airflow layer dashboards and menu i18n under Workflow Scheduler in Horizon UI (SWIP-7).
0 commit comments