VoltDB是一个宣称性能超过Mysql 100倍的新型数据库。它源自Micheal Stonebraker一篇论文H-Store。在这篇论文发表后，Stonebraker成立了VoltDB公司带着他的一些学生开始在OLTP数据库领域打拼。Stonebraker从上世纪70年代——数据库刚开始发展的时间——就开始在数据库领域活跃，这样的老古董提出的数据库的新想法，给了整个存储领域很大的想象空间。
VoltDB源起于应用领域与硬件发展翻天覆地的变化。用户的使用方法发生了变化，在数据库开始发展的阶段，事务是一个较长的过程，用户或者管理员可以在”BEGIN TRANSACTION”和”END TRANSACTION”之间慢慢地人工执行整个事务的步骤。但是现在，大部分操作是由Web服务端发起的书写良好的事务，用户访问的是Web服务器，在Web服务器的执行逻辑里再访问数据库，所以即使是很复杂的事务也可以很快执行完。计算机硬件的发展更是一日千里。几十GB的内存服务器已经很常见。以太网络也已经步入Gbps时代，而且正在朝向10Gbps方向迈进。基于以太网的集群的机器价格也降低到比PC机贵不了太多。VoltDB的设计充分利用了这些特点，数据主要存储在内存中，Shared Nothing的集群结构，单机是单线程处理事务，不是用锁而是基于Optimistic的方法处理事务并发，所有的事务必须以存储过程形式先提交到VoltDB系统。下面分开来说。
事务提交
既需要支持复杂的事务操作，又需要快速的执行过程，VoltDB采取了一个比较极端的事务提交方式。虽然VoltDB支持部分SQL语句接口，但是不允许用户使用传统的”BEGIN TRANSACTION”和”END TRANSACTION”的语法模式，而是完全基于存储过程。用户通过写存储过程完成应用程序的逻辑，作为一个先置条件将存储过程提交到VoltDB。运行时，用户程序调用存储过程完成事务操作，所有事务的运行逻辑是由VoltDB在服务器进程中完成的。这种方式保证了事务不会被人为打断，并且服务器可以预先判断各个事务的逻辑，也为事务并发处理挖掘信息。
数据分布
VoltDB使用Shared Nothing结构，整个数据库的数据分散到集群的多台机器上。VoltDB的数据分布策略是基于哈希的，存储在VoltDB中的每一张表，对数据的主键哈希取模后的结果对应于数据存储的节点。相比较于BigTable基于主键的连续范围分段的方法，哈希方法的好处是数据分散的均匀，没有动态数据调整的烦恼。但也有很多缺点，采用这种方法后，集群的规模是事先确定好的，新增机器需要停止服务后重新分布数据。另外，数据哈希被分散后，数据的连续性被打乱了，在这个数据结构上做范围查询需要动用服务这张表的所有机器，这个后面会祥说。
VoltDB集群的每台机器都会服务多张表。VoltDB的数据复制是基于机器单位的，蓝色框圈住的两台机器内的数据是完全同构的。
VoltDB的哈希分布数据的方法是系统设计的简化，这种简化让VoltDB工程实现难度降低，可以快速的商用。天下没有免费的午餐，这个设计也是VoltDB功能缺陷，导致VoltDB无法动态扩容以及其他一些问题。
数据一致性
同一份数据的多个副本之间需要保证数据一致性，VoltDB采用所有修改操作在每一个副本上单独更新的方式。如何保证更新操作在所有副本上以相同的顺序更改而不至于产生不一致，这就要提到VoltDB的并发控制方式。
VoltDB的事务并发控制需要依赖于集群内所有机器的时间是一致的，这个可以使用NTP之类的时间同步协议，保证机器之间的时间差异远远小于一个交换机下的两台机器之间的Round Trip时间。VoltDB对于用户每一次事务的调用分配一个时间戳，并且保证这个时间戳是全局有序的，虽然时间戳是由集群中的各台机器独自分配的，但是加上机器的序号，可以保证（机器序号，时间戳）的组合值是全局有序的。一台服务器执行事务之前，需要等待Round Trip时间后，如果其他机器没有开始比自己更早的事务，那么就执行自己的事务。以这种方式保证集群内多台机器之间事务的有序。数据的多个副本的更新操作也都以相同的顺序进行修改，所有副本之间保证了一致性。
事务并发处理
为了充分发挥多核机器的性能，而又不引入多线程执行事务的复杂性，VoltDB的数据分片规模是按照集群核数来划分的。一台物理机器上可能运行多个VoltDB服务器进程，每个进程对应于一个核，服务器进程之间都是通过网络进行通信。在单个进程内，只使用单线程，所有的事务执行都是顺序进行的。
多个事务在多个服务器节点同时执行，VoltDB保证如果事务之间有冲突，那么事务的执行是完全隔离的，即达到SERIALIZABLE ISOLATION。VoltDB会事先分析好存储过程之间的关系，如果两个事务可能存在冲突，则不让这两个进程在同一个时间执行。
在VoltDB的并发处理中，每一个事务在执行之前都要等待一个Round Trip时间，显然会增加事务执行的时延。这么做是为了确保别的节点没有发起比这个事务更早的事务，保证事务执行的顺序。在实现中，VoltDB用了另外一种优化方法。例如A，B两个节点，分别要执行事务1和2，A节点开始执行事务1的时间是T1，如果A收到B发了事务2的执行需求，并且T2 > T1，那么A节点可以确认从B节点不会有更早的事务再发送过来，A节点就不必等Round Trip时间，可以直接执行事务1。当整个系统压力比较大时，这个优化方法效果尤其明显，事务的时延有效降低。
VoltDB还花了很大精力在处理事务之间的逻辑关系，尽可能对事务分门别类进行处理，以期获得更好的性能。
范围查询的处理
VoltDB取巧的采用的哈希的方法做数据分布，在面对范围查询的需求时，再次吃到苦果。哈希方法打乱了数据的连续性，对于范围查询的处理能力显著下降。VoltDB执行某张表的范围查询，需要发送这个查询到这张表的所有数据分片上。在所有分片完成同样的范围查询，再将结果汇总，才能得到全局的准确结果。所以VoltDB处理范围查询会很低效
数据持久化
虽然Stonebraker在H-Store的论文里反复提到，在内存型数据库里，即使使用Group Commit写操作日志也是非常低效的，但是为了保证数据的持久性，VoltDB还是不得不采用记操作日志的办法。VoltDB使用定期做Snapshot加上记操作日志来保证数据持久性，这种方法没有什么特别的地方。