转自：https://blog.csdn.net/ransom0512/article/details/50440316
http://www.360doc.com/content/16/0712/11/9200790_574921580.shtml
https://www.cnblogs.com/kkyycom/p/9359090.html
VoltDB数据库是一个分布式，可扩展，shared-nothing的内存数据库。使用JAVA 写的存储过程来定义事务。使用标准SQL访问数据，使用并行的单线程处理方式确保数据一致性，同时避免了传统数据库的锁，插销，资源管理开销。
VoltDB具有如下特点：
- 高吞吐量：百万次每秒
- 横向拓展：可以根据需求自由拓展，性能线性增长。
- 高可用性：数据支持副本、也可以持久化保存、除此之外，还支持双活机制。
- 实时数据分析：数据实时性高，因为都是内存计算。
- 完整ACID支持，保证事务性和可靠性。
VoltDB的设计动机来源于内存成本的大幅下降，系统对于数据的时效性要求越来越高，而传统数据库由于数据在本地文件保存，所以不论并发还是处理速度，都难以满足要求。而新型的NoSQL数据库，又缺乏SQL支持以及完整的ACID的支持，完全无法提单传统数据库。
VoltDB、NoSQL和传统关系型数据库的对比如下所示：
适用场景
VoltDB适合OLTP系统，单个事务较小，但是事务总量非常之多的应用。比如金融，零售，WEB2.0等传统OLTP应用。不适合进行范围查询或者频繁多表Join这样的场景。
设计思路
高吞吐量、实时性
VoltDB通过对传统数据库进行分析，发现数据只有12%的CPU时间在做真正有意义的数据操作，而其他绝大部分时间都被缓存，并发控制等步骤消耗了。
- 索引管理(Index Management)：数据库的索引一般是基于B树的，这些索引会显著消耗IO和CPU。
- 日志(Logging)：传统数据库一般会写两次日志，一个是数据库数据存储部分，一个是数据库恢复日志，而且这些操作都必须强制性刷到磁盘上去，这就带来显著的IO消耗。
- 锁(Locking)：数据的读写操作都会涉及到锁，这是一个十分频繁的操作。
- 锁管理器(Latching)：全局共享的数据比如索引数据，表元数据，资源信息等，都必须保障多线程环境下的可靠运行，所以这种锁管理器无疑会消耗更多的CPU资源。
- 缓存管理(Buffer Management)：数据存储在固定大小的磁盘页中，缓冲池则管理着这些磁盘页，这些都会来言密集的IO操作。
综上，有88%的CPU时间都浪费在这些对于实际操作无意义的步骤上去了，要提升数据库性能，只有从根本上减少这种冗余的步骤，集中进行数据运算，才能完全利用CPU。
VoltDB通过内存存储、数据分区和无锁计算来实现高性能运算。
- 内存存储
VoltDB所有数据都保存在内存中(可靠性中会有数据刷到磁盘，见VoltDB ACID中可靠性设计), 内存存取速度已经比磁盘远远高出几个数量级了，这就是VoltDB高性能的重要原因。 - 数据分区
VoltDB对每个节点的内存进行管理，在每个节点上创建多个分区，所有分区表中的数据，都分散在各个分区中，然后在读写的时候，就可以实现多个分区并发进行，所以拓展性是线性提升的。
这种分区机制也会带来问题，当集群需要扩容的时候，需要停止整个集群，然后再进行扩容；当集群启动的时候，VoltDB会重新调整数据分布，在所有数据分布调整完毕之后，才开始提供服务。 - 无锁计算
VoltDB数据分区存放，在执行SQL语句的时候，客户端就会根据条件自动判断数据在哪个分区中，然后下发至该分区执行。如果查询条件中不包含分区列，那么就会由客户端进行统一控制，在每个分区上都进行查询之后，再统一返回结果，这种场景会极大影响性能。
VoltDB的程序都是以存储过程的方式执行的，支持使用java或者其他语言定义存储过程。每个分区的存储过程执行都是单线程线性执行的，这就保证了单分区的无锁设计。当一个语句涉及到多个区分协调读写的时候，VoltDB会在协调，统一锁定分区队列，等该语句执行完毕之后，才会释放锁。所以多分区操作才会如此消耗性能。
VoltDB在分区管理上，建议每个物理CPU创建一个分区，这样单个分区内的数据都在CPU的一级缓存和二级缓存上，避免在多个CPU之间的数据操作，最大限度的提升CPU利用率，避免并发锁。所以理论上，VoltDB的CPU使用率是可以达到100%的。
横向拓展
VoltDB多分区设计，使得数据分散在各个分区中，每个分区可以提供并发访问，既提升了性能，也达到了无锁的效果。所以理论上，VoltDB的横向拓展可以使得性能得到线性提升。
高可用性
VoltDB使用K-safety、双活、snapshot、WAL机制组合机制保证数据的高可用性。
- K-Safety
其实就是N+1的副本机制，VoltDB在写数据操作的时候，会在每个副本中执行该语句，这样就可以保证数据被正确插入每个副本。这N+1的副本都可以同时提供访问，同时允许最多N个副本丢失(分区故障), 当N+1个副本都不可用的时候，VoltDB就会停止服务进行修复。 - 双活
多集群双活机制，两个集群都可以提供服务，数据在多分区之间异步复制，当一个集群挂了的时候，另外一个集群提供服务，当异常集群恢复之后，会自动进行数据同步，只有数据一致的时候，才会提供服务。但是这种机制其实还是有问题，有可能导致数据不一致，因此同步复制机制还是需要的。 - Snapshot
由于数据在内存中存放，当节点掉电的时候，数据就会丢失，所以VoltDB会定期对每个分区数据做快照，以备节点掉电时候进行恢复。 - WAL
Write ahead log，VoltDB会在对数据进行插入操作的时候，预先进行写日志操作，这个和传统数据库一样，但是由于是顺序写入，所以性能还是比传统数据库要好很多。
Snapshot机制和WAL机制会导致造成性能5%左右的下降，不过这个也是为了完整ACID不得不做出的牺牲。
分区表和复制表
- 分区表
创建表之后，需要手工执行分区语句为表进行分区。
PARTITION TABLE towns ON COLUMN state_num;
该语句表明使用state_numn字段为towns表进行分区。之后插入数据的时候，VoltDB会自动将数据插入指定分区。
目前VoltDB只支持Hash分区，后续可能会考虑支持范围分区。
VoltDB的分区是一个逻辑上的概念，一个分区中可能包含多个表的多个数据分区的数据。VoltDB建议按照物理CPU的数量进行分区，每个分区独立使用一个CPU，这样可以避免CPU之间的锁竞争。 - 复制表
一个表，没有指定分区，那么就是一个复制表。这个表的特征就是会在每个分区保存一份全量副本，这样在和其他表在做Join查询的时候，就不会跨节点查询，大大加快Join速度。
复制表适合于数据比较稳定，只有少量更新的场景。如果数据要更新，就意味着要在每个分区上都执行一次插入操作，这种操作会显著降低系统并发度。
性能
VoltDB 宣称具备非常高的可伸缩性，超过 120 个分区、39台服务器，可在 300 个 CPU 核心上每秒钟处理 160 万的复杂事务
VoltDB在资料中有一个和数据库进行的性能对比，结果如下：
Dell R610, 2x 2.66Ghz Quad-Core Xeon 5550 with 12x 4GB (48GB) DDR3-1333 Registered ECC DIMMs, 3x 72GB 15K RPM 2.5in Enterprise SAS 6GBPS Drives
ACID
- 原子性（Atomicity）
VoltDB通过使用存储过程来确保原子性，一个存储过程执行必须等待前一个存储过程成功或因为失败而回滚结束。- 一致性（Consistency）
VoltDB强数据类型约定，在所有的数据库查询中强制schema与数据类型约束.- 隔离性（Isolation）
VoltDB事务全局（所有被影响的分区）顺序执行（没有交叉）（任何一个分区同一时间只有一个执行，即串行的）。- 持久性（Durability）
VoltDB提供K-safely机制以及snapshot,确保数据持久化。
License
License为AGPL，该许可比GPL要求更加严格，产品即使以WEB的方式发布了，也必须公开源代码。在使用的时候需要小心。
