查找人网站 优帮云,免费的带货视频素材网站,餐饮美食网站模板源码,如何建国际商城网站码到三十五 #xff1a; 个人主页 心中有诗画#xff0c;指尖舞代码#xff0c;目光览世界#xff0c;步履越千山#xff0c;人间尽值得 ! 目录 1️⃣OceanBase 整体架构1.1 分区1.2 分片1.3 日志流1.4 对等节点1.5 多租户 2️⃣OceanBase 架构与组件详解2.1 存储层2.2 … 码到三十五 个人主页 心中有诗画指尖舞代码目光览世界步履越千山人间尽值得 ! 目录 1️⃣OceanBase 整体架构1.1 分区1.2 分片1.3 日志流1.4 对等节点1.5 多租户 2️⃣OceanBase 架构与组件详解2.1 存储层2.2 复制层2.3 均衡层2.4 事务层原子性隔离性 2.5 SQL 层2.5 多种计划2.6 接入层 3️⃣ 核心组件与功能概述基础架特性核心组件与功能数据库实例内部组件 结语 1️⃣OceanBase 整体架构
OceanBase 数据库采用 Shared-Nothing 架构各个节点之间完全对等每个节点都有自己的 SQL 引擎、存储引擎、事务引擎运行在普通 PC 服务器组成的集群之上具备高可扩展性、高可用性、高性能、低成本、与主流数据库高兼容等核心特性。 1.1 分区
OceanBase 数据库的一个集群由若干个节点组成。这些节点分属于若干个可用区Zone每个节点属于一个可用区。可用区是一个逻辑概念表示集群内具有相似硬件可用性的一组节点它在不同的部署模式下代表不同的含义。例如当整个集群部署在同一个数据中心IDC内的时候一个可用区的节点可以属于同一个机架同一个交换机等。当集群分布在多个数据中心的时候每个可用区可以对应于一个数据中心。每个可用区具有 IDC 和地域Region两个属性描述该可用区所在的 IDC 及 IDC 所属的地域。一般地地域指 IDC 所在的城市。可用区的 IDC 和 Region 属性需要反映部署时候的实际情况以便集群内的自动容灾处理和优化策略能更好地工作。根据业务对数据库系统不同的高可用性需求OceanBase 集群提供了多种部署模式。
1.2 分片
在 OceanBase 数据库中一个表的数据可以按照某种划分规则水平拆分为多个分片每个分片叫做一个表分区简称分区Partition。某行数据属于且只属于一个分区。分区的规则由用户在建表的时候指定包括hash、range、list等类型的分区还支持二级分区。例如交易库中的订单表可以先按照用户 ID 划分为若干一级分区再按照月份把每个一级分区划分为若干二级分区。对于二级分区表第二级的每个子分区是一个物理分区而第一级分区只是逻辑概念。一个表的若干个分区可以分布在一个可用区内的多个节点上。每个物理分区有一个用于存储数据的存储层对象叫做 Tablet用于存储有序的数据记录。
1.3 日志流
当用户对 Tablet 中记录进行修改的时候为了保证数据持久化需要记录重做日志REDO到 Tablet 对应的日志流Log Stream里。每个日志流服务了其所在节点上的多个 Tablet。为了能够保护数据并在节点发生故障的时候不中断服务每个日志流及其所属的 Tablet 有多个副本。一般来说多个副本分散在多个不同的可用区里。多个副本中有且只有一个副本接受修改操作叫做主副本Leader其他副本叫做从副本Follower。主从副本之间通过基于 Multi-Paxos 的分布式共识协议实现了副本之间数据的一致性。当主副本所在节点发生故障的时候一个从副本会被选举为新的主副本并继续提供服务。
1.4 对等节点
在集群的每个节点上会运行一个叫做 observer 的服务进程它内部包含多个操作系统线程。节点的功能都是对等的。每个服务负责自己所在节点上分区数据的存取也负责路由到本机的 SQL 语句的解析和执行。这些服务进程之间通过 TCP/IP 协议进行通信。同时每个服务会监听来自外部应用的连接请求建立连接和数据库会话并提供数据库服务。
1.5 多租户
为了简化大规模部署多个业务数据库的管理并降低资源成本OceanBase 数据库提供了独特的多租户特性。在一个 OceanBase 集群内可以创建很多个互相之间隔离的数据库实例叫做一个租户。从应用程序的视角来看每个租户等同于一个独立的数据库实例。不仅如此每个租户可以选择 MySQL 或 Oracle 兼容模式。应用连接到 MySQL 租户后可以在租户下创建用户、database与一个独立的 MySQL 库的使用体验是一样的。同样的应用连接到 Oracle 租户后可以在租户下创建 schema、管理角色等与一个独立的 Oracle 库的使用体验是一样的。一个新的集群初始化之后就会存在一个特殊的名为 sys 的租户叫做系统租户。系统租户中保存了集群的元数据是一个 MySQL 兼容模式的租户。
2️⃣OceanBase 架构与组件详解
OceanBase 使用通用服务器硬件依赖本地存储分布式部署使用的多个服务器也是对等的没有特殊的硬件要求。OceanBase 的分布式数据库处理采用 Shared Nothing 架构数据库内的 SQL 执行引擎具有分布式执行能力。
OceanBase 在服务器上会运行叫做 observer 的单进程程序作为数据库的运行实例使用本地的文件存储数据和事务 Redo 日志。
OceanBase 集群部署需要配置可用区Zone由若干个服务器组成。可用区是一个逻辑概念表示集群内具有相似硬件可用性的一组节点它在不同的部署模式下代表不同的含义。例如当整个集群部署在同一个数据中心IDC内的时候一个可用区的节点可以属于同一个机架同一个交换机等。当集群分布在多个数据中心的时候每个可用区可以对应于一个数据中心。 用户存储的数据在分布式集群内部可以存储多个副本用于故障容灾也可以用于分散读取压力。同一个租户在一个可用区内的数据只有一个副本不同的可用区可以存储同一个数据的多个副本副本之间由共识协议保证数据的一致性。
OceanBase 内置多租户特性每个租户对于使用者是一个独立的数据库一个租户能够在租户级别设置租户的分布式部署方式。租户之间 CPU、内存和 IO 都是隔离的。
OceanBase 的数据库实例内部由不同的组件相互协作这些组件从底层向上由存储层、复制层、均衡层、事务层、SQL 层、接入层组成。
2.1 存储层
存储层以一张表或者一个分区为粒度提供数据存储与访问每个分区对应一个用于存储数据的Tablet分片用户定义的非分区表也会对应一个 Tablet。
Tablet 的内部是分层存储的结构总共有 4 层。DML 操作插入、更新、删除等首先写入 MemTable等到 MemTable 达到一定大小时转储到磁盘成为 L0 SSTable。L0 SSTable 个数达到阈值后会将多个 L0 SSTable 合并成一个 L1 SSTable。在每天配置的业务低峰期系统会将所有的 MemTable、L0 SSTable 和 L1 SSTable 合并成一个 Major SSTable。
每个 SSTable 内部是以 2MB 定长宏块为基本单位每个宏块内部由多个不定长微块组成。
Major SSTable 的微块会在合并过程中用编码方式进行格式转换微块内的数据会按照列维度分别进行列内的编码编码规则包括字典/游程/常量/差值等每一列压缩结束后还会进一步对多列进行列间等值/子串等规则编码。编码能对数据大幅压缩同时提炼的列内特征信息还能进一步加速后续的查询速度。
在编码压缩之后还可以根据用户指定的通用压缩算法进行无损压缩进一步提升数据压缩率。
2.2 复制层
复制层使用日志流LS、Log Stream在多副本之间同步状态。每个 Tablet 都会对应一个确定的日志流每个日志流对应多个 TabletDML 操作写入 Tablet 的数据所产生的 Redo 日志会持久化在日志流中。日志流的多个副本会分布在不同的可用区中多个副本之间维持了共识算法选择其中一个副本作为主副本其他的副本皆为从副本。Tablet 的 DML 和强一致性查询只在其对应的日志流的主副本上进行。
通常情况下每个租户在每台机器上只会有一个日志流的主副本可能存在多个其他日志流的从副本。租户的总日志流个数取决于 Primary Zone 和 Locality 的配置。
日志流使用自研的 Paxos 协议实现了将 Redo 日志在本服务器持久化同时通过网络发送给日志流的从副本从副本在完成各自持久化后应答主副本主副本在确认有多数派副本都持久化成功后确认对应的 Redo 日志持久化成功。从副本利用 Redo 日志的内容实时回放保证自己的状态与主副本一致。
日志流的主副本在被选举成为主后会获得租约Lease正常工作的主副本在租约有效期内会不停的通过选举协议延长租约期。主副本只会在租约有效时执行主的工作租约机制保证了数据库异常处理的能力。
复制层能够自动应对服务器故障保障数据库服务的持续可用。如果出现少于半数的从副本所在服务器故障因为还有多于半数的副本正常工作数据库的服务不受影响。如果主副本所在服务器出现问题其租约会得不到延续待其租约失效后其他从副本会通过选举协议选举出新的主副本并授予新的租约之后即可恢复数据库的服务。
2.3 均衡层
新建表和新增分区时系统会按照均衡原则选择合适的日志流创建 Tablet。当租户的属性发生变更新增了机器资源或者经过长时间使用后Tablet 在各台机器上不再均衡时均衡层通过日志流的分裂和合并操作并在这个过程中配合日志流副本的移动让数据和服务在多个服务器之间再次均衡。
当租户有扩容操作获得更多服务器资源时均衡层会将租户内已有的日志流进行分裂并选择合适数量的 Tablet 一同分裂到新的日志流中再将新日志流迁移到新增的服务器上以充分利用扩容后的资源。当租户有缩容操作时均衡层会把需要缩减的服务器上的日志流迁移到其他服务器上并和其他服务器上已有的日志流进行合并以缩减机器的资源占用。
当数据库长期使用后随着持续创建删除表并且写入更多的数据即使没有服务器资源数量变化原本均衡的情况可能被破坏。最常见的情况是当用户删除了一批表后删除的表可能原本聚集在某一些机器上删除后这些机器上的 Tablet 数量就变少了应该把其他机器的 Tablet 均衡一些到这些少的机器上。均衡层会定期生成均衡计划将 Tablet 多的服务器上日志流分裂出临时日志流并携带需要移动的 Tablet临时日志流迁移到目的服务器后再和目的服务器上的日志流进行合并以达成均衡的效果。
2.4 事务层
事务层保证了单个日志流和多个日志流DML操作提交的原子性也保证了并发事务之间的多版本隔离能力。
原子性
一个日志流上事务的修改即使涉及多个 Tablet通过日志流的 write-ahead log 可以保证事务提交的原子性。事务的修改涉及多个日志流时每个日志流会产生并持久化各自的write-ahead log事务层通过优化的两阶段提交协议来保证事务提交的原子性。
当涉及到多个日志流的事务发起提交时事务会选择其中一个日志流作为两阶段提交的协调者协调者会与事务修改的所有日志流通信判断 write-ahead log 是否持久化当所有日志流都完成持久化后事务进入提交状态协调者会再驱动所有日志流写下这个事务的 Commit 日志表示事务最终的提交状态。当从副本回放或者数据库重启时已经完成提交的事务都会通过 Commit 日志确定各自日志流事务的状态。
宕机重启场景下宕机前还未完成的事务会出现写完 write-ahead log 但是还没有Commit 日志的情况每个日志流的 write-ahead log 都会包含事务的所有日志流列表通过此信息可以重新确定哪个日志流是协调者并恢复协调者的状态再次推进两阶段提交协议直到事务最终的 Commit 或 Abort 状态。
隔离性
GTS 服务是一个租户内产生连续增长的时间戳的服务其通过多副本保证可用性底层机制与上面复制层所描述的日志流副本同步机制是一样的。
每个事务在提交时会从 GTS 获取一个时间戳作为事务的提交版本号并持久化在日志流的write-ahead log 中事务内所有修改的数据都以此提交版本号标记。
每个语句开始时对于 Read Committed 隔离级别或者每个事务开始时对于Repeatable Read 和 Serializable 隔离级别会从 GTS 获取一个时间戳作为语句或事务的读取版本号。在读取数据时会跳过事务版本号比读取版本号大的数据通过这种方式为读取操作提供了统一的全局数据快照。
2.5 SQL 层
SQL 层将用户的 SQL 请求转化成对一个或多个 Tablet 的数据访问。
SQL 层组件 SQL 层处理一个请求的执行流程是Parser、Resolver、Transformer、Optimizer、Code Generator、Executor。
Parser 负责词法/语法解析Parser 会将用户的 SQL 分成一个个的 “Token”并根据预先设定好的语法规则解析整个请求转换成语法树Syntax Tree。
Resolver 负责语义解析将根据数据库元信息将 SQL 请求中的 Token 翻译成对应的对象例如库、表、列、索引等生成的数据结构叫做 Statement Tree。
Transformer 负责逻辑改写根据内部的规则或代价模型将 SQL 改写为与之等价的其他形式并将其提供给后续的优化器做进一步的优化。Transformer 的工作方式是在原Statement Tree 上做等价变换变换的结果仍然是一棵 Statement Tree。
Optimizer优化器为 SQL 请求生成最佳的执行计划需要综合考虑 SQL 请求的语义、对象数据特征、对象物理分布等多方面因素解决访问路径选择、联接顺序选择、联接算法选择、分布式计划生成等问题最终生成执行计划。
Code Generator代码生成器将执行计划转换为可执行的代码但是不做任何优化选择。
Executor执行器启动 SQL 的执行过程。
在标准的 SQL 流程之外SQL 层还有 Plan Cache 能力将历史的执行计划缓存在内存中后续的执行可以反复执行这个计划避免了重复查询优化的过程。配合 Fast-parser 模块仅使用词法分析对文本串直接参数化获取参数化后的文本及常量参数让 SQL 直接命中 Plan Cache加速频繁执行的 SQL。
2.5 多种计划
SQL 层的执行计划分为本地、远程和分布式三种。本地执行计划只访问本服务器的数据。远程执行计划只访问非本地的一台服务器的数据。分布式计划会访问超过一台服务器的数据执行计划会分成多个子计划在多个服务器上执行。
SQL 层并行化执行能力可以将执行计划分解成多个部分由多个执行线程执行通过一定的调度的方式实现执行计划的并行处理。并行化执行可以充分发挥服务器 CPU 和 IO 处理能力缩短单个查询的响应时间。并行查询技术可以用于分布式执行计划也可以用于本地执行计划。
2.6 接入层
OceanBase 数据库代理OceanBase Database ProxyODP是 OceanBase 数据库的接入层负责将用户的请求转发到合适的 OceanBase 实例上进行处理。
ODP 是独立的进程实例独立于 OceanBase 的数据库实例部署。ODP 监听网络端口兼容 MySQL 网络协议支持使用 MySQL 驱动的应用直接连接 OceanBase。
ODP 能够自动发现 OceanBase 集群的数据分布信息对于代理的每一条 SQL 语句会尽可能识别出语句将访问的数据并将语句直接转发到数据所在服务器的 OceanBase 实例。
ODP 有两种部署方式一种是部署在每一个需要访问数据库的应用服务器上另一种是部署在与 OceanBase 相同的机器上。第一种部署方式下应用程序直接连接部署在同一台服务器上的 obproxy所有的请求会由 ODP 发送到合适的 OceanBase 服务器。第二种部署方式下需要使用网络负载均衡服务将多个 ODP 聚合成同一个对应用提供服务的入口地址。
3️⃣ 核心组件与功能概述
基础架特性
OceanBase 是一个分布式数据库系统它采用通用服务器硬件不依赖特定的高性能硬件。它在本地存储数据并通过分布式部署在多个对等的服务器上实现高可用性和可扩展性。OceanBase 遵循 Shared Nothing 架构其 SQL 执行引擎具备分布式执行能力。
核心组件与功能 Observer OceanBase 在每个服务器上运行一个单进程程序称为 observer作为数据库的运行实例。使用本地文件存储数据和事务 Redo 日志。 集群与可用区Zone OceanBase 集群由多个服务器组成配置为不同的可用区。可用区是逻辑概念代表集群内硬件可用性相似的一组节点。 数据副本与一致性 用户数据在集群内部存储多个副本用于故障恢复和读取扩展。副本之间通过共识协议保持数据一致性。 多租户特性 OceanBase 内置多租户支持每个租户表现为一个独立的数据库。租户之间在 CPU、内存和 IO 方面实现隔离。
数据库实例内部组件 存储层以表或分区为单位提供数据存储与访问采用分层存储结构包括 MemTable、L0/L1 SSTable 和 Major SSTable支持数据压缩和编码。 复制层使用日志流LS在多个副本之间同步状态通过 Paxos 协议保证数据一致性能自动处理服务器故障。 均衡层负责数据的均衡分布通过日志流的分裂、合并和迁移操作确保数据和服务在多个服务器之间保持均衡。 事务层保证 DML 操作的原子性和事务之间的多版本隔离能力通过优化的两阶段提交协议和 GTS 服务实现。 SQL 层将 SQL 请求转化为对 Tablet 的数据访问包括解析、语义解析、逻辑改写、优化、代码生成和执行等步骤。 接入层通过 OceanBase 数据库代理ODP实现用户请求的接入和转发支持 MySQL 网络协议能够自动发现数据分布信息。
结语
OceanBase 通过其分布式架构和核心组件的协作提供了高可用、可扩展的数据库服务适用于需要处理大量数据和复杂事务的应用场景。其多租户特性和灵活的部署选项进一步增强了其作为企业级数据库解决方案的吸引力。 听说...关注下面公众号的人都变牛了纯技术纯干货 !
