跳至主要內容

Klustron(原KunlunBase) 1.1 性能对比测试报告

Klustron大约 3 分钟

Klustron(原KunlunBase) 1.1 性能对比测试报告

1. 测试场景及工具

在 Klustron 1.1 版本发布之后,我们针对新版本与其他竞品进行了性能对比测试。测试模型采用 TPCC。其中与 TiDB 的对比采用 go-tpc,该工具是 TiDB 提供的符合 TPCC 标准的压测工具。与 OceanBase 的对比测试中,采用了 benchmarkSQL 工具,该工具是 TPCC 的开源实现,该工具也是 OceanBase 官方推荐的压测工具。

2. 物理资源及部署配置

本次测试机器资源为阿里云 ECS,其中资源配置如下图标所示

资源名资源规格规格详情
CLIENTecs.c5.4xlargeVCPU:2 MEM:4
METAecs.g5.2xlargeVCPU:8 MEM:32
STORAGE001ecs.r6e.8xlargeVCPU:32 MEM:256
STORAGE002ecs.r6e.8xlargeVCPU:32 MEM:256
STORAGE003ecs.r6e.8xlargeVCPU:32 MEM:256
STORAGE004ecs.r6e.8xlargeVCPU:32 MEM:256
STORAGE005ecs.r6e.8xlargeVCPU:32 MEM:256
STORAGE006ecs.r6e.8xlargeVCPU:32 MEM:256

上表所列出来的所有的物理设备,都是在同一个可用区,因而内网带宽可以理解为没有瓶颈。同事每个 storage 设备,都会挂载一个200GB 的 ESSD 云盘作为主要的外存,所有的日志及数据都会落在该磁盘上。

2.1 Klustron 部署拓扑及配置

其中 Klustron 的部署模式如下:

组件/资源名metastorage1storage2storage3storage4storage5storage6
meta-cluster
shard1-Master
shard1-Slave
shard2-Master
shard2-Slave
shard3-Master
shard3-Slave
compute1
compute2
compute3

各组件的参数配置如下:

{
  "comp":[{
    "statement_timeout":1200000,
    "mysql_read_timeout":1200,
    "mysql_write_timeout":1200,
    "lock_timeout":1200000,
    "log_min_duration_statement":1200000
  }
  ],
  "metadata":[{
    "lock_wait_timeout":1200,
    "innodb_lock_wait_timeout":1200,
    "innodb_buffer_pool_size": "5*1024*1024*1024"
  }
  ],
  "storage":[{
    "innodb_buffer_pool_size": "10*1024*1024*1024",
    "lock_wait_timeout":1200,
    "innodb_lock_wait_timeout":1200,
    "fullsync_timeout":1200000,
    "enable_fullsync": "ON",
    "innodb_flush_log_at_trx_commit": 1,
    "sync_binlog": 1,
    "max_binlog_size": "1*1024*1024*1024"
  }
  ]
}

2.2 TiDB 部署拓扑及配置

组件/资源名metastorage1storage2storage3storage4storage5storage6
pd
tidb1
tidb2
tidb3
tikv1
tikv2
tikv3

相关组件参数:

server_configs:
  tidb:
    log.slow-threshold: 300
    log.level: "error"
  tikv:
    sync-log: true
    readpool.storage.use-unified-pool: false
    log-level: "error"
    rocksdb.defaultcf.block-cache-size: "10GB"
    rocksdb.writecf.block-cache-size: "6GB"
    storage.block-cache.capacity: "10GB"
    readpool.coprocessor.use-unified-pool: true
  pd:
    schedule.leader-schedule-limit: 4
    schedule.region-schedule-limit: 2048
    schedule.replica-schedule-limit: 64

2.3 OceanBase 部署拓扑及配置

组件/资源名metastorage1storage2storage3storage4storage5storage6
observer1
observer2
observer3
obproxy1
obproxy2
obproxy3

相关配置如下:

writing_throttling_trigger_percentage: 100
memory_limit_percentage: 80
syslog_io_bandwidth_limit: 10MB
enable_async_syslog: True
builtin_db_data_verify_cycle: 0
enable_monotonic_weak_read: False
weak_read_version_refresh_interval: 0
enable_sql_audit: False
enable_perf_event: False
syslog_level: PERF
devname: eth0
mysql_port: 2881
rpc_port: 2882
zone: zone1
datafile_size: 150G
appname: obcluster
root_password: observer
proxyro_password: obproxy
enable_syslog_recycle: true
enable_syslog_wf: true
max_syslog_file_count: 4

3. 性能对比

此次性能压测数据量为 100 warehouse,Klustron与 TiDB 的对比测试,采用 TiDB 开源 go-tpc 工具。Klustron 与 OceanBase 的对比测试,采用 benchmarkSQL 工具。该工具也是 OceanBase 官方推荐工具。测试共分 3 轮,每轮的并发数逐步递增,每轮测试时长为 10 mins。

3.1 Klustron VS TiDB(v6.5.0)

KlustronTiDB
threadstpmCtpmC
5074719.894909.6
100124970.4129772.6
200170531.1154680.8

3.2 Klustron VS OceanBase(v4.0.0)

KlustronOCEANBASE
threadstpmCtpmC
5055827.4350934.49
10091339.635916.29
20098710.1834571.55

4. 总结

在与 TiDB 的对比测试中,可以看到随着并发的增加,Klustron 的优势逐渐体现。在与 OceanBase 的对比测试中,Klustron 的线性扩展能力优势较为明显。

从性能对比测试的结果来看,目前 Klustron 在同等的物理资源以及请求压力下,性能数据的表现相对于友商产品保持一定的优势。随着版本的后续迭代,Klustron 事务处理的能力也会进一步加强,从而为客户创造更大的价值。

在整个对比测试的过程中,我们对友商产品的参数调优是通过参考对应产品的公开文档进行的,因此可能也会有遗漏,导致没有展现出竞品的最优性能的情况出现。我们也希望和欢迎社区内有相关经验的同学能够仔细检查我们对 TiDB 和 OceanBase 的性能测试方法和参数设置,如果发现有问题的话指出来并与我们展开讨论。

END