超融合DB脑图1202 思维导图模板_ProcessOn思维导图、流程图

前言

第一部分为什么要有超融合数据库

第1章当前数据库存在什么尴尬的情形

1.1 数据库的选型困难

1.2 比选型更困难的困难

1.3 让我们一起回顾历史

第2章从数据库发展史中寻找深层规律

2.1 漫谈数据库发展简史

2.1.1 上古时期

2.1.2 工业化时期

2.1.2.1 自动数据处理

2.1.2.2 电子数据处理

2.1.3 1960-2000年的信息化时代

2.1.3.1 层状

2.1.3.2 网状

2.1.3.3 关系型

OLTP

OLAP

2.1.4 大数据(互联网)时代

2.1.4.1 NOSQL百花齐放

2.1.4.2 关系型王者归来

1. MPP 关系型数据库异军突起

2. 分布式OLTP王者归来

3. HTAP闪亮登场

4. NEWSQL

5.库内机器学习优势凸显

2.1.5 数智化(物联网)时代

2.1.5.1 SQL关系模型强势回归

2.1.5.2 时序成为专用数据库

2.2 推动数据库改变的力量

2.2.1 系统发展的主要因素

2.2.2 数据库的原动力探讨

2.2.3 数据处理平台的进化

2.2.4 合合分分的经历发展

第3章超融合数据库是时代发展的必然

3.1 为什么需要超融合数据库

3.1.1 物联网+数智化时代数据特点

3.1.2 数据库需要哪些能力

3.1.2.1 多场景适应能力

3.1.2.2 多模态支持

3.1.2.3 易用性与生态

3.1.2.4 高性能与可扩展性

3.1.3 这种能力能不能实现

3.1.3.1 超融合手机已经成为现实

3.1.3.2 超融合数据库条件已具备

3.2 到底什么是超融合数据库

3.2.1 超融合数据库定义与公式

3.2.2 超融合数据库边界在哪里

3.2.2.1 便利与专业性的平衡

3.2.2.2 不可忽略的经济因素

3.2.2.3 超融合边界是无边界

3.3 超融合数据库已成功落地

3.3.1 有复杂数据处理的场景

3.3.2 有复杂时序分析的场景

3.3.3海量泛物联网设备场景

3.3.4 传统的数仓OLAP场景

第二部分 如何打造出超融合数据库

第4章 微内核——超融合数据库桥梁

4.1 什么是微内核

4.2 如何实现一库多核

4.3 如何为每个场景实现极限性能

4.3.1 微内核的独立性

4.3.2 场景的协作性

4.3.3 优化器和执行器的完美配合

4.3.4 数据存储的统一性

4.4 质疑、挑战

第5章 一体化——超融合数据库目标

5.1 从数据模型到字段类型的场景一体化融合

5.1.1 在关系数据模型中扩展JSON类型

5.1.2 在关系数据模型中扩展MXKV2类型

5.1.3 在关系数据模型中扩展非结构数据类型

5.1.4 在关系数据模型中扩展向量类型

5.1.5 在关系数据模型中扩展GIS类型

5.1.6 在关系数据模型中扩展时序类型

5.1.7 在关系数据模型中扩展图类型

5.1.8 从模型到类型的一体化融合小结

5.2 将数据与完备性融为一体的关系数据场景

5.2.1 关系模型场景的数据处理方式1——OLTP

5.2.2关系模型场景的数据处理方式2——OLAP

5.2.3  OLTP与OLAP的对比与联系

5.2.4 OLTP与OLAP的集成与创新

5.2.5  小结

5.3 将数据与时间融为一体的时序场景

5.3.1 时序场景如何产生

5.3.2 时序数据到底是什么

5.3.3 时序数据模型是什么

5.3.4 时序场景建模思路

5.3.5 时序场景下的数据建模示例

5.3.6  时序场景写入特征

<div><h4>5.3.7 时序数据库的挑战与发展趋势</h4></div>

5.3.8 小结

5.4 将数据与空间融为一体的GIS场景

5.4.1  GIS数据库概述

5.4.2 GIS数据库的功能

5.4.3 GIS与关系型数据库的融合

5.4.4 GIS与关系型数据库融合的实例分析

5.4.5 GIS数据库的未来发展趋势

5.5 将数据与关联关系融为一体的图场景

5.5.1 图场景说明与需求

5.5.2 社交网络场景探究

5.5.3 溯源追溯场景剖析

