1.实战教程第一章：OceanBase 数据库概述
2.MySQL 核心模块揭秘 | 12 期 | 创建 savepoint
3.工具Datax的基本概念（初识ETL工具）
4.OceanBase-4.0社区源码-内存篇以及C++知识扩展（OB代码-》/lib/alloc相关）-上篇
5.国产的数据库软件有那些
6.企业如何实践开源协同
实战教程第一章：OceanBase 数据库概述
OceanBase 是由阿里巴巴和蚂蚁集团自主研发的一款分布式关系型数据库，它基于通用服务器集群，使用Paxos协议和分布式架构，具有高可用、线性扩展、高性能和低成本等核心技术优势。c ssdt hook源码
OceanBase 集群支持跨机房跨城市的部署，并在故障时，内部多副本自动切换，不丢失数据，天然适合异地容灾和多活建设。
在 OceanBase 社区版中，您可以免费复制和使用源代码，但需遵守 MulanPubL - 2.0 许可证。 OceanBase 社区版官方网站为 open.oceanbase.com，支持的操作系统包括但不限于 Linux、macOS 和 Windows。
相比于 MySQL，OceanBase 社区版在存储空间压缩效果上更出色，甚至可以达到 MySQL 空间大小的四分之一。OceanBase 提供了多租户支持，每个租户可按需分配资源，具有高可用能力，易于维护。
OceanBase 提供了强大的 SQL 引擎能力，支持 SQL 解析和执行计划缓存，复杂 SQL 运算，大纲技术干预 SQL 执行计划等，同时一套 SQL 引擎可以同时支持 OLTP 和 ROLAP 类型的混合场景需求。OceanBase 集群支持水平拆分技术，无需分库分表，SQL 和事务对业务完全透明，功能上没有限制。
在 OceanBase 社区版中，包含 OceanBase 企业版的所有核心功能，例如多租户、高可用和强一致能力，以及自动化运维平台，可以解决 MySQL 在高可用和强一致问题上的痛点。
对于业务访问压力大、数据量增长和查询性能下降等问题，OceanBase MySQL 租户提供分区表的水平拆分方案，提供原生的 SQL 和事务能力，对业务透明，同时支持在线扩容和缩容，内部数据迁移异步进行，具备高可用能力。
在 OceanBase 数据库上进行复杂查询时，useradmin源码可以减少不必要的数据同步，同时提供不同程度的读写分离技术来控制复杂查询对交易场景的影响。
OceanBase 社区版适合业务规模大、自动化运维需求高、数据量增长和查询性能下降以及需要原生 SQL 和事务能力的场景。
如果您在使用 OceanBase 时遇到任何问题，欢迎与我们联系，我们将为您提供支持。
MySQL 核心模块揭秘 | 期 | 创建 savepoint
回滚操作，除了回滚整个事务，还可以部分回滚。部分回滚，需要保存点（savepoint）的协助。本文我们先看看保存点里面都有什么。
作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 MySQL 和 OceanBase 源码。 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源
本文基于 MySQL 8.0. 源码，存储引擎为 InnoDB。
InnoDB 的事务对象有一个名为undo_no 的属性。事务每次改变（插入、更新、删除）某个表的一条记录，都会产生一条 undo 日志。这条 undo 日志中会存储它自己的序号。这个序号就来源于事务对象的 undo_no 属性。
也就是说，事务对象的 undo_no 属性中保存着事务改变（插入、更新、删除）某个表中下一条记录产生的 undo 日志的序号。
每个事务都维护着各自独立的 undo 日志序号，和其它事务无关。
每个事务的 undo 日志序号都从 0 开始。事务产生的第 1 条 undo 日志的序号为 0，第 2 条 undo 日志的序号为 1，依此类推。
InnoDB 的 savepoint 结构中会保存创建 savepoint 时事务对象的 undo_no 属性值。
我们通过 SQL 语句创建一个 savepoint 时，server 层、binlog、InnoDB 会各自创建用于保存 savepoint 信息的结构。
server 层的 savepoint 结构是一个SAVEPOINT 类型的对象，主要属性如下：
binlog 的 savepoint 结构很简单，是cocod源码一个 8 字节的整数。这个整数的值，是创建 savepoint 时事务已经产生的 binlog 日志的字节数，也是接下来新产生的 binlog 日志写入 trx_cache 的 offset。
为了方便介绍，我们把这个整数值称为binlog offset。
InnoDB 的 savepoint 结构是一个trx_named_savept_t 类型的对象，主要属性如下：
创建 savepoint 时，server 层会分配一块 字节的内存，除了存放它自己的 SAVEPOINT 对象，还会存放 binlog offset 和 InnoDB 的 trx_named_savept_t 对象。
server 层的 SAVEPOINT 对象占用这块内存的前 字节，InnoDB 的 trx_named_savept_t 对象占用中间的 字节，binlog offset 占用最后的 8 字节。
客户端连接到 MySQL 之后，MySQL 会分配一个专门用于该连接的用户线程。
用户线程中有一个m_savepoints 链表，用户创建的多个 savepoint 通过 prev 属性形成链表，m_savepoints 就指向最新创建的 savepoint。
server 层创建 savepoint 之前，会按照创建时间从新到老，逐个查看链表中是否存在和本次创建的 savepoint 同名的 savepoint。
如果在用户线程的 m_savepoints 链表中找到了和本次创建的 savepoint 同名的 savepoint，需要先删除 m_savepoints 链表中的同名 savepoint。
找到的同名 savepoint，是 server 层的SAVEPOINT 对象，它后面的内存区域分别保存着 InnoDB 的 trx_named_savept_t 对象、binlog offset。
binlog 是个老实孩子，乖乖的把 binlog offset 写入了 server 层为它分配的内存里。删除同名 savepoint 时，不需要单独处理 binlog offset。
InnoDB 就不老实了，虽然 server 层也为 InnoDB 的 trx_named_savept_t 对象分配了内存，但是 InnoDB 并没有往里面写入内容。
事务执行过程中，用户每次创建一个 savepoint，InnoDB 都会创建一个对应的 trx_named_savept_t 对象，并加入 InnoDB 事务对象的 trx_savepoints 链表的末尾。
因为 InnoDB 自己维护了一个存放 savepoint 结构的链表，server 层删除同名 savepoint 时，InnoDB 需要找到这个链表中对应的 savepoint 结构并删除，流程如下：
InnoDB 从事务对象的 trx_savepoints 链表中删除 trx_named_savept_t 对象之后，server 层接着从用户线程的 m_savepoints 链表中删除 server 层的SAVEPOINT 对象，也就连带着清理了 binlog offset。
处理完查找、删除同名 savepoint 之后，server 层就正式开始创建 savepoint 了，edger 源码这个过程分为 3 步。
第 1 步，binlog 会生成一个 Query_log_event。
以创建名为test_savept 的 savepoint 为例，这个 event 的内容如下：
binlog event 写入 trx_cache 之后，binlog offset 会写入 server 层为它分配的 8 字节的内存中。
第 2 步，InnoDB 创建 trx_named_savept_t 对象，并放入事务对象的 trx_savepoints 链表的末尾。
trx_named_savept_t 对象的 name 属性值是 InnoDB 的 savepoint 名字。这个名字是根据 server 层为 InnoDB 的 trx_named_savept_t 对象分配的内存的地址计算得到的。
trx_named_savept_t 对象的savept 属性，是一个 trx_savept_t 类型的对象。这个对象里保存着创建 savepoint 时，事务对象中 undo_no 属性的值，也就是下一条 undo 日志的序号。
第 3 步，把 server 层的 SAVEPOINT 对象加入用户线程的 m_savepoints 链表的尾部。
server 层会创建一个SAVEPOINT 对象，用于存放 savepoint 信息。
binlog 会把binlog offset 写入 server 层为它分配的一块 8 字节的内存里。
InnoDB 会维护自己的 savepoint 链表，里面保存着trx_named_savept_t 对象。
如果 m_savepoints 链表中存在和本次创建的 savepoint 同名的 savepoint， 创建新的 savepoint 之前，server 层会从链表中删除这个同名的 savepoint。
server 层创建的 SAVEPOINT 对象会放入m_savepoints 链表的末尾。
InnoDB 创建的 trx_named_savept_t 对象会放入事务对象的trx_savepoints 链表的末尾。
工具Datax的基本概念（初识ETL工具）
ETL技术的实质是将数据经过抽取、清洗转换之后加载到数据仓库的过程。DataX是由阿里巴巴研发并开源的异构数据源离线同步工具，能实现不同数据源之间的数据同步，包括关系型数据库、NoSQL数据存储、无结构化数据存储、时间序列数据库以及阿里的云数仓数据存储。DataX是阿里云DataWorks数据集成的开源版本，用于在阿里巴巴集团内广泛使用的离线数据同步工具/平台，支持包括MySQL、Oracle、OceanBase、SqlServer、Postgre、HDFS、Hive、ADS、HBase、drc源码TableStore(OTS)、MaxCompute(ODPS)、Hologres、DRDS等各种异构数据源之间的高效数据同步。
DataX采用Framework + plugin的架构，数据同步步骤将数据的读取、写入操作抽象为由Reader/Writer插件处理，纳入整个同步框架。其核心组件包括Job、Task、Channel以及Transformer。
Job代表数据同步任务；Task代表运行一个单独的同步线程，该线程使用一个Channel作为Reader与Writer的数据传输媒介；数据流转方向为Reader—>Channel—>Writer。
Transformer模式提供强大的数据转换功能，DataX内置丰富数据转换实现类，用户可根据自身需求扩展数据转换。
DataX的安装部署可选择直接下载工具包或下载源码自主编译。下载后解压至本地目录即可运行同步作业。自检脚本为：python { YOUR_DATAX_HOME}/bin/datax.py { YOUR_DATAX_HOME}/job/job.json。
若数据源同步遇到格式不匹配问题，可以修改相应的reader与writer代码，然后maven编译，后续会提供具体源码修改示例。
DataX的源码可在gitee上找到，以解决github地址在国内可能存在的连接问题。参考网址提供了更多关于ETL工具-Datax的资源。
OceanBase-4.0社区源码-内存篇以及C++知识扩展（OB代码-》/lib/alloc相关）-上篇
OceanBase-4.0社区源码的内存篇深入探讨了内存池及其在C++中的实现，特别是关注`/lib/alloc`相关部分。内存池的核心在于减少内存碎片，通过预先申请大块内存并分割使用，以降低频繁小块内存申请导致的内存管理问题。
内存池的实现主要包括提前申请大内存，将其分割为小块供程序使用，使用完毕后不立即释放，而是循环使用。C++中的`malloc()`、`calloc()`和`realloc()`函数各有特点：`malloc()`用于动态内存分配，`calloc()`分配内存并初始化为零，`realloc()`则用于调整已分配内存大小。这些函数在使用时需要注意内存泄漏问题，尤其是`realloc()`，尽管能减少内存申请次数，但也可能带来数据移动和潜在风险。
OceanBase的源码分析着重于`ob_malloc.cpp`，这个文件负责内存分配和释放，通过`ObTenantCtxAllocatorGuard`和`ABlock`来管理内存。`abit_set.cpp`和`abit_set.h`用于位图管理，标记已分配内存，而`alloc_assist.cpp`和`alloc_assist.h`提供内存分配和管理的辅助函数。`alloc_failed_reason`定义了内存分配失败的原因，如`VmRSS`、`VmHWM`等与进程内存使用的指标。
源码中还涉及了访问结构体成员的高效方式，使用箭头操作符和线程局部存储（RLOCAL）的概念。`alloc_func.cpp`和`alloc_func.h`进一步实现了内存分配相关的函数，展示了OceanBase中回调函数和extern "C"、nodiscard等C++特性在内存管理中的应用。
总的来说，上篇内容为理解OceanBase内存管理机制提供了基础，下篇将深入分析更多细节和调用逻辑，以及与C++技术的结合点。通过阅读，你将对内存池的实现和OceanBase的内存管理有更深入的认识。
国产的数据库软件有那些
一、DM软件名称：达梦数据库（DM）。
开发商：武汉华工达梦数据库有限公司。
软件描述：
达梦数据库具有如下技术特色：支持多个平台之间的互联互访、高效的并发控制机制、有效的查询优化策略、灵活的系统配置、支持各种故障恢复并提供多种备份和还原方式。
具有高可靠性、支持多种多媒体数据类型、提供全文检索功能、各种管理工具简单易用、各种客户端编程接口都符合国际通用标准、用户文档齐全。
二、OpenBASE
软件名称：OpenBASE。
开发商：东软集团有限公司。
软件描述：
主要包括OpenBASE 多媒体数据库管理系统、OpenBASE Web应用服务器、OpenBASE Mini嵌入式数据库管理系统、OpenBASE Secure安全数据库系统等产品。
所有的这些产品涵盖了企业应用、Internet/Intranet、移动计算等不同的应用领域，具有不同的应用模式。
形成了OpenBASE面向各种应用的全面的解决方案。多媒体数据库管理系统OpenBASE是OpenBASE产品系列的核心和基础，其它的产品都是在其基础上，根据各自应用领域的不同特点发展、演变而成的。
三、OSCAR
软件名称：神舟OSCAR数据库系统。
开发商：北京神舟航天软件技术有限公司。
软件描述：
神舟OSCAR数据库系统基于Client/Server架构实现，服务器具有通常数据库管理系统的一切常见功能，此外还包括一些有助于提高系统对工程数据支持的特别功能，而客户端则在提供了各种通用的应用开发接口的基础上，还具有丰富的连接、操作和配置服务器端的能力。
提供与Oracle、SQL Server、DB 2等主要大型商用数据库管理系统以及TXT、ODBC等标准格式之间的数据迁移工具。
四、KingbaseES
软件名称：金仓数据库管理系统KingbaseES。
开发商：北京人大金仓信息技术有限公司。
软件描述：
交互式工具ISQL；图形化的数据转换工具； 多种方式的数据备份与恢复； 提供作业调度工具；方便的用户管理；支持事务处理；支持各种数据类型；提供各种操作函数；提供完整性约束；支持视图；支持存储过程/函数；支持触发器。
五、iBASE
软件名称：iBASE。
开发商：北京国信贝斯软件有限公司。
软件描述：
包括五个部分：iBASE Reliax Server全文检索服务器。
iBASE Web网上资源管理与发布系统。
iBASE Index System文文件管理与发布系统。
iBASE Webrobot 网络资源采编发系统。
iBASE DMC 数据库管理中心。
扩展资料：
国产最新商业数据库系统：
一、阿里的数据库系统
软件名称：OceanBase & PolarDB
官方称为“完全自主研发的金融级分布式关系数据库”。下面是其官网的介绍：OceanBase 对传统的关系数据库进行了开创性的革新。
在普通硬件上实现金融级高可用，在金融行业首创“三地五中心”城市级故障自动无损容灾新标准，同时具备在线水平扩展能力，创造了万次/秒处理峰值的纪录（注：当时TPS官宣为.6w）。
现在OceanBase的版本已经2.x了，OceanBase TPC-C的评测刷遍了朋友圈，TPS达到了w (w tpmc)，榜单第一。
二、腾讯的数据库系统
软件名称：TDSQL
其官网简介：分布式数据库（Tencent Distributed SQL，TDSQL）是腾讯打造的一款分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性。
同时提供智能 DBA、自动化运营、监控告警等配套设施，为用户提供完整的分布式数据库解决方案。
目前 TDSQL 已经为超过+的政企和金融机构提供数据库的公有云及私有云服务，客户覆盖银行、保险、证券、互联网金融、计费、第三方支付、物联网、互联网+、政务等领域。TDSQL 亦凭借其高质量的产品及服务，获得了多项国际和国家认证，得到了客户及行业的一致认可。
三、华为的数据库系统
软件名称：GaussDB
全球首款AI-Native数据库，内部有、、多个版本，应该是基于PostgreSQL开发的。在国内，可能除了阿里，就到华为的团队了（高斯实验室）。和不少高校建立了合作。
企业如何实践开源协同
企业实践开源协同的关键在于共享工作流，确保所有贡献者基于同一核心流程工作。对于企业内部项目开放源代码，若不考虑共享工作流，则外部贡献者难以有效参与。以OceanBase项目为例，其在GitHub和Gitee平台同时托管，却缺乏统一工作流，导致外部贡献者只能处理简单的补丁问题，无法更深入参与。这种情况下，企业内部活动与开源平台活动分离，形成内外两套工作流，难以形成真正的开源共同体。
而以Apache InLong项目为参考，其在明确开源协同目标后，对工作流进行融合，将问题报告、补丁提交和版本发布流程统一，内部需求也基于共享工作流构建。这样不仅减少了内部与开源平台之间的沟通损耗，还提高了软件工程效率。
TiDB项目展示了开源协同中设计文档的重要性。项目早期设计文档的缺失导致了功能设计的内部封闭讨论，而缺乏公开讨论。在成立公司后，虽然设计文档有所恢复，但依然存在内部决策直接在开源平台上线的情况，缺乏与社区成员的同步。通过改进工作流，明确设计文档的公开讨论，以及关注持续集成的改进，TiDB项目逐渐增强了与开源社区的互动。
Taichi项目则提供了开源协同在不同背景参与者中的实践案例。随着项目发展，虽然缺乏背景信息的情况有所改善，但仍需关注保持开源协同的核心价值，即公开讨论与贡献。通过招募不同背景的参与者，鼓励在GitHub平台上的开放交流，Taichi项目能够吸引并整合来自全球的贡献者。
寻找不同背景的参与者是企业实践开源协同的另一个关键。用户群体并不总是能提供大规模的核心贡献者，企业应更积极地寻找具备技术深度的开发者，同时寻找能够与开源项目整合形成用户解决方案的开发者。项目的核心逻辑与扩展机制是吸引这些参与者的关键，通过设计丰富的扩展点和策略替换机制，企业可以吸引到关注生态互连的贡献者。
总之，企业实践开源协同需要关注共享工作流的建立、设计文档的公开讨论、不同背景参与者招募以及项目核心逻辑的开放性。通过这些策略，企业可以有效参与到开源共同体中，促进项目的可持续发展和创新。
MySQL 核心模块揭秘 | 期 | 回滚到 savepoint
深入理解 MySQL，了解如何实现部分回滚操作。本文由技术专家操盛春撰写，他在公众号『一树一溪』分享 MySQL 和 OceanBase 源码研究。本文基于 MySQL 8.0.，InnoDB 存储引擎，探讨核心模块的工作原理。
首先，我们创建测试表并插入数据。关键操作分为四个阶段，编号为 SQL 1 至 SQL 4，其中 SQL 4 是讨论焦点。SQL 2 和 SQL 3 分别产生 undo 日志 0 和 1。
当执行事务时，产生的 binlog 日志在 trx cache 中。回滚整个事务时，需要清除这些日志。然而，实际操作中，binlog 回滚步骤看似简单，却并未执行真正清除，只是为后续的 InnoDB 回滚做准备。
InnoDB 回滚是关键环节，它会根据 undo 日志执行反向操作，恢复事务影响的数据。以 SQL 为例，会从最新的 undo 日志开始回滚，逐条执行反向操作，包括记录的删除。
回滚后，事务的执行状态需要通过提交事务来更新。这不同于 commit 语句，因为回滚操作已经改变了数据，即使从逻辑上看恢复了原样，也需要将 InnoDB 中的修改正式提交。
trx cache 中的 binlog 日志会在 InnoDB 回滚完成后进行清除，这个过程涉及内存 buffer 和磁盘临时文件。binlog 回滚步骤延迟到这个阶段，是因为在事务提交前，binlog 日志并不需要写入持久化存储。
总结起来，MySQL 的部分回滚包括：无实际动作的 binlog 回滚，执行 InnoDB 回滚恢复数据，然后提交 InnoDB 事务，最后清理 trx cache 中的临时 binlog。如果你对文中内容有疑问，欢迎留言交流。
对于 SQL 质量管理，如需更多工具支持，可以了解 SQLE，一个覆盖开发到生产环境的 SQL 管理平台，提供流程自动化和数据质量管理功能。
