在线甘特图|横道图|项目管理|计划管理 zz-plan
人员、任务、进度、工时、周期、依赖关系 一目了然。无论项目大小、简单复杂都能轻松管理
PolarDB MySQL · PolarTrans事务系统介绍(一)
原生事务系统
MySQL原生事务系统是基于活跃事务列表来实现的, 该方案在高并发场景下会带来较为严重的性能瓶颈, 无法充分利用CPU多核心并发处理事务逻辑; 其次, 基于活跃事务列表方案在集群一致性读, 集群多点写入, 以及Share-Nothing架构中的分布式事务管理上存在天然的缺陷.
trx_sys->mutex热点问题
MySQL原生的基于活跃事务列表的维护开销较大, 这体现在事务流程的多个方面, 比如读写事务启动, 提交, 活跃事务查询, readvi
源码分析 · InnoDB Redo Log 重构
背景介绍
Redo Log 是 MySQL InnoDB 引擎中的 WAL，所有的数据修改都需要通过 Redo Log 进行保护，当 MySQL 发生异常重启时，需要通过 Redo Log 来恢复数据，这也是 MySQL 数据库实现 ACID 中 D(durability) 的基本保障。长期以来，MySQL InnoDB 中的 Redo Log 采用了循环覆盖写的结构，以社区默认配置为例，MySQL 在启动时会默认创建两个日志文件：ib_logfile0 和 ib_logfi
PolarDB MySQL · 多主架构 · 全局 Binlog 介绍
背景介绍
PolarDB MySQL多主架构集群版包含多个RW计算节点，支持不同数据库在不同计算节点并发写入，支持最多32个节点同时写入，且支持数据库跨节点动态调度、秒级完成切换。
这些特性给PolarDB MySQL多主架构的binlog带来了新的挑战：
每个RW计算节点写入自己的binlog文件。
用户可以对某个db的写入进行切换，即从一个RW节点切换到另一个RW节点。
这就导致了没有一份全局的binlog呈现给用户，且多个RW节点上的binlog可能逻
MySQL · 源码分析 · innodb-BLOB演进与实现
BLOB 介绍
InnoDB 存储引擎中所有可变长度类型的字段（如 VARCHAR、VARBINARY、BLOB 和 TEXT）可以存储在主键记录内，也可以存储在主键记录之外的单独 BLOB 页中（在同一表空间内）。所有这些字段都可以归类为大对象。这些大对象要么是二进制大对象，要么是字符大对象。二进制大对象没有关联的字符集，而字符大对象有。在 InnoDB 存储引擎中，字符大对象和二进制大对象的处理方式没有区别，我们使用“BLOB”来指代上述的大对象字段。BLOB不同大小，不
MySQL · 源码分析 · innodb 空间索引实现
innodb空间索引介绍
innodb支持空间索引，但很少有关于innodb关于空间索引的实现的介绍文章，本篇文章主要目的是介绍innodb关于空间索引的源码介绍，知其所以然。空间索引本质上是二级索引中的一种，基于R树实现。
innodb索引主要是基于B+树实现，B+树是一棵平衡树，是把一维直线分为若干段线段，当我们查找满足某个要求的点的时候，只要去查找它所属的线段即可。这种思想其实就是先找一个大的空间，再逐步缩小所要查找的空间，最终在一个自己设定的最小不可分空间内找出满足
PolarDB MySQL · 引擎特性 · 内核原生的全局索引支持
前言（分区的价值和问题）
不管是Oracle等传统数据库，还是近年来涌现的分布式数据库，分区/分表作为重要的企业级数据库特性，被广泛应用在不同行业的业务场景中。简单来说，分区是将逻辑数据库（例如表、表空间）划分为不同的独立部分，分而治之，从而提高可管理性、整体性能或者负载均衡的效果。例如，Oracle等数据库通过分区，支持更灵活轻量的冷热数据分区管理，达到降本增效的能力。例如，分布式数据库通过分区，将数据均匀打散到多个节点上，获取更好的水平扩展能力。
MySQL作为最流行的
MySQL · 行业洞察 · 长路漫漫, 从Blink-tree 到Bw-tree (上)
天不生我 bw-tree, 索引万古如长夜
背景
在前面的文章 路在脚下, 从BTree 到Polar Index中提到, 我们已经将InnoDB 里面Btree 替换成Blink Tree, 高并发压力下, 在标准的TPCC 场景中最高能够有239%的性能提升, 然后我们对InnoDB 的file space模块也进行了优化, 在分配新page 的时候, 可以允许不进行填0 操作, 从而尽可能的减少fsp->mutex 的开销, 在这之后我们发现瓶颈卡在了pa
PolarDB MySQL·HTAP·浅析IMCI的列存数据压缩
前言
数据库迁移上云是大数据时代的一大趋势，PolarDB MySQL是阿里云自研的云原生数据库，主要处理在线事务负载(OLTP, OnLine Transactional Processing)，深受企业用户的青睐。当下，数据分析对于企业的重要性越发显著：企业使用数据驱动决策，利用分析结果精准调配资源，从而降低成本，提升企业效率，推动业务创新，快速适应外部环境的变化。然而，传统数仓架构的滞后性限制了企业的创新步伐。因此，企业对OLTP数据库提出更高的要求，希望能在OLTP数
PostgreSQL · 插件特性 · FDW 异步执行特性
Foreign Data Wrapper（FDW）是 PostgreSQL 提供的一个非常有意思的特性，中文翻译为 外部数据包装器。从字面意思上，PostgreSQL 数据库能够通过 FDW 扩展来操作当前数据库以外的数据。这些外部的数据源可以是：
文件
关系型数据库（PostgreSQL / Oracle / MySQL / …）
非关系型数据库
Git 仓库
网页
大数据平台（Hadoop / Hive / …）
…（尽情遐想）😏
Po
PolarDB Serverless之路 · 无感秒切
背景介绍
PolarDB的架构优势
PolarDB是阿里云自主研发的云原生关系型数据库，借助物理复制、RDMA高速网络和分布式存储等技术，实现了存储计算分离架构。相比开源的MySQL，新架构在快速弹性和高可用场景下为PolarDB带来了很多优势，并长期被客户认可：
PolarDB支持一写多读，集群内的多个节点共享同一份数据，增减只读节点无需搬迁数据，速度快效率高；
当PolarDB执行升降配切换（Switchover）或主节点故障容灾（Failover）时，基于