前言
随着5G时代的来临，万物互联概念的兴起，物联网渐渐覆盖到了各行各业中。本系列文章将为大家介绍基于表格存储Tablestore的一站式物联网存储解决方案。以共享充电宝场景为例，实现物联网场景下元数据、时序数据存储，高并发更新、分析计算等需求。
背景
共享经济是近年来兴起的一种概念，共享概念极大方便了人们的生活。例如共享单车、共享车位、共享充电宝等等。这些场景里包含了大量的设备元数据，例如单车状态数据、车位状态数据等，与此同时，设备状态的变化也将产生规模巨大的时序数据。如何低成本稳定地存储数据，如何高并发低延迟地更新数据，以及如何挖掘数据的商业价值，这些难点对于存储系统的功能、性能无疑是一个巨大的挑战。
需求分析
这里以共享充电宝场景为例，分析此类场景的角色、功能需求以及实现难点。
共享充电宝场景是以多租赁机柜终端的模式，为用户提供充电宝租赁服务。机柜终端分布在全国各地，海量机柜元数据对存储系统的规模要求极高，机柜元数据包括机柜位置、机柜型号、机柜电量、机柜上线状态、时价、可用充电宝数量等等。存储系统需根据这些元数据检索出合适的机柜终端信息推送到客户端，为用户提供服务。
场景中会出现三种角色：用户、运维人员、运营人员
- 用户。用户通常较为关注服务功能性和响应速度。例如：可根据机柜距离远近、可用充电宝数量、机柜上线状态等机柜元数据，通过业务系统查询到合适的租赁机柜位置，便于租赁或者归还充电宝。用户的每一次租赁或归还，都会产生一条租赁订单记录，订单记录包括了用户信息、租赁归还时间、租赁时长、机柜型号、机柜ID等订单信息；同时会更新机柜元数据，例如可用充电宝数量等，而如果更新响应延迟过高，则可能出现其他用户查询到的数据不是最新状态，影响用户的服务体验。
- 运维人员。运维人员通常更关注机柜状态、机柜性能等信息，通常会分析机柜的状态数据。例如：机柜终端提供租赁服务期间，难免会出现一些损坏或未检修的机柜。运维人员可定期查询机柜元数据，根据机柜上线状态、机柜检修时间戳等信息，生成需替换或检修的机柜名单，定期更换机柜。同时可统计每个型号机柜的损坏比例，为后续机柜采购提供参考。
- 运营人员。运营人员通常更关注营业额，通过挖掘元数据和订单数据中的价值信息，及时调整业务的发展方向。例如通过分析订单表，可根据地域、机器型号批量计算营业额，生成报表。同时可生成机柜元数据时序表，统计每个时间段各地域充电宝的租赁比例等。
总结，不同的角色具有不同的需求侧重点，对应到对存储系统的功能需求也不一样。角色与功能需求的对应关系如下图：
从上图可以看出，存储系统需要具备并发更新、多维查询、离线分析、批量计算的能力。下面为每个功能列举了部分具体的场景示例。
- 批量更新
用户
租赁充电宝、归还充电宝
- 运维人员
新增机柜、下架机柜
- 多维查询
用户
查询机柜距离在xx范围内的机柜、查询时价在xx范围内的机柜、查询有可用充电宝的机柜...
- 运维人员
查询检修时间在xx范围外的机柜、查询已报废的机柜...
- 离线分析
运维人员
统计每个厂商的机柜损坏比例、统计每个型号的机柜损坏比例
- 运营人员
统计每个地域机柜的租赁比例、统计每个时间段机柜的租赁比例
- 批量计算
运营人员
按照地域定时成营收报表、按照机器型号定时生成营收报表
技术难点
- 机柜终端元数据规模巨大。对数据库存储要求高。
- 机柜终端元数据更新频繁，并发度较高。对存储服务稳定性、负载能力要求高。
- 多维查询延迟敏感。
方案选择
传统数据库MySQL方案
MySQL是传统的OLTP型数据库，对于一些在线交易类场景的读写能提供良好的事务能力。共享充电宝场景下机柜元数据规模非常大，可能会达到TB级别，然而MySQL的性能存在明显的瓶颈，当单表数据量级超过千万行或者访问QPS超过1万时，性能会明显下降。并且随着机柜数量的增加，业务数据会进一步增加，对于存储系统的可扩展性同样是巨大的挑战。若采用传统的分库分表方案，则需要做数据迁移、业务代码重构，这些无疑会加大运维成本和开发成本。对于多维查询的需求，MySQL提供的多列索引只能支持最左前缀匹配，当无法满足匹配条件时，可能会退化为全表扫描，进而影响查询速度。离线分析类的需求，OLTP库显然更不能满足。
基于表格存储Tablestore方案
表格存储Tablestore是阿里云自研的多模型结构化数据存储，表格存储的分布式存储和强大的索引引擎能够支持PB级存储、千万TPS以及毫秒级延迟的服务能力。MySQL与表格存储Tablestore各个维度的对比如下图：
| MySQL | 表格存储Tablestore | |
|---|---|---|
| 单表存储规模 | 千万行 | 百亿行 |
| QPS | 一万以内 | 千万级 |
| 扩展性 | 分库分表 | 表分区水平扩展 |
| 多维检索 | 多列索引 | 多元索引 |
| 生态产品 | / | Spark、Blink、DataV、DLA |
从上图可以看出，在各个维度的对比下。表格存储Tablestore更适用于共享充电宝场景，表格存储不仅支持海量数据存储与千万级TPS读写，在扩展性方面，可通过表分区分裂来提升服务的存储和吞吐能力。表格存储Tablestore提供了多元索引功能，其多存储引擎的形态也可同时满足多维查询、轻量级分析的业务需求。在上下游生态方面，表格存储Tablestore可对接一些分析类、计算类产品，例如Spark、Blink、DataV等等，为存储系统衍生出强大的数据分析、数据计算、数据可视化等能力。基于表格存储Tablestore实现共享充电宝场景架构图如下:
小结
共享充电宝场景的数据规模较大、QPS较高，对存储系统的功能需求也比较丰富，难以使用单一的OLTP数据库方案实现。这里选择基于表格存储Tablestore的方案，实现共享充电宝场景的存储系统。本系列文章将共分为六篇为大家介绍。分别为:
《基于Tablestore的一站式物联网存储解决方案-场景篇》，
《基于Tablestore的一站式物联网存储解决方案-表设计篇》，
《基于Tablestore的一站式物联网存储解决方案-数据操作篇》，
《基于Tablestore的一站式物联网存储解决方案-Spark 分析》,
《基于Tablestore的一站式物联网存储解决方案-数据湖分析》，
《基于Tablestore的一站式物联网存储解决方案-Flink 实时计算》。
下章节《基于Tablestore的一站式物联网存储解决方案-表设计篇》，将介绍表格存储Tablestore的实例和表的创建步骤，以及如何结合Tablestore的服务架构与共享充电宝场景设计出合理的表结构。