5.5.4 小结

5.6 将无模式设计与列存融为一体的MXKV2

5.7 将数据与高维特征融为一体的向量场景

5.7.1 深度学习与向量数据库

5.7.2 pgvector作用与原理

5.7.3 如何使用pgvector

5.7.4 小结

5.8 超融合目标实现总结

第6章 高性能——超融合数据库支柱

6.1  存储器

6.1.1 高速读取

6.1.2 高速写入

6.1.3 Compactor

6.1.4 MARS 存储特性说明

6.1.5 存储策略

6.1.5.1 冷热分级存储

6.1.5.2 自动降级存储

6.1.5.2 自研压缩算法

6.2 执行器

6.2.1 向量化执行引擎技术

6.2.2 Runtime Filter 优化

6.3  优化器

6.3.1 多节点并行

6.3.2 多核并行

6.3.3 fast direct dispatch

6.4  高性能写入

6.4.1  高速加载的核心架构

6.4.2 极致性能的关键原理

6.5  库内机器学习

6.5.1 什么是库内机器学习

6.5.2 PLPython的使用技巧

6.5.3 库内机器学习优势与不足

6.6  库内流计算

6.6.1 持续聚集

6.6.2 滑动窗口

6.6.3 库内与库外流计算

6.7 性能总结

第7章 分布式——超融合数据库基座

7.1 体系架构

7.2 数据分布

7.2.1 哈希分布

7.2.2 随机分布

7.2.3 复制分布

7.3 镜像分布

7.3.1 散列镜像分布

7.3.2 组镜像分布

7.3.3 环状镜像分布

7.4 跨节点关联Motion操作

7.4.1 数据重分布

7.4.2 数据广播

7.4.3 数据聚集

7.5 Motion执行计划构造与解读

7.5.1 表与记录构造

7.5.2 执行计划解读、

7.6 分布式事务

7.6.1 两阶段提交(Two Phase Commit，2PC)

7.6.2 三阶段提交（3PC）

7.6.3 基于消息的事务

7.7 分布与分区

7.8 分布式总结

第8章 易用性——超融合数据库保障

8.1 如何化解场景一体化带来的数据库管理压力

8.1.1  极简安装

8.1.1 极简图形化单机安装

8.1.1 极简图形化集群扩容

8.1.2  资源管控

8.3.1 查看 resourcegroup 信息

8.3.2 资源组与队列的差异对比

8.1.3  平滑扩容

8.1.4  便捷迁移

8.1.5自动分区

8.1.5.1 分区策略

8.1.5.2 操作状态设置

8.1.5.3删除策略

8.1.5.4 日志监控

8.2 如何让跨场景融合的数据分析发挥更大价值

8.2.1 通用表达式

8.2.2 递归调用

8.2.3 分析函数

8.2.4 数据立方体

8.2.5 UPSERT

8.2.6 CASE WHEN

8.3 如何有效保障多模数据融合之下的数据安全

8.3.1  故障自愈

8.3.1.1 Etcd集群与数据库共存自管理

8.3.1.2 Mirror镜像确保数据不丢

8.3.2  快速恢复

8.3.2.1 逻辑备份恢复

8.3.2.2 并行备份恢复

8.3.3 权限管控

8.4 如何规避超融合数据库复杂度所带来的风险

8.4.1  智能预警

8.4.1.1 YMatrix Dashboard

8.4.1.2 YMatrix Database

8.4.2 Mxmanager的健康体检

第三部分 YMatrix超融合经典实战

第9章  行业数据痛点与YMatrix的超融合解决之道

9.1 企业数据应用所面临的四大痛点

9.1.1 痛点1 ——性能需求难以满足

9.1.2 痛点2 ——稳定性难以有保障

9.1.3 痛点3 ——功能需求难以实现

9.1.4 痛点4 ——成本过高难以负担

9.2 企业应对数据库痛点的三大神器

9.2.1 数据痛点应对神器1——限制

9.2.2 数据痛点应对神器2——升级

9.2.3 数据痛点应对神器3——拆分

9.3 超融合数据库的一站式解决之道

9.3.1 才解决旧痛点又遭遇新麻烦

9.3.2 旧痛点卷土重来的根因剖析

9.3.3 超融合兵器库大战四大痛点

9.3.3.1 YMatrix第一弹——提升性能的兵器

9.3.3.2 YMatrix第二弹——保稳定性的兵器

9.3.3.3 YMatrix第三弹——完善功能的兵器

