接着昨天的说，当下数据库的设计思路已经从“我都行” 到 “分工合并” 型的设计思路。
数据库本身主要的三大件，数据库存储引擎，数据计算引擎，数据库接入层。
1 数据库的存储引擎负责数据的存储的方式，其中根据需求分为
1 数据的存储的扩展方式： 单体存储 和 分布式存储
2 数据的存储格式： 行模式， 列模式， 混合模式
3 行模式存储： B TREE 数据存储 ， 堆表数据存储， lsm tree 数据存储模式
数据存储方式的差异也是根据数据库要达到的目的而定。今天我们看看一款叫 MatrixDB 的数据库的设计理念是什么。
我们通过如下的产品简介，看看能分析出什么
1 数据库支持OLTP 也支持 OLAP
2 物联网
3 在线扩容
4 PG 兼容性
5 分布式事务一致性
从上面的简介我们汇总了如上的关键词
1 OLTP OLAP 均支持，说明这款数据库在数据存储方面应该会存在两种可能
和ORACLE PG 类似的兼容性， 或和 TIDB 一样的双数据存储引擎的方式。
2 时序性，
3 物联网， 数据库针对的场景定位，这说明一个字， 大， 什么大， 数据存储容量大
4 紧接着就是在线扩容，面对超大容量的数据，必然是需要更方便的数据存储的扩容的方式方法
5 PG ,GP 的兼容性，也就是说这款数据库的数据接入层可能使用类似PG的使用方式，如果掌握PG操作方式可能学习通用的操作成本会比较低。
6 分布式事务一致性，说明数据本身遵循了通过的分布式事务的协议
下面针对 MatrixDB 的一篇博客来看看数据库设计的思路
https://www.ymatrix.cn/blog/20210615-MatrixDB-Mars
以下为看完相关博客的讲解后的分析，如不清楚可以先看上面的链接的博客内容。
———————————————————————————————
首先MatrixDB 本身是一款双引擎工作的数据库， 其中包含行式数据库引擎与行列混合式数据库引擎。行引擎的原理以可以参见POSTGRESQL， 这里着重说 行列混合引擎。
首先数据库定位的是物联网时序性的数据库，则时序是串联这个数据库的一个基本点，也就是数据的有序性，众所周知行式数据库引擎对于数据的统计分析是一个弱点，这也是行式数据存储本身的缺陷。
Matrix 数据库本身通过行套列的方式来存储数据， 上图可以看到ROW GROUP ，通过逻辑的方式来划分ROW GROUP。这里还的祭出数据库的定位，物联网。
物联网中的设备采集的数据上基本上都会有采集数据设备的设备的标记，也就是设备的ID号，而设备的ID号必然是唯一的，至少在这个数据库的层级里面应该是唯一的。
这里通过设备ID 时间作为数据存储的rowgroup，通过时间来对不同的物联网设备在时间的维度上进行分割。
我们以设备 时间段的方式来存储数据，（逻辑数据分割），一个设备必然有一个ROW GROUP （至少有一个），根据在数据库内时间的设置，例如设置1天，那么一个设备存储的数据就是以天为单位产生一个Row group，以此类推。那么这里解决的就是数据的海量存储中的数据分割而治的问题。
而每个RG本身中数据的存储为列式存储，而列式存储的目的就是为了另一个目的，数据的合并和汇总以及聚合分析。这又要从业务逻辑来，可能一个设备需要分析的维度有，一天设备的总数据的平均数，或者最大数和最小数等这些需求。而这些需求均通过列式存储来进行满足。这样统计的速度必然是很快的。
当然这里还没有完，MATRIX数据库中通过另一个方式footer ，将总结的数据进行存储，让统计后的数据有位置存放，为未来的数据更大的统计分析做预先的数据计算和存储。换句话就是空间换时间，预先我都把数据计算出来，你随时提取，而不是到你需要的时候我在提取计算。这对大数据量的统计分析是十分有必要的。
最后MATRIX 数据库通过列式存储，又解决了数据查询中过滤无用数据的扫描问题。基于列与实践的方式，在查询中确定了时间和字段，则会大大减少数据查询中的由于数据量大而引发的 TABLE SCAN的问题（行式存储的缺陷），而仅仅SCAN 某一个列即可，则I/O扫描的量会下降很多。
当然这个数据库的定制化的可预期性也很大， 如果需求方提出一些其他的数据聚合需求，则也可以做到 ROW GROUP 中的 FOOTER 中，算是二次开发。
最后一个问题，MATRIX 数据库引擎包含行和MIX引擎，那么一个是基于OLTP也就是平时数据的输入是要通过行引擎接入的，而行列混的数据库引擎主要做的是OLAP的事情。
那么数据库中应该有一个数据传输的功能，将数据输入与数据分析进行贯通，BLOG 里面没有提到，这里也仅仅是臆想。
在分析完后，文字的第一句话当下数据库的设计思路已经从“我都行” 到 “分工合并” 型的设计思路，是不是又得到了一些的验证呢？
