oceanbase-周跃跃-分布式数据库 OceanBase 架构演进与业务场景实践-
讲师简介 专注于数据库特别是分布式数据库领域多年，熟悉分布式数据库技术原理与解决方案落地，目前主要从事OceanBase数据库方案落地和技术布道。 周跃跃OceanBase架构师 目录 •架构升级以及背后的故事•核心特性以及原理解读•OceanBase在企业场景落地实践•进一步开源开放的OceanBase生态 架构升级以及背后的故事 分布式架构 无共享架构+Paxos协议+分区级高可用 •多副本：一般部署为三/五个Zone，每个Zone由多个服务器节点（OBServer）组成•对等节点：每个节点均有自己的SQL引擎和存储引擎，自主管理各自承载的数据分区，TCP/IP互通，协同服务•无需存储设备共享：数据分布在各个节点上，不基于任何设备级共享存储技术，不需要SAN网络•分区级可用性：分区是可靠性与扩展性的基本单元，自动实现访问路由、策略驱动负载均衡、自主故障恢复•高可用+强一致：多副本+Paxos分布式协议的高效高可靠工程实现，确保数据（日志）持久化在多数派节点成功 核心特性以及原理解读 架构升级-主备模式 像使用MySQL一样使用OceanBase（租户主备） 典型场景介绍 •单副本高可用架构•高网络延迟架构 方案价值 •不再需要中间介质来实现•租户级别主备•RTO秒级、RPO秒级•主备独立，互不感知 3.X架构局限性-paxos选举开销 “从大到小”，不仅仅是架构变小，更要解决在小规格配置时流畅的使用OceanBase 3.x架构下，选举就会消耗不少的CPU资源，小规格资源无法承担业务 分布式事务 现象：参与者的数量变多的时候，到4个时，性能大概会减半；当参与者到100个的时候，性能会再减半；结论：参与者的数量越多，事务的性能就会越差。 4.X如何解决 合并日志流 核心：日志流数量太多 架构升级-单日志流 3.X分区与日志流高度耦合 4.X分区与日志流解耦 单个日志流可服务多个分区优化后1、开销小（日志流数量非常小）2、日志流内一阶段提交单机分区达到百万级别性能、资源、稳定性进一步提升 场景1、数据量大造成分区数量巨大（建议5-8w）2、频繁创建、删除和truncate表和分区等问题1、系统开销（状态机）：网络、CPU、内存等2、性能损失：多分区两阶段提交 更多优化 资源占用更小，执行更快 优化SQL 优化CPU 优化内存 增强自动改写，生成更好计划优化执行引擎，提升执行效率 减少不必要的后台线程数量按需降低后台线程扫描频率 存储层元数据按需加载大数据结构内存按需扩张 性能表现与对比 存储收益 功能特性 ★原生分布式 ★单机分布式一体化 全量数据校验真正实现数据强一致，数据不丢失，高可用，平滑扩展 自研一体化架构突破高性能和高可用，实现应用无限扩展和服务永远在线 ★MySQL平滑迁移 ★HTAP 一份数据既能做事务处理又能实时分析，通过HTAP助力拓展更多可能 业务少量修改甚至不改即可迁移到OB，自动评估和迁移工具 ★多租户 ★低成本 资源隔离按需使用，灵活管理，适合微服务架构和SaaS行业应用 基于LSM-Tree的高压缩引擎平衡了“性能”和“压缩”的瓶颈，有效降低存储成本70% - 90% OceanBase在企业场景落地实践 六大典型场景解决方案 历史库 高并发 多租户 资源池化|降低成本 分库分表聚合库|极速扩展|弹性扩所容 低成本|生命周期自 用异地多活|单元化丨极致弹性 动管理|超大容量 过OceanBase的分布式多租户架 构 ， 实 现 基 于 面 向 服 务（SOA）的多数据库资源整合。 通过OceanBase智能化的历史库迁移平台，帮助用户快速、安全的完成冷数据归档，一次配置即可自动管… 基于OceanBase的在线扩缩容能力和高并发低延迟特性，快速应对业务负载变化，支撑业务高速发展 OceanBase通过强大的异地部署能力和灵活的副本变换以及负载均衡能力，帮助企业在关键核心场景中构建… 实时数仓 OBKV 极低延迟|极简架构|海量存储 低成本|平滑替代|更高性能 集数据加工处理以及数据即时查询于一体的OceanBase原生分布式HTAP据库解决方案，为业务提供实时数仓支撑 平滑替代HBase业务,大幅提升性能,节省大量HBase相关组件,统一技术栈,降低运维成本. 典型场景一:历史库（高级压缩技术）显著降低存储成本 数据压缩是降低海量数据存储空间占用的关键手段。OceanBase高压缩比的分布式存储引擎，摒弃了传统数据库的定长数据块存储，采用基于LSM-Tree的存储架构和自适应压缩技术，创造性的解决了传统数据库无法平衡“性能”和“压缩比”的难题，并基于数据日志分离方法的分布式存储技术，进一步降低存储成本，实现了高性能和低存储成本。基于LSM-Tree的存储引擎，利用编码压缩大大降低存储成本。 基于数据变长-定长的存储压缩技术 通过使用压缩率较高且解压缩较快的压缩算法对数据进行压缩，提高数据压缩倍率，减少数据的存储成本。同时由于LSM-Tree的结构特性，采用读写分离设计和行级细粒度记录更新，变更数据保存在内存中，并批量写入到磁盘上。因此能达到内存数据库级写入性能和磁盘数据库的存储成本，并消除了传统B+Tree的磁盘随机写瓶颈和存储空间碎片化问题，使得数据写入性能比传统的实时更新数据块的方式更高。 同一业务的数据存储量OceanBase仅为MySQL数据库的1/8-1/10 显著提升业务系统稳定性、安全性有效降低存储成本70%-90% 基于数据编码的存储压缩技术 支撑OLTP业务在线高压缩比 采用行列混合存储格式，磁盘数据块按列组织，自研一套对数据库进行行列混存编码的压缩方法（encoding），使用行列的字典、差值、前缀等编码算法，在通用压缩算法之前对数据做了编码压缩，从而带来更大的压缩率。 LSM-Tree架构、动态修改写内存、静态数据无修改；批量写高压缩支持、强数据校验、对SSD友好无随机写。 基于数据日志分离的低成本存储技术 传统的Paxos协议中，系统需要三个副本（五副本），OceanBase数据库将用户数据和日志数据分离，比如日志数据基于Paxos协议使用三副本（五副本）存储，而用户数据本身可以使用两副本（三副本/四副本）进行存储。在保障相同可用性的前提下，数据日志分离可节省20%-40%的用户数据存储成本。 www.top100summit.com 典型场景一:历史库 业务挑战 收益 •扩展性不足：随着订单业务量的增加，业务数据迅猛增长，传统数据库的存储瓶颈以及性能不佳问题越来越明显； •数据量大：业务数据量在OceanBase单集群达到百T级别，同时单表大小达到10T级别以上，同时存在大量数据进行聚合，有复杂的AP请求•业务特征极端：数据量百T级别，读写请求峰值QPS百万级别•稳定性要求高：业务要求返回延迟为ms级，如无法在规定时间内完成，影响核对结果，同时系统出现故障或者请求异常抖动时，会产生资损，与钱挂钩 •运维更加高效与便捷：单集群替换300+套MySQL环境，运维管理成本大大降低，同时管理更加方便。 •低成本：支撑上百TB数据存储场景且性能和稳定性有保证，同时相比较之前的方案，OceanBase方案的存储成本降低75%，降本效果明显。•架构收益明显：使用OceanBase替换掉ES+MySQL方案之后，替换掉ES服务，同时MySQL机器成本缩减一半，整体节省50台机器•一套OCP管理OceanBase集群8套，OBServer节点数超过200个 解决方案 •OceanBase同城三机房部署架构，实现RPO =0，RTO< 30秒的容灾能力；同时又可以在异地增加一个只读Zone提供本地的读服务，提升查询效率。同城容灾以及本地读等功能为业务提供稳定性和性能双重保障。 •OceanBase具备灵活的资源扩展能力，根据业务实际发展情况可以动态的进行计算和存储能力的线性扩展，支撑海量数据的存储和计算，同时很好地应对未来的业务增长要求。 •相比传统的集中式数据库MySQL，OceanBase在存储层面极致的压缩能力，有效降低企业使用数据库的硬件成本。 典型场景二：多租户（对碎片化资源进行整合） 大集群&多租户 大集群：将长尾应用的多实例MySQL、多业务统一进行管理，有效提高资源密度，消除存储碎片。 多租户：实现数据库内核级虚拟化（CPU、IO、内存），满足数据安全隔离的同时，提供基于业务画像的可伸缩计算资源，同时通过Leader打散实现混部。 通过提升资源密度的方式，实现满足相同业务需求的情况下，降低资源成本 典型场景二：Saas服务资源隔离、灵活管理 原生多租户架构，一个集群中同时运行多个数据库租户，每个租户可以视为一个独立的数据库服务。租户间数据和资源互相隔离，并且在集群内统一调度。支持在创建租户时选择不同的兼容模式，每个租户可单独配置数据副本数量、副本类型、存储位置及计算资源等。 适合微服务架构 随着企业内业务系统越来越复杂，原来的单体服务在工程和管理上变的越来越不堪重负。使用微服务架构，新增和调整功能只需要增加新的微服务节点。但是每个微服务需要使用不同的数据库，数据库的数量大大增加，可靠性和运维管理都带来了挑战。使用OceanBase多租户特性，管理员只需要运维少量集群，既能保证租户之间数据和资源互相隔离，又提升了数据库的稳定性。 适合多租户SaaS服务 云上的SaaS服务商，往往提供的是多租户的服务。多个业务租户的数据库如果在一个单机数据库中做逻辑名字空间隔离，大小租户之间互相影响。如果每个业务租户使用一个独立的数据库，成本高，几十到上百套分散数据库环境，运维工作复杂，同时扩展性受限。使用OceanBase数据库内原生多租户，能更好地平衡隔离性和成本，而且大小租户可以独立扩缩容。 零售Saas场景 典型场景二：错峰超卖 从硬件方面考虑，OceanBase的优势降本在于超卖，各系统错峰使用超分资源。不同租户之间的弹性可以分时复用，提升资源利用率 适合多租户错峰服务 假设对应以上三个系统，高峰期使用的资源都需要4C，8G，如果使用MySQL，需要为三个业务系统都分配3个4C 8G规格的资源；如果使用OceanBase，只需要分配三个1C，8G的租户，余3个CPU资源可以共享；另外，如果开启OceanBase的读写分离特性，CPU资源还能进一步充分利用。 典型场景3:极致高可用-基于paxos的多副本架构 •多数派投票协议，包含leader、follower等角色•每个事务成功写入需要满足超过大多数节点•RPO=0；RTO<8s•强主模式，leader读/写，可开启弱一致性读 Paxosor Raft ? 典型场景3:极致高可用-数据校验（物理&逻辑）保证底层数据正确 内置多种强校验机制，能够自动发现多副本数据的不一致、网络数据错误、磁盘静默错误、索引与主表的不一致错误等，保证数据可靠。 www.top100summit.com•读取最小单位是微块,写最小单位是宏块；读取时,会校验微块校验和•SSTable累计行校验和•SSTable列校验和•合并时:•索引列列校验和和主表列的列校验和进行比较•副本之间的行校验和和列校验和进行比较 •迁移/备份时,会校验宏块校验和；后台周期性巡检宏块校验和 典型场景3:极致高可用-基于架构的高可用解决方案 典型场景3:极致高可用 极致高可用支撑7x24无停机 业务挑战 收益 •数据库服务器资源利用率达到75%，在系统处理能力遭遇瓶颈时，可进行便捷的水平扩展，增加集群计算资源来提升处理能力。 •实现数据库同城双活、异地RPO=0。机房级容灾达到RPO=0，RTO<30s，即故障发生后，从IT系统宕机导致业务停顿到系统恢复至可以支持各部门的运作时间，少于30秒。达到工商银行5级容灾要求，满足7
