内存数据库，顾名思义就是将数据放在内存中直接操作的数据库。相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。同时，内存数据库抛弃了磁盘数据管理的传统方式，基于全部数据都在内存中重新设计了体系结构，并且在数据缓存、快速算法、并行操作方面也进行了相应的改进，所以数据处理速度比传统数据库的数据处理速度要快很多，一般都在10倍以上。内存数据库的最大特点是其“主拷贝”或“工作版本”常驻内存，即活动事务只与实时内存数据库的内存拷贝打交道。
 
 
 内存数据库与传统数据库的异同
 
 　　内存数据库的目标是通过使用内存实现数据存储来提高吞吐量和降低延迟。这与使用磁盘存储的传统数据库管理系统不同，由于内部优化算法更简单，而且执行的CPU指令较少，所以内存内数据的速度比基于磁盘的数据库快。访问内存数据可以提高响应速度，对于一些响应时间要求较高的应用程序，如交易、电信和国防系统，一般都会使用内存数据库。由于内存数据库的这种特性，这些数据库使用内存要多于磁盘数据库产品。具体差别如下：
 
 　　1. 传统的数据库系统是关系型数据库，开发这种数据库的目的，是处理永久、稳定的数据。关系数据库强调维护数据的完整性、一致性，但很难顾及有关数据及其处理的定时限制，不能满足工业生产管理实时应用的需要，因为实时事务要求系统能较准确地预报事务的运行时间。
 
 　　2. 对磁盘数据库而言，由于磁盘存取、内外存的数据传递、缓冲区管理、排队等待及锁的延迟等使得事务实际平均执行时间与估算的最坏情况执行时间相差很大，如果将整个数据库或其主要的“工作”部分放入内存，使每个事务在执行过程中没有I/O，则为系统较准确估算和安排事务的运行时间，使之具有较好的动态可预报性提供了有力的支持，同时也为实现事务的定时限制打下了基础。这就是内存数据库出现的主要原因。
 
 　　3. 内存数据库所处理的数据通常是“短暂”的，即有一定的有效时间，过时则有新的数据产生，而当前的决策推导变成无效。所以，实际应用中采用内存数据库来处理实时性强的业务逻辑处理数据。而传统数据库旨在处理永久、稳定的数据，其性能目标是高的系统吞吐量和低的代价，处理数据的实时性就要考虑的相对少一些。实际应用中利用传统数据库这一特性存放相对实时性要求不高的数据。
 
 　　在实际应用中这两种数据库常常结合使用，而不是以内存数据库替代传统数据库。
 
 
 
 
 常用的几种内存数据库：
 
 eXtremeDB：eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库，只有50K到130K的开销，速度达到微秒级。eXtremeDB完全驻留在主内存中，不使用文件系统（包括内存盘）。eXtremeDB采用了新的磁盘融合技术，将内存拓展到磁盘，将磁盘当做虚拟内存来用，实时性能保持微秒级的同时，数据管理量在32BIT下能达到20G。支持跨平台,支持多种开发语言, 但不开源不开源，价格不菲。
 Oracle TimesTen：Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业（例如电信、资本市场和国防）所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。不开源，价格不菲。
 SolidDB：Solid Information Technology 成立于 1992 年，全球总部位于加州Cupertino，Solid数据管理平台将基于内存和磁盘的全事务处理数据库引擎、载体级高可用性及强大的数据复制功能紧密地融为一体。
 Altibase：ALTIBASE公司从1999年就一直致力于内存数据库软件和其应用的开发，提供高性能和高可用性的软件解决方案。特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。目前占据80%以上内存数据库市场，可以说是当今数据库软件技术的领导者。目前Altibase在国内成功案例也比较多，尤其是在电信行业，已经得到了广泛认可。
 
 Hsqldb 支持跨平台，支持java，内存数据库，开源
 
 BerkeleyDB  支持跨平台，分为C++版和Java版 ，内存数据库，开源
 
 Postgresql 支持跨平台，非内存数据库，开源
 SQLite  支持跨平台，内存数据库（非默认），开源
 
 Redis 内存数据库，开源
 
     
 
 
 
 
 

