开发者社区> 开源小秘书> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

PolarDB-X 全局Binlog解读之性能篇(上)

简介: 本篇来介绍一下PolarDB-X全局binlog在性能方面的一些设计和思考,先通过几个实际的测试案例来展示全局binlog的性能情况,然后结合这些案例来深入讲解全局binlog关于优化的故事。
+关注继续查看
福利推荐:阿里云、腾讯云、华为云等大品牌云产品全线2折优惠活动来袭,4核8G云服务器899元/3年,新老用户共享优惠,点击这里立即抢购>>>

本篇来介绍一下PolarDB-X全局binlog在性能方面的一些设计和思考,先通过几个实际的测试案例来展示全局binlog的性能情况,然后结合这些案例来深入讲解全局binlog关于优化的故事。

测试准备

准备一个PolarDB-X 2.0实例,本文测试所用实例版本为5.4.14-16576195,实例配置如下:

  • 实例拓扑:8CN + 8DN + 2CDC
  • 单CN节点规格:32核128GB
  • 单DN节点规格:32核128GB
  • 单CDC节点规格:16核32GB

准备两台ECS压测机,机器配置:64核128G

名词解释

  • EPS

Event Per Second,每秒写入binlog文件的event个数

  • DML EPS

DML Event Per Second,每秒写入binlog文件的dml event个数,所谓dml event特指binlog中的TableMapEvent、WriteRowsEvent、UpdateRowsEvent和DeleteRowsEvent

  • BPS

Byte Per Second,每秒写入binlog文件的字节数,后文为表达方便,采用M/s来作为计量单位

  • TPS

Transaction Per Second,每秒钟写入binlog文件的事务个数

  • FPM

File Per Minute,每分钟生成binlog文件的个数,单个文件大小500M

  • Delay Time

延迟时间,单位ms

测试方案

TPCC

测试方法参见:https://help.aliyun.com/document_detail/405018.html
本测试案例,TPCC核心参数的配置如下:

  • warehouses=2000
  • loadWorkers=500
  • terminals=1024
  • runLoader.sh 中JVM参数配置 -Xms60g -Xmx60g
  • runBenchmark.sh 中JVM参数配置 -Xms60g -Xmx60g

场景一:TPCC数据导入

  • 测试目的

在进行压测数据导入时,DN节点会瞬时产生大量物理binlog,借此观察全局binlog的性能指标情况

  • 测试方式

在每台ECS上面分别部署多份tpcc程序包,同时运行多个./runDatabaseBuild.sh,来构造流量

场景二:TPCC交易测试

  • 测试目的

执行TPCC测试,模拟真实交易场景,考察全局binlog的性能情况(重点关注延迟)

  • 测试方式

调整压测并发度,构造不同的tmpC参考指标,观察全局binlog延迟指标。由于8CN+8DN在压力打满的情况下,全局binlog的延迟依然比较低,所以下面的测试,不局限于8CN+8DN

Sysbench

测试方法参见: https://help.aliyun.com/document_detail/405017.html

场景一:Sysbench数据导入

  • 测试目的

在进行压测数据导入时,DN节点会瞬时产生大量物理binlog,借此观察全局binlog的性能指标情况

  • 测试方式

调整--tables和--threads的参数值,测试不同压力状态下全局binlog的性能指标

场景二:Sysbench oltp_write_only

  • 测试目的

执行sysbench oltp_write_only,测试混合写入场景下,全局binlog性能情况

  • 测试方式

执行oltp_write_only,构造不同qps参考指标,观察全局binlog延迟情况

Large Transaction

  • 测试目的

测试超大事务场景下,CDC的性能情况和稳定性,重点关注延迟时间

  • 测试方式

参考如下脚本,构造不同大小的事务,进行测试,按如下脚本,每插入20w条数据可以构造一个500M大小的事务

