OceanBase 6大学习法--OBCA视频学习总结第一章

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2730人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6群均已爆满，7群450+即将停止申请，开8群150+ 9群)

一直提到框架学习法，其中主体的思想就是如何快速的学习某项数据库产品的知识。其中框架学习法里面有一条系统学习，系统学习是在给学习的知识搭建“骨架”，所以从这期起，开始搭建OceanBase学习的骨架。今年要和“申公豹”一样修炼岂可怠慢。

这里先解释一下什么是6大学习法，怎么将知识变成一种理念的过程，首先知识的学习是要以兴趣为动力的，没有兴趣去学习是无法提高学习的效率和成效的，在有了兴趣去学习后，那么上来就要上逻辑法，将学习的知识分成小块，也就是我们习以为常的总分总的分，在学习中不断的通过重复记忆，提炼的方法加深记忆，在理解了知识后， 使用庞统法，来将知识和周边的常识进行关联，最后通过费曼学习法将知识铁桶话，最后一步就是将学到的知识进行知行合一，这就是将知识转变为自己常识的知识学习6大法。学习OB的兴趣和动力我有了，下面首先就要上的是逻辑法，和重复记忆法。

https://open.oceanbase.com/course/275  

其中OceanBase的官方视频网站是一个快速学习的好地方，这里将过年最近一段时间观看视频网站的部分的知识进行总结，帮助和我一样的人快速学习OceanBase。

在这将视频学习的总结和大家进行一个沟通和分享，首先这四个视频看完后进行总结和分析，这四个视频主要介绍了

OceanBase 数据库的多种工具、部署方式、以及核心特性，并讨论了其在不同场景下的应用。 具体的内容饱含了如下的内容：

一、 OceanBase 的工具体系:

OBD (OceanBase Deployer): 用于快速部署 OceanBase 数据库，特别是测试和演示环境。它提供了命令行和图形化两种部署模式，以适应不同用户的需求。

OCP (OceanBase Cloud Platform): 用于生产环境的部署和运维管理，提供全生命周期的管理，包括资源管理、监控告警、备份恢复和自动化运维等功能。与 OBD 相比，OCP 的操作都是白屏化的，并且有后台常驻进程进行监控和告警。 注解：白屏化指的是屏幕操作，鼠标点击类的操作方式。

OMS (OceanBase Migration Service): 用于数据迁移和同步，支持将其他异构数据库迁移到 OceanBase，并支持实时数据同步。它还提供数据校验功能，以保证数据的正确性。

ODC (OceanBase Developer Center): 一个开发者工具，类似于 数据库中的GUI软件Navicat，用于数据库开发和管理。它支持 SQL 编辑、数据导入导出、安全审计、变更管控和数据归档等功能。Odc 不仅支持 OceanBase 作为数据源，还支持 MySQL。

好了OB的提供的工具有OBD,OCP,OMS,ODC

二、部署方式

OceanBase 的部署方式:

快速部署: 通过 OBD 可以快速部署 OceanBase 用于测试。

单机部署: OceanBase 可以以单机模式运行，其性能不输于传统的单机数据库。

分布式部署: OceanBase 支持多副本部署，例如三副本和五副本，以保证高可用性和数据一致性。

混合部署: OceanBase 支持单机到分布式的平滑过渡，允许用户根据业务需求选择合适的部署模式

三、OceanBase 的核心特性

高可用: 通过 Paxos 协议保证数据强一致性，并能在少数副本发生故障时自动切换业务流量。

高扩展性: 支持水平扩展，可以动态增加节点和可用区，并进行自动负载均衡。

低成本: 通过 LST 架构和数据压缩技术，显著降低存储成本。

HTAP (Hybrid Transactional/Analytical Processing): 支持在同一系统内同时进行在线事务处理和在线数据分析，并提供多种方式实现读写分离。

高兼容性: 兼容 MySQL 和 Oracle 语法，并提供数据迁移工具。

多租户: 支持在同一集群中创建多个独立的租户，每个租户相当于一个独立的 MySQL 实例，适用于微服务架构和 SaaS 服务商

四、OceanBase的应用场景

