voltdb mysql_voltdb的一些文档

粉丝平台

于 2021-01-30 12:54:55 发布

阅读量189

点赞数

文章标签： voltdb mysql

本文链接：https://blog.csdn.net/weixin_42240669/article/details/113548266

版权

本帖最后由〇〇于 2014-8-31 16:23 编辑

VoltDB实时投票应用性能测试

分类: 工作日志

2013-01

voter是votedb开源包中的一个性能测试程序，代码位于源码包examples/voter/目录下。该程序模拟短时间内大量用户发起投票的场景，测试每秒处理的投票请求(三次读一次写的事务)的能力。官方发布的两个基于该程序的性能测试报告。测试环境部署在12台Amazon E2云主机服务上，服务端版本是voltdb 2.2：

686K TPS with Spring Framework Web App and VoltDB

695k TPS with Node.js and VoltDB

本文将深入到voter程序内部，分析该测试的流程，以及给出自己的性能测试结果。 (本文代码部分的格式正在修改，先请将就看文本的)

1、表结构(ddl.sql)

contestants表存储候选人编号和名字，该表的数据量较小，并且不会改变。

CREATE TABLE contestants

(

contestant_number integer NOT NULL

, contestant_name varchar(50) NOT NULL

, CONSTRAINT PK_contestants PRIMARY KEY

(

contestant_number

)

);

vote表存储每一次投票的信息，包括投票电话、州名和所投的候选人编号。同时该表的会按电话号码做多节点分区。

CREATE TABLE votes

(

phone_number bigint NOT NULL

, state varchar(2) NOT NULL

, contestant_number integer NOT NULL

);

PARTITION TABLE votes ON COLUMN phone_number;

area_code_state表存储州编号和州名的映射关系。

CREATE TABLE area_code_state

(

area_code smallint NOT NULL

, state varchar(2) NOT NULL

, CONSTRAINT PK_area_code_state PRIMARY KEY

(

area_code

)

);

根据voter表创建视图v_votes_by_phone_number，表示每个电话号码已经投票的次数(应用限制最大投票次数)

是的，voltdb支持Create View。根据官方文档的解释，VoltDB存储的是物理视图，即每次插入、更新、删除数据都会修改物理视图中所关联记录的数据。

CREATE VIEW v_votes_by_phone_number

(

phone_number

, num_votes

)

SELECT phone_number

, COUNT(*)

FROM votes

GROUP BY phone_number

;

根据contestants表创建视图v_votes_by_contestant_number_state，表示每个候选人来自不同州的投票数。

CREATE VIEW v_votes_by_contestant_number_state

(

contestant_number

, state

, num_votes

)

SELECT contestant_number

, state

, COUNT(*)

FROM votes

GROUP BY contestant_number

, state

;

2、存储过程

voter中定义了5个存储过程，其中主要的Vote存储过程包含4个statement，三次Select和一次Insert

通过候选人编号，查询候选人

public final SQLStmt checkContestantStmt = new SQLStmt(

"SELECT contestant_number FROM contestants WHERE contestant_number = ?;");

通过电话号码，查询该号码已投的票数

public final SQLStmt checkVoterStmt = new SQLStmt(

"SELECT num_votes FROM v_votes_by_phone_number WHERE phone_number = ?;");

通过州编号，查询州名

public final SQLStmt checkStateStmt = new SQLStmt(

"SELECT state FROM area_code_state WHERE area_code = ?;");

将投票的电话号码、来源州、投票对象记录到votes表，同时更新两个视图

public final SQLStmt insertVoteStmt = new SQLStmt(

"INSERT INTO votes (phone_number, state, contestant_number) VALUES (?, ?, ?);");

存储过程，输入投票电话、候选人编号，以及每个电话最大投票数(常量)

