基于混搭存储引擎融合型分布式数据库架构

《基于混搭存储引擎融合型分布式数据库架构》由会员分享，可在线阅读，更多相关《基于混搭存储引擎融合型分布式数据库架构（37页珍藏版）》请在金锄头文库上搜索。

1、基于混搭存储引擎的融合型 分布式数据库架构 服务型分布式计算和混搭型分布式数 据存储助力大数据时代的数据宝藏挖掘 1 分布式的3W问题 2 3 服务型分布式计算 基于混搭存储引擎的融合型分布式数据库 4 大数据与分布式计算/分布式数据库 （1+1=? ） 经典商业应用场景的困境（一） OLTPOLTP（1+1=?） 业务 、数据大集中 简单 任务高并发 响应时间 敏感 永远的痛：关系型数据库 经典对策 小型机 数据库集群 业务 拆分 迫切需求 破除单点故障 提升性能 提升业务 和数据规模 ） 灵活的通讯模式 简单任 数据是瓶颈，复杂业务 功能瓶颈 务，高并发 的痛 经典对策 （1+1=? 经典

2、商业应用场景的困境（二） OLTP会话型应用 业务大集中、数据大 集中 会话数据需长期保存 灵活的数据形式 增删改查 强调RASP，响应时间 敏感 关系型数据库是永远 多机处理业务 CDN 多样性数据存储 迫切需求 丰富的会话语义 丰富的数据存储形式 弹性的业务 、数据规模 ） 业务大 叠加高并发雪上加霜 集中、数据大 的痛 经典对策 并行/（1+1=? 经典商业应用场景的困境（三） OLTP分布式计算、大数据 繁重单任务 集中 切分功能瓶颈、数据处理瓶颈 简单任务，高并发 增删改查 强调RASP，响应时间 敏感 关系型数据库是永远 多机计算 多样性数据的多机存储 Hadoop、Spark、S

3、torm 迫切需求 丰富的分布式语义 大容量并行执行 混杂海量数据的丰富检索分析 语义 、性能、伸缩性 困境中的答案 分布式 计算 分布式 存储 提升计算节点个数 同一类任务由超过一 个CPU完成 摩尔定律“回归” 通过scale out解脱单一计算节 点上无法从硬件无限突破的两 大性能瓶颈：CPU和磁盘 提升存储节点个数 维持单位存储管理成本 高 可 用 高 可 靠 弹 高 性 性 可 能 伸 缩 分布式 分布式的直观分类 个体任务的步骤并行 流水线提升吞吐量 两者并用 如何分配工作？ 领导 分配 人人自主分配 只要有备份，就有数据不一致 恐怖的“时间窗口” “时间 窗口”发生的各种错误 的

4、自动 识别 、修复和遗留问题 的清理 安排尽可能多的人共同执 行一个任务 路由：谁能干 负载 均衡：谁比较闲 再说什么是分布式 分布式不是一种新技术 应用框架，设计 模式 衍生的支撑技术 路由、负载 均衡、任务调 度、并行计算、 资源竞争、线程间/进程间/网络通讯， 衍生的设计 需求 RASP 多任务串行多任务并行 提高请求/任务吞吐量、保持响应时间 单任务串行单任务并行 降低响应时间 分布式的粒度：子系统，模块（函数、对象） 性能与管理成本的权衡决定粒度 应用把控 理想的分布式应用架构长什么样？ 用工作流的形式来将步骤解耦并分布式 2 3 1 4 理想的分布式应用设计方法论 应用角度主导的“

5、分而治之” 框架 应用 决定如何“分”和“治” 平台 分布式应用 开发态 编程范式和API支撑 “分”：保持原状，任何粒度，任 何层次整合 “治”：步骤连接的多样性 最少的知识投资 通用、底层、简单、轻量 杜绝“分布式”设计框架 运行时 强大的运行容器，应用透明 “分”：任何粒度，规模无限 “治”：步骤连接任意顺序、 任意整合 多线程/进程/机器透明并发 必杀技：强大的RASP 理想的分布式计算框架/平台该做什么？ “最高深的技术是那些令人无法察觉的技术，这些技术不停地把他们 自己编织进 日常生活，直到你无从发现为 止”Mark Weiser 1 分布式的3W问题 2 3 服务型分布式计算 基

