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表存储候选人编号和名字，该表的数据量较小，并且不会改变。
1CREATE TABLE contestants 2( 3 contestant_number integer NOT NULL 4, contestant_name varchar(50) NOT NULL 5, CONSTRAINT PK_contestants PRIMARY KEY 6 ( 7 contestant_number 8 ) 9);
vote表存储每一次投票的信息，包括投票电话、州名和所投的候选人编号。同时该表的会按电话号码做多节点分区。
1CREATE TABLE votes 2( 3 phone_number bigint NOT NULL 4, state varchar(2) NOT NULL 5, contestant_number integer NOT NULL 6); 7PARTITION TABLE votes ON COLUMN phone_number;
area_code_state表存储州编号和州名的映射关系。
1CREATE TABLE area_code_state 2( 3 area_code smallint NOT NULL 4, state varchar(2) NOT NULL 5, CONSTRAINT PK_area_code_state PRIMARY KEY 6 ( 7 area_code 8 ) 9);
根据voter表创建视图v_votes_by_phone_number，表示每个电话号码已经投票的次数（应用限制最大投票次数）
是的，voltdb支持Create View。根据官方文档的解释，VoltDB存储的是物理视图，即每次插入、更新、删除数据都会修改物理视图中所关联记录的数据。
1CREATE VIEW v_votes_by_phone_number 2( 3 phone_number 4, num_votes 5) 6AS 7 SELECT phone_number 8 , COUNT(*) 9 FROM votes 10GROUP BY phone_number 11;
根据contestants表创建视图v_votes_by_contestant_number_state，表示每个候选人来自不同州的投票数。
1CREATE VIEW v_votes_by_contestant_number_state 2( 3 contestant_number 4, state 5, num_votes 6) 7AS 8 SELECT contestant_number 9 , state 10 , COUNT(*) 11 FROM votes 12GROUP BY contestant_number 13 , state 14;
2、存储过程
voter中定义了5个存储过程，其中主要的Vote存储过程包含4个statement，三次Select和一次Insert
通过候选人编号，查询候选人
1public final SQLStmt checkContestantStmt = new SQLStmt( 2 "SELECT contestant_number FROM contestants WHERE contestant_number = ?;");
通过电话号码，查询该号码已投的票数
1public final SQLStmt checkVoterStmt = new SQLStmt( 2 "SELECT num_votes FROM v_votes_by_phone_number WHERE phone_number = ?;");
通过州编号，查询州名
1public final SQLStmt checkStateStmt = new SQLStmt( 2 "SELECT state FROM area_code_state WHERE area_code = ?;");
将投票的电话号码、来源州、投票对象记录到votes表，同时更新两个视图
1public final SQLStmt insertVoteStmt = new SQLStmt( 2 "INSERT INTO votes (phone_number, state, contestant_number) VALUES (?, ?, ?);");
存储过程，输入投票电话、候选人编号，以及每个电话最大投票数（常量）
1public long run(long phoneNumber, int contestantNumber, long maxVotesPerPhoneNumber) { 2 voltQueueSQL(checkContestantStmt, EXPECT_ZERO_OR_ONE_ROW, contestantNumber); 3 voltQueueSQL(checkVoterStmt, EXPECT_ZERO_OR_ONE_ROW, phoneNumber); 4 //根据电话号码计算所在州区号 5 voltQueueSQL(checkStateStmt, EXPECT_ZERO_OR_ONE_ROW, (short)(phoneNumber / 10000000l)); 6 VoltTable validation[] = voltExecuteSQL(); 7 //验证输入的候选人编号是否合法 8 if (validation[0].getRowCount() == 0) { 9 return ERR_INVALID_CONTESTANT; 10 } 11 //验证该电话投票数是否到达上限 12 if ((validation[1].getRowCount() == 1) && 13 (validation[1].asScalarLong() >= maxVotesPerPhoneNumber)) { 14 return ERR_VOTER_OVER_VOTE_LIMIT; 15 } 16 //如果计算的州区号没有记录，投票仍然有效，州名记录为XX 17 final String state = (validation[2].getRowCount() > 0) ? validation[2].fetchRow(0).getString(0) : "XX"; 18 //完成投票 19 voltQueueSQL(insertVoteStmt, EXPECT_SCALAR_MATCH(1), phoneNumber, state, contestantNumber); 20 voltExecuteSQL(true); 21 return VOTE_SUCCESSFUL; 22}
另外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的，我知道，但总算有个开源数据库供我们学习之）
下期预告
- VoltDB的集群如何部署？
- 为什么我把voter服务端部署到两个节点之后，性能反而比单服务器下降了呢？
- 如何让VoltDB客户端支持路由？