异数OS-织梦师-操作系统与数据库的合体(十一)-使用异数OS打造高性能低成本元宇宙OLTP数据库引擎
异数OS-织梦师-操作系统与数据库的合体(十一)-使用异数OS打造高性能低成本元宇宙OLTP数据库引擎
文章目录
- 异数OS-织梦师-操作系统与数据库的合体(十一)-使用异数OS打造高性能低成本元宇宙OLTP数据库引擎
- 背景
- 注意事项
- 操作系统与数据库的合体
- 1. System IO 成本高性能不够用
- 2. CPU Page或Disk Page存在并发障碍
- 3. CPU Page或Disk Page存在读写带宽放大问题
- 异数OS的操作系统与数据库的合体
- 方案实现了以下特性：
- 为什么通用操作系统无法抄袭异数OS的操作系统与数据库合体方案
- 1. SystemIO的 高IOPS硬性要求没有改变
- 2. 基于高性能TCP协议基础上的ScatterGatherIO。
- 元宇宙OLTP 数据库性能可行性分析
- 目标
- 1. Insert可行性分析
- 2. Query可行性分析
- 3. Update可行性分析
- 3. Delete使用Update实现，不用分析
- 总结与未来目标
- 测试数据
- 1M cache 慢速路径性能测试过程截图
- Insert 性能测试 峰值TPS 774万
- Update 随机性能测试 峰值TPS 173万
- Update 顺序性能测试 峰值TPS 878万
- Query 随机性能测试 峰值QPS 321万
- Query 顺序性能测试 峰值QPS 877万
- 1G cache 快速路径性能测试过程截图
- Query 随机性能测试 峰值QPS 805万
- Query 顺序性能测试 峰值QPS 1585万
- Updata 随机性能测试 峰值TPS 697万
- Updata 顺序性能测试 峰值TPS 1405万
背景
1998年，百兆以太网普及，元宇宙服务器基础技术在梅特卡夫定律指导下成型，其中主要技术指标有两个，一个是万人听令弓箭雨，一个是尸山，当时预计这两个元宇宙需求按照摩尔定律计算需要50年后才能实现，然而遗憾的是业内自1998年后就开始原地踏步，按照1998年百兆服务器的IOPS设计上限14万计算，2025年的mysql 5000 tps仅能发挥1998年百兆服务器IOPS性能的5%，保持tpmC世界记录的OceanBase 7.07亿tpmC,1554节点，每节点性能仅7500TPS，仅能发挥1998年百兆服务器IOPS性能的6%，高性能的redis nginx 仅8万qps，仅能发挥1998年百兆服务器IOPS性能的80%。
在1998百兆服务器操作系统基础理论约束下，万人听令弓箭雨通常只能实现不足千人规模，欣慰的是该问题在中间件 异数OS-织梦师-圣甲虫中已得到初步解决，实现了10万人同服同屏 1.6T设计带宽的元宇宙服务器，而尸山体验成为下一步需要攻克的大山。
尸山体验，尸山体验的价值最早是在热血传奇中被挖掘体现，但由于成本问题以及技术天花板问题，该体验在后续抄袭者中都已放弃，这造成了传奇体验至今没有游戏能超越，同时也导致热血传奇到今天依然有人就卡顿的无解，这是因为尸山体验需要实现一个高性能低成本的数据库，假定尸山面积1000X1000平米，每平米表面堆积10个尸体，则需要1000万尸体，在元宇宙大场面活动中每尸体每秒爆出两个装备，则数据库系统需要实现2000万TPS峰值的CURD性能，这相当于阿里双11峰值TPS的40倍左右，或者相当与阿里 OceanBase峰值性能的189%，OceanBase 7.07亿tpmC, 3.98 Price/tpmC， 假定OceanBase能够实现2000万TPS的性能，则拥有成本需要48亿，如果将其用于元宇宙则会给元宇宙用户带来沉重的税收负担，10万人同服同屏，假设3年要求回本，则每户至少需要充值4.8万， 这会导致元宇宙失活。
因此要实现元宇宙尸山体验，我们需要将数据库系统的TPS性能提升4个数量级，同时需要将拥有成本降低6个数量级，使他能够跑在699的洋垃圾上，OceanBase 性能足够但成本巨大，原因在于OceanBase 虽然实现了分布式事务并发，但却没有实现节点内事务并发，这使得OceanBase 和mysql一样受到通用操作系统RTT约束，仅能利用1998年百兆服务器硬件的5%，而在2018年100G的服务器上这可能是十万分之无，当然这不能归结为OceanBase 的无能，而在于通用操作系统如linux的并发bug，基于linux io栈的应用都无解，这是OceanBase mysql 无能为力的原因。
注意事项
- 本文假设事务在业务逻辑上有并发基础，可以使用老子无冲突流水线做二元事务负载规划或者通过hash分表来均匀分载。
- 本文方案不适合通用操作系统抄袭借鉴。
操作系统与数据库的合体
不少资深的OLTP数据库研究者发现要解决1998年百兆服务器天花板问题，就需要将操作系统和数据库系统合体，通过页IO阻塞排队事务线程来实现安全可控的事务并发，以达到绕过RTT的约束，所以形成了下面这张教科书式的图，他是操作系统，同时也是数据库，但实际上他存在以下几个问题，每个问题都足以让这种想法躺在教科书中。
1. System IO 成本高性能不够用
通用的操作系统如windows通常在cache命中的情况下只有40万性能，linux甚至不足10万，单跑posix系统调用的性能也只有100万左右，成本巨大，根本无法为节点内2000万io调用提供支持。
2. CPU Page或Disk Page存在并发障碍
操作系统通常以CPU Page或Disk Page为单位实现页换入换出，应用数据库通常以行读写来提交IO，但行IO不能和CPU Page边界对齐，这会导致行内半消费IO问题，行读写都无法一致，那这种方案就算是报废了。
3. CPU Page或Disk Page存在读写带宽放大问题
假设行尺寸64，Disk Page尺寸4096，如果随机访问冷页，每页只有1个热度行，则会导致63/64的设备总线带宽浪费，同时带来频繁的磁盘IO。
异数OS的操作系统与数据库的合体
异数OS的操作系统与数据库合体方案如下图，它采用两级节点来实现，一级是事务节点，一级是存储节点，两节点使用基于以太网或者异数OS虚拟交换机的tcp协议栈链接。
方案实现了以下特性：
- 逻辑页缓存(Logic Page Cache),逻辑页缓存根据数据库应用行尺寸确定每页大小，每页64行，因此基于逻辑页缓存的事务IO不存在页或行的半消费行为。
- 稀疏页读写，通过异数OS上的Tcp分散集中IO技术(ScatterGatherIO)实现了稀疏页读写特性，他解决了页式IO存在的读写带宽放大问题，解决了行式IO的IOPS需求高的问题，解决了页式内存相对行式内存存在的内存碎片问题，比如在慢速路径的随机Updata测试中，IO带宽需求从13GB/s下降到了200MB/s,在慢速路径的顺序Updata测试中，磁盘IOPS需求从1700万下降到70万。
- 事务节点采用逻辑页缓存，存储节点采用磁盘页缓存，一个较小尺寸的事务节点逻辑页缓存可以降低事务系统延迟，与无状态服务器类似，这可以降低不稳定NP数据业务带来不可控的负载造成宕机时的损失成本恢复成本和迁移成本，而一个较大的存储节点磁盘页缓存在实现逻辑页到磁盘页的转换的同时，还可以降低磁盘IO需求，而存储节点因为没有不可控负载，因此是稳定的。
- 使用CURD语义，非KV语义，因为CURD语义可以做出准确的默认缓存策略，KV则需要开发者掌握高深的缓存策略并根据应用来设计。
- 内联嵌入模式支持，提供应用与数据库引擎的行内存共享，除了lru缓存策略，还提供了事务与组事务缓存策略，因为事务或应用管理页是热管理，并且事务读写行过程中不会频繁分配释放页，而lru需要冷页内存加载，频繁使用lru管理内存成本会很高，因此使用事务管理缓存会比lru更高效，并且能大大降低系统负载。
- bitmapTree 自增索引线性表，其他结构理论上可以通过组合事务在线性表基础上表达。
为什么通用操作系统无法抄袭异数OS的操作系统与数据库合体方案
1. SystemIO的 高IOPS硬性要求没有改变
System IO是实现高性能事务的基础条件，不可能通过融合，合批等手段绕过。
2. 基于高性能TCP协议基础上的ScatterGatherIO。
较小尺寸的事务节点逻辑页缓存，意味着较低的cache hit，从而对存储节点的IOPS要求较高，存储层依赖高性能的Tcp ScatterGatherIO,异数OS平台的TCP IOPS通常是通用操作系统的2到4个数量级，他的性能决定了慢速路径的最差性能。
元宇宙OLTP 数据库性能可行性分析
目标
2000万峰值QPS TPS的CURD性能，64字节行（8个64位字段或者16个32位字段，对于元宇宙装备信息这够用了），要求在699元的12700h这样的洋垃圾上满足2000万TPS的性能需求。
1. Insert可行性分析
insert属于顺序写，使用64行页写模式，磁盘IOPS需求可以降低64倍，2000万行， 磁盘IOPS需求为31万，2025年普通SSD可以满足该需求，根据图Insert 性能测试 峰值TPS 774万，大概三组节点6个CPU核可以达成。
2. Query可行性分析
Query需要分为快速路径和慢速路径来得到最低短板，快速路径在cache中命中返回，慢速路径则需要等待磁盘IO完成，我们先来看一下事务节点的路径成本。
| IO类型 | 快速路径 | 慢速路径 |
|---|---|---|
| 事务IO（SystemIO） | 1 | 1 |
| 设备IO(DeviceIO) | 0 | 1 |
| 总计IO需求 | 1 | 2 |
快速路径测试得到成绩，采用图1G cahce Query 顺序性能测试 峰值QPS 1585万
慢速路径测试得到成绩，采用图1M cahce Query 随机性能测试 峰值QPS 321万
| IO类型 | 快速路径IOPS | 慢速路径IOPS |
|---|---|---|
| 事务IO IOPS（SystemIO） | 1585万 | 321万 |
| 设备IO IOPS(DeviceIO) | 0 | 321万 |
| 总计IO IOPS | 1585万 | 642万 |
假定我们的系统峰值QPS等于快速路径和慢速路径的平均值，则峰值QPS为953万，因此大概三组节点6个CPU核可以达成。
3. Update可行性分析
Update需要分为快速路径和慢速路径来得到最低短板，快速路径在cache完成读写事务，慢速路径则需要等待磁盘IO完成，我们先来看一下事务节点的路径成本。
| IO类型 | 快速路径 | 慢速路径 |
|---|---|---|
| 读事务IO（SystemIO） | 1 | 1 |
| 写事务IO（SystemIO） | 1 | 1 |
| 读设备IO(DeviceIO) | ~0 | 1 |
| 写设备IO(DeviceIO) | 1/64 | 1 |
| 总计IO需求 | 129/64 | 4 |
快速路径测试得到成绩，采用图1G cahce Updata 顺序性能测试 峰值TPS 1405万
慢速路径测试得到成绩，采用图1M cahce Update 随机性能测试 峰值TPS 173万
| IO类型 | 快速路径IOPS | 慢速路径IOPS |
|---|---|---|
| 读事务IO IOPS（SystemIO） | 1405万 | 173万 |
| 写事务IO IOPS（SystemIO） | 1405万 | 173万 |
| 读设备IO IOPS(DeviceIO) | 0 | 173万 |
| 写设备IO IOPS(DeviceIO) | 49K | 173万 |
| 总计IO IOPS | 2815万 | 692万 |
假定我们的系统峰值TPS等于快速路径和慢速路径的平均值，则峰值TPS为789万，因此大概三组节点6个CPU核可以达成，但慢速路径与2000万峰值TPS差距1一个数量级，因此未来这将是一个短板优化重点。
3. Delete使用Update实现，不用分析
总结与未来目标
通过上面性能分析可知三组节点6个CPU核可以实现2000万TPS QOS的尸山体验数据库，最慢路径在1M cache Updata随机测试中，原因是页内行热度只有1/64，这使得读写设备的IOPS需求都较高，读写总计350万IOPS，这已经达到了异数OS TCP RAM网盘性能的一半，因此如果你的事务负载是清晰稳定的，那么你应该使用较大的cache，比如1G，以提高read命中率降低read io开销，对于write操作，则需要增加lru写出超时，提高页内行热度，从而降低write io需求。
异数OS平台目前这个数据库只提供了几个基本事务，用于OLTP目标，没有复杂查询支持，未来如果需要考虑 OLAP则需要实现sql DSL在基础事务之上做任务图。
测试数据
测试分为1M cahce 慢速路径性能测试和1G cahce 快速路径性能测试，3000万条记录的CURD，128并发事务线程，一个事务节点一个存储节点，硬件是12700H笔记本，4年未更换硅脂，散热原因成绩会有30%抖动误差。
1M cache 慢速路径性能测试过程截图
Insert 性能测试 峰值TPS 774万
Update 随机性能测试 峰值TPS 173万
Update 顺序性能测试 峰值TPS 878万
Query 随机性能测试 峰值QPS 321万
Query 顺序性能测试 峰值QPS 877万
1G cache 快速路径性能测试过程截图
Query 随机性能测试 峰值QPS 805万
Query 顺序性能测试 峰值QPS 1585万
Updata 随机性能测试 峰值TPS 697万
Updata 顺序性能测试 峰值TPS 1405万