替代大规模 MySQL 实例: 适用于大规模 MySQL 实例的场景，通过多租户能力，将多个 MySQL 实例集中到一个或少数几个 OceanBase 集群中。

历史库和归档库: 适合作为历史库和归档库，利用 OceanBase 的高压缩率降低存储成本。

高并发和快速增长业务: 适用于业务压力大、增长快的场景，能够通过分区表和水平扩展来解决数据规模增长的问题

分布式数据架构的演变：

集中式数据库阶段：

早期，大部分企业使用集中式数据库，如 Oracle 和 DB2。

这些数据库的性能和可靠性依赖于特定的高端硬件，如 IBM 小型机和 EMC 高端存储设备。

扩展方式主要为垂直扩展，即提升单机硬件配置，但成本高且扩展性有限。

分布式数据库中间件阶段：

为了解决集中式数据库的扩展性问题，开始出现分布式数据库中间件产品，如 MySQL 中间件和阿里早期的开源中间件 Cobar。

中间件主要解决水平扩展问题，通过连接一批 MySQL 数据库，可以在普通 x86 服务器上运行，降低了对高端硬件的依赖。

但这种架构也带来了一些新问题，如跨库查询和跨库事务的限制，以及数据重分布和迁移的复杂性。

原生分布式数据库阶段：

原生分布式数据库是演变的最终形态，它有原生的 SQL 引擎，支持分布式查询和事务，业务无需关心底层数据分布和事务。

部署模式比中间件架构更灵活，高可用和负载均衡能力也更强。

OceanBase 是原生分布式数据库的一个代表，从 SQL 到存储都是完全自研的。 OceanBase 的发展历程：

1 OceanBase 最初是为了解决淘宝收藏夹业务问题而立项的。

早期版本是一个分布式 KV 存储，2016 年重构后成为原生分布式数据库。

具备自研的 SQL 引擎、存储引擎，支持多副本和高可用。

2 从 2016 年 1.4 版本开始对外商业化，南京银行是第一家外部客户。

后续版本不断增强事务处理能力，并提出了单机分布式一体化的架构。 OceanBase 的特点：

3 单机分布式一体化：

允许用户从单机模式平滑过渡到分布式模式，根据业务需求选择合适的部署模式。单机模式下性能不输传统单机数据库，分布式模式下提供高扩展性。用户无需频繁更换数据库选型，降低了技术栈调整的成本。

OceanBase 数据库的特性

高可用性：

通过 Paxos 一致性协议保证数据强一致性，并能在少数副本发生故障时自动切换业务流量。故障恢复时间小于 8 秒。支持跨机房、跨城市部署。

高扩展性：

支持水平扩展，可以动态增加节点和可用区，进行自动负载均衡。

可以根据业务需求，增加副本数量，提高容灾能力。

HTAP：

支持在同一系统内同时进行在线事务处理（TP）和在线数据分析（AP）。通过弱一致性读和只读副本等方式，实现 TP 和 AP 的读写分离。通过大查询队列限制复杂查询的资源使用，保证 TP 业务的性能。

多租户：

可以在同一集群中创建多个独立的租户，每个租户相当于一个独立的 MySQL 实例。租户之间数据和资源隔离，适用于微服务架构和 SaaS 服务商。

低成本:

通过 LST 架构和数据压缩技术, 显著降低存储成本.

存储成本只有 MySQL 的 1/4 左右. 

总结： 分布式数据库架构从集中式到中间件再到原生分布式，演变的主要目的是解决数据扩展性和可用性的问题。OceanBase 作为原生分布式数据库的代表，不仅具备高可用、高扩展等特性，还通过单机分布式一体化架构、HTAP 能力等提供了更灵活的部署和业务支持，并支持多租户，适合多种业务场景。

OceanBase 发展的几个阶段

1 早期 (2010年之前)：

立项背景：OceanBase 项目的启动是为了解决淘宝的收藏夹业务所面临的问题。当时淘宝收藏夹业务的数据量巨大，实例数量众多，传统的集中式数据库难以满足其需求。

初始形态：早期的 OceanBase 类似于一个分布式键值 (KV) 存储系统。

2 重构时期 (2016年)：

1.0 和 2.0 时代：OceanBase 在 2016 年进行了重构，从分布式 KV 存储转型为原生的分布式数据库。