9.3.3.4 YMatrix第四弹——降低成本的兵器

9.3.4 超融合数据库的迁移三部曲

第一曲——预备阶段

第二曲——执行阶段

第三曲——优化阶段

第10章  某新能源制造巨头大数据平台超融合之路

10.1 大数据平台场景介绍

10.1.1 从众单一生产业务系统说起

10.1.2 数据汇聚催生出大数据平台

10.1.3 大数据平台重要模块与困境

10.1.3.1 大数据平台的重要模块

10.1.3.2  大数据平台模型极复杂

10.2 大数据平台所面临的痛点与挑战

10.2.1 企业大数据平台痛点与挑战1 ——性能

10.2.1.1 写入性能无法满足需求

1. 迈向统一汇聚的各系统数据（MES、ERP、PLM、SCM、CRM、QMS、RPM、BPM....）

2. 日志数据（非结构数据，如交接管理单、上位机产生的性能测试数据等）

3. 传感器实时采集数据（各设备上的状态、参数等数据会不进MES直接抽取至大数据平台）

10.2.1.2 决策分析查询性能不足

1. 生产相关指标报表

2. 产品质量指标报表  

3. 企业管理维度报表

10.2.1.3 点查明细查等性能不足

1. 快速追溯某批次产品质量

2. 快速查询客户的相关信息

3. 实时判断设备的运行状态

10.2.1.4更新性能难以满足需求

10.2.2 企业大数据平台痛点与挑战2——稳定

10.2.2.1 应用时快时慢（各个模块资源分配不均、统计信息收集机制不合理等）

10.2.2.2 出现宕机情况（由大量临时表删除引发过集群节点大规模宕机的严重故障）

10.2.3 企业大数据平台痛点与挑战3——功能

10.2.3.1 统一多模操作实现困难

1. 大数据平台无法支持复杂混合复杂查询

1. 需要较强的OLTP能力（用于满足设备状态、参数、客户信息这类信息保存在大数据平台，查询需要快速返回）

2. 需要强劲的OLAP能力（用于支持维度多、关联复杂的生产指标、产品质量、销售、售后、财务等报表的快速返回）

2. 预测相关的机器学习场景不满足实效性

3. 追溯相关的图计算的场景开发周期过长

4. 生产及售后相关时序相关场景过于复杂

10.2.3.2 易用性差影响运维效率

10.2.4 企业大数据平台痛点与挑战4——成本

10.2.4.1 超大内存服务器集群是成本最大的痛

1. 整个体系中，生产端HANA的成本高到难以承受，合计数亿投资，投资还在持续增长中

2.大量历史数据仍需处理，导致磁盘空间已经出现严重不足，需采购大量存储设备

3. 需要采购大量的数据库服务器，根据业务规模发展趋势，半年内要采购上千万元的服务器

10.2.4.2 大量数据库的人月投入影响整体任务

10.2.4.3 复杂需求导致关键应用上线无限延迟

10.2.5 企业大数据平台的痛点与挑战总结

10.3 YMatrix对大数据平台的改造及成效

10.3.1 企业大数据平台第一战——提升性能的改造

10.3.1.1 Mxgate提升10倍的写入提升！

10.3.1.2 分析型查询实现5-20倍提升！

10.3.1.3 点查明细查实现5-10倍提升！

10.3.1.4 更新提升3-5倍且锁争用减缓！

10.3.2 企业大数据平台第二战——保稳定性的改造

10.3.2.1 资源组技术及统计信息优化

10.3.2.2 用全局临时表真正释放资源

10.3.3 企业大数据平台第三战——完善功能的改造

10.3.3.1 微内核实现多模操作融合

1. 赋予大数据平台真正的混合负载处理能力

2. 预测相关的机器学习场景性能提升10多倍

3. 追溯相关的图计算场景开发周期缩减80%

4. 生产及售后指标相关的时序场景远超预期

10.3.3.2 平台易用性得有效到保障

10.3.4 企业大数据平台第四战——节省成本的改造

10.3.4.1 软硬件缩减空间高达数亿

1. YDB替换HANA（使用触发器、递归、Upsert等高级SQL及分布式能力）

2. 压缩与存储策略（冷热分级存储+编码压缩=大幅提升存储利用率，可节省到存储只达到原有架构三之一左右）

3.性能提升则服务器减少（使用Ymatrix高性能引擎，能在确保性能提升5倍的情况下将原数据平台的服务器数量缩减一半）

