VoltDB实时投票应用性能测试 - HelloWorld开发者社区

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性能是指每秒执行的事务数，包括三次读操作，其中两次是轻量级表的读，一次是对大表视图的读，以及一次带主键并发互斥的写操作。）

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

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

仅从已测试数据来看，我们推测当服务端配置线程数接近服务器可用内核数时，VoltDB达到最优吞吐率和较理想的延时波动。当然由于本次测试的CPU不支持Intel超线程技术，不清楚这个关于内核数的推断应该适用于物理内核数、还是逻辑内核数。
从VoltDB公布的技术架构来看，以上推断也是可以成立的。VoltDB的服务端采用CPU级别的Share-noting设计，为每个线程分配了固定的主键区间，事务操作串行化，这样可以减少数据在CPU缓存和kenel内存区的加载频率，从而提高处理性能。当所服务端线程数与内核数相匹配，便恰好符合该设计。

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

下期预告