Question 1

What does Pinot performance tuning cover?

Accepted Answer

Star-tree index optimization (dimension selection, aggregation function audit), segment sizing (target 100MB-1GB per segment for query performance), broker fanout reduction (server tagging, partition routing), multi-tenant isolation tuning (broker pools, server tagging per tenant), LLRT realtime consumer throughput, Helix coordination tuning, deep-storage I/O optimization. Deliverables include before/after p99 latency benchmarks.

Question 2

p99 latency creeping up — where to start?

Accepted Answer

Query log analysis (Pinot Prometheus metrics + minion stats) to identify slow query patterns. Common findings: queries that don't hit star-tree (missing dimensions, aggregation functions not pre-computed), too many segments per query (segment-fetch dominates), broker-server fanout too wide (single query touches every server), inadequate star-tree maxLeafRecords forcing fallback to raw scan. We've never seen a slow Pinot cluster without at least 2 of these.

Question 3

Star-tree index tuning — what are the levers?

Accepted Answer

Dimension order (low-cardinality first), aggregation function selection (pre-compute SUM, COUNT, MIN, MAX, DISTINCTCOUNT — pick only what queries use), maxLeafRecords (smaller = deeper tree = faster queries but more storage), no-dictionary columns for high-cardinality fields. We benchmark candidate star-tree configurations against query workload before committing — wrong star-tree wastes storage without speedup.

Question 4

Segment size — what's optimal?

Accepted Answer

Target 100MB-1GB per segment for query performance. Too small (under 50MB): per-segment overhead dominates, broker-server fanout explodes. Too large (over 2GB): single-segment scan becomes the bottleneck. For realtime tables: segment.flush.threshold.size + segment.flush.threshold.rows control LLRT commit cadence. For offline tables: batch generator config controls segment granularity. We tune both against ingestion rate and query latency budget.

Question 5

Multi-tenant isolation — how to prevent noisy neighbours?

Accepted Answer

Pinot tag-based server segmentation: assign tag to tenant's tables (table-level), pin tenant to specific servers via tag matching. Broker pools per tenant tier for query isolation. Per-tenant query rate limiting via instance-level config. We audit existing tenant load + design the isolation topology before code ships — retrofitting isolation after the fact is expensive.

Question 6

LLRT consumer throughput is plateauing — what to check?

Accepted Answer

Pinot LLRT consumer task count should match Kafka topic partitions. Common bottlenecks: server JVM heap pressure (large segment buffers), Kafka consumer config (fetch.min.bytes, fetch.max.wait.ms tuning), commit cadence too aggressive (small segments). Diagnose via Pinot metrics: pinot_realtime_consumed_count, pinot_realtime_lag_in_messages. We tune consumer config + server resources together.

Question 7

StarTree Cloud vs self-managed tuning?

Accepted Answer

StarTree Cloud handles most tuning automatically (segment size, broker fanout, JVM tuning). Self-managed needs explicit operator attention. We tune both — engagement scope changes based on which deployment model you're on. For the engine-decision phase, see Pinot consulting.

Apache Pinot Performance Tuning

What our Pinot perf tuning covers

Pinot perf tuning — common questions

Ready to fix Pinot performance?