CREATE TABLE `t_1`
(`id` bigint(20) NOT NULL AUTO_INCREMENT,
`c_bit_1` bit(1) DEFAULT NULL,
`c_bit_8` bit(8) DEFAULT NULL,
`c_bit_16` bit(16) DEFAULT NULL,
`c_bit_32` bit(32) DEFAULT NULL,
`c_bit_64` bit(64) DEFAULT NULL,
`c_tinyint_1` tinyint(1) DEFAULT NULL,
`c_tinyint_4` tinyint(4) DEFAULT NULL,
`c_tinyint_8` tinyint(8) DEFAULT NULL,
`c_tinyint_8_un` tinyint(8) unsigned DEFAULT NULL,
`c_smallint_1` smallint(1) DEFAULT NULL,
`c_smallint_16` smallint(16) DEFAULT NULL,
`c_smallint_16_un` smallint(16) unsigned DEFAULT NULL,
`c_mediumint_1` mediumint(1) DEFAULT NULL,
`c_mediumint_24` mediumint(24) DEFAULT NULL,
`c_mediumint_24_un` mediumint(24) unsigned DEFAULT NULL,
`c_int_1` int(1) DEFAULT NULL,
`c_int_32` int(32) DEFAULT NULL,
`c_int_32_un` int(32) unsigned DEFAULT NULL,
`c_bigint_1` bigint(1) DEFAULT NULL,
`c_bigint_64` bigint(64) DEFAULT NULL,
`c_bigint_64_un` bigint(64) unsigned DEFAULT NULL,
`c_decimal` decimal DEFAULT NULL,
`c_decimal_pr` decimal(10,3) DEFAULT NULL,
`c_float` float DEFAULT NULL,
`c_float_pr` float(10,3) DEFAULT NULL,
`c_float_un` float(10,3) unsigned DEFAULT NULL,
`c_double` double DEFAULT NULL,
`c_double_pr` double(10,3) DEFAULT NULL,
`c_double_un` double(10,3) unsigned DEFAULT NULL,
`c_date` date DEFAULT NULL COMMENT 'date',
`c_datetime` datetime DEFAULT NULL,
`c_timestamp` timestamp DEFAULT CURRENT_TIMESTAMP,
`c_time` time DEFAULT NULL,
`c_year` year DEFAULT NULL,
`c_year_4` year(4) DEFAULT NULL,
`c_char` char(50) DEFAULT NULL,
`c_varchar` varchar(50) DEFAULT NULL,
`c_binary` binary(200) DEFAULT NULL,
`c_varbinary` varbinary(200) DEFAULT NULL,
`c_blob_tiny` tinyblob DEFAULT NULL,
`c_blob` blob DEFAULT NULL,
`c_blob_medium` mediumblob DEFAULT NULL,
`c_blob_long` longblob DEFAULT NULL,
`c_text_tiny` tinytext DEFAULT NULL,
`c_text` text DEFAULT NULL,
`c_text_medium` mediumtext DEFAULT NULL,
`c_text_long` longtext DEFAULT NULL,
`c_enum` enum('a','b','c') DEFAULT NULL,
`c_set` set('a','b','c') DEFAULT NULL,
`c_testcase` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`) )ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='10000000' dbpartition by hash(`id`) tbpartition by hash(`id`) tbpartitions 8;
INSERT t_1 (c_bit_1 , c_bit_8 , c_bit_16 , c_bit_32 , c_bit_64 , c_tinyint_1 , c_tinyint_4 , c_tinyint_8 , c_tinyint_8_un , c_smallint_1 , c_smallint_16 , c_smallint_16_un , c_mediumint_1 , c_mediumint_24 , c_mediumint_24_un , c_int_1 , c_int_32 , c_int_32_un , c_bigint_1 , c_bigint_64 , c_bigint_64_un , c_decimal , c_decimal_pr , c_float , c_float_pr , c_float_un , c_double , c_double_pr , c_double_un , c_date , c_datetime , c_timestamp , c_time , c_year , c_year_4 , c_char , c_varchar , c_binary , c_varbinary , c_blob_tiny , c_blob , c_blob_medium , c_blob_long , c_text_tiny , c_text , c_text_medium , c_text_long , c_enum , c_set , c_testcase) 
VALUES( 
b'1' , b'11111111' , b'1111111111111111' , b'11111111111111111111111111111111' , b'1111111111111111111111111111111111111111111111111111111111111111' , '82' , '-101' , '-75' ,'253' , '14497' , '5070' , '9427' , '-5888259' , '-1845105' , '2350597' , '-2147483648' , '-2147483648' , '3653062473' , '-816854218224922624' , '7292572323853307904' , '2902765992697493504' , '-1613793319' , '1223077.292' , '9.1096275E8' , '-5839673.5' , '2648.644' , '4.334081673614155E9' , '6973286.176' , '7630560.182' , '2019-02-15' , '2019-02-15 14:54:41' , '2019-02-15 14:54:41' , '20:12:46' , '2019' , '2019', 'xxx','int a = max(4,5)','xxxxxxx','varchar a = ','xxkdkwjsjdfdsk','varchar a = ',';sdjfaljdljfsljldjlsjdljflsjdlfjsaljdlfhahdljflajdlfasdf','int a = max(4,5)','xxx','sdjflshdflsjlfa;;dfjadjfahdfhklsajdfklsafasjlfjls',repeat('a',1024),repeat('a',1024), 'a', 'a', 'caseNo1');
INSERT t_1 ( c_bit_1 ,  c_bit_8 ,  c_bit_16 ,  c_bit_32 ,  c_bit_64 ,  c_tinyint_1 ,  c_tinyint_4 ,  c_tinyint_8 ,  c_tinyint_8_un ,  c_smallint_1 ,
c_smallint_16 ,  c_smallint_16_un ,  c_mediumint_1 ,  c_mediumint_24 ,  c_mediumint_24_un ,  c_int_1 ,  c_int_32 ,  c_int_32_un ,  c_bigint_1 ,  c_bigint_64
,  c_bigint_64_un ,  c_decimal ,  c_decimal_pr ,  c_float ,  c_float_pr ,  c_float_un ,  c_double ,  c_double_pr ,  c_double_un ,  c_date ,  c_datetime ,  c_timestamp ,  c_time ,  c_year ,  c_year_4 ,  c_char ,  c_varchar ,  c_binary ,  c_varbinary ,  c_blob_tiny ,  c_blob ,  c_blob_medium ,  c_blob_long ,  c_text_tiny ,  c_text ,  c_text_medium ,  c_text_long ,  c_enum ,  c_set ,  c_testcase) select c_bit_1 ,  c_bit_8 ,  c_bit_16 ,  c_bit_32 ,  c_bit_64 ,  c_tinyint_1 ,  c_tinyint_4 ,  c_tinyint_8 ,  c_tinyint_8_un ,  c_smallint_1 ,  c_smallint_16 ,  c_smallint_16_un ,  c_mediumint_1 ,  c_mediumint_24 ,  c_mediumint_24_un ,  c_int_1 ,  c_int_32 ,  c_int_32_un ,  c_bigint_1 ,  c_bigint_64 ,  c_bigint_64_un ,  c_decimal ,  c_decimal_pr ,  c_float ,  c_float_pr ,  c_float_un ,  c_double ,  c_double_pr ,  c_double_un ,  c_date ,  c_datetime ,  c_timestamp ,  c_time ,  c_year ,  c_year_4 ,  c_char ,  c_varchar ,  c_binary ,  c_varbinary ,  c_blob_tiny ,  c_blob ,  c_blob_medium ,  c_blob_long ,  c_text_tiny ,  c_text ,  c_text_medium ,  c_text_long ,  c_enum ,  c_set ,  c_testcase from t_1;

测试报告

先给出汇总后的测试报告,再进行详细介绍,测试数据如下:

测试场景参考指标DelayTimeEPSBPS
TPCC数据导入4000仓/600并发300ms10w/s350M/s
TPCC数据导入8000仓/1200并发700ms15w/s450M/s-500M/s
TPCC数据导入12000仓/1800并发1s-60s15w/s450M/s-500M/s
Sysbench数据导入32Tables/32并发500ms180w/s140M/s
Sysbench数据导入48Tables/48并发1s210w/s170M/s
Sysbench数据导入64Tables/64并发1s-70s220w/s180M/s
TPCC交易测试50w tpmC400ms60w/s130M/s
TPCC交易测试100w tpmC500ms120w/s250M/s
TPCC交易测试150w tpmC1s-4s170w/s350M/s
Sysbench Oltp_write_only20w QPS500ms130w/s125M/s
Sysbench Oltp_write_only30w QPS600ms180w/s170M/s
Sysbench Oltp_write_only35w QPS1s-18s210w/s200M/s
大事务500M2s24w/s500M/s
大事务1G4.8s24w/s500M/s
大事务2G7.8s24w/s500M/s
大事务3G9.4s24w/s500M/s
大事务4G12.5s24w/s500M/s
大事务5G(no swap)17s24w/s500M/s
大事务5G(with swap)25s22w/s350M/s
大事务10G(with swap)55s22w/s350M/s
大事务20G(with swap)115s22w/s350M/s

TPCC数据导入

Test With 2 Client

  • EPS: 10w/s,DML EPS: 6w/s

undefined

  • BPS: 350M/s,FPM: 40个/m

undefined

  • TPS: 11000/s

undefined

  • Delay Time: 300ms

undefined

  • 另附CDC进程GC情况:内存使用率不高、GC平稳、无老年代GC

undefined

综述:两个client场景下(4000仓/600并发),写入吞吐平均值约350M/s,延迟时间在300ms左右,完全无压力

Test With 4 Client

  • EPS: 14w/s ~ 16w/s,DML EPS: 7.5w/s ~ 9w/s

undefined

  • BPS: 450M/s ~ 500M/s,FPM: 52个/m ~ 60个/m

undefined

  • TPS: 15000/s

undefined

  • Delay Time: 700ms,最大延迟抖动10S

undefined

  • 另附CDC进程GC情况:老年代内存使用率略有提升、GC平稳、无老年代GC

undefined

综述:四个client场景下(8000仓/1200并发),基本无压力,写入吞吐在450M/s~500M/s,延迟时间总体上可以维持在1S以下,最大延迟抖动10S且有一定的持续时间,其它大部分指标相比两个client场景基本可以达到翻倍

Test With 6 Client

  • EPS: 14w/s ~ 16w/s,DML EPS: 8w/s ~ 9w/s

undefined

  • BPS: 450M/s ~ 500M/s,FPM: 55个/m ~ 60个/m

undefined

  • TPS: 15000/s

undefined

  • Delay Time: 延迟呈递增趋势,最大延迟1分钟

undefined

  • 另附CDC进程GC情况:缓冲区开始出现积压,老年代使用率提升明显

undefined

  • 另附CDC文件写入线程CPU使用率情况

undefined

综述:六个client场景下(12000仓/1800并发),延迟开始出现增长,数据导入时长20min,触发最大延迟60S,其它指标和4个Client场景下相比基本持平,主要瓶颈点在文件写入线程,CPU使用率已经达到了100%,每秒500M左右的写入速度目前是全局binlog能支持的最大吞吐,后序进一步的优化进展会在本文持续更新,敬请关注

Sysbench数据导入

Test With 32 Tables

sysbench --config-file='sysb.conf' --create-table-options='dbpartition by hash(`id`) tbpartition by hash(id) tbpartitions 8'  --tables='32' --threads='32' --table-size='10000000' oltp_point_select prepare
  • EPS: 180w/s,DML EPS: 60w/s

undefined

  • BPS: 140M/s,FPM: 17个/m

undefined

  • TPS: 30w/s

undefined

  • Delay Time: 500ms,最大延迟抖动2s

undefined

综述:32张表并行插入场景下,延迟基本可以控制在1s以内。相比TPCC导数据,Sysbench场景下EPS指标呈现了数十倍的提升,但BPS指标则要低很多,主要是因为Sysbench的表比较小,插入逻辑也简单直接,所以数据插入的rps(record per second)很高但流量并不是很大,各项指标对比见下表:

指标项TPCCSysbench
EPS14w/s ~ 16w/s170w/s
DML EPS7.5w/s ~ 9w/s60w/s
BPS450M/s ~ 500M/s140M/s
TPS15000/s30w/s
Delay Time700ms500ms
FPM52个/m ~ 60个/m17个/m

Test With 48 Tables

sysbench --config-file='sysb.conf' --create-table-options='dbpartition by hash(`id`) tbpartition by hash(id) tbpartitions 8'  --tables='48' --threads='48' --table-size='10000000' oltp_point_select prepare
  • EPS: 210w/s,DML EPS: 接近70w/s

undefined

  • BPS: 170M/s

undefined

  • TPS: 36w/s,FPM: 20个/m

undefined

  • Delay Time: 1s,最大延迟10s

undefined

综述:48张表并行插入场景下,各项指标有了小幅度提升,延迟时间总体在1s左右,最大10s。

Test With 64 Tables

sysbench --config-file='sysb.conf' --create-table-options='dbpartition by hash(`id`) tbpartition by hash(id) tbpartitions 8'  --tables='64' --threads='64' --table-size='10000000' oltp_point_select prepare
  • EPS: 220w/s,DML EPS: 接近75w/s

undefined

  • BPS: 180M/s

undefined

  • TPS: 37w/s,FPM: 21个/m

undefined

  • Delay Time: 最大延迟70s

undefined

综述:64张表并行插入场景下,各项指标有了小幅度提升,延迟时间开始增大,最大延迟时间70s。因涉及全局排序和事务合并,以及需要对每个event进行checksum的计算,目前全局binlog可支持的最大EPS在220w/S左右,后序进一步的优化进展会在本文持续更新,敬请关注

TPCC交易测试

50w-55w tpmC

  • tpmC: 50w/m ~ 55w/m

undefined

  • EPS: 60w/s,DML EPS: 37w/s ~ 40w/s

undefined

  • BPS: 130M/s,FPM: 15个/m

undefined

  • TPS: 18000/s

undefined

  • Delay Time: 400ms

undefined

综述:tpmC 50w/m ~ 55w/m,Tps 18000/s, 全局binlog延迟400ms左右, DML EPS平均在37w/s左右,BPS 130M/s左右

100w-105w tpmC

  • tpmC: 100w/m ~ 105w/m

undefined

  • EPS: 120w/s,DML EPS: 75w/s

undefined

  • BPS: 250M/s,FPM: 30个/m

undefined

  • TPS: 35000/s

undefined

  • Delay Time: 500ms

undefined

综述:tpmC 100w/m~105w/m,Tps 35000/s, 全局binlog延迟500ms左右, DML EPS平均在75w/s左右,BPS 250M/s左右

145w-150w tpmC

  • tpmC: 145w/m ~ 150w/m

undefined

  • EPS: 170w/s,DML EPS: 100w/s

undefined

  • BPS: 350M/s,FPM: 42个/m

undefined

  • TPS: 50000/s

undefined

  • Delay Time: 1s ~ 4s。前段和后段延迟在1.5s左右,中段延迟在4s左右,但中段tpmC其实并没有前段高,原因在于在压力打满情况下,偶发抖动都会导致延迟时间的变化,多次复测并不是每次都会达到4s延迟,这里取一个最坏的测试结果,150w tpmC场景下常规延迟时间大概在2s左右

undefined

综述:tpmC 145w/m ~ 150w/m,Tps 50000/s, 全局binlog延迟1s-4s左右,EPS 170w/s,DML EPS平均在100w/s左右,BPS 350M/s左右

Sysbench oltp_write_only

20w qps

sysbench --config-file='sysb.conf' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all'  --tables='16' --table-size='10000000' --threads=300 oltp_write_only run
  • Sysbench: 21w+ qps, 5w+ tps

undefined

  • 延迟时间:500ms

undefined

  • EPS:130w+, DML EPS:43w+

undefined

  • BPS: 125M/s

undefined

30w qps

sysbench --config-file='sysb.conf' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all'  --tables='16' --table-size='10000000' --threads=512 oltp_write_only run
  • Sysbench: 30w qps, 7.5w tps

undefined

  • 延迟时间:600ms

undefined

  • EPS:180w+, DML EPS:55w+

undefined

  • BPS: 170M/s

undefined

35w qps

sysbench --config-file='sysb.conf' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all'  --tables='16' --table-size='10000000' --threads=800 oltp_write_only run
  • Sysbench: 35w~40w qps, 9w~10w tps

undefined

  • 延迟时间:18s

undefined

  • EPS: 200w+/s, DML EPS:70w+/s

undefined

  • BPS: 200M/s

undefined

综述:35w qps压力下,已经接近220w/s的最大EPS能力,压测时间10分钟,最大延迟达到18s

Large Transaction

先来介绍几个参数

  • storage.isPersistOn

是否开启swap功能,即当内存不足或遇到大事务时,是否支持数据临时swap到磁盘(RocksDB),默认为true

  • storage.persist.mode

持久化模式,可选配置有两个:AUTO和FORCE。AUTO模式下,系统会根据内存使用率自动判断是否需要将数据swap到磁盘;FORCE模式下,系统会强制将数据swap到磁盘

  • storage.persistNewThreshold

内存中新增数据触发swap的阈值,即内存使用率达到多大之后,新增数据会被swap到磁盘,默认85%

  • storage.persistAllThreshold

内存中存量数据触发swap的阈值,即内存使用率达到多大之后,存量数据会被swap到磁盘,默认95%

5G Close Persist

单个事务大小5G,关闭swap功能,本测试场景,老年代内存14G,即使考虑到数据膨胀,足够放下5G数据

  • Delay Time: 所有数据完成排序时延迟7s,所有数据输出到全局binlog文件时延迟17s

undefined

  • Task进程内存: 老年代使用率显著提升

undefined

综述:关闭持久化,全内存模式下,5G数据在17S内完成同步,老年代内存使用率显著提升

5G Force Persist

单个事务大小5G,开启swap功能,并将持久化模式设置为FORCE

  • Delay Time: 所有数据完成排序时延迟10s,所有数据输出到全局binlog文件时延迟25s

undefined

  • CDC进程内存情况: 由于采用强制持久化机制,内存占用无起伏

undefined

综述:相比close persist模式,强制持久化模式下,延迟增加了8s,老年代内存占用无明显起伏

10G Auto Persist With 4G Memory

单个事务大小10G,开启swap功能,并将持久化模式设置为AUTO,Task进程内存设置为4G(无法放下10G数据),评测系统的自动持久化能力

  • Delay Time: 所有数据完成排序时延迟23s,所有数据输出到全局binlog文件时延迟55s

undefined

  • Task进程内存: 老年代并未显著上涨

undefined

  • Swap日志:单个局部事务大小超过阈值,直接触发了swap

undefined

综述:AUTO模式下,对于大事务的落盘,系统采取了更加积极主动的方式,即使内存使用率还未触发swap阈值,当单个局部事务大小超过阈值之后,也会直接触发swap,并且性能还算不错。之所以引入这种策略,主要原因是:

  • 出现大事务时,大概率会触发内存不足,直接触发swap,免去老年代GC的成本
  • swap操作虽然会有一定的损耗,但总体上的延迟还不错,优先考虑稳定性

20G Auto Persist With 4G Memory

单个事务大小20G,开启swap功能,并将持久化模式设置为AUTO,Task进程内存设置为4G(无法放下20G数据),评测系统的自动持久化能力

  • Delay Time: 所有数据完成排序时延迟49s,所有数据输出到全局binlog文件时延迟115s

undefined

  • Task进程内存: 老年代小幅上涨

undefined

  • Swap日志:单个局部事务大小超过阈值,直接触发了swap

undefined

总结

本文基于TPCC、Sysbench和Large Transaction3个场景,对全局Binlog的性能和稳定性情况进行了详细介绍,综合来看:

  • 写入吞吐可以达到500M/S(30G/min)左右,EPS指标可以达到220W/S左右,且内存使用率维持在较低的水位
  • TPCC场景,在150w tpmC压力下,延迟时间可以控制在4s以内,大部分时间段延迟时间保持在2s左右
  • Sysbench场景,30w QPS压力下,延迟时间可以维持在1s以内,更高压力下由于已经触达220w/s的EPS能力,延迟时间开始增长(继续提升EPS的上限是全局binlog后续的一个重点目标)
  • Large Transaction场景,依托自动swap能力,使用很小的内存可以稳定的同步超大事务,且能保持还不错的性能(继续优化swap的读写能力,延迟时间还有进一步的降低空间)

优化无止境,如果对PolarDB-X充满兴趣,可持续关注我们,最新的优化进展会持续更新。本文是全局Binlog性能解读系列的上篇,下篇将从原理层面展开深入介绍,敬请关注。

欢迎关注PolarDB-X知乎机构号,阅读更多技术好文。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
PolarDB-X 1.0-性能白皮书-PolarDB-X TPC-C测试说明
本文介绍如何使用TPC-C工具测试PolarDB-X数据库的联机交易处理(偏向OLTP能力),您可以按照本文介绍自行测试对比,快速了解数据库系统的性能。
0 0
PolarDB-X 1.0-性能白皮书-TPC-H测试说明
本文详细介绍了PolarDB-X的TPC-H测试设计、测试过程和测试结果。
0 0
PolarDB-X 1.0-性能白皮书-PolarDB-X Sysbench测试说明
Sysbench 说明 Sysbench是一款开源的、模块化的、跨平台的多线程性能测试工具,可以执行数据库、CPU、内存、线程、IO等方面的性能测试。目前支持的数据库有MySQL、Oracle和PostgreSQL。以下验证PolarDB-X在Sysbench OLTP和SELECT场景中的性能表现。
0 0
PolarDB-X 1.0-性能白皮书-Sysbench 使用指南
PolarDB-X 性能测试使用 Sysbench 作为压测工具,本文介绍 Sysbench 的使用方法。
0 0
PolarDB-X 1.0-常见问题-性能问题-如何选购PolarDB-X与RDS的规格,才会有比较好的性能?
关于选择PolarDB-X与RDS实例规格的问题,请参见选择PolarDB-X与RDS实例规格。
0 0
PolarDB-X 1.0-常见问题-性能问题-同一个 RDS 实例之间的跨库查询和多个 RDS 之间的跨库查询的速度差异有多大?
假定两种查询场景的查询数据量相同,并且不考虑 RDS 机器的硬件资源限制,那么,理论上后者会比前者查询更快(这在聚合查询场景更为典型)。因为后者并行度更高,能更好利用 RDS 的 CPU 资源与 IO 资源。
0 0
PolarDB-X 私有协议:提升集群的性能和稳定性
PolarDB-X的私有协议作为计算节点和存储节点之间的桥梁,主要实现查询下发和结果回传等基础功能,同时针对一些常用的场景进行了特殊优化。私有协议设计时借鉴了RPC的处理思路,采用了异步化协议设计、会话连接解耦、实例级连接池、流量控制等机制,解决了大部分使用传统连接池遇到的问题,使得PolarDB-X的性能和稳定性都有所提升。
0 0
百万级活跃用户、十亿级数据,揭秘PolarDB-X如何提升小打卡性能和稳定性
通过PolarDB-X+RDS MySQL的分布式数据库解决方案支持客户核心业务圈子打卡日记,采用PolarDB-X的水平拆分给客户提供海量数据存储能力,利用平滑扩容能力提供计算和存储的平滑扩展,可支持到百亿级数据存储和读写。
0 0
PolarDB-X迎来开源后首个重大版本升级,2.1版本新增5大特色功能
2022 年 5 月25日,阿里云开源 PolarDB-X 升级发布新版本!PolarDB-X 从 2009 年开始服务于阿里巴巴电商核心系统, 2015 年开始对外提供商业化服务,并于 2021 年10月正式开源。本次发布是开源后首个重大版本升级,重磅推出在稳定性、生态融合以及易用性上有了长足进步的 2.1 版本,该版本在内核能力上首次对齐商业版,新增 X-Paxos、自动分区、OSS 冷热数据分离等诸多重要特性,并在 MySQL 生态融合、K8S 生态融合方向持续迭代。
0 0
+关注
开源小秘书
开源数据库运营小编~
文章
问答
文章排行榜
最热
最新
相关电子书
更多
PolarDB-X 2.0核心技术能力解读
立即下载
PolarDB-X 基于 X-Paxos 一致性协议的高可用
立即下载
PolarDB-X (开源版)从入门到实战
立即下载


http://www.vxiaotou.com