public long run(long phoneNumber, int contestantNumber, long maxVotesPerPhoneNumber) {

voltQueueSQL(checkContestantStmt, EXPECT_ZERO_OR_ONE_ROW, contestantNumber);

voltQueueSQL(checkVoterStmt, EXPECT_ZERO_OR_ONE_ROW, phoneNumber);

//根据电话号码计算所在州区号

voltQueueSQL(checkStateStmt, EXPECT_ZERO_OR_ONE_ROW, (short)(phoneNumber / 10000000l));

VoltTable validation[] = voltExecuteSQL();

//验证输入的候选人编号是否合法

if (validation[0].getRowCount() == 0) {

return ERR_INVALID_CONTESTANT;

}

//验证该电话投票数是否到达上限

if ((validation[1].getRowCount() == 1) &&

(validation[1].asScalarLong() >= maxVotesPerPhoneNumber)) {

return ERR_VOTER_OVER_VOTE_LIMIT;

}

//如果计算的州区号没有记录，投票仍然有效，州名记录为XX

final String state = (validation[2].getRowCount() > 0) ? validation[2].fetchRow(0).getString(0) : "XX";

//完成投票

voltQueueSQL(insertVoteStmt, EXPECT_SCALAR_MATCH(1), phoneNumber, state, contestantNumber);

voltExecuteSQL(true);

return VOTE_SUCCESSFUL;

}

另外4个存储过程没有列入性能统计，不再具体介绍，含义如下：

• Initialize.java 初始化区号表和候选人表

• GetStateHeatmap 获取按分区得票数最高的候选人

• ContestantWinningStates.java 查询每个候选人早获胜的N个州

• Results.java 获得最终投票结果

3、单节点性能测试

测试环境是两台双路E5420服务器，服务端版本采用2013年1月刚发布的VoltDB 3.0开源版：

• CPU: 2 * E5420 (qual 2.5G)

• RAM: 8GB

• LAN: 1000Mbps

• 1 client，1 server

性能测试的配置参数包括：

• 服务端处理线程数，分别取1、2(默认值)、4、8、16

• 客户端连接模式，分别是sync同步、jdbc同步，async异步三种。

考察的性能指标包括：

• 每秒执行的事务数：tps

• 平均请求延时：latency_avg

• 95%最大请求延时：latency_95

• 99%最大请求延时：latency_99

以下是三种请求模式和不同服务端线程数情况下的性能曲线图，其中8线程异步模式下性能达到11.8万TPS。而两种同步模式下的性能最高值则是服务端4线程，分别是6.3万和5.9万。

(需要再次提醒，所统计的TPS性能是指每秒执行的事务数，包括三次读操作，其中两次是轻量级表的读，一次是对大表视图的读，以及一次带主键并发互斥的写操作。)

image

以下两张图分别是平均和95%延时统计。可以看出sync和jdbc两种同步模式下延时一直维持很低(小于5ms)。而async异步模式下，当服务端线程数小于等于8时，也保持低于20ms的水平，但当服务端线程数为16，平均和95%最大延时都出现了大幅的增加，分别达到了131ms和350ms。

imageimage

为了进一步分析上面不同线程数下“延时突变”现象，我有进行了进一步的测试——对线程数进行微调。从4到11每个线程数都测试async异步模式的延时，最终得到如下数据。当线程数低于6时，延时随线程数缓慢上升。而当线程数在7到10，延时则突然下降到小于10ms区间。当线程数增加到11以上后，又发生了延时数据的突变，产生了大幅增长。

image

仅从已测试数据来看，我们推测当服务端配置线程数接近服务器可用内核数时，VoltDB达到最优吞吐率和较理想的延时波动。当然由于本次测试的CPU不支持Intel超线程技术，不清楚这个关于内核数的推断应该适用于物理内核数、还是逻辑内核数。

从VoltDB公布的技术架构来看，以上推断也是可以成立的。VoltDB的服务端采用CPU级别的Share-noting设计，为每个线程分配了固定的主键区间，事务操作串行化，这样可以减少数据在CPU缓存和kenel内存区的加载频率，从而提高处理性能。当所服务端线程数与内核数相匹配，便恰好符合该设计。

最后总结以下，VoltDB的处理能力不一定超出Redis等KV数据库，但考虑其SQL和事务能力能力，而KV数据库如果需要应用控制事务性能往往大打折扣。因此，我们可以认为VoltDB是一个性能很强大的内存关系数据库，适合使用在需要实时高性能和事务支持的在线游戏、交易等业务。

(好吧，它是AGPL的，我知道，但总算有个开源数据库供我们学习之)

下期预告

• VoltDB的集群如何部署？

• 为什么我把voter服务端部署到两个节点之后，性能反而比单服务器下降了呢？

• 如何让VoltDB客户端支持路由？