rqe-optimizer: MILP on cost by use, with batch latency (reported, or as an SLA)

[zzylol]

What

The MILP that plans RQE deployments now prices a plan's cost billed by use, and computes the plan's batch latency. Latency is used in two versions:

1. No SLA: the cheapest plan, with its latency reported. A latency bound can be swept to trace the cost–latency Pareto frontier.
2. Batch latency SLA: the cheapest plan whose batch latency is at most L.

This is for the AutoSketch vs. planner evaluation (ProjectASAP/ASAPQuery#777). The evaluation itself is #138, stacked on this PR.

The design is in docs/rqe_sketch_deployment_v1.md, section "Cost by use and batch latency". Every formula and the algorithm come with a plain-English explanation. The sections are:

1. Definitions.
2. Cost model, and how it maps to cloud billing.
3. CPU parts and how each is computed.
4. Memory parts and how each is computed.
5. Batch latency and the SLA.
6. The job placement algorithm.
7. MILP formulation.
8. Solution method.
9. Outputs.

Model

• Cost: w1 · AUC(CPU) + w2 · AUC(memory), CPU elastic, as on fine-grained autoscaling platforms. Provisioned (peak) billing is not modeled.
• CPU:
  • Ingest (the precompute) runs on ⌈ρ⌉ workers split by sample.
  • A compaction job merges the workers' partial copies at each window close.
  • Each RQE firing issues one query job, which merges the query window's instances and then estimates.
  • Every job uses at most one core, because sketch-bench's operations are single-threaded (CPU time = wall time).
• Memory, each part counted once:
  • ingest (open windows × workers);
  • storage (compacted closed windows);
  • compaction (partial copies, while it runs);
  • query (merge accumulators and output, while it runs).
• Batch latency: the job placement (issue order, compaction before queries, longest first, up to one core per job) gives it. With elastic CPU it has a closed form: the longest chain, compaction then query.
• MILP: linear and exact in both versions. A latency bound or SLA is a filter that rules out pairs whose chain is longer than L.

Code

• rqe-optimizer/src/usage.rs: a plan's resource use, cost by use, and latency.
• milp::minimize_usage_cost:
  • optional latency_bound_ms, for the frontier or the SLA;
  • optional allowed candidates per RQE, so PerQuery can rule out sharing: identical deployments become separate copies, each paying its own ingest.
• analytical_cost_model: ingest_workers, compaction_secs, compaction_bytes, chain_ms.
• The existing minimize is unchanged, so ASAPQuery's planner is unaffected.

Tests

• Cost by use and latency of a small plan.
• minimize_usage_cost matches brute force under three weight settings, and under four latency bounds; looser bounds never cost more.
• allowed keeps identical deployments apart.
• All 92 rqe-optimizer tests pass; clippy is clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FhcWJExZcmVqS6r6rEtjis

[milindsrivastava1997]

should rho_D be divided by scrape interval for "mean vCPUs"?

[zzylol]

No: the scrape interval is already inside λ_D = card(series) / scrape interval (samples per second). ρ_D = λ_D (samples/s) × x/y (windows per sample) × c_ins (CPU-seconds per insert) is already CPU-seconds per second. The definitions table now states λ_D's definition, and the explanation spells out the units (5aa3932).