为了成功的实施VoltDB,必须了解清楚VoltDB的机制，如何设计一个好的数据库系统。
以下建议翻译自VoltDB官方文档《VoltDB Do's and Don'ts》以及一些个人理解。
Do's
1.设计好的表分区算法，最大化单分区事务，最小化多分区事务。（说白了就是降低跨分区的事务，因为跨分区的开销是比较大的，这种事务一多的话VoltDB的吞吐量就降低下来了，性能可能会比传统的OLTP还烂。）
2.评估数据卷已使用频率，应用的所有事务，决定采用哪些列作为分区列。（与第一条雷同）
3.当某存储过程是单分区运行时，使用@ProcInfo来指出。（否则，VoltDB会认为是多分区执行的模式）
4.在同一个存储过程中使用多条SQL比把每一条SQL放在不同的存储过程效率高出10倍多。（有点类似于多步提交和单步提交带来的明显差异）
5.在每一个存储过程的最后一个voltExecuteSQL()后面加上一条IsFinal的结束语句，这将带来性能提升，特别是在多分区模式。
6.不同的应用采用的节点数应该是不一样的，为了获得最匹配的节点数量，应该做真实的应用测试。（不是节点越多越好，哈哈。能满足应用需求是最好的，否则多在那里也是增加无用的碳排放）
7.使用异步函数调用，客户端连接到VoltDB的所有节点，以最大化吞吐量。
8.检查异步函数调用的返回值，确保已经在队列中。如果不在队列中，在调用下一个异步操作时，先调用backpressureBarrier()等待队列清空。
Don'ts
1.尽量不要在生产环境使用特殊SQL查询。
2.如无特殊需求，尽量不要因为某些表的记录比较少，就把这些表作为复制表。（如果是UPDATE较多的表，复制的话就会影响性能。）
3.不要创建非常大的行记录的表。（如表中包含的字段较多，或者使用了较大的VARCHAR），使用小表，公共的分区键值来满足这类需求较好。
4.尽量避免不带约束条件的查询，或者说尽量避免大数据量返回的查询，特别是在多分区事务中。（因为VoltDB的串行处理机制？）
5.尽量少在异步回调中做扩展处理。这样做可以避免回调被阻塞或停止。
6.不要试图在单机上测试应用系统性能，在多机上体现出来的是完全不一样的。（多机的话要考虑复制，分区等，还是尽量模拟真实环境吧）
7.不要假设任何单个事务的低延时，VoltDB设计初衷是整个应用的高吞吐量，而不是单个事务的低延时。（貌似又是串行机制的弊端，没有锁造成的。唉！绝对要避免单事务的延时才行！！否则就等着吧）
8.不要在客户端多次调用ClientFactory.createClient(),可以有多个客户端连接到数据库集群，并且每个客户端都可以有多个连接到数据库集群。但是每个客户端只能有一个客户端实例。
总结：
1.好像很多约束都是为了获得更短的单事务时间消耗，原因是不是VoltDB是串行执行造成的呢？这是我的个人见解。
2.VoltDB适合真正的OLTP系统，（事务粒度小，事务量多。)
3.如何解决长事务？貌似目前VoltDB的杀手就是长事务啊。看样子在做应用设计时应该考虑到应对措施才行。否则会死得很惨
