InfluxDB Beginner's Guide: Time-Series Database Concepts & Hands-On Installation

What Are Time-Series Data and Time-Series Databases?

1. What Is Time-Series Data

Time-series data is data generated in chronological order. The author illustrates with three concrete examples:

Running top to see server CPU and memory usage constantly refreshing — used to judge server load.

Phone weather app updating temperature and humidity hourly — helps decide whether to wear a coat.

Smart scale recording weight daily — tracks whether you are losing weight.

These examples share three key characteristics: they carry timestamps, arrive in sequence, and are continuously produced . Historical records are rarely modified (you don't go back and change yesterday's weight); data is mostly append-only, and volume grows steadily.

2. Four Core Differences Between Time-Series and Regular Data

Core difference: Time is the primary key for time-series data; for regular data it's just an auxiliary field. Queries on time-series data are typically range-based (e.g., past 24 hours of household electricity consumption), whereas regular data queries often target a specific record (e.g., a single user).

Generation pattern: Regular data is frequently updated (usernames, passwords). Time-series data is immutable once written — only high-frequency appends occur.

Lifecycle: Regular data (e.g., transaction records) must be kept long-term. Time-series data has a "shelf life" — monitoring logs might only need 30 days (or six months for compliance) and can then be auto-deleted.

Query patterns: Regular data requires complex joins and multi-condition filters. Time-series queries follow fixed patterns: time-range scans, aggregations (averages), and trend analysis.

3. What Is a Time-Series Database (TSDB)

A TSDB is a purpose-built database for storing and processing time-series data. Its design directly addresses the pain points of forcing relational databases like MySQL to handle time-series workloads. MySQL excels at structured, mutable business data (user profiles), while a TSDB is optimized for append-only, expiring, high-frequency metric data.

4. Four Core Advantages of TSDB Over MySQL

High-frequency writes without stalls: Example — 1,000 smart meters collecting every 15 minutes generate ~100,000 data points per day. MySQL eventually suffers write latency; a TSDB handles the volume smoothly.

Disk space efficiency: Time-series data has high redundancy. A TSDB compresses automatically — 1 million monitoring points might take several GB in MySQL but only a few hundred MB in a TSDB.

Fast time-range queries: Aggregations over time windows return in seconds; the same query on MySQL often times out or runs extremely slowly.

Lower ops overhead: TTL policies auto-delete expired data; MySQL requires manual cleanup scripts that are error-prone.

Summary: MySQL manages static, occasionally updated business data; TSDBs manage dynamic, continuously generated metric data. It's not that MySQL is bad — it's just not the right tool for time-series workloads.

Popular Time-Series Databases

The author lists four mainstream options:

InfluxDB: Simple install, intuitive operation, mature ecosystem, built-in compression and retention, approachable query syntax. Best for ops monitoring, IoT, personal learning, small-to-medium projects (the focus of this tutorial). Widely used in production.

Prometheus: Purpose-built for ops monitoring, strong multi-dimensional queries and alerting, commonly paired with Grafana for visualization, open-source and free. Essential for server/cluster monitoring and DevOps. Many don't realize it embeds a TSDB.

TimescaleDB: Built on PostgreSQL, full SQL compatibility — no new query language to learn. Supports hybrid storage of relational and time-series data. Suits projects needing both business and metric data, especially with existing PostgreSQL expertise.

Elasticsearch (time-series use): Excels at log-type time-series storage and retrieval, flexible queries, strong visualization, but consumes more resources. Ideal for log monitoring and analysis (system logs, application logs). Familiar to most developers.

Step-by-Step InfluxDB 2.7 Installation on Linux (CentOS/Ubuntu)

1. Download the Package

Official downloads can be slow; the author provides a direct wget command for version 2.7 (stable, beginner-friendly):

wget https://dl.influxdata.com/influxdb/releases/influxdb2-2.7.0-linux-amd64.tar.gz

Note: If the command fails with an internal error, the official link may be temporarily unavailable — retry later or use an alternative mirror.

2. Extract and Enter Directory

# Extract
tar -zxvf influxdb2-2.7.0-linux-amd64.tar.gz
# Enter extracted directory
cd influxdb2-2.7.0-linux-amd64

3. Copy Binaries to System Path (Critical Step)

Enables global influx and influxd commands:

cp influxd /usr/local/bin/
cp influx /usr/local/bin/

4. Verify Installation

Run both commands; version output confirms success:

influxd version
influx version

5. Start InfluxDB (Two Modes)

Beginners should test with foreground mode first, then switch to background for production:

# Mode 1: Foreground (test only, stops when terminal closes)
influxd

# Mode 2: Background daemon (recommended for long-term use)
nohup influxd > influxd.log 2>&1

Default port is 8086 . If startup fails, check for port conflicts or firewall blocks. On CentOS, open the port:

firewall-cmd --add-port=8086/tcp --permanent
firewall-cmd --reload

6. Web UI Initialization (Required)

Open http://your-server-ip:8086 in a browser. First visit launches the setup wizard:

Username (e.g., admin)

Password (memorable, used for later login)

Organization Name (e.g., my-org — save for later)

Bucket Name (equivalent to a MySQL database name, e.g., my-bucket — save for later)

Click Continue to finish initialization.

7. Obtain API Token (Required for All Subsequent Operations)

Log in, navigate to Data → API Tokens on the left sidebar.

Copy the default token generated during setup; store it securely — it's needed for every write and query.

8. Quick Functional Test: Write and Query a Data Point

Replace placeholders ( your-org, your-token, your-bucket) with actual values:

# 1. Configure connection (one-time setup)
influx config create \
  --n my-config \
  --u http://localhost:8086 \
  --o your-org \
  --t your-token \
  --b your-bucket

# 2. Write a test point (simulated server CPU metrics)
influx write \
  -b your-bucket \
  -o your-org \
  'cpu,host=server01 usage_idle=95.5,usage_user=4.2'

# 3. Query last hour of CPU data
influx query \
  'from(bucket:"your-bucket") |> range(start:-1h) |> filter(fn: (r) => r._measurement == "cpu")'

If the query returns the written point, InfluxDB is installed and working correctly.

Key Takeaways

Time-series databases are specialized tools for time-series data, solving the specific pain points of using MySQL for metrics.

InfluxDB offers the gentlest learning curve; advanced usage and visualization (with Grafana) will be covered later.

Use the right tool for the job: MySQL for static, mutable business data; TSDBs for dynamic, ever-growing metric data.