内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用，关注性能，作用类似于缓存，并不注重数据完整性和数据一致性。基于键值型的内存数据库比关系型更加易于使用，性能和可扩展性更好，因此在应用上比关系型的内存数据库使用更多。本文首先比较FastDB、Memcached和Redis主流内存数据库的功能特性，再从性能上比较H2、Memcached和Redis三种内存数据库，希望大家能够根据自己业务需求的具体特点，选择合适的开源产品。
 
主流内存数据库功能比较
 FastDB
 FastDb是高效的关系型内存数据库系统，具备实时能力及便利的C++接口。FastDB针对应用程序通过控制读访问模式作了优化。通过降低数据传输的开销和非常有效的锁机制提供了高速的查询。对每一个使用数据库的应用数据库文件被影射到虚拟内存空间中。因此查询在应用的上下文中执行而不需要切换上下文以及数据传输。fastdb中并发访问数据库的同步机制通过原子指令实现，几乎不增加查询的开销。
 
    FastDB的特点包括如下方面：
 
1、FastDB不支持client-server架构因而所有使用FastDB的应用程序必须运行在同一主机上；
 
2、fastdb假定整个数据库存在于RAM中，并且依据这个假定优化了查询算法和接口。
 
3、fastdb没有数据库缓冲管理开销，不需要在数据库文件和缓冲池之间传输数据。
 
4、整个fastdb的搜索算法和结构是建立在假定所有的数据都存在于内存中的，因此数据换出的效率不会很高。
 
5、Fastdb支持事务、在线备份以及系统崩溃后的自动恢复。
 
6、fastdb是一个面向应用的数据库，数据库表通过应用程序的类信息来构造。
 
    FastDB不能支持Java API接口，这使得在本应用下不适合使用FastDB。
 
Memcached
 Memcached是一种基于Key-Value开源缓存服务器系统，主要用做数据库的数据高速缓冲，并不能完全称为数据库。
 
    memcached的API使用三十二位元的循环冗余校验（CRC-32）计算键值后，将资料分散在不同的机器上。当表格满了以后，接下来新增的资料会以LRU机制替换掉。由于    memcached通常只是当作缓存系统使用，所以使用memcached的应用程式在写回较慢的系统时（像是后端的数据库）需要额外的程序更新memcached内的资料。

    memcached具有多种语言的客户端开发包，包括：Perl、PHP、JAVA、C、Python、Ruby、C#。
 
Redis
 Redis是一个高性能的key-value数据库。redis的出现，很大程度补偿了memcached这类keyvalue存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了C++、Java、Python，Ruby，Erlang，PHP客户端。
 
小结
 由于不支持Java客户端，因此FastDB并不合适。在Memcached和Redis的比较上，分为性能和功能两个方面。
 
    关于性能方面的详细内容建议继续阅读后面的内容，我对H2、Memcached和Redis亲自从读写删三方面进行了性能测试。

    因此从内存数据库功能特性方面综合来看，推荐使用Redis。
 
主流内存数据库性能比较
 测试目的
 本次性能测试选择目前成熟度和使用度都比较高的内存数据库，通过读写的性能测试比较这些主流数据库中的性能优劣。在性能测试过程中同时记录各个产品的稳定性。
 
    比较的内存数据库包括Memcached、Redis、H2。
 
测试方法
 性能测试主要包括对内存数据库读、写、删除的测试。
 
    使用单个线程将一定量的记录插入内存数据库，记录插入时间，每条记录的数据大小相同；然后在进行一定量的读操作，记录读出时间；最后将这些数据删除，记录时间。
 
根据读写效率综合评估内存数据库性能。
 
    具体的测试数据量为：
 
1、插入10000条数据，记录时间；
 
2、读取上述10000条数据，记录时间；
 
3、将上述10000条数据逐条删除，记录时间。
 
测试环境
 本次测试共需要使用一台联系服务器，配置如下：
 
CPU：Intel® Xeon® CPU E7-4830 @ 2.13GHz，共32个CPU，每个CPU8核；
 
内存：物理内存8G，交换分区9G；
 
磁盘：物理磁盘250G；
 
网卡：单网卡，带宽上限1000Mbps，全双工
 
    在该服务器上搭建中标云平台，并创建虚拟机，三种内存数据库均部署在该虚拟机中，虚拟机配置为：
 
CPU：Intel® Xeon® CPU E7-4830 @ 2.13GHz，共2个CPU，每个CPU8核；
 
内存：物理内存1G，交换分区5G；
 
磁盘：物理磁盘50G；
 
