Data and Database Architecture

Architecture Goals

FastBee's data architecture aims for stable business data, high-throughput device data, high cache hit rates for hot data, and traceable historical data. Relational databases handle business master data and transactional consistency, time-series databases handle large-scale device data, and Redis handles cache, sessions, and distributed coordination.

Data Layers

Database Responsibilities

Type	Example Components	Main Responsibility	Applicable Data
Relational database	MySQL, PostgreSQL, DM, Kingbase	Transactions, permissions, configuration, business tables	Users, organizations, products, devices, rules, alarms
Time-series database	TDengine, IoTDB, InfluxDB	High write throughput, time-based queries, history archive	Device properties, collected values, telemetry
Cache	Redis, Redisson	Hot reads, sessions, distributed locks, rate limits	Tokens, device status, thing models, configuration cache
Bridge data source	Database bridge and dynamic data source	External database integration or rule output	Rule forwarding, third-party system synchronization

Data Access Layer

• MyBatis Plus unifies pagination, SQL filtering, audit-field filling, and ID generation.
• Dynamic data sources adapt primary databases, time-series databases, and external data sources.
• Pagination queries should limit page size. Export tasks are better handled asynchronously.
• Complex queries should be continuously optimized with indexes, query plans, and slow-SQL logs.

Cache Strategy

Cached Object	Recommendation
Device status	Use short TTL or event-driven updates to avoid long-term inconsistency
Thing model and product configuration	Warm up on startup or load on first access; invalidate after modifications
Modbus/gateway configuration	Refresh after configuration changes so collection jobs do not read old data
OTA tasks	Set expiry according to task state and device response
Rules and scenes	Refresh runtime configuration after rule publishing and keep execution logs

Consistency Principles

• Strongly consistent data should first go to the relational database, such as users, permissions, and order-like business data.
• Device reports and rule triggers can use eventual consistency, with messages, logs, and compensation mechanisms for traceability.
• Cache updates should follow "update database first, then invalidate cache" or a business-verified delayed double-delete strategy.
• Distributed locks should be used only for necessary concurrency control. Keep lock scope small and always set an expiry time.

Backup and Migration

1. Keep initialization SQL, upgrade SQL, and a current configuration snapshot before launch.
2. Back up relational databases regularly. Production environments should add incremental or physical backups where needed.
3. Plan time-series archives according to retention periods, hot/cold tiers, and compliance requirements.
4. Redis must not be the only persistent data source. Critical data must be recoverable from databases.
5. Before cross-version upgrades, replay SQL and core business flows in a test environment, then switch production.

Troubleshooting Checklist

• Database connection failure: check connection string, account permissions, network, firewall, and container service name.
• Slow queries: review slow SQL, execution plans, index hits, and pagination parameters.
• Cache issues: check key naming, TTL, serialization, cache penetration, and lock release.
• Time-series write failure: check driver version, port, timezone, disk space, and retention policy.
• Data inconsistency: confirm whether messages are duplicated or lost, then check rule execution logs and cache invalidation paths.