A New Data Model for Time Series Data Processing
summary
Claims a relational variant called one table per sensor that stores time-ordered blocks, column-compresses per-device streams, and keeps tags separate so aggregation uses a supertable template. Reports ingestion rates 2–5× higher, query latency 2–30× lower, much better compression and lower CPU, and a claimed ability to manage up to 1 billion tables. Benchmarks use the TSBS benchmark suite with reproducible scripts and ingestion/query comparisons against InfluxDB and TimescaleDB.
AI-written summary · about
chapters (11)
- 0:00TDengine and time series data
- 2:33Challenges with existing time series databases
- 5:18Time series data traits
- 9:59Relational model limits
- 13:15One-table-per-device model
- 18:31Aggregation with super tables
- 25:23TDengine vs competitors
- 27:27Scalability and distributed
- 30:41DB with queue and cache
- 31:44Open source growth
- 33:53Q&A
related talks
39mA New Data Model for Time Series Data Processing
07mTime Series Databases
29mCatching Waves with Time-Series Data
30mCatching Waves with Time-Series Data
23mTime series database: Should I use one?
58mIntroduction to Timeseries Databases
49mThinking in time series, the new solution to your pro...
51mBuilding a scalable time-series database on PostgreSQL