技术特点：重构后的 OceanBase 具备了完全自研的 SQL 引擎和存储引擎，支持多副本和高可用性。

3 商业化时期 (2016年至今)：

对外商业化：OceanBase 从 1.4 版本开始对外商业化，南京银行是首个外部客户。金融行业切入：初期主要面向金融行业的客户，但随后扩展到其他行业。事务能力增强：3.x 版本在事务处理能力方面得到了显著加强。

4 单机分布式一体化时期 (4.x 版本)：

单机部署能力：OceanBase 提出了单机分布式一体化的架构，使得小规格的机器也可以以单机模式运行，并且性能不逊于传统的单机数据库。

分布式扩展：在分布式部署时，OceanBase 能够提供良好的扩展性，并支持自动负载均衡。 总结：

早期目标：OceanBase 的最初目标是解决淘宝收藏夹业务的大规模数据和高并发问题。

演变路径：从分布式 KV 存储到原生分布式数据库的演变，体现了 OceanBase 不断适应业务需求，提升自身技术能力的过程。

持续发展：OceanBase 不仅提供了高可用、高性能和高扩展性的数据库解决方案，还通过单机分布式一体化架构，为用户提供了更加灵活和便捷的选择。技术创新：自研的 SQL 和存储引擎以及 Paxos 一致性协议是 OceanBase 核心竞争力的体现

OceanBase 的核心特性可以总结为以下几个方面，这些特性使其在分布式数据库领域具有显著优势：

高可用 (High Availability)：

OceanBase 通过 Paxos 一致性协议 来保证数据的强一致性。这意味着在多个副本之间，数据保持同步，确保任何时候读取到的数据都是最新的。

当少数副本发生故障时，集群可以自动将业务流量切换到其他健康的副本上。这种故障切换可以在 8 秒内完成，确保业务的连续性。

OceanBase 支持跨机房、跨城市部署，可以通过两地三中心或三地五中心等部署方式，进一步提升高可用性。即使某个机房发生故障，集群仍能继续提供服务。

高扩展性 (High Scalability)：

OceanBase 支持水平扩展，可以动态地增加节点和可用区。当数据量增加时，可以通过添加新的机器来实现自动负载均衡。

OceanBase 可以通过增加可用区来提高集群的容灾能力。 例如，从三副本扩展到五副本，可以容忍更多的副本故障。

在 TPC-C 测试中，OceanBase 的性能可以随着节点数量的增加而线性扩展。例如，当集群从 3 台机器扩展到 1500 台机器时，每分钟处理的事务数也相应地增加。

低成本 (Low Cost)：

OceanBase 的存储引擎基于 LSM-tree 架构，将数据分为机械数据（只读）和增量数据（可读写）。这种架构使得写入操作首先写入内存，然后批量顺序写入磁盘，提高了写入性能。

OceanBase 使用激进的压缩算法，对数据进行多层次的编码和压缩，包括字典编码、流程编码等。这使得 OceanBase 的存储成本显著降低。

在实际测试中，OceanBase 的存储成本可以达到 MySQL 的 1/4 左右。HTAP (Hybrid Transactional/Analytical Processing):

OceanBase 支持在同一个系统内同时进行在线事务处理 (TP) 和在线数据分析 (AP)。为了实现 TP 和 AP 之间的隔离，OceanBase 提供了多种机制。 用户可以选择使用强一致性读来读取最新的数据进行 TP 操作，或使用弱一致性读来读取副本数据进行 AP 操作。

OceanBase 还支持只读副本，可以将 AP 分析的业务路由到只读副本上，避免影响 TP 业务。OceanBase 会对复杂的大查询进行限制，保证 TP 业务的资源充足。

高兼容性 (High Compatibility)：

OceanBase 在创建租户时，可以选择兼容 MySQL 或 Oracle 模式。社区版目前支持 MySQL 模式。

OceanBase 提供了 OMS (OceanBase Migration Service) 工具，可以将其他异构数据库（如 MySQL、Oracle）平滑迁移到 OceanBase。OceanBase 在语法层面兼容 MySQL 和 Oracle，使得用户可以直接使用兼容的工具和语法。

