StarRocks4种数据模型如何在不同场景中实践_sr 建表 明细模型

大部分基于MPP架构的Olap分析DB，对于频繁更新的场景支撑都不是太友好，但业务系统的逻辑特别是核心的交易逻辑决定了频繁更新的场景是软件中最常见的应用场景，一直以来在大数据应用过程中，这个问题都困扰着大多数的开发人员。

针对Olap分析型DB与业务场景的冲突，有些产品已经做出了改进，提供了支持更新数据的技术实践。比如StarRocks。

具体是怎么做的？我们来看看SR的表模型。

SR的表模型提供了4种不同的数据模型，具体为明细模型、聚合模型、更新模型、主键模型，下面分析一下：

明细模型 (Duplicate Key Model)：只能追加数据，不能修改历史数据。这样适应的场景就很明显了，即具有非常强的时序性的日志分析类场景，日志产生记录，发生了就不会再改变，一直追加，比较好的支撑起了行为分析和部分业务场景的分析。由于日志具备不精确的特征，分析的结果往往与实际的业务是不完全等值的，当然一般行业日志分析结果也不需要精准，具备1%左右偏差的特征。在明细模型中，为了提升分析性能，一般会建立排序键，在日志分析的场景中，一般设置的排序键为事件类型和事件时间，这样分析某时间范围的某一类事件时，性能将会得到比较大的提升。但要注意的是，明细模型中没有唯一键，即使是排序键，也是可以重复的。同时，针对索引的处理，也是落盘存储的。

基于上述特征，感觉明细模型不会应用得太广泛，事实恰恰相反，目前明细模型其实是应用最广泛的数据模型，当然需要进行“额外”的处理才行。比如通过业务主键进行数据的维护，保证数据的准确性，具体为开发人员需要自己维护业务主键的唯一性以保证业务逻