6、于混搭存储引擎的融合型分布式数据库 4 大数据与分布式计算/分布式数据库 服务型分布式计算分布式遇上SOA 服务 服务化的开发方式 分布式的步骤服务 任何粒度的封装 服务组装便捷 对内对外服务统一 分布式执行策略 服务虚拟化，计算资源虚拟化 自上而下、自内而外的全SOA 分布式从未如此简单 不改变业务 流程和编程模型 单机单用户思路设计分布式应用 服务型分布式计算的核心功能 托翁 法则 数据/通讯协议 全透明 Binary、JSON、XML、RAW Binary、HTTP、RTSP/RTP 应用透明，动态修改 C/S一键移动互联网 灵活强大的编程模型 全异步编程模型 灵活的服务、通讯、内存语

7、义 核心架构 分布式虚拟机 背板+刀片的架构 基本内功 RASP：分布式系统居家必备 灵活、准确的路由 精准的负载均衡 Google发明、Hadoop落地、Storm/Spark升华 并行编程框架，写分布式应用的“银弹” 合适的时间出现在合适的地方 分布式计算和大数据的唯一方法论？ Hadoop、Spark、Storm：Map-Reduce的 重要代言人 分布式计算框架/平台 Map-Reduce为何物 复杂任务并行的好方案 通用、成熟、“廉价”的 大数据方案 唾手可得的“免费”方案 不解决基础问题 ，非通 用方案 应用于各种场景是错误 低门槛带 来的各种坑 生态圈整合成本高 开源的不断重构和

8、发明 说说Map-Reduce 不是分布式计算、大数据领域的万金油，也不是阿司匹林！ 伟大的创新 服务型分布式计算 VS Map-Reduce Map-Reduce 逆向思维 所有应用需要重构 本末倒置 简单 粗暴的“分而治之” 执行的架构在设计时 决定 服务型分布式计算 顺向思维 应用角度设计 分布式 很少甚至不改造应用实现 分布式 业务 流程主导的个性化分布式模型 分布式策略通过配置而非编程 服务型分布式计算 VS 请求级分布式架构 服务型分布式计算 应用角度设计 分布式 分布式的粒度是步骤，最大程度分布式 全异步、流水线，计算资源用到极致 各种数据生命周期和数据共享 请求间各种通讯 有状

9、态的对话 请求级分布式架构 针对 OLTP和会话应 用的经典分布式架构 分布式的粒度是请求 单请 求成本高 粒度太大，请求隔离差，并发弱 数据共享弱 请求间不能高效率通讯 不支持对话 1 分布式的3W问题 2 3 服务型分布式计算 基于混搭存储引擎的融合型分布式数据库 4 大数据与分布式计算/分布式数据库 分布式存储是一种分布式计算 分布式计算分布式存储分布式计算分布式存储 DaaS 同样的方法论设计 存储 服务就是数据和数据访问 个性化分布式应用 先解决数据的分布（DB sharding， 分布式文件系统） 数据依赖路由 分布式计算 侠义数据库 VS 广义数据库 分布式数据库是分布式存储 方

10、法论和支撑技术的体现。 分布式数据库应该 汲取各种存 储技术的精华，在不同场景选 择最合适的存储技术，而不是 一味破坏式创新。 （分布式）数据库 VS （分布式）存储 数字化 VS 数据化 数据 VS 数据库 VS 存储 数据是货物 数据库将货物放进仓库 有机存 储管理。数据库是存储和管理 数据的有效形式和方法论。 冷热数据分离 读写分离 数据的垂直切分 数据的水平切分（唯一能够彻 底解决数据容量、 吞吐量、延时的全面可伸缩） 数据集中的经典应用架构配合低速系统 永恒优化命题 大数据时代更加严重 数据库的老问题 永远的瓶颈数据库的容量和处理能力 数据库是永恒的焦点 I/O导致低速，竞争导致复杂

11、 持续的瓶颈，持续的焦点 数据库调优 应用的合理设计 合理的索引设计 存储资 源换计 算和I/O资源 SQL优化 内存数据库、缓存 传统数据库集群方案 传统数据库面临的新烦恼 数据的维度和容量极大扩展 数据维度频繁变化 不支持新的数据类型 数据容量有限 数据维度有限 维度修改成本高企 常规分布式数据库方案 解决数据库困境的通用方案 解决老问题 和新烦恼 非定制的通用解决方案 深度定制在特定场景下性能更好 通用和专用的权衡妥协 这个时代需要通用方案 产品思维而非解决问题思维 轻量的可轻松定制、二次开发、优化 通用方案需要具备定制的机制 结构化数据、非结构化数据、混合型数据 OLTP、OLAP、混

