voltdb mysql_voltdb的一些文档

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

VoltDB实时投票应用性能测试

分类: 工作日志

27

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

)

AS

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

)

AS

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客户端支持路由?

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页