网卡：单网卡，带宽上限1000Mbps，全双工
 
    测试应用部署在一台普通台式机中，台式机配置为：
 
CPU：Intel® Xeon® CPU E7-4830 @ 2.13GHz，共2个CPU，每个CPU2核；
 
内存：物理内存1G，交换分区2G；
 
磁盘：物理磁盘64G；
 
网卡：单网卡，带宽上限1000Mbps（共享），全双工
 
    台式机和服务器采用普通内部局域网连接。
 
内存数据库部署
 Memcached
 Memcached的安装前先安装依赖的libevent库，步骤如下：
 
tar -zxvf libevent-2.0.12.stable.tar.gz
 
cd libevent-2.0.12.stable
 
./configure –prefix=/usr/libevent
 
make
 
make install
 
    安装的memcached需要从源码编译安装，步骤如下：
 
tar -zxvf memcached-1.4.15.tar.gz
 
cd ./memcached-1.4.15
 
./configure –with-libevent=/usr/libevent
 
make
 
make install
 
Redis
 Redis的安装也是从源码开始，将Redis源码压缩包拷贝到/usr/local/目录下，安装步骤如下：
 
tar -zxvf redis-2.6.14.tar.gz
 
cd ./redis-2.6.14
 
make
 
    开启Redis服务器和Redis自带的客户端访问工具如下：
 
src/redis-server
 
src/redis-cli
 
H2
 H2的安装较为简单，直接使用unzip命令进行解压即可。
 
    解压之后进入bin目录，并修改h2.sh文件中的Java命令启动的主类和选项为：
 
org.h2.tools.Server -tcpAllowOthers -webAllowOthers
 
    然后执行脚本h2.sh即可启动数据库。H2提供本地命令行控制台，启动方式为：
 
java -cp *.jar org.h2.tools.Shell
 
    一般来说，使用图形化的Web界面更为方便。
 
测试结果
 Memcached的测试结果如下：
 
Benchmark result has listed as follow:
 
Set Data spent time (ms): 344
 
Get Data spent time (ms): 8297
 
Delete Data spent time (ms): 187
 
    Redis的测试结果如下：
 
Benchmark result has listed as follow:
 
Set Data spent time (ms): 5594
 
Get Data spent time (ms): 6312
 
Delete Data spent time (ms): 3969
 
    H2的测试结果如下：
 
Benchmark result has listed as follow:
 
Set Data spent time (ms): 14609
 
Get Data spent time (ms): 14859
 
Delete Data spent time (ms): 10469
 
结果分析
 从结果来看，Memcached的性能最好，Redis其次，而H2的性能则最差。细节方面，Redis的读性能要略好于Memcached。
 
    在执行本次测试之前并没有对各个软件进行优化，因为测试数据总量10000条，每条不到1KB，总共不过10MB，而且单个线程，所以默认配置应该都是足够的，因此测试结果能够反映各自的性能情况。

    产生这个结果的原因主要是三种软件的功能丰富程度不同，以及使用内存的情况不同。H2作为关系型数据库，具有持久存储功能，因此还是大量使用了磁盘，而且H2也要考虑数据完整性和原子性等关系数据库的关键特性；而Redis采用Key-Value范型，不能达到关系型数据库那样的可靠性，实现的特性少，可以更加关注性能，但是为了防止数据丢失，支持持久存储机制；而同样是Key-Value方式的Memcached则不支持持久存储，纯内存软件。

    还有一项与性能无关的情况需要指出，在编写测试应用的时候，Memcached操作的代码量最少，其次为Redis，H2所需代码最多。
 
结论
 综合上述功能特性的分析和性能测试结果分析，对于内存数据库的选型结论如下：
 
1、如果无特殊要求，则Memcached综合性能最好，编程最方便，推荐使用；
 
2、如果读操作很多，而且需要内存数据库提供持久存储以避免重启之后数据丢失，则推荐使用Redis。
 
    在性能方面，可以参考资料[6]中的比较。最终的比较结果表明，在小文件和大文件的读写性能上，Redis都要胜过Memcached，特别是在大文件读写方面，memcached性能不高。

    在功能方面，可以参考资料[7]中的分析。该分析中指出Redis对Memcached的最大的补充是对持久化的支持，这使得在机器重启或者升级时数据不至于丢失。

    我的测试代码采用Java开发，开发环境为Eclipse 3.7，如果需要我的全部测试代码，可以在评论里留下邮箱，我会发过去。
 
