工厂里几百台传感器每秒上报温度、湿度、震动值；智能电表每15分钟往后台扔一条用电记录；共享单车锁每次开合都得记一笔位置和时间——这些不是偶尔冒出来的数据，是持续不断、格式不一、写多读少的‘数据洪流’。
关系型数据库在这儿有点卡壳
用MySQL存设备心跳包？行，但很快就会遇到问题：字段要提前定义好，可新上线的传感器突然多了个‘电池电压’字段，改表结构就得锁表；上万设备同时写入，主键自增+事务锁让插入变慢；更别说想按‘城市+设备类型+时间范围’快速查最近一小时所有异常点，索引建来建去还是拖慢写入速度。
非关系型数据库，天生为物联网而生
它不强求每条数据长得一样。MongoDB里一条记录可以带temperature，下一条多出battery_level也完全没问题；InfluxDB专为时序设计，设备ID+时间戳就是天然主键，写入吞吐轻松过十万点/秒；Redis当缓存层接前端告警，毫秒级响应开关指令，根本不用等磁盘落盘。
一个真实场景：社区智能井盖监控
某地部署了800个带倾角+水位传感器的井盖。每10秒上报一次原始数据，每天产生约7亿条记录。原先用PostgreSQL，插入延迟越来越高，查询历史水位趋势要跑几分钟。换成InfluxDB后：
• 写入稳定在12万点/秒；
• 查某井盖过去7天水位变化，SQL-like语句秒出：
SELECT mean("water_level") FROM "manhole_sensors" WHERE "device_id" = 'MH-2037' AND time > now() - 7d GROUP BY time(1h)• 告警规则直接嵌在数据库里，水位超限自动触发短信，不再靠应用层轮询扫描。
选哪个？看你的‘数据长相’
• 设备属性多变、要灵活查JSON字段？选MongoDB；
• 全是时间戳+数值，重点在写入快、聚合快？InfluxDB或TimescaleDB（PostgreSQL插件）更顺手；
• 需要实时下发控制指令、做在线状态管理？加一层Redis，存设备在线状态、最后通信时间、待执行命令队列，比查表快十倍。
别迷信‘一套库打天下’。实际项目里常见组合：Redis管实时状态 + InfluxDB存原始时序 + MongoDB存设备档案和配置——各干各的活，系统反而更稳、更快、更好扩。