关系型数据库基础：SQL与NoSQL对比、ThingsBoard支持的数据库类型、选型考量因素
大家好，我是你们的老朋友。今天我们来聊聊数据库选型这件事。说实话，我在做ThingsBoard项目时，被问得最多的问题就是：「到底该用SQL还是NoSQL？」「ThingsBoard到底支持哪些数据库？」「我该怎么选？」
嗯，这些问题确实很关键。数据库选型一旦错了，后面改起来就是大工程。我曾经在一个项目中，因为初期图省事选了不合适的数据库，结果半年后数据量上来，查询慢得像蜗牛爬，最后不得不花两周时间做数据迁移……那滋味，真不好受。
所以今天这节课，我把自己踩过的坑和积累的经验，一次性讲清楚。
SQL vs NoSQL：到底有什么区别？
先说说最基础的概念。SQL数据库，说白了就是「结构化查询语言」的数据库。像MySQL、PostgreSQL这些，都是典型的SQL数据库。它们的特点是：数据有固定的表结构，支持事务，强调数据一致性。
NoSQL数据库呢？它是个大家族，包括键值存储（Redis）、文档数据库（MongoDB）、列族数据库（Cassandra）、图数据库（Neo4j）等等。它们的特点是：灵活、可扩展性强，但通常不支持复杂的事务。
我个人的习惯是这么区分的：
- SQL：适合数据关系复杂、需要强一致性的场景。比如用户信息、设备元数据、告警规则。
- NoSQL：适合海量时序数据、高并发写入的场景。比如设备上报的传感器数据、遥测数据。
你想想看，ThingsBoard里什么数据最多？当然是设备上报的遥测数据。每秒成千上万条写入，如果用SQL硬扛，性能很快就会成为瓶颈。但设备元数据、租户信息这些，用SQL管理就非常合适。
核心观点：没有绝对的「谁更好」，只有「谁更合适」。ThingsBoard的架构设计，本身就是混合存储的思路。
ThingsBoard支持的数据库类型
ThingsBoard官方支持的数据库，我整理了一下，主要有这么几类：
| 数据库类型 | 用途 | 典型代表 |
|---|---|---|
| 关系型数据库（SQL） | 存储元数据、实体信息、用户、租户、规则链等 | PostgreSQL、H2（开发测试用） |
| 时序数据库（TSDB） | 存储设备遥测数据、时序数据 | Cassandra、TimescaleDB、SQL（混合模式） |
| 缓存数据库 | 缓存、会话管理、实时数据 | Redis |
| 消息队列 | 异步处理、数据缓冲 | Kafka、RabbitMQ |
这里要特别说明一下：ThingsBoard从3.4版本开始，支持了「混合模式」。什么意思呢？就是你可以把元数据存在PostgreSQL里，把遥测数据存在TimescaleDB或Cassandra里。我个人觉得，这是目前最实用的方案。
小提示：如果你刚开始学习ThingsBoard，用默认的H2+PostgreSQL组合就够了。生产环境我建议用PostgreSQL+TimescaleDB，运维成本低，性能也不错。
选型考量因素：性能、扩展性、运维成本
好，接下来是重头戏。选型到底看什么？我总结了三个核心维度：性能、扩展性、运维成本。
1. 性能
性能这东西，不能光看理论值。我在项目中遇到过这样的情况：Cassandra官方说写入性能极好，但实际部署时，如果节点配置不合理、数据模型设计不对，性能反而比PostgreSQL还差。
具体来说：
- 写入性能：Cassandra > TimescaleDB > PostgreSQL。Cassandra的写入是日志结构的，几乎无锁，适合高并发。
- 查询性能：PostgreSQL（有索引） > TimescaleDB > Cassandra。Cassandra的查询模式有限制，不支持复杂的聚合查询。
- 时序查询：TimescaleDB 在时序数据查询上做了大量优化，比如连续聚合、自动分区，性能非常出色。
说白了，如果你主要做「写入+简单查询」，Cassandra合适。如果你需要「写入+复杂分析」，TimescaleDB更香。
2. 扩展性
扩展性，说白了就是「数据量大了怎么办」。
- PostgreSQL：垂直扩展为主（加CPU、加内存）。水平扩展需要借助第三方工具，比如Pgpool-II、Citus，配置起来有点麻烦。
- Cassandra：天生支持水平扩展。加节点就行，数据自动分片。我见过一个项目，从3个节点扩展到30个节点，几乎零停机。
- TimescaleDB：基于PostgreSQL，支持自动分区（按时间、按设备ID）。水平扩展需要Citus，但比原生PostgreSQL方便一些。
我个人建议：如果预估数据量在TB级别以下，PostgreSQL+TimescaleDB完全够用。如果数据量在PB级别，或者需要全球多数据中心部署，那Cassandra是更好的选择。
3. 运维成本
这一点，很多新手容易忽略。运维成本，说白了就是「你愿不愿意花时间伺候它」。
- PostgreSQL：运维成本低。社区活跃，文档丰富，备份恢复简单。我团队里一个初级运维就能搞定。
- TimescaleDB：运维成本中等。因为是PostgreSQL的扩展，大部分操作和PostgreSQL一样。但需要了解时序数据的特性，比如压缩策略、保留策略。
- Cassandra：运维成本高。需要懂Java调优、GC调优、节点修复、数据一致性配置。我曾经有一个项目，专门配了一个DBA来维护Cassandra集群。
避坑指南：我曾经在一个小团队项目里，为了追求「高大上」选了Cassandra。结果团队里没人懂Cassandra运维，出问题只能干瞪眼。最后不得不花高价请外部顾问。所以，选型时一定要考虑团队的技术储备。
我的推荐方案
说了这么多，给个实际建议吧。根据项目规模不同，我推荐以下方案：
| 项目规模 | 推荐数据库组合 | 理由 |
|---|---|---|
| 小型项目（< 1000设备） | PostgreSQL（全部数据） | 简单、运维成本低、够用 |
| 中型项目（1万-10万设备） | PostgreSQL（元数据）+ TimescaleDB（遥测） | 性能好、运维成本适中、支持时序分析 |
| 大型项目（> 10万设备） | PostgreSQL（元数据）+ Cassandra（遥测） | 水平扩展能力强、高并发写入 |
嗯，这就是我这些年总结出来的经验。数据库选型没有银弹，关键是要搞清楚自己的业务场景和团队能力。下一节课，我会带大家实际动手，配置ThingsBoard的数据库连接，到时候你们就能感受到不同数据库的差异了。
记住一句话：选型不是选「最好的」，而是选「最合适的」。