网站职业技能培训学校,山东建设厅官方网站李兴军,东莞横沥理工学校,政务网站建设论文在刚刚结束的年度发布会上#xff0c;OceanBase正式推出一体化数据库的首个长期支持版本 4.2.1 LTS#xff0c;这是面向 OLTP 核心场景的全功能里程碑版本#xff0c;相比上一个 3.2.4 LTS 版本#xff0c;新版本能力全面提升#xff0c;适应场景更加丰富#xff0c;有更…
在刚刚结束的年度发布会上OceanBase正式推出一体化数据库的首个长期支持版本 4.2.1 LTS这是面向 OLTP 核心场景的全功能里程碑版本相比上一个 3.2.4 LTS 版本新版本能力全面提升适应场景更加丰富有更全面的容灾解决方案。 自发布以来我们陆续收到很多客户、用户对一体化的好奇与咨询我们希望通过本文和大家更深入地探讨 OceanBase 对一体化理念的思考和探索。 OceanBase 13 年前刚成立的时候业界有很多非常流行的开源数据库比如大家都很熟悉的 MySQL但是 MySQL 数据库有两个问题只能处理简单查询无法处理复杂查询只能处理小数据量很难做扩展及处理大数据量。 正因此团队决定开始研发分布式数据库 OceanBase用一体化的思路解决单机与分布式的难题不仅能处理小查询也能处理大查询从 KV 到 TP/AP一体化从简单查询到复杂查询OceanBase 一直在通过应用场景不断驱动自身创新这也是 OceanBase 设计一体化思路的初心。 从 2010 年至今OceanBase 专注 OLTP事务处理场景逐步实现了多个一体化TP/AP 一体化、云上云下一体化、单机分布式一体化。从 1.x 发展到今天的 4.x在用户的支持下OceanBase 的产品能力得到了飞跃发展。作为自研数据库的一员聚焦到“关键业务负载”的核心系统诉求我们需要在稳定性、高性能、高兼容和性价比这几个维度上持续突破和深度打磨这是 OceanBase 的核心竞争力也是 OceanBase 在技术投入和产品打磨上一直以来投入的最重要的关键方向。 在一体化思路的指引之下OceanBase 没有选择复用开源数据库的代码选择了一条应用驱动技术创新、完全自研的发展道路。在这个路线指引之下OceanBase 做了大量的技术创新把分布式领域的核心技术逐步融入到关键数据库领域里。 例如通过把 Paxos 引入到关键数据库实现 RPO0RTO8 秒通过“三地五中心”实现了业内首个城市级无损容灾打榜 TPC-C并且取得世界第一的成绩提出单机分布式一体化架构并且把 LSM-Tree 存储引擎引入到关键数据库里面大幅度地降低了存储成本...... 一体化的设计思路简单来讲可以分成三个层次为了便于大家理解我们以造房子作为举例 首先需要搭地基一体化思路的地基即2022年发布的单机分布式一体化架构主要解决数据规模的问题数据可大可小有了这个架构之后不管多大多小的数据量都可以用一套系统全部统一地解决掉。 其次在一体化架构基础之上进一步搭建一体化引擎包括一体化的存储引擎、一体化的事务一体化的 SQL 引擎以及云上云下存储计算分离的引擎。这个层次主要解决了数据的存储与计算问题。 第三有一体化引擎之后进一步搭建最终的一体化产品即房子。这个产品解决的是如何给客户提供数据服务的问题包括如何支持多种工作负载、实现多种数据模型、实现多种数据接口、实现多种兼容模式等。 与传统的关系型数据相比JSON、XML 等半结构化数据的处理方式更加灵活因此在处理复杂的应用中显得尤为不可或缺。与此同时对于处理 GIS 和 KV 等多样数据的需求也日益凸显。在此过程中数据库经历了从事务型到分析型再到支持 HTAP 两种类型的发展企业通常会根据不同问题使用不同的数据库这也导致了数据库的不断增加数据的使用和管理变得越发复杂。而 OceanBase 今天的一体化思路核心理念是用一个数据库解决 80% 的问题注意这里是 80% 的问题不是百分之百的问题。 一直以来OceanBase 专注于 OLTP 场景从 2010 年开始逐步打造满足现代数据架构需求的多模态、多兼容模式、多租户、多工作负载、多基础设施等核心能力推出的一体化数据库为用户提供简化复杂性的全新可能性。 多租户统一技术栈极大简化数据库基础设施的复杂度。OceanBase 在早期 1.0 版本已经实现工程一体化并提供多租户以及资源隔离能力可将更多的数据库实例整合一个集群中。从用户业务视角不用再关心资源隔离问题可直接通过多租户带来的统一技术栈即可极大简化数据库基础设施的复杂度并显著提高系统利用率。 多兼容模式一个数据库同时兼容 MySQL 和 Oracle。OceanBase 2.0 版本开始提供多兼容模式高度兼容 Oracle 和 MySQL支持存储过程、触发器等高级特性。用户无需关心兼容性问题通过一体化 SQL 引擎同时兼容 MySQL 以及 Oracle 主流数据库同时提供自动迁移工具支持迁移评估和反向同步以保障数据迁移安全支撑金融、政府、运营商等关键业务系统升级。 多工作负载一份数据所有工作负载中提供出色的性能和性价比。3.0 版本加速进化多工作负载能力用户无需关系 ETL 复杂性通过一个系统、一份数据就可以在高性能 OLTP 基础上支持实时分析能力并从根本上保持数据一致性。 单机分布式一体化架构一个数据库满足用户从小到大的业务规模化诉求4.0 版本推出用户无需关心集中式或分布式技术路线选型可以在业务量小的情况下从小规格单机部署起步使用完备功能的单机部署形态随着业务压力的变化将数据库从单机平滑扩容到多机甚至超大规模的分布式集群同时具备多机平滑缩容到单机的能力通过一套数据库满足业务从小到大的集中式和分布式架构诉求。 多模型一个数据库支持多种现代数据类型4.0 版本开始提供多模型能力通过OBKV提供融合多模数据支持无论应用的简单性还是复杂性无论处理的是关系型数据、JSON、Key-Value 还是 GIS 等非结构化数据都可以在同一个的数据库上获得卓越的支持降低应用开发难度和运维复杂性。 多基础设施从“云下”到“云上”按需选择基础设施4.0 版本开始支持本地数据中心、阿里云、AWS 等多基础设施以及跨基础设施部署通过一致的架构和一致的管理显著降低复杂性。每一个企业的基础设施都各不相同不论是应用还是数据库都可以部署在专有云、公有云和混合云中选择权完全交给企业自己。 去年OceanBase 发布了业内首个单机分布式一体化数据库 4.0 小鱼单机分布式一体化的核心是采用一套系统实现从单机到分布式对用户完全透明。通过单机分布式一体化架构可以实现可大可小既能应用到大企业也能应用在中小企业甚至是一些创业公司。此外OceanBase 单机分布式一体化架构在平滑伸缩、小规格部署、RTO 30s 缩短至 RTO8s 的故障恢复能力方面上均进行了创新。 有了单机分布式一体化架构这个底座之后就可以进一步搭建一体化的存储引擎、一体化的SQL 引擎以及存储计算分离的引擎。 一一体化存储引擎 今天业内都在谈论 HTAP众所周知 OLTP 需要行存OLAP 需要用列存如何设计一套一体化的存储引擎能够把行存和列存完全融合到一套系统里面有两种比较经典的设计思路。 第一种设计思路OceanBase 是一个 Shared-Nothing 的多副本架构每个副本仍然采用相同的存储格式都采用行存或者都采用行列混合式存储所有的 OLAP 和 OLTP 的请求都直接由主副本提供服务这种方式的好处很明显它没有任何一致性的问题也没有任何数据延时的问题但是它的问题在于因为没有支持列存所以 OLAP 能力相对来讲差一些比较适合 OLTP非常轻量的 OLAP 的场景比如跑批或者 OLTP 场景里面的复杂查询。 第二种设计思路OceanBase 的多个副本可以采用不同的存储格式主副本支持行存支持OLTP某一个备副本用列存来支持 OLAP。这种方式的好处在于通过引入列存大幅度提升了 OLAP 的处理能力。但是问题在于主副本与备副本之间会额外引入毫秒级的延迟有短暂时间的数据不一致比较适合简单的 OLTP 的场景加上中等的 OLAP 的场景。当然今天讲的 HTAP 无法解决百分之百的 OLTPOLAP 融合到一套系统里面的问题。 二一体化 SQL 引擎 谈到混合负载就一定有简单查询也有复杂查询。如何设计一套一体化的 SQL 引擎把简单查询和复杂查询融入到一套系统里面去 因为简单查询用户比较关注简单查询的延迟所以简单查询比较好的实现方式是串行执行并且由 SQL 层往存储层拉数据复杂查询因为涉及的数据量比较大用户比较关注能否发挥整个数据库所有的并行处理能力比较好的实现方式是用并行执行SQL 层把执行计划下推到存储层从而降低网络上数据传输的开销。 今天 OceanBase 的一体化 SQL 引擎实现了推拉结合的模式对简单查询拉数据复杂查询推执行计划通过这样的方式实现了把简单查询和复杂查询很好地融入到一套系统里。同时OceanBase 支持了一个非常有用的功能叫 Auto DOP自动设计并行优化器可以根据统计信息自动地判断到底应该采用简单查询、串行执行还是并行执行以及并行执行具体的并发度。 当然只要讲到混合负载一定面临简单查询与复杂查询 OLTP 与 OLAP 之间资源隔离的问题之前 OceanBase 已经支持了在数据库内部的 CPU 和内存的资源隔离今年 OceanBase 进一步增强了基于 IO 能力的资源隔离。 三存算分离引擎 作为一个多副本的 Shared-Nothing 架构如何把 Shared-Nothing 架构部署到多云基础设施也是一个很大的技术挑战。这里面涉及到如何把 Shared-Nothing 架构与通常在云上的 Shared-Storage 架构融合起来。 比较幸运的是OceanBase 的底层存储引擎是 LSM-Tree虽然 OceanBase 采用了多个副本的存储架构但是 LSM-Tree 把数据分成了基线数据增量数据OceanBase 多个副本之间的基线数据是一模一样的。 当 OceanBase 把多个副本部署到多云基础设施的时候此时多个副本的基线数据可以共享同样一份共享存储最终可以做到只有接近一份数据的存储成本。当然OceanBase 也可以通过一些日志副本或者仲裁副本的方式进一步降低计算成本的开销最终做到接近一个副本的存储接近两个副本的计算实现 RPO 0并且在云上实现了弹性最终做到 Shared-Nothing 和 Shared-Storage 架构完美融合。有了一体化引擎之后就可以在引擎之上进一步地搭建一体化的产品。 过去一年OceanBase 在一体化的产品层面做了很多事举三个例子 一一体化 SQL 功能 一体化的设计理念有一个核心的目标就是希望能够做到在分布式架构实现与集中式数据库与单机数据库完全对标的 SQL 功能但是某一些 SQL 功能在分布式架构下是非常难以实现。 举两个例子。第一个例子是大事务如果一个大事务设计的参与数、分区数特别多比如几万个甚至几十万个参与者分布式事务基本上不可能完成另外一个例子是表锁比如要在分布式系统里面锁住一张表格这张表格设计的分区数特别多因为要锁每个分区所以这也基本上不可能实现。这个问题的本质在于原有的原生分布式数据库一般来讲每个分区有一个独立的日志流使得大事务表锁这样的操作它的复杂度会与分区的个数成正比。 OceanBase 通过单机分布式一体化架构通过其中的动态日志流的技术把一台机器上所有的分区动态地融入到一个日志流里面使得大事务、表锁这样的复杂度只与机器数成正比不与分区数成正比最终在 4.2 版本里OceanBase 实现了任意大事务没有限制以及全功能的 DDL包括表锁在内。 二多模融合 这里面的多模型不仅仅在一个产品里面支持多个不同的模型还包括如何实现多个模型之间的互相操作。 举个例子OceanBase 经常有一些 HBase 的用户有人说 HBase 的接口比较好用但是 HBase 独接口特别简单语义不够丰富不支持 SQL。当很多 HBase 用户把他们的业务迁移到 OceanBase 之后他们仍然使用与 HBase 兼容的方式来写入但是读取的时候直接采用 SQL 语言。在发布会现场很多人已经前往展台体验了多模 Live Demo现场有很多直接用 HBase、JSON 等写入、SQL 读取的场景实例。 OceanBase 4.0 版本开始提供多模型能力通过 OBKV 提供融合多模数据支持无论应用的简单性还是复杂性无论处理的是关系型数据、JSON、Key-Value 还是 GIS 等非结构化数据都可以在同一个的数据库上获得卓越的支持降低应用开发难度和运维复杂性。 三一体化产品家族 工具产品方面我们希望围绕关键业务负载场景做工具产品核心能力的升级 去兼容更多的关键生态在过去一年无论是 ODC、OMS、Binlog还是 OCP、OAS 都在面向关键业务场景做了大量的能力升级。 ODC打造企业级协同开发平台 ODC 致力于打造企业级的开发者协同平台把企业需要的安全合规流程融入到数据库开发者的工作流程中使得所有的变更操作都可以做到可回溯、可回滚这件事情对于核心业务场景、关键业务负载非常重要。 OMS双向同步、一键逃生 所有把OceanBase应用到关键业务负载的客户一定会提两个需求第一个希望能够做到老系统与新系统之间的长期并跑一键逃生。另外希望能深度掌控 OceanBase。OMS 提供了双向同步的能力长期并跑一键逃生万一新系统出现问题不管什么原因最终都能够保证一键逃生到系统。 OCP 全场景管控 OAS 诊断自治一体化智能运维诊断平台 在 OCP 层面OceanBase 进一步增强了诊断监控功能支持全场景的管控。通过积累在蚂蚁、支付宝多年的运维、稳定性相关的经验进一步将产品进化成 OAS 自助服务输出给客户。 Binlog打通 MySQL生态 同时OceanBase 也在持续完善 MySQL 及 Oracle 兼容性在新增内核兼容功能的同时还提供 MySQL Binlog 协议的支持帮助用户更方便地把数据库接入到下游 MySQL 生态。 今天OceanBase 4.2.1 LTS 版本正式发布 其是一体化数据库的首个长期支持版本包括三个最重要的核心能力升级 第一支持完整的 OLTP 功能是面向 OLTP 核心场景的全功能里程碑版本可以说OceanBase 4.2.1 LTS版本的发布意味着 OceanBase 在分布式 OLTP 核心功能已经就绪这个非常重要第二更是更强的性能相比 3.2 LTS 版本4.2.1 LTS 版本的 OLTP 性能是 3.2 版本的 1.9 倍OLAP TPC-DS 100G 场景性能是 3.2 版本的 2.7 倍第三是更低的容灾成本通过引入基于仲裁的无损容灾方案通过两个副本实现 RPO0。 OceanBase 4.2.1 LTS 版本有五大核心能力 内核能力方面OceanBase 4.2.1 LTS 版本包括三种技术特性第一支持一体化的产品能力包括混合负载以及多模能力OceanBase 4.2.1 LTS 支持 Auto DOP 自动设置并行度 SPM SQL 执行计划管理相信 Oracle DBA 和用户非常熟悉这两个功能对于一个企业级数据库支持复杂查询非常重要支持 KV支持 JSON也把 LOB 的上限提升到 512MB第二支持一体化的 SQL 和事务的能力实现任意大小的事务无限制并且实现全功能的 DDL第三实现了更好的高可用的能力既能支持与传统的集中式数据库完全对标的组备库的方式也实现了通过仲裁的方式以两个副本的成本实现 RPO0。 性能提升方面相比 3.2 LTS 版本OceanBase 4.2.1 LTS 版本的 TP 性能是 3.2 版本的 1.9 倍AP 性能是3.2版本的2.7倍导入性是 3.2 版本的 6 倍。 兼容性方面OceanBase 4.2.1 LTS 版本进一步增强了 MySQL 8.0 的兼容并且提升了 Oracle 的兼容性支持 DBLink、表锁等 Oracle 常见的特性。通过兼容 MySQL Binlog 的方式直接接入到下游数据生态。 工具平台方面OMS 支持双向同步一键逃生ODC 打造企业级协同开发平台OCP 支持全场景的管控OAS 实现智能诊断自治服务。可以说大家可以把关键业务场景非常放心地迁移到 OceanBase 4.2.1 LTS 版本OceanBase 4.2.1 LTS 版本不管是内核能力、迁移过程以及迁移之后的运维稳定性都能够很好地支持关键业务负载。这个版本可以让关键业务负载用得非常省心、放心运维也非常安心。 单机模式方面OceanBase 4.2.1 LTS 版本支持单机模式之所以叫单机模式意味着它可以按需升级到多机模式按需扩展到分布式。同时相比 MySQL 单机数据库OceanBase 4.2.1 LTS 版本能够更好地支持混合负载提供更好的数据压缩能力并且也有更好的高可用能力包括前面提到的通过仲裁的方式以两个副本的开销实现 RTO0。 作为一体化的产品OceanBase 的 OLAP 能力也在非常快速地迭代当然了作为 OLAP 领域新进入的一员OceanBase 需要向业界一流的产品学习包括 ClickHouse。 OceanBase 列存实验室版本与 ClickHouse 的跑分演练 通过跑分可以看到同等硬件条件之下OceanBase 列存实验室版本的性能在实时 OLAP 在大宽表场景已经达到了 ClickHouse 同一水平甚至 OceanBase 的性能稍微快那么一点点。 作为从事十余年的数据库基础设施厂商OceanBase 所提的一体化产品以及数据库基础设施有两件事情是永恒不变的话题性能更快成本更低。 OceanBase 永远都在追求极致的性能与最佳的成本一体化的产品正是能够在追求分布式架构下的极致性能和最佳产品。目前OceanBase 的单机性能已经达到甚至超过了 MySQL 的性能在单机形态、硬件成本以及迁移学习成本上有着显著的优势 单机部署形态成本在单机部署形态下在同等硬件条件下OceanBase 的 SQL 及事务处理性能和 MySQL 相当部分场景下存储成本可降低至原有的1/3 垂直/线性扩展带来的硬件成本随着业务规模的增大无论在云上还是 on-prem为提升性能都需要升级硬件。在此过程中相较于传统数据库的非线性成本增长尤其是高速网络/SAN 存储设备的价格和单机部署时的差异巨大 OceanBase 的水平扩展可以做到真正的线性扩展带来的成本也是线性增长帮助用户更好的降低数据库成本 迁移和学习成本OceanBase 实现了单机和分布式架构的统一同时兼容集中式数据库的行为和使用方式。这使得用户在基本不修改业务代码的情况下能够平滑地从单机形态扩容到分布式形态而无需额外的迁移及学习成本。 最后和大家分享下 OceanBase 4.x 产品路线图。去年 8 月份也就是去年 OceanBase 产品发布会首次发布了单机分布式一体化架构以及 OceanBase 4.0今年 3 月份OceanBase 发布了面向开发者的里程碑版本 OceanBase 4.1。今天OceanBase 发布了 4.x 的首个 LTS 版本 OceanBase 4.2.1明年 4 月份 OceanBase 4.3 版本即将发布包含前面提到的列存功能明年 10 月份OceanBase 4.4 版本将会和大家见面支持存储计算分离的能力。欢迎大家关注 OceanBase一起打造更好的一体化数据库。
