SiteWhere数据库这事儿，得从头说起。搞物联网的人，多半听过SiteWhere的大名，它是个开源的企业级物联网平台，专门管设备接入、数据采集、命令下发这些脏活累活。但很多人一开始就被它的数据库设计给整懵了——一张设备表，几十个字段，外键拉出好几层，查询起来像迷宫探险。我见过不少团队，设备接入跑通了，结果报表查询慢得跟蜗牛爬似的，才发现是数据库没吃透。
SiteWhere的默认存储是MongoDB，这选择挺有意思。传统关系型数据库处理设备上报的时序数据，就像用卡车拉快递，装得下但效率低。MongoDB的文档模型天生适合存JSON格式的设备消息，字段可以随意扩展，今天多传个温度，明天多传个湿度，不用改表结构。但问题也出在这儿——太灵活了，反而容易让人偷懒，不设计索引，不上分片，数据一多，查询直接超时。
再说说它的数据库分层。SiteWhere把数据分成了好几个库：设备管理库、事件库、资产库、用户库，各管一摊。这种设计有个好处，就是业务隔离，设备数据和用户数据互不干扰，备份恢复也方便。但坑也在这儿，很多人不知道事件库默认是不做TTL的，设备一天上报几万条，几个月下来，硬盘爆了，MongoDB直接罢工。所以用SiteWhere，第一件事就是把事件库的过期策略配好，别等出事了再哭。
有人问我，SiteWhere能不能换MySQL？当然能，它支持HBase、InfluxDB这些，但换了之后，很多开箱即用的功能就废了。比如它的设备状态机、命令队列，都是基于MongoDB的文档特性设计的，你用MySQL硬扛，等于逼着大象穿芭蕾舞鞋。我见过一个团队，非要用MySQL，结果光是把嵌套的设备元数据拆成关系表，就写了三百行SQL，维护起来欲哭无泪。
再深入聊聊数据模型。SiteWhere的设备实例，本质是个大文档，里面塞了设备类型、客户、站点、装配、状态、元数据，全部嵌套在一起。这种设计对写入友好，一次insert搞定全部关联。但读的时候，你要是想按客户查设备，按站点查事件，就得靠索引兜底。MongoDB的复合索引，SiteWhere默认建了不少，但很多人不知道，自定义字段的查询，必须手动建索引，不然全表扫描，慢到怀疑人生。
还有个容易被忽略的点，SiteWhere的批量操作。设备多了以后，OTA升级、批量配置下发，都是对数据库的写风暴。SiteWhere提供了批量导入接口，但很多人习惯一条条insert，结果数据库连接池被打满，其他设备的数据全被堵住。我建议用它的BulkOperations，把一万条消息打包成一次写，性能能提升几十倍。这个细节，官方文档里写得模糊，但实际项目里，就是生死线。
说到数据安全，SiteWhere的数据库层做了不少功夫。MongoDB的用户认证、TLS加密传输，它都支持，但默认是关着的。很多人图省事，裸奔上生产环境，结果被扫IP的脚本拖库了。设备数据还好说，要是客户信息泄露，那就不是技术问题了。我见过一个项目，MongoDB暴露在公网，连密码都没设，两天就被勒索病毒加密了，只能恢复备份，损失惨重。
再讲个实战案例。去年帮一个智慧园区项目调优，他们的SiteWhere数据库，MongoDB跑了三个月，查询越来越慢。我上去一看，事件库没做分片，单节点数据量到了200GB，索引占了一半内存，磁盘IO持续100%。后来做了三件事：一是加TTL，事件保留30天；二是按站点做分片键，把热点数据分散到三个节点；三是把设备元数据和事件数据拆到不同的MongoDB实例。调完之后，查询延迟从8秒降到200毫秒，设备接入量还翻了一倍。所以说，数据库不是买回来就能跑的，得伺候。
说点实在的。SiteWhere数据库的选型，本质是取舍。你要纯时序性能，直接上InfluxDB；你要关系型业务的强一致性，别碰SiteWhere；但你要的是完整的物联网平台，设备管理、规则引擎、报表分析都想要，那MongoDB打底是最省心的。别被网上那些“MongoDB性能差”的言论吓住，那是没调优的人抱怨。真正的坑，是那些不设索引、不做TTL、不分片的懒汉。SiteWhere的数据库，就像一把好刀，你得磨，得保养，才能砍得动柴火。用好了，它就是物联网项目的定海神针；用不好，它就是性能陷阱的百慕大。你选哪条路，自己掂量。
