本帖最后由 斌斌有你 于 2025-2-11 15:34 编辑 背景 ● 硬件 CPU:32C 内存 :128G 硬盘:1.4TSSD ● 压测方法 使用同一配置文件,针对 insert、delete、select、update 等常规操作进行压测。每次压测20分钟,每次压测空闲 10 分钟,保证 buffer pool 数据均刷盘。分别压测并发数 2 4 8 16 32 64 128 256 512。 ● 数据库版本 1. Percona-Server-5.7.34-37 2. Percona-Server-8.0.32-24 3. GreatSQL-8.0.32-24 4. GreatDB-1.0.0.6038032-GA-2 1. TPS bulk_insert mysql 5.7 的拐点早早出现,在 8.0 这一情况得到很好的优化。让人意外的是 GreatSQL 的表现更好于 GreatDB。 oltp_delete 和上图一样,mysql 5.7 的拐点早早出现,在线程达到 512 时,mysql 8.0 和 mysql 5.7 区别不大。GreatDB这一方面做足了优化 oltp_insert GreatSQL 8.0 表现更好 oltp_read_write 线程数少的时候,表现基本一致。但是 5.7 的拐点和下降趋势在线程数达到 64 之后变现明显 oltp_update_index GreatSQL 变现更优,让人意外的是 GreatDB 和 mysql8.0 在前面表现居然不如 mysql 5.7 oltp_update_non_index GreatDB 表现更好,mysql 5.7 线程数少的时候也不错,但是拐点出现过早。 oltp_write_only 可以看到GreatSQL表现稳定,后来居上。GreatDB也很不错。 2. QPS oltp_point_select 可以明显的看到 8.0 对于查询的优化效果。GreatDB的优势显而易见 oltp_read_only 表现基本一致 oltp_read_write 前面表现基本一致, 5.7 早早的出现拐点 select_random_points mysql 5.7 居然是表现最好的,而且 GreatDB 在这对比中落于下风 select_random_ranges GreatSQL表现抢眼 结论 注意本次小结仅针对本次压测,不为其他场景负责。 通过多图发现,大多数场景下,GreatDB和GreatSQL都有优越的表现,甚至社区版比商业版在个别指标上更好。可以看出万里企业,对于 mysql 的投入很大。作为 mysql 原生态开发而来的GreatDB和GreatSQL,我认为完全可以平替,乃至胜任目前 mysql 的工作 |
GreatSQL社区
2025-2-11 16:49:29
| ||
yejr
2025-2-14 09:03:19
| ||
earl86
2025-2-14 09:15:21
| ||
caihe.li
2025-2-14 09:21:21
| ||
earl86
2025-2-14 09:35:18
| ||
caihe.li
2025-2-14 09:48:16
| |
合作电话:010-64087828
社区邮箱:greatsql@greatdb.com