人员、任务、进度、工时、周期、依赖关系 一目了然。无论项目大小、简单复杂都能轻松管理
用户在使用数据库产品时可能会遇到一些情况,需要将数据还原到特定的时间点。PolarDB作为一款业界领先的企业级数据库产品,拥有强大的备份恢复能力,赋予用户通过指定时间点来查询历史数据状态或者还原历史状态的能力。主要包括以下几部分组成:实例级别的备份与恢复、库表备份与恢复、表回收站以及Flashback query等。
下面我们首先介绍下用户在哪些情况下需要备份恢复及选择哪些备份恢复方法更为合适,然后介绍PolarDB几种备份恢复功能实现的原理。
场景及方案选择
问题场景不
游戏行业痛点
在我看来, 不同行业对数据库使用有巨大的差别. 比如游戏行业没有复杂的事务交易场景, 他有一个非常大的blob 字段用于存储角色的装备信息, 那么大Blob 字段的更新就会成为数据库的瓶颈, 比如在线教育行业需要有抢课的需求, 因此会有热点行更新的场景, 对热点行如何处理会成为数据库的瓶颈, 比如SaaS 行业, 每一个客户有一个Database, 因此会有非常多的Table, 那么数据库就需要对多表有很好的支持能力.
游戏行业和其他行业对数据库的使用要求是
第四届全球数据库大赛,瓜分40万奖金池,只等你来!各赛道TOP10都可获得现金奖励
“云原生共享内存数据库性能优化”赛道,邀您提交评测啦!
早鸟活动说明
1、即日起–7月29日,前60名报名【云原生共享内存数据库性能优化】赛道、提交有效代码并成功出分的参赛队伍,均可获赠 天池定制款笔记本一件 或 阿里云数据库定制款帆布包一个,先到先得!
2、即日起–8月22日,【云原生共享内存数据库性能优化】赛道初赛排行榜成绩前40位(需成功出分),且在赛道论坛发布高分心得文章的选手,均可
本文将结合MySQL分区表功能重点介绍一致性哈希算法以及其他一些哈希算法的特性和在分区表中的使用。
分区表介绍
分区表是数据库根据一定的分区规则,把一个表划分为多个更小的、更容易管理的子数据集合。
数据库创建示例:
CREATE TABLE test (id INT)
PARTITION BY HASH (id) PARTITIONS 1000;
比起分区表,很多人可能更熟悉分库分表操作,这两者的目的都是为了减少单表的数据量,提升整体的性能。
二者的区别在于:分库分表通
问题定义
Join graph
为了应用经典的图算法,我们需要通过join构建出一张图,该图的定义为
join语句中的每一个table都可以作为一个节点
join语句中的每一个predicate都可以作为一条边
Join tree
在经典的volcano模型中,每个query 会转成一颗树去执行,而join 部分也会转为其中的子树。不同的join tree对应不同的执行顺序,经典的join tree可以分为三类:left-deep、zig-zag 和 bus
三种形式
RAND 表达式有以下三种形式:
RAND(非常量表达式),此时 RAND 的值仅和表达式的计算值相关,与其所在的位置无关
RAND(常量),每次查询都相同
RAND(),每次查询都不相同,这种与通常概念上的随机比较接近
我们通过一些例子来实际看看 RAND 的结果:
第一种形式 RAND(非常量表达式)
create table t1(c1 int, c2 varchar(10)) engine innodb;
insert into t1
目前在系统里面, 我们可以通过perf 或者 pt-pmp 汇总堆栈的方式来查看系统存在的热点, 但是我们仅仅能够知道哪些地方是热点, 却无法定量的说这个热点到底有多热, 这个热点占整个访问请求的百分比是多少? 是10%, 还是40%, 还是80%?
所以我们需要一个定量分析系统瓶颈的方法以便于我们进行系统优化.
本文通过Performance_schema 来进行定量的分析系统性能瓶颈.
原理如下:
performance_schema.events_waits_s
云数据库实现计算存储分离,支持计算与存储的独立扩展,其用户还可以享受按量付费等特性。这使得基于云数据库的系统更加高效、灵活。因此,构建并使用云原生数据库的势头愈演愈烈。另一方面,云化存储服务已经是云的标准能力,存储侧提供兼容通用的文件接口,并且不对外暴露持久化、容错处理等复杂细节,其易用性和规模化带来的高性价比使得云存储成为了云上系统的第一选择。在通用云存储服务上构建云数据库,无疑是一种既能够享受规模化云存储红利,又能够通过可靠云存储服务实现降低维护成本、加速数据库开发周期的
本文基于MySQL Community 8.0.23 Version
通过之前 InnoDB之UNDO LOG介绍这篇文章的介绍,我们已经基本明白了undo log的整个生命周期是怎样的,但是其中对于具体undo log是如何purge的没有进行分析更深入的介绍。
具体的,只介绍到purge undo log record时主要分为两种情况:清理TRX_UNDO_DEL_MARK_REC记录或者清理TRX_UNDO_UPD_EXIST_REC记录;但是没有介绍如何对这两
InnoDB LOB 物理结构
在 InnoDB 引擎中,对于 VARCHAR、VARBINARY、BLOB、TEXT 这类可变长字段,如果数据长度过长,会将其单独存储在主索引记录之外的 LOB page 上(从主索引所属的 tablespace 上分配),LOB 字段对应的主索引记录中只存储一个定长的 reference 指向它,而二级索引中的记录不会关联外部存储的 LOB 字段。
接下来我们主要介绍 LOB 字段的存储结构。
在 MySQL 8.0 引入 Parti