青年节献礼:AliSQL青年节版本Release 增动态加字段和Thread Pool

简介: AliSQL 5.4版本Release: 动态加字段和Thread Pool; 加字段作为业务需求变更中最常见的需求,InnoDB引擎表的加字段功能一直以来被运维人员所诟病, 虽然支持了online方式,但随着表空间越来越大,copy整张表的代价也越来越大。

动态加字段和Thread Pool

Abstract

加字段作为业务需求变更中最常见的需求,InnoDB引擎表的加字段功能一直以来被运维人员所诟病,
虽然支持了online方式,但随着表空间越来越大,copy整张表的代价也越来越大。
AliSQL版本在InnoDB的compact记录格式的基础上,设计了新的记录格式comfort,支持动态加字段。

MySQL默认的one-thread-per-connection的线程模型,在面对大并发的连接请求的时候,变成了性能杀手,随着线程的增多,吞吐能力会急剧下降。AliSQL 引入了MariaDB版本的Thread Pool线程模型,以应对大并发连接请求的时候,保证持续稳定的性能。

AliSQL REPO: https://github.com/alibaba/AliSQL
AliSQL Release Notes: https://github.com/alibaba/AliSQL/wiki/Changes-in-AliSQL-5.6.32-(2017-05-04)

1. Add Column Dynamically

Description

AliSQL设计了一种新的记录格式,命名为comfort,其格式从compact演化而来,格式如下:

[lens | n_nulls | n_fields | extra_bytes | id...]
其中:

  1. extra_bytes中info_bits占用一个bit来标识comfort记录.
  2. n_fields占用1或者2个bytes来标识当前记录的column数量.

相对于compact格式增加了空间的使用,但对于当前磁盘来讲,基本可以忽略不计。

注意:
动态加的字段需要添加在表结构的最后,可为空,并且没有设置默认值的column。

Syntax

CREATE TABLE t (
  id INT
)ENGINE=InnoDB ROW_FORMAT=comfort.

ALTER TABLE t ADD col1 INT;

对比compact和comfort记录格式的加字段效果:

COMPACT:

y.png

COMFORT:

x.png

2. Thread Pool

Description

Thread Pool模型,使用限定的有限的CPU(x86)调度单元线程来服务client端的请求,在面对大量的client连接请求的时候,维持MySQL server的吞吐量持续稳定。

AliSQL 从 MariaDB port此功能,这里做下高并发情况下性能稳定性测试供参考:

  1. Sysbench UPDATE场景Thread Pool和one-thread-per-connection的对比测试:
    TP1.png
  2. Sysbench OLTP场景Thread Pool和one-thread-per-connection的对比测试:
    tp2.png
目录
相关文章
|
Go 数据库
[Golang] gorm从版本1升到版本2,数据库close()方法被弃用,应该怎样去关闭数据库?
[Golang] gorm从版本1升到版本2,数据库close()方法被弃用,应该怎样去关闭数据库?
|
关系型数据库 MySQL Java
dbvis 数据库连接工具-更新数据库驱动方法示例演示,驱动与数据库版本不匹配问题:Unknown system variable ‘query_cache_size‘解决方法
dbvis 数据库连接工具-更新数据库驱动方法示例演示,驱动与数据库版本不匹配问题:Unknown system variable ‘query_cache_size‘解决方法
569 0
dbvis 数据库连接工具-更新数据库驱动方法示例演示,驱动与数据库版本不匹配问题:Unknown system variable ‘query_cache_size‘解决方法
|
SQL 监控 关系型数据库
【DB吐槽大会】第40期 - PG 缺少qps计数器
大家好,这里是DB吐槽大会,第40期 - PG 缺少qps计数器
|
存储 JSON 搜索推荐
【DB吐槽大会】第35期 - “富人”的烦恼?PG 不会自动选择索引类型
大家好,这里是DB吐槽大会,第35期 - “富人”的烦恼?PG 不会自动选择索引类型
|
SQL 关系型数据库 PostgreSQL
PostgreSQL 统计信息混淆之处(scan,read,fetch,hit)源码解读
PostgreSQL 几个统计信息的解释难以理解,所以本文花一些时间从源码的角度来解释一下。 让大家对这几个容易误解的统计值有更好的理解。 比较难理解的几个统计值为: pg_stat_all_indexes 的 ``` idx_scan idx_tup_read idx_tup_fetch ``` pg_statio_all_indexes 的 ``` idx_blks_read idx_blks_hit ``` pg_stat_all_tables 的 ``` seq_scan seq_tup_read idx_
4450 0
|
存储 关系型数据库 MySQL
MySQL · 源码分析 · InnoDB的read view,回滚段和purge过程简介
笔者最近开始学习InnoDB的内部机制,参照之前的几篇文章整理出InnoDB多版本部分相关的一些实现原理。 InnoDB undo log 漫游 性能优化·5.7 Innodb事务系统 InnoDB 事务系统 [MySQL 5.6] Innodb 新特性之 multi purge thread innodb purge操作 对于undo日志,第1篇文章写得非常清楚,图文并茂。
6382 0