Theta sketch compact() before storage vs. keeping the updatable form for low-cardinality tenant streams

Answer the question first

For the described workload – thousands of tenants, most with < 500 distinct values per hour – the sensible default is to keep each tenant’s sketch in its updatable form while it is being updated, and to call compact() once at the end of the hourly window before the sketch is serialized or cached. The compaction cost is negligible compared to the cost of hashing each incoming item, and the memory savings are substantial: a compacted sketch for a tenant with 200 distinct values consumes roughly 200 × 4 bytes ≈ 0.8 kB versus the 4096 × 4 bytes ≈ 16 kB of the default buffer.

Why compaction only at serialization?

• CPU cost is tiny. The main work in compact() is copying the internal hash table. For a nominal size of 4096, this is a few hundred microseconds – far less than the time spent hashing a small batch of items.
• Memory pressure is the real issue. Keeping 10,000 tenants in the 4096‑entry form can consume 160 MB of heap, whereas compacting each to its true size brings that down to under 1 MB.
• Update speed stays high. The updatable form is designed for fast incremental updates; compaction would force a copy on every update, which would add latency to the streaming pipeline.

When is undersizing nominalEntries defensible?

Lowering nominalEntries to 512 reduces per‑sketch memory to 512 × 4 bytes ≈ 2 kB. However, the 95 % relative error bound rises from about 1.6 % (for 4096) to roughly 4.4 % (≈ √(1/512)). If your application can tolerate that higher error, and you have confidence that no tenant will exceed the nominal size in a single hour, the smaller sketch may be acceptable. The risk is that a sudden cardinality spike will cause the sketch to underestimate and the error bound to be violated silently.

Recommended wrapper pattern

Encapsulate the lifecycle in a small helper that hides the compaction logic:

class TenantSketch {
    private final Sketch<Double> mutable;
    private Sketch<Double> compacted;

    TenantSketch() {
        this.mutable = new ThetaSketch(4096); // or 512 if error tolerance allows
    }

    void add(Object value) { mutable.update(value); }

    // Call once per hourly window
    Sketch<Double> snapshotAndCompact() {
        if (compacted == null) {
            compacted = mutable.compact();
        } else {
            compacted = compacted.compact();
        }
        return compacted;
    }
}

Use snapshotAndCompact() only when you need to serialize or cache the result. Keep mutable alive for the next window.

What diagnostic detail could change the recommendation?

Ask yourself: What is the acceptable relative error for your cardinality estimates? If you need <2 % error, default to 4096 and compact only at serialization. If 4 % is tolerable, you may experiment with 512, but you should monitor the distribution of cardinalities and have an alert for spikes that exceed the nominal size.

Practical verification steps

1. Instrument your update loop to record the time spent in update() and in compact() for a sample tenant.
2. Measure heap usage with 10,000 tenants in updatable form versus after compaction.
3. Inject a spike (e.g., 2000 distinct values) into a tenant configured with 512 nominal entries and verify the error exceeds the 4.4 % bound.
4. If memory pressure remains high, consider a two‑tier approach: keep a compacted copy in the cache and a mutable copy only while the window is active.

Conclusion

For low‑cardinality, high‑tenant workloads, keep sketches mutable during updates and compact only at serialization. Undersize nominalEntries only if your error tolerance justifies it and you can monitor for cardinality spikes. A lightweight wrapper that enforces this boundary keeps the code clean and the memory footprint minimal.