多租户 (Multi-tenancy)：

在同一个 OceanBase 集群中，可以创建多个独立的租户。每个租户相当于一个独立的 MySQL 实例，可以按需分配资源。租户之间的数据和资源是隔离的，这使得 OceanBase 非常适合微服务架构和 SaaS 服务商。多租户特性可以有效平衡隔离性和成本，使得多个业务租户可以共享同一个集群，而不会互相影响。

单机分布式一体化

OceanBase 支持从单机部署到分布式部署的平滑过渡。用户可以从小规模的单机部署开始，随着业务量的增长，逐步扩展到分布式集群。

这种模式使得用户在整个过程中无需频繁更换数据库选型，降低了技术栈调整的成本。 总结来说，OceanBase 通过这些核心特性，提供了一个高可用、高扩展、低成本且多功能的数据库解决方案，满足了不同业务场景的需求。

OceanBase 的低成本特性主要体现在其存储引擎架构和数据压缩技术上，这些技术共同作用，显著降低了存储成本。具体来说，可以从以下几个方面理解：

LSM-tree 架构：OceanBase 的存储引擎基于 LSM-tree (Log-Structured Merge-Tree) 架构。这种架构将数据分为两部分：

基线数据: 这部分数据是只读的，一旦生成就不会再被修改。

增量数据：这部分数据支持读写，包括插入、更新和删除操作。这些操作首先被写入到内存中的 memtable，当 memtable 达到一定大小时，会批量顺序写入磁盘，形成增量的 SSTable。

顺序写入的优势：相比于一些使用 B+ 树结构的数据库的随机写入，LSM-tree 的顺序写入方式提高了磁盘写入的性能。

数据合并：当增量的 SSTable 达到一定规模时，系统会将增量数据与基线数据合并，生成新的基线数据。这个合并过程通常在业务低峰期进行，如凌晨 2 点。

激进的数据压缩算法：

由于 LSM-tree 架构的基线数据是只读的，OceanBase 可以采用非常激进的压缩算法。

多层次编码压缩：OceanBase 对数据进行多层次的编码和压缩，包括：行切分：将数据按行切分为 16KB 大小的块。列编码：在每个数据块内，按列进行编码压缩，例如使用字典编码和流程编码。列间编码：基于列与列之间的数据关系，进行进一步编码压缩，例如处理等值、差值或子串关系。通用压缩：在列间编码后，还可以使用用户指定的通用压缩算法，如 LZ4 和 ZSTD。

压缩算法优势：这些多层次的压缩算法能有效提升数据压缩率，从而降低存储成本。

压缩比的实际效果：

在 TPC-H 100G 测试场景中，OceanBase 的存储成本约为 MySQL 的 1/4。在其他测试中，OceanBase 的存储成本有时甚至可以达到 MySQL 的 1/10 甚至更低。实际的压缩比可能与表中的列以及数据类型有关.

总结

成本优势明显: 通过使用 LSM-tree 架构、多层次编码和压缩，以及顺序写入等技术，OceanBase 显著降低了存储成本，使得用户能够以更经济的方式存储和管理数据。

实际应用: 从 MySQL 迁移到 OceanBase 的用户，通常可以发现存储空间占用显著减少，从几十 TB 减少到几 TB。 总之，OceanBase 通过其存储引擎的独特设计和激进的数据压缩技术，实现了显著的低成本优势，这使其在与其他数据库的竞争中更具吸引力。

OceanBase 的 HTAP (混合事务/分析处理) 功能允许在同一个系统中同时进行在线事务处理 (TP) 和在线数据分析 (AP)，这通过多种机制实现，以确保 TP 和 AP 工作负载互不干扰。以下是 OceanBase HTAP 的一些关键方面：

TP 和 AP 业务分离：

读写分离: OceanBase 通过多种方式实现读写分离，保证 TP 业务的实时性和数据一致性，同时支持 AP 业务的分析需求.

强一致性读：TP 业务默认使用强一致性读，读取主副本的数据，确保读取到最新的实时数据。

弱一致性读：AP 业务可以选择使用弱一致性读，读取副本数据，从而分散主副本的压力。这种方式适用于对实时性和数据一致性要求不高的 AP 分析业务。

