Definition
Time Series DB (Time Series Database) is specifically designed for time-series data and stores device Telemetry data. It supports high-concurrency writes and time-range aggregation queries, providing a data foundation for Device Monitoring and Predictive Maintenance.
Core Features and Selection
Time-series databases are optimized for the "timestamp + metric value" structure, supporting high-throughput writes, downsampling, and aggregations by time window (such as avg, max, percentile). Common options include InfluxDB, TimescaleDB, OpenTSDB, and Prometheus. Device Management Platforms need to choose based on the scale of devices, sampling frequency, retention policy, and query patterns; large-scale IoT scenarios usually adopt columnar storage and compression, support hot and cold data tiering, and balance long-term storage with real-time queries.
Data flow with DMP
Device telemetry is ingested via MQTT or protocol gateways, and then written into the time-series database by a rules engine or data pipeline. The data model typically uses device ID and digital twin properties as tags, with timestamps and values as time-series points. The platform provides aggregation query APIs for Device Monitoring dashboards, Report Analytics reports, and visualization tools like Grafana; algorithms such as RUL remaining useful life prediction and anomaly detection also rely on time-series data as input.
Use Cases
Time-series databases support telemetry storage and analysis scenarios including energy monitoring, industrial sensors, smart metering, and connected vehicles. High-concurrency write capabilities accommodate millions of devices reporting simultaneously; downsampling and retention policies control storage costs; multi-dimensional queries by device and by time support fault investigation and trend analysis. They are a core component of the data foundation for Device Management Platforms.
A time-series point is tags, a timestamp, and a value
A point in a time-series database is one value at one time on one series. The series is distinguished by a small number of stable tags, for example a device identity and a thing model property. The timestamp is the sample time. The value is stored in the type the model specifies. If the platform treats receive time as the only time, backfilled data crowds the moment the connection recovered, and a fault traced by time lands in the wrong place. One series and one timestamp should have only one value. A conflict has to be handled explicitly. Do not rely on the database's default overwrite and leave no trace.
Writes suit append. Editing history, and frequently deleting points in the middle, both run against how this kind of store is organized. When a correction is required, append a correction point and keep the original value, or rebuild a whole stretch under a stated retention rule. On the query side, the common cases are raw points inside a time window, or a mean, maximum, or percentile over a fixed window. A window aggregate must say what an empty window does. If there is no point, do not emit zero. A new series produced by downsampling should take a different retention period, and it should say that it cannot restore a spike. A rule that needs the spike should read the raw series, or a downsample that is fine enough, not the hourly mean kept to save space.
High-cardinality tags become the bottleneck before disk does
The number of tag combinations is the order of magnitude of the series count. Device identity times the number of properties is already the expected scale. Put a per-request trace id, an operator name, or a free-text note into a tag as well, and the series count grows with the number of events. Index and memory fill before the disk does. The condition for use is therefore that tags hold only dimensions that recur and that are used to filter. One-off information goes into the value, the log, or a separate asset store.
A query should carry a time range and at least a device or a property selection. Avoid an unbounded scan across every series. A bulk export should go through a dedicated task, with concurrency limited, rather than letting every board open scan the whole table. Retention differs by property. High-rate vibration does not have to be kept as long as daily energy. Expiry deletion should be a continuous policy, not a manual stop of writes when the disk is already in alarm. Stopping writes makes the rule engine go silent for lack of data, which looks as if the site has returned to normal.
Turning every asset-record field into a tag
Site name, owner, contract number, and installation address are often written into the tags of every telemetry point at once, so someone can "query the curve directly by address." Those fields change. Change the owner and the old and new points of the same device belong to different series. The curve breaks on the day of the change, and filtering by the new person does not see data from before the change. Asset fields should stay in the device record. A query resolves a list of device identities first, then filters the time series. Occasional historical ownership is reconstructed at query time from the change record. Do not freeze the name of the moment into every point.
Another mistake is to copy a full set of raw points for every counting definition. If online rate, the daily report, and alarm replay each store their own detail, write volume multiplies, and the definitions drift apart easily. Keep one copy of the detail. Compute each definition in a query or a summary task, and store the summary result rather than a copy of the detail. If points with a wrong clock enter the aggregate directly, they pollute windows in the far future or the far past. Before ingest, mark timestamps that are obviously outside a reasonable range and isolate them. Do not let them into the default query in the name of not losing data. The isolation area can still be inspected by hand, but the default curve, the rules, and the reports do not read it.
Before a new tag goes live, estimate the series count: device count times property count times the number of possible values of that tag. If the estimate exceeds the memory budget, put it in the asset record or in the value instead. Periodically look at series that have gone longest without a new point, and at the tags that occupy the most series, and find dimensions that have been split too far. The repair is to stop writing that tag and convert it at query time, not to delete history immediately. A delete removes samples from a review that is still running. Capacity alarms should come before write failures. After an alarm, first shorten retention of high-rate properties, or reduce how many copies are kept before they are downsampled, and record which queries that tradeoff affects.