9-4 海量物联网设备元数据存储引擎选型和演进

业务场景介绍

• 场景描述：统一设备元数据管理平台，涉及物流车、无人贩售机等设备，常见存储字段包括设备ID、类型、最近修改时间、在线时间等。
• 需求特点：多类型接入、海量设备、并发更新、灵活检索和圈选。
• 能力拓展：支持活动场景业务激增。

存储架构演进

• 第一代架构：MySQL单库/分库分表，适用于活跃设备万级别、终端类型少量、峰值读写100QPS的场景。
• 第二代架构：HBase + MySQL + Elasticsearch，适用于活跃设备亿级别、终端类型数十个、峰值读写10k+QPS，并支持复杂检索。
• 问题：第一代架构成本高、运维复杂、弹性不足；第二代架构存在数据同步、更新能力弱、大促弹性不足等问题。

存储引擎对比

• HBase：分布式、LSM、写入能力强，适用于海量数据存储和简单查询。
• MySQL：分布式、B+树、SQL查询能力强，适用于中小数据集合下的CRUD操作。
• Elasticsearch：分布式、Lucene倒排、全文索引能力强，适用于复杂查询。

自研新存储引擎

• 需求：活跃设备十亿级别、终端类型数百个、峰值读写100k+QPS，支持复杂检索分析。
• 架构设计：分布式存储系统、存储计算分离、LSM文件组织、复合索引和灵活数据路由策略。
• 关键技术：分布式架构、存储计算分离、LSM存储引擎、CDC数据订阅能力、自动分区扩展。

场景优化

• 海量设备圈选问题：亿级别设备中基于条件圈选命中数据量大时性能不满足。
• 优化措施：加并发优化查询、分片键路由、存储层深入优化（ParallelScan）。

架构对比

• HBase+ES vs 自研引擎 vs Tablestore：
  • HBase+ES：需要额外维护数据同步，运维门槛高。
  • 自研引擎：存储计算分离，支持CDC和OLAP查询，扩展性强。
  • Tablestore：Serverless免运维，租户隔离能力完善。

总结和展望

• 当前工作：多介质分层存储、基于SQL扩展分布式OLAP能力、提升存储引擎计算能力。