只读副本：OceanBase 支持创建只读副本。只读副本仅用于读取数据，不参与 Paxos 协议的选举，只从主副本同步数据。通过将 AP 业务路由到只读副本，可以进一步隔离 TP 和 AP 业务。

资源隔离:

OceanBase 通过多种方式来隔离 TP 和 AP 业务的资源使用，避免相互影响。

大查询队列：OceanBase 可以识别并管理大查询。当查询的执行时间超过 5 秒（默认值，可配置）时，系统会将其放入大查询队列中。大查询队列中的查询会被限制资源使用，例如，默认情况下只能使用 30% 的资源，从而保证 TP 业务的小查询可以获得足够的资源。

HTAP 的优势：

减少数据延迟：传统的 TP 和 AP 系统通常使用不同的数据库，并通过 ETL 工具进行数据转换。这会导致数据延迟，并增加数据不一致的风险。OceanBase 的 HTAP 功能可以省去 ETL 过程，实现数据的实时分析。

降低成本：HTAP 系统可以避免为 TP 和 AP 分别存储数据，从而节省存储成本。

简化架构：通过在一个系统中处理 TP 和 AP 工作负载，可以简化整个数据处理架构，减少运维复杂性。

OceanBase 的 HTAP 实现方式:

OceanBase 使用同一套 SQL 引擎来满足 TP 和 AP 的业务需求，属于第三种 HTAP 数据库，即 TP 和 AP 能力齐头并进。

不同副本类型: OceanBase 提供全功能副本和只读副本。全功能副本既可以读写，又可以参与 Paxos 协议的选举。只读副本只能读取数据，且不参与选举，仅用于 AP 分析。

关于数据一致性:

使用弱一致性读或只读副本进行 AP 分析时，可能无法保证读取到最新的数据，但数据的一致性仍然很高。即使是使用主备库进行读写分离，AP 业务的延迟也可以控制在秒级。

未来发展

OceanBase 还在不断发展 HTAP 能力， 例如，即将发布的 4.3 版本将支持列存，这将进一步提升 AP 分析的性能，并且提供更多读写分离的方案。 总而言之，OceanBase 的 HTAP 功能通过精巧的资源隔离、灵活的读取策略以及统一的架构，实现了在同一个系统中高效运行 TP 和 AP 工作负载。这不仅降低了成本和复杂性，还提高了数据分析的实时性，满足了现代业务的需求。

OceanBase 的多租户和兼容性是其关键特性，使其在各种业务场景中具有显著优势。以下是对这两个特性的详细解释： 多租户 (Multi-tenancy):

定义: 在同一个 OceanBase 集群中，可以创建多个独立的租户。每个租户相当于一个独立的 MySQL 实例，可以按需分配资源。

资源隔离: 租户之间的数据和资源是隔离的。这意味着每个租户都有自己独立的 CPU、内存和 IO 资源，从而避免了租户之间的互相影响。

按需分配: 租户的资源可以根据需要进行动态调整。如果集群有剩余资源，可以随时创建新的租户。如果某个租户的资源使用量减少，可以将其资源收回。

快速部署: 相比传统数据库，在 OceanBase 中创建新租户非常快速。传统数据库可能需要一两天来准备新的数据库实例，而 OceanBase 只需要几分钟即可完成。

微服务架构适用: 多租户特性非常适合微服务架构和 SaaS 服务提供商。多个业务租户可以共享同一个集群，从而平衡了隔离性和成本。

规模化运维: 通过多租户功能，可以将大量的 MySQL 实例集中到少数几个 OceanBase 集群中，大大简化了运维管理。

独立扩缩容: 每个租户可以独立进行扩容或缩容，增加了灵活性。 兼容性 (Compatibility):

多模式支持: OceanBase 在创建租户时，可以选择兼容 MySQL 或 Oracle 模式。社区版目前只支持 MySQL 模式。

平滑迁移: OceanBase 提供了 OMS (OceanBase Migration Service) 工具，可以将其他异构数据库（如 MySQL、Oracle、TIDB 等）平滑迁移到 OceanBase。

