How Does the InfluxDB Data Model Work?
Understand InfluxDB's measurement, tag, and field data model, why tag cardinality matters, and how series are defined.
Expected Interview Answer
InfluxDB organizes data around measurements, which act like tables, and each data point within a measurement is defined by a timestamp, a set of indexed tags (string key-value metadata used for filtering), and a set of fields (the actual numeric or string values being recorded), grouped together into a series by the unique combination of measurement and tag values.
A measurement (e.g. "cpu_usage") holds many points over time, and each point carries tags such as host or region that InfluxDB indexes for fast filtering, plus fields such as usage_percent that hold the actual measured value but are not indexed the same way. The combination of a measurement plus a specific set of tag values defines a series, and InfluxDB stores each series' points together in time order, which is why choosing tags versus fields correctly matters enormously: putting a high-cardinality value (like a unique request ID) into a tag creates an explosion of series that can degrade performance, so tags should be low-cardinality metadata used for filtering and grouping, while fields hold the actual measured data.
- Tags enable fast, indexed filtering and grouping by metadata
- Fields store the actual measured values without indexing overhead
- Series-based storage keeps points from the same source together in time order
- Schema is flexible, letting new tags or fields be added without migrations
AI Mentor Explanation
A cricket statistics system records every delivery under a measurement called "deliveries," tagging each entry with low-cardinality metadata like team and venue for fast filtering, while fields hold the actual measured values like speed and swing angle. If ball ID were made a tag instead of left out, the number of distinct series would explode since every delivery is unique. InfluxDB's tag-versus-field split works exactly this way: tags are for filtering metadata, fields are for the numbers actually being measured.
Step-by-Step Explanation
Step 1
Choose the measurement
Group related data under one measurement name, analogous to a table (e.g. cpu_usage).
Step 2
Select tags for filtering
Pick low-cardinality metadata (host, region, environment) as indexed tags used to filter and group.
Step 3
Select fields for values
Store the actual measured numbers or strings (usage_percent, latency_ms) as fields, which are not indexed the same way.
Step 4
Write points with a timestamp
Each write combines the measurement, tag set, field set, and a timestamp to form one point in a series.
What Interviewer Expects
- Clear distinction between tags (indexed, low-cardinality metadata) and fields (measured values)
- Understanding of what defines a series and why series cardinality matters
- Awareness of the schema-on-write flexibility InfluxDB offers
- Concrete example of a well-designed measurement/tag/field split
Common Mistakes
- Putting high-cardinality identifiers (user ID, request ID) into tags, causing series explosion
- Confusing InfluxDB measurements with relational tables in every respect
- Forgetting that fields are not indexed the way tags are
- Not explaining what a "series" means in InfluxDB's model
Best Answer (HR Friendly)
“InfluxDB organizes data into measurements, similar to tables, and each data point has tags, which are indexed metadata used for filtering like region or device type, and fields, which hold the actual measured values like temperature or CPU usage. The important design decision is keeping tags low-cardinality, because putting something like a unique ID into a tag can create so many distinct series that performance suffers.”
Code Example
-- Line protocol write: measurement,tag_set field_set timestamp
cpu_usage,host=server01,region=us-east usage_percent=72.5 1721318400000000000
-- Conceptual query: filter by tag, aggregate a field over a time range
-- SELECT mean(usage_percent)
-- FROM cpu_usage
-- WHERE host = 'server01' AND time > now() - 1h
-- GROUP BY time(5m)Follow-up Questions
- What is series cardinality and why does high cardinality hurt performance?
- How do tags differ from fields in terms of indexing and query cost?
- What happens when you query without specifying any tag filters?
- How does InfluxDB's schema-on-write model compare to a fixed relational schema?
MCQ Practice
1. In InfluxDB, what defines a series?
A series is uniquely identified by its measurement name plus the exact combination of tag key-value pairs.
2. Why should high-cardinality values like unique request IDs be avoided as tags?
Each distinct tag value combination creates a new series, so high-cardinality tags multiply series count and hurt performance.
3. What is stored as a "field" in InfluxDB's data model?
Fields hold the actual data being measured (numeric or string values) and are not indexed the same way tags are.
Flash Cards
What is a measurement in InfluxDB? — A named container for related time-series data, similar to a table.
What is a tag? — Indexed, low-cardinality metadata used for filtering and grouping, like host or region.
What is a field? — The actual measured value stored per point, such as temperature or usage percentage.
What defines a series? — The unique combination of a measurement name and its tag key-value set.