10.3.4.2 项目的人月投入减少30%

10.3.4.3 无限延期的项目逐步上线

10.3.5 大数据平台的超融合改造总结

第11章   某造车新势力的车机信号系统超融合之路

11.1 车机信号系统场景介绍

11.2 车机信号系统所遇痛点与挑战

11.2.1 车机信号系统痛点与挑战1 ——性能

11.2.1.1 入库延迟严重

11.2.1.2 查询分析缓慢

11.2.2 车机信号系统痛点与挑战2——稳定

11.2.2.1 数据处理能力呈现不平稳态势

11.2.3 车机信号系统痛点与挑战3——功能

11.2.3.1 难以应对时序数据处理场景的复杂性

1. 指标的动态增减

2. 延迟与乱序上报

3. 分批上报与合并

4. 自动降采样上报

5. 自动化数据治理

6. 数据的删除修改

7. 数据的高效压缩

11.2.3.2 难以应对数据查询分析需求的复杂性

1. 信号全域数据拉通困难

2. 时空一体需求难以满足

3. 机器学习的实时性不足

11.2.4 车机信号系统痛点与挑战4——成本

11.2.4.1 专用时序集群规模投入巨大

11.2.4.2 复杂度导致人力成本的飙升

11.2.4.3 指标研发周期过长影响生产

11.2.5 车机信号系统所遇痛点与挑战总结

11.3 YMatrix对车机信号系统的改造及成效

11.3.1 车机信号系统第一战：提升性能的改造

11.3.1.1 创1.5亿数据点每秒的写入业界纪录！

11.3.1.2 实时分析与复杂查询皆提升20多倍！

11.3.2 车机信号系统第二战：保稳定性的改造

11.3.2.1 数据处理能力呈现平稳态势

11.3.3 车机信号系统第三战：完善功能的改造

11.3.3.1 全面支撑业界最复杂的时序数据处理场景！

1. 指标动态变化的适应性

2. 乱序与延迟上报的应对

3. 分批上报与合并的处理

4. 自动降采样上报的实现

5. 自动化数据治理的实现

6. 数据删除和修改的优化

7. 自适应编码压缩的落地

11.3.3.2 完美应对业界最复杂的时序数据分析场景！

1. 信号全域数据全面拉通

2. 时空一体数据高效融合

3. 大幅升机器学习实效性

11.3.4 车机信号系统第四战：节省成本的改造

11.3.4.1 节省的软硬件成本超3000万

11.3.4.2 项目的人月投入减少超50%

11.3.4.3 指标研发周期从3天到1小时

11.3.5 车机信号系统的超融合改造总结

第12章  某装备制造业龙头的智能平台超融合之路

12.1 装备智能平台场景介绍

12.2 装备智能平台所遇痛点与挑战

12.2.1 装备智能平台痛点与挑战1 ——性能

12.2.1.1 数据处理的实时性不满足需求

12.2.2 装备智能平台痛点与挑战2——稳定

12.2.2.1 数据同步出现异常中断

12.2.3 装备智能平台痛点与挑战3——功能

12.2.3.1 无法实现千车千面模型

12.2.3.2 无法提供即时分析功能

12.2.3.3 同批数据无法高效合并

12.2.4 装备智能平台痛点与挑战4——成本

12.2.4.1 数据处理环节复杂让软件成本激增

12.2.4.2 数据处理过于复杂让人力成本过高

12.2.4.3 建模误差的反复调整延误开发周期

12.2.5 装备智能平台所遇痛点与挑战总结

12.3 YMatrix对装备智能平台的改造与成效

12.3.1 装备智能平台第一战：提升性能的改造

12.3.1.1 彻底解决数据实时性的问题

12.3.2 装备智能平台第二战：保稳定性的改造

12.3.2.1 数据不再异常中断

12.3.3 装备智能平台第三战：完善功能的改造

12.3.3.1 创单平台2.5万+模型的建模记录！

12.3.3.2 实现了平台所有业务的即时分析

12.3.3.3 实现平台全场景的数据高效合并

12.3.4 装备智能平台第四战：节省成本的改造

12.3.4.1 软硬件规模缩减超过90%

12.3.4.2 项目的人月投入减少60%

12.3.4.3 算法的开发周期缩短40%

12.3.5 装备智能平台的超融合改造总结

第13章 超融合数据库的回顾、思考、与未来展望

全书回顾

附录