语法兼容: OceanBase 在语法层面兼容 MySQL 和 Oracle，使得用户可以直接使用兼容的工具和语法。

工具兼容: OceanBase 的 MySQL 模式租户可以像使用 MySQL 一样，直接使用如 Navicat、DBVisualizer 等 MySQL 周边工具。

底层引擎: 尽管在语法层面兼容 MySQL 和 Oracle，OceanBase 的底层 SQL 引擎和存储引擎都是完全自研的。这意味着用户可以利用 OceanBase 的所有核心特性，而不受限于兼容模式的限制。

开源: OceanBase 的内核是开源的，社区版也提供了平台工具的二进制文件供下载使用. \

总结: OceanBase 的多租户特性使其能够在一个集群内管理多个独立的数据库实例，并通过资源隔离保证了各租户之间的稳定性。兼容性特性则允许用户平滑地将现有数据库迁移到 OceanBase，并继续使用熟悉的工具和语法。这两个特性结合，使得 OceanBase 在各种业务场景中具有高度的灵活性和实用性，尤其是在微服务架构、SaaS 服务提供商以及需要大规模数据库管理的企业中。

OceanBase 社区版主要适用于以下几种业务场景，这些场景利用了 OceanBase 的多租户、高兼容性、高可用性和低成本等核心特性：

大规模 MySQL 实例管理：

问题: 许多企业拥有大量的 MySQL 实例，导致运维复杂且成本高昂。MySQL 主从架构在故障切换时可能出现数据不一致的情况，增加了运维难度。

解决方案: OceanBase 可以将大量的 MySQL 实例集中到少数几个 OceanBase 集群中，利用其多租户特性，每个 MySQL 实例对应一个 OceanBase 租户。这样可以简化运维，提高资源利用率。

蚂蚁集团的实践: 蚂蚁集团内部有上万台服务器使用 OceanBase，通过多租户能力，每个 MySQL 实例都有一个租户，从而解决了大规模 MySQL 实例的管理难题。

历史库和归档库：

问题: 云上 ECS 自建的 MySQL 实例通常使用云盘，存在容量上限。历史库和归档库的数据量大，对存储成本敏感。

解决方案: 将历史库和归档库迁移到 OceanBase，可以利用 OceanBase 的高数据压缩率和低存储成本的优势。OceanBase 的存储成本约为 MySQL 的 1/4，某些情况下甚至可以达到 1/10 或更低。

成本优势: 迁移到 OceanBase 后，原先几十 TB 的数据可能只需要几 TB 的存储空间.

业务量增长快、变化大的场景:

问题: 业务量增长快、变化大的场景（如大促活动）通常使用基于 MySQL 改造的分布式数据库中间件，需要 DBA 人工拆库拆表，运维成本高，且引入了额外的中间件，增加了使用风险。分库分表对事务和 SQL 也存在限制，跨库查询性能受影响.

解决方案: OceanBase 的分区表可以解决这个问题，避免人工拆库拆表，降低运维成本。OceanBase 的水平扩展能力可以支持业务量的快速增长，并且可以通过弱一致性读或只读副本实现读写分离，来应对复杂的查询场景。

HTAP 场景:

方案: 虽然没有明确指出社区版在HTAP方面的应用，但OceanBase的HTAP能力允许在同一系统中进行在线事务处理 (TP) 和在线数据分析 (AP)。社区版可以通过弱一致性读或只读副本实现读写分离，将 AP 查询路由到副本节点，从而分散主节点的压力。此外，OceanBase 还会通过大查询队列来限制复杂查询的资源使用，从而保障TP业务的正常运行。

开源生态:

开放的工具: OceanBase 不仅开源了数据库内核，还提供了配套的平台工具 (如 OCP, OMS, ODC) 的社区版，并开放了二进制文件供用户下载使用.

社区支持: 用户可以在社区论坛或技术答疑群获得支持. 总而言之，OceanBase 社区版适用于需要管理大量 MySQL 实例、降低存储成本、应对高并发和快速变化业务的场景，并且提供了完整的开源工具链和社区支持，使得用户可以以较低的成本享受到高性能、高可用的数据库服务。这些特性也使得 OceanBase 成为开源数据库领域一个有竞争力的选择。