![]()
![]()
SoTP 的重要支撑
“小”数据和“宽”数据的崛起
开篇还是回顾一下，我们提出 SoTP 的重要背景：从“大”数据转向“小”数据和“宽”数据。
根据 Gartner 技术成熟度曲线的判断，小数据正处于“创新出发点”的阶段，可能还需要一段时间才可以进入成熟，不过，随着小数据市场渗透率不断提高，它对 AI 以及更广义的数据分析的影响是显而易见且非常深远的。小数据的优势在于，抛开了对大型单体数据的依赖，实现了对于大型、小型、结构化、非结构化数据源的分析与协同。
这个趋势不仅仅是被 Gartner 一家认可的， 国际权威学者吴恩达教授也在今年 2 月初提出了：AI 的下一个发展方向，是从大数据转向小数据。当然，我们提的 AI 也只是实时事务处理与数据分析的一个重要应用领域而已，并不是全部。不过，未来数据库、数据分析处理与 AI、ML 的结合却是必然的，就比如我们后续将在 StoneDB 架构中加入的 StoneDB Autopilot 功能。作为在人工智能和机器学习领域上有着全球级影响力的领军人物，吴恩达最近几年一直在倡导以数据为中心的人工智能。什么叫以数据为中心？那就是对数据的质要有更高的要求而不是一昧的追求量（优质的小数据集经过训练也能有很好的泛化能力，如果读者感兴趣，可以阅读吴恩达接受 IEEE Spectrum 的采访新闻），而“小”数据和“宽”数据恰恰就是高质量数据集的最佳载体，可以理解为，这是众多数据分析场景逐渐从依托“量”转向提升“质”的重大发展趋势。
大势所趋之下，作为实时数据分析场景的基础底座之一，HTAP 数据库扮演着的角色也越来越重要。如果说通过“小”数据和“宽”数据获得了更高质的数据，那么热数据则是对这个质的再一次提升。
热数据一般是指频繁被访问查询的在线数据，而在一个实时智能决策系统中，近期产生的热数据往往才会发挥最大的价值，但是，并非所有 HTAP 数据库都是专注于热数据场景下的“小”而“宽”数据的，对此，StoneDB 作为国内首个对标 Oracle MySQL HeatWave 的开源实时一体化 HTAP 数据库，率先提出了面向热数据、小数据和宽数据场景的 SoTP 型数据库理念。
![]()
SoTP 数据库的定义
2.1 Serving 的定义和分类
先说这个 Serving 场景，一些同学可能有些不熟悉，因为好像之前听到的都是 OLTP 场景（指在线事务处理，比如业务处理，交易系统等） 和 OLAP 场景（指在线分析处理，比如BI、Adhoc等），但其实还有一种场景，是指在线实时服务的，介于 OLTP 和 OLAP 之间，可能还偏向 OLTP 一些，那么这种场景我们就称之为 Serving（英语时态学得好的人，应该可以 Get 到，就是进行时的意思，也即可理解为“进行中的服务”）
![]()
Serving 可以和 OLTP 组合，也可以和 BigData 或者 Stream 组合，我们把 Serving 分成了三类：
Type1. Serving over TP（StoneDB）
Type2. Serving for BigData
Type3. Serving for Stream
特点：处理非结构化数据，作业状态状态等数据管理
典型代表：RocksDB
为了方便大家理解，我们做了一张图，三种类型的 Serving 数据库如图所示：
![]()
2.2 SoTP 的定义和解决的问题
那么，SoTP （Serving over TP）的定义也就很清晰了，简单来说，我们把这种有能力对在 OLTP 数据库上的热数据、小数据、宽数据进行 Serving（在线实时服务） 操作的数据库，称之为 SoTP 数据库。具体来讲，比如以 SoTP 数据库 StoneDB 为例，一个 SoTP 产品至少要满足以下几点要求：
数据量：一个系统，数据量不超过 100 TB，通常介于 100GB~100TB 之间
数据类型：主要处理结构化数据，可处理 Text、JSON 等半结构化数据，不处理非结构化数据
NoETL：TP 到 Serving 的流转过程中，NOETL，直接基于 TP 数据完成实时分析
查询类型：复杂即时的查询，将事务型热数据，从行存变成可被快速读取的列存数据
高并发的混合负载：比 AP 查询的并发高 3 个数量级
成本控制：TCO 总成本下降 80%
简单举个例子。如下图，右边就 SoTP 据库 StoneDB，对外主要接受两个业务请求，分别是左边的 OLTP 和 Serving，其中，进行 Serving 请求的主要是是 OLTP 产生的热数据。那么这个 SoTP 处理数据的过程就是先把 OLTP 请求交给主引擎——TP 引擎承载（如 InnoDB），然后再把 Serving 请求交给次引擎——Serving 引擎承载（如 Tianmu）。
![]()
2.3 SoTP 的典型场景案例
2.3.1 场景一：Native Analytics Query
注意，我们这里重点提出了一个 Native，什么叫 Native，就是指数据源上的原生，我们如果对 OLTP 系统产生的数据进行查询分析，这里的数据应该是同源的热数据，而不是另外一份数据。
客户需要一个数据库，既能执行 OLTP，还能高效、实时地运行Analytics；否则还得需要另外一个数据库运行 Analytics，这引入了额外的复杂性和代价。
传统的 ETL 方案架构就是比较复杂的，比如 MySQL + ETL + Elastic：
![]()
这种方案就不能称为是 Native，体现在数据源的不一致、查询语句语法变更等等。但是，使用 SoTP 数据库 StoneDB，就有所不同了，我们是完全一体化架构，如下：
![]()
StoneDB 一体化架构
采用 StoneDB 这种一体化架构就可以达成降本增效的效果，下图就是我们在华东地区的一个 CRM 客户使用 StoneDB 的案例：
![]()
总结来说，这个厂商获得了以下成果：
![]()
高兼容：平行替代MySQL业务，零改动
低成本：节省了成本 52%
强性能：DTU 提升了 68%
易维护：技术难度降低 50%
2.3.2 场景二：Native Autopilot
Autopilot 自动化了实现大规模高查询性能的许多最重要和最具挑战性的方面，包括provisioning、数据加载、查询执行和故障处理。
![]()
如图，StoneDB 未来的 Autopilot 将有以下特性：
自动系统配置
数据加载
查询执行
故障处理
这里也可以举个例子，比如现在我们的需求是减少用户使用成本：要提供自动化的集群配置、加载数据、查询处理和故障处理服务，使得用户可以更多关注业务开发，减少其繁重且易出错的运维操作。
在使用 Autopilot 之前：
1. 依据数据量和数据变化率，估算节点数量；
2. 与业务开发人员确定数据分布方案；
3. 业务运行中，不断优化SQL语句；调整数据分布策略；
4. 集群节点变化导致数据迁移，业务架构，中间件等相关策略需调整；
在使用 Autopilot 之后：
1. 搭建好StoneDB服务；
2. 系统依据运行情况，自动调整相关参数，使得StoneDB处于最佳运行状态；
3. 业务人员和DBA等得到解放，更加关注业务。
![]()
![]()
SoTP 与 OLTP、OLAP 的差异
我们总结了 SoTP 与 OLTP、OLAP 的差异，具体如下表：
![]()
![]()
SoTP 数据库——StoneDB
当然，可能有部分同学看到我们上述的定位，会想着说 SoTP 和 HTAP 有一些相同之处，这是当然，毕竟我们的说法是 HTAP 的下一步，SoTP 初探。实际上，SoTP 针对的是更加细分的 HTAP 赛道，我们的核心目标就是对最近产生的热数据、小数据和宽数据进行实时分析，更进一步的是，把数据分析能力与机器学习相结合，而且因为我们是基于 MySQL 生态做的一体化架构，也可以把我们称作是 MySQL 热数据分析加速器。总之，StoneDB 作为 SoTP 数据库的核心特性就是：能够将 Serving 需要的热数据实时分析做到极致。
我们努力的现在，就是为了让下一代热数据分析尽早走上国产数据库的历史舞台，让更多的用户体验到真正的商业智能，从而更好地利用数据协作共享、驱动运营和做出决策。以下便是我们的 StoneDB 2.0 架构图：
![]()
StoneDB 的 2.0 架构完全对标 Oracle MySQL MDS（HeatWave），HeatWave 有多强大？我们后面也会出一篇文章给大家分享一下。目前，我们的架构设计方案的RFC文档也完全公布在了 Github 上：
https://github.com/stoneatom/stonedb/issues/436
如果您想了解更多，也可以关注我们的 Github 仓库：
https://github.com/stoneatom/stonedb
以上，就是本次的分享，欢迎大家批评指正。如果您还有其他疑问，欢迎添加StoneDB小助手，加入StoneDB开源社区技术交流群，在群里您可以随时提问，我们会认真为您解答。
![]()
扫码添加小助手
加入StoneDB开源社区用户群
讨论交流，共同进步
![]()
2023 年十大战略技术趋势中哪一项最需要 HTAP ？
StoneDB 的 2.0 架构完全对标 Oracle MySQL MDS（HeatWave），HeatWave 有多强大？我们后面也会出一篇文章给大家分享一下。目前，我们的架构设计方案的RFC文档也完全公布在了 Github 上：
