http://baotiao.github.io
很多时候业务架构设计里面最重要的一环就是数据库模型设计。由于单机MySQL 的限制, 很多业务架构师不得不考虑对大表进行拆分, 通过中间件或者其他手段进行分库分表。本文
unique secondary index 是客户经常使用的场景,用来保证index 上的record 的唯一性。但是大量的客户在使用unique secondary index以后,会发现偶尔会有死锁或者不应该锁等待的时候,却发生锁等待的情况。也有很多客户来问我们这个问题。理论上PolarDB ...
游戏行业痛点在我看来,不同行业对数据库使用有巨大的差别。比如游戏行业没有复杂的事务交易场景,他有一个非常大的blob 字段用于存储角色的装备信息,那么大Blob 字段的更新就会成为数据库的瓶颈;比如在线教育行业需要有抢课的需求,因此会有热点行更新的场景,对热点行如何处理会成为数据库的瓶颈;比如Saa...
我们分析了云存储的性能特征,将它们与本地SSD存储进行了比较,总结了它们对B-tree和LSM-tree类数据库存储引擎设计的影响,并推导出了一个框架CloudJump来指导本地存储引擎迁移到云存储的适配和优化。 并通过PolarDB, RocksDB 两个具体Case 展示优化带来的收益。
目前在系统里面, 我们可以通过perf 或者 pt-pmp 汇总堆栈的方式来查看系统存在的热点, 但是我们仅仅能够知道哪些地方是热点, 却无法定量的说这个热点到底有多热, 这个热点占整个访问请求的百分比是多少? 是10%, 还是40%, 还是80%?所以我们需要一个定量分析系统瓶颈的方法以便于我们进...
在前面的文章 路在脚下, 从BTree 到Polar Index中提到, 我们已经将InnoDB 里面Btree 替换成Blink Tree, 高并发压力下, 在标准的TPCC 场景中最高能够有239%的性能提升, 然后我们对InnoDB 的file space模块也进行了优化, 在分配新pag...
### MySQL Replace into issue MySQL 并发 Replace into 引起死锁问题 在之前的文章 [#issue 68021 MySQL unique check 问题](https://zhuanlan.zhihu.com/p/503880736)中, 我们已经介绍了在 MySQL 里面, 由于唯一键的检查(unique check), 导致 MySQ
PolarDB 目前物理复制到了ro 开始刷120s apply_lsn 不推进的信息以后, 即使压力停下来也无法恢复, 为什么? 如下图所示: ![image-20230410025547807](https://raw.githubusercontent.com/baotiao/bb/main/uPic/image-20230410025547807.png)
在数据库的使用场景中, 最常见的场景是并发插入或者导入数据场景, 在该场景中并不指定自增id, 由数据库自动生成自增id, 然后插入到数据库中, 因此我们也叫auto_inc 场景的数据插入. 典型的业务场景如: 游戏行业开服过程中的大批的登录注册场景, 电商活动中给商家后台推单场景等等. 我们看看PolarDB 是如何优化针对这种并发插入场景进行优化的. 背景知识: 在这种并发
**背景** 很多时候业务架构设计里面最重要的一环就是数据库模型设计, 由于单机MySQL 的限制, 很多业务架构师不得不考虑对大表进行拆分, 通过中间件或者其他手段进行分库分表. 很多业务在快速发展阶段,开始考虑数据拆分的原因其实并不是计算能力遇到了瓶颈,而是海量数据的存储到达了单实例的上限,但是由于最初设计的时候没有考虑到海量数据的使用方式,或是在业务逻辑中,数据无法进行清理或归档。 运
unique secondary index 是客户经常使用的场景, 用来保证index 上的record 的唯一性. 但是大量的客户在使用unique secondary index 以后会发现偶尔会有死锁或者不应该锁等待的时候却发生锁等待的情况. 也有很多客户来问我们这个问题. 理论上PolarDB 默认使用read-commit isolation level, 在rc 隔离级别下绝
> 天不生我 bw-tree, 索引万古如长夜 > ### 背景 在前面的文章 [路在脚下, 从BTree 到Polar Index](https://zhuanlan.zhihu.com/p/374000358)中提到, 我们已经将InnoDB 里面Btree 替换成Blink Tree, 高并发压力下, 在标准的TPCC 场景中最高能够有239%的性能提升, 然后我们对InnoDB 的fi
PolarDB 在游戏行业的最佳实践
目前在系统里面, 我们可以通过perf 或者 pt-pmp 汇总堆栈的方式来查看系统存在的热点, 但是我们仅仅能够知道哪些地方是热点, 却无法定量的说这个热点到底有多热, 这个热点占整个访问请求的百分比是多少? 是10%, 还是40%, 还是80%? 所以我们需要一个定量分析系统瓶颈的方法以便于我们进行系统优化. 本文通过Performance_schema 来进行定量的分析系统性能瓶颈
云数据库实现计算存储分离,支持计算与存储的独立扩展,其用户还可以享受按量付费等特性。这使得基于云数据库的系统更加高效、灵活。因此,构建并使用云原生数据库的势头愈演愈烈。另一方面,云化存储服务已经是云的标准能力,存储侧提供兼容通用的文件接口,并且不对外暴露持久化、容错处理等复杂细节,其易用性和规模化带来的高性价比使得云存储成为了云上系统的第一选择。在通用云存储服务上构建云数据库,无疑是一种既能够享
为什么InnoDB 的redo log 是**Physiological logging**? 有一个存储的同学来问, 如果redo log 是纯physical log 的话, 那么就可以省去double write buffer 的开销, 保证每一次修改都是在4kb以内(由操作系统保证4kb以内的原子操作), 那么就不存在应用redo 到不新不旧的page 上的问题, 就不需要double
**什么是inno_space?** [inno_space ](./https://github.com/baotiao/inno_space) 是一个可以直接访问InnoDB 内部文件的命令行工具, 可以打印出文件的内部结构. Jeremy Cole 用ruby 写了一个类似的工具, 不过不支持MySQL 8.0, 并且ruby 编译以及改动起来特别麻烦, 所以用cpp 重写了一个.
##### 背景 首先1992 年发表的SQL Standard 对隔离级别进行的定义是根据几个异象(Dirty Read, Non-Repeatable Read, Phantom Read) , 当然这个定义非常模糊, 后面Jim Grey 也有文章说这个不合理, 然而此时MVCC, snapshot isolation 还没被发明. 等有snapshot isolation 以后发
这个系列, 介绍upstream 一些有意思的worklog **问题** 在InnoDB 现有的版本里面, 如果一个table space 被truncated 或者 drop 的时候, 比如有一个连接创建了临时表, 连接断开以后, 对应的临时表都需要进行drop 操作. InnoDB 是需要将该tablespace 对应的所有的page 从LRU/FLUSH li
(一般在数据库里面latch 指的是物理Lock, Lock 指的是事务的逻辑lock, 这里混用) 在InnoDB 的实现中, btree 主要有两种lock: index lock 和 page lock index lock 就是整个Index 的lock, 具体在代码里面就是 dict_index->lock page lock 就是我们在btree 里面每一
### InnoDB mutex InnoDB 中的mutex 和 rw_lock 在早期的版本都是通过系统提供的cas, tas 语义自己进行实现, 并没有使用pthread_mutex_t, pthread_rwlock_t, 这样实现的好处在于便于统计, 以及为了性能考虑, 还有解决早期操作系统的一些限制. 大概是原理是: 在mutex_enter 之后, 在sp
### InnoDB buffer pool flush 策略 **1. 刷脏整体策略** 首先从整体上来说, 刷脏的coordinator_thread 会判断进入哪一种场景刷脏 在 buf_flush_page_coordinator_thread() 函数里面 刷脏主要有3个场景 1. 如果 buf_flush_sync_lsn > 0, 则因为r
结论: 同样写1G 大小的文件, 4k memory and file address aligned 写入: buffer write: 16920538 us fallocate + buffer write: 13469360 us fallocate + filling zero + buffer write: 4028809 us 可以看出fall
### avoid read-on-write 什么是 "read-on-write" problem? 在我们使用最常见的buffer write 中 "read-on-write" 问题指的是当我需要进行小于4k 大小buffer write 的时候, 需要先将数据所在的page 从disk 中读取出放入到page cache, 在page cache 中修改好, 然后再将
InnoDB 和大部分的存储引擎一样, 都是采用WAL 的方式进行写入数据, 所有的数据都先写入到redo log, 然后后续再从buffer pool 刷脏到数据页 又或者是备份恢复的时候从redo log 恢复到buffer poll, 然后在刷脏到数据页, WAL很重要的一点是将随机写转换成了顺序写, 所以在机械磁盘时代, 顺序写的性能远远大于随机写的背景下, 充分利用了磁盘的性能.
由于郁白之前写的关于Multi-Paxos 的文章流传非常广, 具体地址: http://oceanbase.org.cn/?p=111 原文提出了一个叫"幽灵复现" 的问题, 认为这个是一个很诡异的问题, 后续和很多人交流关于一致性协议的时候, 也经常会提起这个问题, 但是其实这个问题我认为就是常见的"第三态"问题加了一层包装而已. **幽灵复现问题** 来自郁白的博客: 使用
这个是Amazon Aurora 发的第二篇文章, 发在2018 年SIGMOD上, 题目很吸引人避免在I/O, commit, 成员变更的过程使用一致性协议. 在大家都在使用一致性协议(raft, multi-paxos)的今天, Aurora 又提出来了不用一致性协议来做, 主要观点是现有这些协.