参考资料
 [1] Memcached Build from Source.http://code.google.com/p/memcached/wiki/NewInstallFromSource.
 
[2] Configure Memcached.http://code.google.com/p/memcached/wiki/NewConfiguringServer.
 
[3] Redis Document.http://redis.io/documentation.
 
[4] Jedis 2.0 API.http://www.jarvana.com/jarvana/view/redis/clients/jedis/2.0.0/jedis-2.0.0-javadoc.jar!/index.html.
 
[5] H2 Database Engine Version 1.3.172 (2013-5-25).http://www.h2database.com/html/main.html.
 
[6] Memcache and Redis Performance Compare.http://timyang.net/data/mcdb-tt-redis/.
 
[7] Memcache and Redis Functional Analysis.http://www.oschina.net/news/26691/memcached-timeout.

 
 
摘自：http://blog.okbase.net/linkman/archive/2426.html
 
 

 
 
很多情况下，用户会将实时数据库与关系数据库混为一谈，实际上，这两类产品的设计理念及应用场合是完全不同的。
 
内存数据库就是将数据放在内存中直接操作的数据库，它利用内存的读写速度比磁盘快、内存是随机访问而磁盘是顺序访问这两个特点，将数据保存在内存中，在内存中模仿建立表结构和索引结构并针对内存特性进行优化，相比从磁盘上访问，内存数据库能够提高应用的性能。
 
而实时数据库不但利用了内存的特性，而且考虑到工控行业的应用特性，将关系数据库的表结构和表关系简化，以进行性能的优化，并针对工控行业的数据特性，对数据进行压缩处理。
 
关系数据库、实时数据库与内存数据库相比，有如下差别：
 
 
比较项目
 
 
关系数据库
 
 
内存数据库
 
 
实时数据库
 
 
说明
 
 
表结构
 
 
完整
 
 
完整
 
 
简化
 
 
实时数据库不能处理复杂的表关系，但在特定行业的应用中，
 
比如工控监控软件中，不需要复杂的表关系
 
 
每秒读写速度
 
 
3000
 
 
50000
 
 
500000
 
 
内存实时数据库比关系数据库快10倍左右，实时数据库比内存数据库快10倍左右
 
 
历史数据压缩
 
 
无
 
 
无
 
 
有
 
 
实时数据库比内存数据库的压缩率能达到20~40倍
 
 
4G空间能存贮30万个测点的每秒变化一次的历史数据（不带索引）
 
 
5小时
 
 
5小时
 
 
8.5天
 
 
在4G内存的情况下，在单服务器处理30万点的情况下，内存数据库只能存贮5小时以内的历史数据，在带索引时，只能保存3小时以内的历史数据。(详见我的博文《实时数据库存贮容量计算方法》)
 
 
128G空间能存贮30万个测点的每秒变化一次的历史数据（不带索引）
 
 
7天
 
 
7天
 
 
269天
 
 
内存数据库有般用在电信行业，国内电信行业应用的最大项目也就使用了90G内存，在128G内存下，内存数据库也只能保存7天的历史数据
 
 
是否需要历史数据库
 
 
不需要
 
 
需要
 
 
不需要
 
 
内存数据库还需要配套使用历史数据库，且历史数据库同样存在不能压缩、不能保存长时间海量历史数据的问题
 
 
从以上的表格可以看出，内存数据库与关系数据库相比，速度快10-20倍左右，且具有与关系数据库类似的完整表结构，因此在电信业处理大量实时事务业务时经常用到，它也可以应用在工控行业，比如，在很多电力行业SCADA软件中，都包含了一个小型的内存数据库系统（但不是真正意义上的内存数据库），但是，在超大型SCADA软件中，它仍不能满足需求，因为它性能比实时数据库慢10倍，且不能解决历史数据存贮的问题，还存在因为掉电导致大量数据丢失的风险。
 
以上的比较，指标并不全面，也并不是说，实时数据库一定比关系数据库和内存数据库好，只能说，需要针对不同应用的不同需求，做出综合决策，选择最适合自己需要的数据库产品。
 
最后，列举一些典型的内存数据库产品：
 
■ Oracle TimesTen 
 
Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业（例如电信、资本市场和国防）所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。
 
■ Altibase 
 
