TDH_Socket与HandlerSocket和MySQL的特性优缺点对比

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
云数据库 RDS MySQL Serverless,价值2615元额度,1个月
简介:


TDH_SOCKET



HandlerSocket



SQL

IO策略

Dynamic IOStrategy



Same-thread IOStrategy



one-thread-per-connection

优点 worker线程只处理与DB相关的逻辑最大化DB的操作吞吐量 上下文切换真心很少 资源分离 不太会相互干扰
缺点 上下文切换一般,测试时最高在10w,但可以接受 IO逻辑对DB逻辑影响较大一旦io处理的慢了,会导致QPS下降很多(比如说较多的连接数并发请求导致io处理变慢也会是整体QPS下降) 线程资源浪费严重,太多的线程会导致高并发是上下文切换多,从而影响性能,测试时最高60w
读策略

1. 无需SQL解析
2. 可在THD上cache open过的table(可配置关闭)
3. 一次轮询只lock一次table
4. 请求按table的hash值平均分配到可活动的线程上
5. 如果有table被过多访问,那么此table的请求可被分配到多个线程上
6. 在带io请求少时,可以用较少的线程work.来减少锁征用导致的上下文切换
7. 有一定量带io请求时,能调整worker线程数来充分利用io资源.
8. 当带io请求巨多时,将区分带io的请求和不带io的请求.分别用两个线程池来执行,防止带io的请求堵住不带io的请求.
9. 还可以设置流控带io的请求数来防止client的堵塞情况,能使DB继续输出较高的QPS
10. 如果返回大批量数据可以以stream的方式返回,避免过多占用内存
1. 无需SQL解析
2. 可在THD上cache open过的table(不可配置关闭)
3. 一次轮询只lock一次table
4. worker线程数固定,且无法做请求数的平衡,只能做连接数的平衡


1. 可global的做table的cache
2. 每次请求都lock一次table
优点 多种策略配合能一直输出较高的QPS 在全缓存的请求下,输出的QPS很高 由于是一个连接一个请求,不会出现由带io的请求堵塞不带io的请求的情况出现
缺点 流控会丢失一部分请求,预测请求带不带io不是非常准确(如果使用row cache就能较精确的预测了) 一旦有带io的请求出现,就很容易堵塞住不带io的请求出现,所以缓存命中率下降后QPS下降的非常厉害返回大批量数据会占用过多内存 有极限一般QPS最高输出到6-7w
写策略 1. 一次轮询的请求一次commit
2. 请求按table的hash值平均分配到写线程上,即同一个表肯定在一个写线程的被执行,不会有死锁的问题,也不会有同一条row的锁问题.
3. 支持Batch方式的小事务,Batch内的请求保证同时成功,同时失败
4. 可以在Client端通过指定hash的方式,来控制请求被指定的线程执行,来避免一些锁或死锁


1. 一次轮询的请求一次commit
2. 可配置多个写线程,但是有一个user_lock保证只有一个写线程在工作,来防止死锁
1. 一次请求一次commit
优点 同一个表必然在同一个线程上执行,所以行锁的征用被降到最低,加上group commit就能提供很搞的TPS可以多个写线程并发写,不会有死锁问题支持batch小事务 Group commit可以减少fsync次数,提高写性能

支持大事务
缺点 写线程数有限,在有io堵塞请求下,性能会有下降 同一时刻只有一个写线程能被执行,很容易达到瓶颈,一旦有多表插入并发出现,很容易影响整体更新性能生成binlog没有执行时间(bug)

多表insert会有自增id获取失败的问题(bug)
性能受限于IOPS
可维护性

1. DDL操作不会被hang住(因为可以主动close 被cache的table)

1. 支持KILL 命令直接终止正在执行的操作

1. 大部分参数都为在线可配置

1. status数据监控完善
1. DDL会被hang住,因为handlersocket只open table不管主动close table,只有在流量较小time out时才会close table
最高
易用性

