使用者无须感知，而终端场景因为要支持各类庞杂的设备和场景接入，必须要有个标准协议定义。
）根据订阅的主题 Topic 去查找消息；
2）根据订阅者 ID 去查找消息。这个就是业界常说的放大模型：读放大、写放大。
客户端 MQTT 场景可以按照 MQTT 多级 Topic 以及通配符订阅进行消费消息。
这样的一个队列模型就可以同时支持服务端和终端场景的接入和消息收发，达到一体化的目标。
如上图所示，一般一个分布式 KV 读写流程是，Key 通过 hash 得到一个逻辑 slot，slot 通过一个映射表得到具体的 node。
另外前面介绍的队列模型里面，消息也是按照 Topic 队列进行存储的，MQTT 的 Topic 是一个灵活的多级 Topic，客户端可以任意生成
代码写的非常冗余，完全是过程是的思考方式，最后导致系统非常难以维护。而且更糟糕的是，出来混总是要还的，前期的领域模型设计的不好，不够抽象
所以，我个人从来不相信什么子域划分的技巧什么的东西，因为我觉得这个工作没有任何诀窍可以使用。当我们不了解一个东西的时候，如何去拆解它？
微软在SQL Server 2016 SP1上，开始提供Column Store Indexs功能，用户可以根据负载特征，灵活的使用纯行存表，纯列存表
在分析场景经常需要访问某个列的大量记录，而列存按列拆分存储的方式会避免读取不需要的列。其次列存由于把相同属性的列连续保存，
高。同时该方法对计算过程提供简洁的抽象，将数据和计算过程分离，天然适合并行计算。