Altibase是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。它提供高性能、容错能力和事务管理能力，特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度地发挥数据库服务系统的潜力，增强数据服务器的处理能力。Altibase支持客户端/服务器架构或嵌入式架构。其中客户端/服务器架构非常适合一般的应用。而嵌入式架构将应用程序嵌入到数据库服务器，适合于有高时效要求的实时系统。 
 
■ eXtremeDB 
 
eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库，只有50K到130K的开销，速度达到微秒级。eXtremeDB完全驻留在主内存中，不使用文件系统（包括内存盘）。eXtremeDB采用了新的磁盘融合技术，将内存拓展到磁盘，将磁盘当做虚拟内存来用，实时性能保持微秒级的同时，数据管理量在32BIT下能达到20G。
 

1.  nosql
 

 NoSQL = Not Only SQL，泛指非关系型的数据库。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。NoSQL数据库没有标准的查询语言(SQL)，许多NoSQL数据库都有REST式的数据接口或者查询API。
 
 

 使用场景：
 

 1、数据模型比较简单；
 

 2、需要灵活性更强的IT系统；
 

 3、对数据库性能要求较高；
 

 4、不需要高度的数据一致性；
 

 5、对于给定key，比较容易映射复杂值的环境。
 
 
2.  nosql 数据库4大分类
 

  
 
名称
描述
优点/缺点
键值(Key-Value)存储数据库
 
主要会使用到一个哈希表
 
 如redis
 
 
 场景：
 内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。
 适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。
 
 
优点：查询速度快
 缺点：数据无结构化，通常只被当作字符串或者二进制数据
列存储数据库
 
通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列
 
 如： HBase
 
 场景：分布式的文件系统
 适用于偏好BigTable:)并且需要对大数据进行随机、实时访问的场合
 
查找速度快，可扩展性强，更容易进行分布式扩展；
 
 功能相对局限
文档型数据库
 
可以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高
 如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源
 
 场景：Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）
数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构；
 
 
 查询性能不高，而且缺乏统一的查询语法。
 
图形(Graph)数据库
 
使用灵活的图形模型，并且能够扩展到多个服务器上。
 如：Neo4J, InfoGrid, Infinite Graph.
 场景：社交网络，推荐系统等。专注于构建关系图谱
利用图结构相关算法。比如最短路径寻址，N度关系查找等；
 
 很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。
 
 
 
 
 
 
 
3.  多种nosql数据库对比
 

 http://blog.jobbole.com/1344/
 
 

 
 
 
