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
Copy file name to clipboardExpand all lines: docs/compaction.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,20 +6,20 @@
6
6
7
7
## 1. Overview
8
8
9
-
Compactions are orchestrated by `compact.Manager` with `lsm.levelManager`implementing the executor hooks. Each level owns two lists of tables:
9
+
Compactions are orchestrated by `lsm.compaction` with `lsm.levelManager`supplying scheduling input and executing the plan. Each level owns two lists of tables:
10
10
11
11
-`tables` – the canonical sorted run for the level.
12
12
-`ingest` – a staging buffer that temporarily holds SSTables moved from the level above when there is not yet enough work (or bandwidth) to do a full merge.
13
13
14
-
The compaction manager periodically calls into the executor to build a list of `compact.Priority` entries. The priorities consider three signals:
14
+
The compaction runtime periodically calls into the picker to build a list of `Priority` entries. The priorities consider three signals:
15
15
16
16
1.**L0 table count** – loosely capped by `Options.NumLevelZeroTables`.
17
17
2.**Level size vs target** – computed by `levelTargets()`, which dynamically adjusts the “base” level depending on total data volume.
18
18
3.**Ingest buffer backlog** – if a level’s `ingest` shards have data, they receive elevated scores so staged tables are merged promptly.
19
19
20
20
The highest adjusted score is processed first. L0 compactions can either move tables into the ingest buffer of the base level (cheap re‑parenting) or compact directly into a lower level when the overlap warrants it.
21
21
22
-
Planning now happens via `compact.Plan`: LSM snapshots table metadata into `compact.TableMeta`, `compact.PlanFor*` selects table IDs + key ranges, and LSM resolves the plan back to `*table` before executing.
22
+
Planning now happens via `Plan`: LSM snapshots table metadata into `TableMeta`, `PlanFor*` selects table IDs + key ranges, and LSM resolves the plan back to `*table` before executing.
23
23
24
24
---
25
25
@@ -41,9 +41,9 @@ Compaction tests (`lsm/compaction_test.go`) assert that after calling `moveToIng
41
41
42
42
To prevent overlapping compactions:
43
43
44
-
-`compact.State.CompareAndAdd` tracks the key range of each in-flight compaction per level.
44
+
-`State.CompareAndAdd` tracks the key range of each in-flight compaction per level.
45
45
- Attempts to register a compaction whose ranges intersect an existing one are rejected.
46
-
- When a compaction finishes, `compact.State.Delete` removes the ranges and table IDs from the guard.
46
+
- When a compaction finishes, `State.Delete` removes the ranges and table IDs from the guard.
47
47
48
48
This mechanism is intentionally simple—just a mutex‐protected slice—yet effective in tests (`TestCompactStatusGuards`) that simulate back‑to‑back registrations on the same key range.
Copy file name to clipboardExpand all lines: docs/ingest_buffer.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,11 +16,11 @@ flowchart LR
16
16
-**Sharded by key prefix**: ingest tables are routed into fixed shards (top bits of the first byte). Sharding cuts cross-range overlap and enables safe parallel drain.
17
17
-**Snapshot-friendly reads**: ingest tables are read under the level `RLock`, and iterators hold table refs so mmap-backed data stays valid without additional snapshots.
18
18
-**Two ingest paths**:
19
-
-*Ingest-only compaction*: drain ingest → main level (or next level) with optional multi-shard parallelism guarded by `compact.State`.
19
+
-*Ingest-only compaction*: drain ingest → main level (or next level) with optional multi-shard parallelism guarded by `State`.
20
20
-*Ingest-merge*: compact ingest tables back into ingest (stay in-place) to drop superseded versions before promoting, reducing downstream write amplification.
21
21
-**IngestMode enum**: plans carry an `IngestMode` with `IngestNone`, `IngestDrain`, and `IngestKeep`. `IngestDrain` corresponds to ingest-only (drain into main tables), while `IngestKeep` corresponds to ingest-merge (compact within ingest).
22
22
-**Adaptive scheduling**:
23
-
- Shard selection is driven by `compact.PickShardOrder` / `compact.PickShardByBacklog` using per-shard size, age, and density.
23
+
- Shard selection is driven by `PickShardOrder` / `PickShardByBacklog` using per-shard size, age, and density.
24
24
- Shard parallelism scales with backlog score (based on shard size/target file size) bounded by `IngestShardParallelism`.
25
25
- Batch size scales with shard backlog to drain faster under pressure.
26
26
- Ingest-merge triggers when backlog score exceeds `IngestBacklogMergeScore` (default 2.0), with dynamic lowering under extreme backlog/age.
@@ -33,7 +33,7 @@ flowchart LR
33
33
34
34
## Benefits
35
35
-**Lower write amplification**: bursty L0 SSTables land in ingest first; `IngestKeep`/ingest-merge prunes duplicates before full compaction.
0 commit comments