1. client端不需要openIndex,直接请求即可(如:

client.query().use(“test”).select(“id”, “a”, “b”, “c”).from(“t”)

.where().fields(“a”).in([“1”, “1”], [“2”], [“1”]).get())

1. server端只需要一个port 就能做读写分离
2. 可支持一些MySQL的内置函数

1. 现在支持Update/Insert的时候可以插入now()

1. 基于辅助索引的联合主键可以支持简单的order by

1. 只能支持=的order by
5. Java客户端支持JDBC


* 1. 读写分离需要在server端配置两个port是实现
2. client请求前需要先openIndex
最高


本文来源于"阿里中间件团队播客",原文发表时间" 2012-05-16 "

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
15天前
|
存储 JSON 关系型数据库
《MySQL 简易速速上手小册》第9章:高级 MySQL 特性和技巧(2024 最新版)
《MySQL 简易速速上手小册》第9章:高级 MySQL 特性和技巧(2024 最新版)
31 1
|
27天前
|
存储 安全 关系型数据库
Mysql 的binlog日志的优缺点
MySQL的binlog(二进制日志)是一个记录数据库更改的日志文件,它包含了所有对数据库执行的更改操作,如INSERT、UPDATE和DELETE等。binlog的主要目的是复制和恢复。以下是binlog日志的优缺点: ### 优点: 1. **数据恢复**:当数据库出现意外故障或数据丢失时,可以利用binlog进行点恢复(point-in-time recovery),将数据恢复到某一特定时间点。 2. **主从复制**:binlog是实现MySQL主从复制功能的核心组件。主服务器将binlog中的事件发送到从服务器,从服务器再重放这些事件,从而实现数据的同步。 3. **审计**:b
|
4月前
|
存储 SQL 关系型数据库
MySQL相关(五)- 事务四大特性及隔离级别的详细介绍
MySQL相关(五)- 事务四大特性及隔离级别的详细介绍
44 0
|
4月前
|
存储 SQL 关系型数据库
MySQL 事务的 ACID 特性
MySQL事务是什么,**它就是一组数据库的操作,是访问数据库的程序单元,事务中可能包含一个或者多个 SQL 语句。这些SQL 语句要么都执行、要么都不执行。**我们知道,在MySQL 中,有不同的存储引擎,有的存储引擎比如MyISAM 是不支持事务的,所以说**MySQL 事务实际上是发生在 存储引擎部分**。
53 0
MySQL 事务的 ACID 特性
|
10天前
|
SQL 关系型数据库 MySQL
MySQL8.0索引新特性
MySQL8.0索引新特性
13 0
|
3月前
|
SQL 关系型数据库 MySQL
Mysql事务隔离级别和锁特性
Mysql事务隔离级别和锁特性
|
3天前
|
SQL 安全 关系型数据库
【Mysql-12】一文解读【事务】-【基本操作/四大特性/并发事务问题/事务隔离级别】
【Mysql-12】一文解读【事务】-【基本操作/四大特性/并发事务问题/事务隔离级别】
|
5月前
|
SQL 关系型数据库 MySQL
⑨【MySQL事务】事务开启、提交、回滚,事务特性ACID,脏读、幻读、不可重复读。
⑨【MySQL事务】事务开启、提交、回滚,事务特性ACID,脏读、幻读、不可重复读。
36 0
|
5月前
|
存储 SQL 关系型数据库
MySQL8.0新特性与旧特性移除总结
MySQL从5.7版本直接跳跃发布了8.0版本 ,可见这是一个令人兴奋的里程碑版本。MySQL 8版本在功能上做了显著的改进与增强,开发者对MySQL的源代码进行了重构,最突出的一点是对MySQL Optimizer优化器进行了改进。不仅在速度上得到了改善,还为用户带来了更好的性能和更棒的体验。
131 1
|
2月前
|
存储 缓存 关系型数据库
MySQL事务的四大特性是如何保证的
在MySQL数据库中还有一种二进制日志,其用来基于时间点的还原及主从复制。从表面上来看其和重做日志非常相似,都是记录了对于数据库操作的日志。但是,从本质上来看有着非常大的不同。
14 1