TPCC测试究竟意味着什么

1、TPCC代表了什么

TPCC的业务场景其实很简单，本文中我们关注其中几个重要的概念即可：

仓库（Warehouse），有很多的仓库，每个仓库有很多的商品（Item），每个商品在每个仓库有自己的库存数目。仓的数目很多，比如一般测试都是1000仓起步（这个与一些电商平台是不一样的，例如淘宝，核心单元可能就个位数）。
买家（Customer），绝大多数情况下，买家只会从绑定的一个仓库买东西；少数情况下，买家才会从其他仓库买东西

基于这样的业务特征，所以在数据库的设计上，很容易想到将数据库按照仓库的ID（wid）进行分片。这种分片可以确保大多数的事务可以在单个分片内完成。

例如假设我们有这样一份TPCC的测试报告：

我们可以做如下的解读：

TPMC就是指每分钟下单（New-Order）的数量。是一般情况大家最关注的指标，也是TPCC官方进行性能排名使用的指标。
下单和支付（Payment）两种事务的数量，占了总事务量的45%+43%=88%。
90%的下单操作是单机事务，85%的支付操作是单机事务，分布式事务合计占比45%*10%+43%15%=11%。整个集群分布式事务的TPS是：100,000,00011%/60=18万TPS
按机器数做下平均，每台机器贡献的单机TPMC是1亿/22289%=40万，分布式TPMC是1亿/22211%=5万，加起来是45W

可以看出，TPCC中，TPMC指标中最大头是单机事务贡献的。但是，这种单机事务其实是无法体现分布式特有的一些问题的，例如，节点之间无需互相传递数据，也无需对事务的状态进行协调等。

这里的第一个结论是，TPCC可以很好的体现一个数据库的单机性能，但是它无法很好的体现一个分布式数据库的分布式事务能力（性能、扩展性，甚至在一些不严格的测试中，连一致性也无法验证）

如果真的像TPCC一样，严格控制分布式事务的使用，对业务来说代表了什么？

代表业务永远都要去考虑分区键这个东西，只有业务能划出很统一的分区键，才能尽可能的去减少分布式事务。

无论一个分布式数据库号称多么“先进”，只要它需要你去设计分区键，那其实它就是个“伪”分布式数据库。使用这样的数据库，和使用分库分表中间件+单机数据库没有太明显的区别。

事实上，分库分表中间件+单机数据库除了这11%的分布式事务无法实现，TPCC的其他指标诸如性能、扩展性都能做的很好。只要加足够多的机器，一样能跑到很高的TPMC，这个过程会是非常线性的。只是那11%的分布式事务，阻止了分库分表+单机数据库的方案。

这里的第二个结论是，如果你的业务愿意像使用中间件“谨慎并良好的设计每个表的分区键，避免分布式事务”一样去使用分布式数据库，那么每台机器承载的TPMC（上例中的45万）是很好的参考依据，集群的总TPMC（上例中的1亿）并没有太大的参考价值