主流内存数据库功能特性和性能比较

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

内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用,关注性能,作用类似于缓存,并不注重数据完整性和数据一致性。基于键值型的内存数据库比关系型更加易于使用,性能和可扩展性更好,因此在应用上比关系型的内存数据库使用更多。本文首先比较FastDB、Memcached和Redis主流内存数据库的功能特性,再从性能上比较H2、Memcached和Redis三种内存数据库,希望大家能够根据自己业务需求的具体特点,选择合适的开源产品。

 FastDB的特点包括如下方面: 

1、FastDB不支持client-server架构因而所有使用FastDB的应用程序必须运行在同一主机上;

2、fastdb假定整个数据库存在于RAM中,并且依据这个假定优化了查询算法和接口。

3、fastdb没有数据库缓冲管理开销,不需要在数据库文件和缓冲池之间传输数据。

4、整个fastdb的搜索算法和结构是建立在假定所有的数据都存在于内存中的,因此数据换出的效率不会很高。

5、Fastdb支持事务、在线备份以及系统崩溃后的自动恢复。

6、fastdb是一个面向应用的数据库,数据库表通过应用程序的类信息来构造。

 FastDB不能支持Java API接口,这使得在本应用下不适合使用FastDB。 
 memcached的API使用三十二位元的循环冗余校验(CRC-32)计算键值后,将资料分散在不同的机器上。当表格满了以后,接下来新增的资料会以LRU机制替换掉。由于 memcached通常只是当作缓存系统使用,所以使用memcached的应用程式在写回较慢的系统时(像是后端的数据库)需要额外的程序更新memcached内的资料。 memcached具有多种语言的客户端开发包,包括:Perl、PHP、JAVA、C、Python、Ruby、C#。 
 关于性能方面的详细内容建议继续阅读后面的内容,我对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(共享),全双工

 台式机和服务器采用普通内部局域网连接。 

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

tar -zxvf redis-2.6.14.tar.gz

cd ./redis-2.6.14

make

 开启Redis服务器和Redis自带的客户端访问工具如下: 

src/redis-server

src/redis-cli

 解压之后进入bin目录,并修改h2.sh文件中的Java命令启动的主类和选项为: 

org.h2.tools.Server -tcpAllowOthers -webAllowOthers

 然后执行脚本h2.sh即可启动数据库。H2提供本地命令行控制台,启动方式为: 

java -cp *.jar org.h2.tools.Shell

 一般来说,使用图形化的Web界面更为方便。 

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

 在执行本次测试之前并没有对各个软件进行优化,因为测试数据总量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,如果需要我的全部测试代码,可以在评论里留下邮箱,我会发过去。 

[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.

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/229099.html原文链接:https://javaforall.net

(0)
上一篇 2026年3月16日 下午5:28
下一篇 2026年3月16日 下午5:29


相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号