12、合型应用 基于混搭存储引擎的融合型分布式数据库 TextText 核心指导思想 应用（数据库）角度设计 分布式 数据的分布存储（sharding） 充分利用水平伸缩的存储和计算资源 创新 润物细无声的分布式数据库 分布式环境下支持全SQL语义 扩展的SQL语义 融合混搭存储引擎的Big Table 融合多存储引擎的优势 将任何存储引擎分布式 不是迁就，而是保护 不同场景选择 最合适的存储引擎 整合多种存储引擎 传统 关系数据库的继承借鉴 不应完全被否定 有限范围内的强大单机处理能力 灵活的SQL语义 融合型 分布式 数据库 融合型分布式数据库的定位 分布式 关系型 数据库 分布式 NoSQL数

13、 据库 分布式 文件系 统 分布式 内存数 据库 分布式 缓存系 统 混搭型 存储系 统 融合型分布式数据库的分布式架构 服务型分布式计算的一个实例 DBaaS 按照单线 程数据库设计 主业务逻辑 (写/读）封装成服务 多存储引擎串行读/写异步并行调用服务 串行服务调 用异步调用流水线 特殊的分布式计算 数据依赖路由 根据数据分布策略选存储引擎写服务 根据分布式索引选存储引擎读服务 和传统数据库的功能区别 和存储引擎解耦的数据库 实现 K-V存储以外的所有功能 分布式索引 高效的分布式数据访问 Hashing的精准定位+范围查询 最大程度发挥 “库内计算” 数据访问更复杂 数据定位 多存储引擎

14、的数据合并、过滤 、统计 、去重、排序等 良好的数据水平分布策略 路由算法的基础，性能和伸缩性的保证 连续 性唯一标识 最大程度避免数据倾斜 物理节点虚拟化应对 大量不均衡删除 分组一致性hashing自动识别 新节点，避免数据迁移 Hashing重组进 行整理 融合型分布式数据库的RASP 分布式数据库独有的RASP 读写高性能 数据分片 最优执 行计划 读 一份数据多个拷贝 一份拷贝多个读服务 实时 步骤优 化 数据和服务的高可用 数据的多重备份 读 数据的多个读服务 写 数据的多个写服务 应用级的数据复制保 证数据的业务 完整性， 异构存储引擎间数据 同步 数据规模和访问可伸缩 数据分布

15、策略保证无 数据倾斜 数据和服务的高可靠 可用性、稳定性 强大的tracing和现场 记录 服务型分布式数据库的优势 服务型分布 式计算平台 的传承 数据/通讯协议 全透明 数据库的访问 灵活 一键变 成开放平台 服务的热插拔 规模扩展异常轻松 服务级 的RASP 各种数据访问 、二次过滤 、二次整合、索引 更新都是服务 服务型分布式计算架构 完全屏蔽分布在多节点的数据和服务带 来的 复杂性，轻松的实现 分布式。 我们发明车子不发明轮子 融合型分 布式数据 库 单机关系 型数据库 主从式 数据库 集群 数据库一 体机 水平切分的 关系型数据 库集群 类NoSQL 数据库 MPP数据 库 类HD

16、FS的 分布式文 件系统 数据规模 可伸缩性 可以不可以不可以有限可以部分可以可以可以 数据高可 用 读写无读写单点故障部分可以部分可以部分可以读写 读写性能 随节点数 提升 线性不能读非线 性 有限线性部分线性线性线性 支持数据 类型 任意结构化结构化结构化结构化（非）结 构化 结构化非结构化 支持业务 场景 各种OLTPOLTPOLTP/OLA P OLTPOLAPOLAP批处理 支持全SQL能能能能部分部分能不能 支持异构 数据整合 能不能不能不能不能不能不能不能 总体拥有 成本（ TCO） 低低中等高低中等低高 各种数据库方案对比 服务型分布式计算+融合型分布式数据库 OLTP 展现层 单一服务支持多种终端 UI和后台服务完全隔离 业务层 服务虚拟化 基于配置的服务缓 冲池 数据访问层 数据存储虚拟化 基于配置选择 合适的存 储引擎和数据部署形式 基于任何关系型数据库 全面线性可伸缩 服务和数据的RASP 会话型应用 业务逻辑 丰富的语义 支持