4.   内存数据库
 

 
 内存数据库，顾名思义就是将数据放在内存中直接操作的数据库。相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。
 
 

 
 
 

 内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用，关注性能。
 作用类似于缓存，并不注重数据完整性和数据一致性。基于键值型的内存数据库比关系型更加易于使用，性能和可扩展性更好，因此在应用上比关系型的内存数据库使用更多。
 
 

 
 
 
 
 
 
     
 
      名称
     
 
 
     
 
      开源或商业
     
 
 
     
 
      主要特点
     
 
 
     

       Oracle TimesTen
     
 
 
     

       不开源，商业使用付费
     
 
 
     

       1. 符合RDBMS标准的独立内存数据库服务。
     
 
 
     

       2.支持SQL访问，支持ODBC&JDBC。
     
 
 
     

       3.本身不支持与非Oracle数据库的互操作。
     
 
 
     

       4.高可靠性，支持完整日志，支持镜像复制功能。
     
 
 
     

       5.目前不支持存储过程和触发器。
     
 
 
     

       6.内存结构简单，并没有数据库缓冲区、保存池或丢弃池的概念。
     
 
 
     

       7.目前支持散列索引和T树索引，前者仅支持余键-值查找，速度非常快，执行过程与底层表的数量无关，具有较高的读取扩展性和很好的并发性；T树索引读取效率很高，但是，在繁重写操作时，并发性较差。
     
 
 
     

       ASE-IMDB
     
 
 
     

       不开源、商业使用付费
     
 
 
     

       1.被整合到Sysbase ASE平台中（TimesTen则为一个独立的数据库）。
     
 
 
     

       2. 基于经典ASE数据库模板创建。
     
 
 
     

       3. 采用复制技术实现读取其他数据源的数据。
     
 
 
     

       4. 完全支持ASE本身的SQL语法、安全性和加密。
     
 
 
     

       IBM SolidDB
     
 
 
     

       不开源、商业使用付费
     
 
 
     

       1.可以提供超快的速度和超高的可用性，可以提供每秒数万至数十万事务的吞吐率，并且始终可以获得微秒级的响应时间。
     
 
 
     

       2.抛弃大数据块结构，表行和索引节点独立地存储在内存中，可以直接添加索引，而不必重新组织大块结构。
     
 
 
     

       3.放弃使用大块索引，以精简结构、增加索引层数、将索引节点最小化，从而避免节点内处理的成本。
     
 
 
     

       4.使用一种称作trie（前缀树）的索引方式，更适合现代处理器缓存，通过有效促进缓存的使用来提高处理器的效率，从而实现性能的最大化。
     
 
 
     

       5.使用一种获得专利的检查点方法来加快数据处理，查询事务的延时通常是10到20微秒，更新事务的延时通常小于100微秒。
     
 
 
     

       VoltDB
     
 
 
     

       开源版本免费
     
 
     

       商业版本需付费
     
 
 
     

       1.基于存储过程的事务提交方式：用户通过写存储过程完成应用程序的逻辑，作为一个先置条件将存储过程提交到VoltDB，运行时，用户程序调用存储过程完成事务操作，所有事务的运行逻辑是由VoltDB在服务器进程中完成。
     
 
 
     

       2．基于Shared Nothing结构的数据分布，整个数据库的数据分散到集群的多台机器上。
     
 
 
     

       3.基于哈希的数据分布策略，好处是数据分散的均匀，没有动态数据调整的烦恼；缺点是新增的机器需要停止服务后重新分布数据。哈希方法打乱了数据的连续性，使得VoltDB对于范围查询的处理能力显著下降。
     
 
 
     

       4.其事务并发控制需要依赖于集群内所有机器的时间一致，其数据分片规模是按照集群核数来划分，当整个系统压力比较大时，可以使事务的时延有效降低。
     
 
 
     

       eXtremeDB
     
 
 
     

       不开源的商业数据库，
     
 
     

       测试版本在功能上与正式版没有区别，但是，对连接次数做了限制
     
 
 
     

       1.高性能和高效的存储效率，为了提高性能方便程序使用，eXtremeDB中的数据未做任何压缩。
     
 
 
     

       2.不仅开源建立完全运行在主内存的内存数据库，更可以建立磁盘/内存混合介质的数据库。
     
 
 
     

       3.嵌入式数据库：其内核以链接库的形式包含在应用程序之中，开销只有50KB-130KB；避免了进程间的通信，从而剔除了进程间通信的开销和不确定性；其独特的数据格式方便程序直接使用，剔除了数据复制及数据翻译的开销，缩短了应用程序的代码执行路径。
     
 
 
     

       4.由应用定制的API，应用程序对eXtremeDB数据库的操作接口是根据应用数据库设计而自动产生，剔除了通用接口所必不可少的动态内存分配。
     
 
 
     

       5.其独特的体系结构，保证了数据管理的可预测性。
     
 
 
     

       SQLite
     
 
 
     

       开源，免费使用
     
 
     

       商业目的的分发版免费
     
 
 
     

       1.需要专业支持则需要购买。
     
 
 
     

       2. 在并发（包括多进程和多线程）读写方面的性能一直不太理想。数据库可能会被写操作独占，从而导致其它读写操作阻塞或出错。
     
 
 
     

       3.3264位主流操作系统均支持。
     
 
 
     

       4.不支持ODBC连接，需通过第三方驱动支持JDBC连接。
     
 
 
     

       5.支持SQL
     
 
 
     

       H2
     
 
 
     

       开源，免费使用
     
 
     

       商业目的的分发版免费
     
 
 
     

       1.需要专业支持则需要购买。
     
 
 
     

       2. 并发性较好（在模拟器中有使用，支持50个并发查询没问题），数据量少的情况，查询速度很好。
     
 
 
     

       3.3264位主流操作系统均支持，但需Java平台支持。
     
 
 
     

       4.支持ODBC&JDBC
     
 
 
     

       5.支持SQL
     
 
 
 
 
 

 更多参考：
 

 
 
 

 http://www.360doc.com/content/10/1202/16/3196411_74404988.shtml
 
 

 http://www.360doc.com/content/14/0110/21/281812_344213831.shtml