NoSQL数据库- continue posting...

  现在的NoSQL数据库实在是太多了，也尚未发现有比较完整的介绍、评价以及评测。最近微博上又热炒MongoDB是多么的不靠谱，用户声泪具下的控诉10Gen是多么的不靠谱。可见一个东西并非加个好名字，不靠谱的就靠谱的，毕竟数据这块还是很敏感的，在上项目的时候最好就能有个比较清晰的选择，否则未来还是会遇到结婚了还要离婚的痛苦场面。

  另外需要特别指明的就是NoSQL数据库和现在一些流行的分布式缓存系统的区别，比如Memcached等。NoSQL本意所指的是去掉了R的DBMS，一般也会取消对事务和其他高级特性，比如表关系的关联等，因此并没有人规定NoSQL一定是基于Key-Value的，虽然大部分是这么做的。而现有的分布式缓存系统大多是基于键值存储、同样不提供RDBMS的复杂功能。因此，缓存系统和NoSQL的根本区别就是是否认真考虑了持久化。虽然个别缓存系统可以实现部分功能的持久化，但是毕竟系统设计并不是从这个角度出发的，功能上还是有很大的差别。

 

  因此，本文想尽量多的描述现有的NoSQL数据库，并且实地的进行一下测试，时间有限，有些不足的内容会慢慢补充本文。这里有一个链接： http://nosql-database.org/ 里面列举了超过120个NO-SQL数据库，当然本文不可能一一列举，了解多少写多少吧。

  

Memcachedb Link

Memcachedb是一个基于Memcached实现的，带有持久性的内存数据库，跟Memcached一样采用key-value的数据模型，但是使用了BerkeleyDB作为后台，因此据其作者介绍“具备了事务和备份”功能。

Memcachedb的特点：

  • 高性能的对象读写
  • 带事务功能的高可靠的持久存储
  • 使用备份提供更高的可用性
  • 支持Memcached协议

Memcachedb的命令

  • get、set、add、replace、delete、incr、decr、stats
  • db_checkpoint, db_archive, stats bdb, rep_ismaster, rep_whoismater, rep_set_priority, rep_set_ack_policy, rep_set_ack_timeout, rep_set_bulk, rep_set_request, stats rep

Memcachedb的性能

  • 官方测试的结果 key:16byte, value:100byte, 8 concurrents, every process does 2,000,000 set/get
    • memcachedb -d -r -u root -H /data1/mdbtest/ -N -v
    • write: 18868 w/s
    • read: 4444 r/s
    • memcachedb -d -r -u root -H /data1/mdbtest/ -N -t 4 -v
    • write: 23564 w/s
    • read: 64257 r/s

先不论Memcached的性能或者设计怎么样，从其google code上的代码库最近一次稳定版本是2008年10月就可以知道，这个项目已经被作者放逐了。更可怕的是，configure文件中居然有BerkeleyDB.4.7这样令神鬼哭泣的写死的配置条目，我不得不说，赞！而且，我下了最新版的BerkeleyDB后，发现该项目已然编译不过了。还有什么好说的呢。。。

 

 

Leveldb Link  

Leveldb是Google实现的一个非常高效的KV数据库，从其作者名字就可见一斑啊，CTO啊，兄弟们。就这您就大胆的用吧。。。目前版本1.2能够支持十亿级别的数据量，“其是一个单进程服务，在一个4核Q6600的CPU机器上，每秒写数据超过40w，随机读超过10w”

 

levelDB的现在开源实现非常简单，没有分布式也没有服务器端的实现，就是一个单机的，基于磁盘的NoSQL数据库，貌似使用LSMTree来加速随机写，可以遍历数据，支持atom操作，不过没有memcached，所以可能并没有那么快。随机读的性能受限，比较适合SSD硬盘

 

下面是Google Code上公布的性能数据：

采用16字节的Key、100字节的Value做测试，服务器性能如下：

   LevelDB:    version 1.1
   Date:       Sun May  1 12:11:26 2011
   CPU:        4 x Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
   CPUCache:   4096 KB
   Keys:       16 bytes each
   Values:     100 bytes each (50 bytes after compression)
   Entries:    1000000
   Raw Size:   110.6 MB (estimated)
   File Size:  62.9 MB (estimated)

下面是写的性能，其中sync表示所有的操作都要从操作系统buffer写入到磁盘中，否则则不。每一个op都会写入一个单独的key、value对，因此随机写的操作中，大概每一秒能写入400,000次。

   fillseq      :       1.765 micros/op;   62.7 MB/s     
   fillsync     :     268.409 micros/op;    0.4 MB/s (10000 ops)
   fillrandom   :       2.460 micros/op;   45.0 MB/s     
   overwrite    :       2.380 micros/op;   46.5 MB/s    

   readrandom   :      16.677 micros/op;  (approximately 60,000 reads per second)
   readseq      :       0.476 micros/op;  232.3 MB/s    
   readreverse  :       0.724 micros/op;  152.9 MB/s    　　
Some of the high cost of reads comes from repeated decompression of blocks read from disk. 
If we supply enough cache to the leveldb so it can hold the uncompressed blocks in memory, the read performance improves again:
   readrandom   :       9.775 micros/op;  (approximately 100,000 reads per second before compaction)
   readrandom   :       5.215 micros/op;  (approximately 190,000 reads per second after compaction)

　　

这边还有一个LevelDB和MySQL性能对比数据，可以参考一下：Link

还有淘宝一工程师的分享：Link；Jeffy本人对LevelDB实现的描述：Link

 

 

Oracle No SQL Database Link

Oracle作为RDBMS的老大，现在也按耐不住对NoSQL的‘向往’，最近发布了NoSQL Database产品，该产品最有特点的地方在于它支持事务，支持事务对于NoSQL意味着什么，我还在微博上与人讨论过，使用2PC来支持事务真的有那么难么？我觉得不尽然，虽然事务并不是NoSQL数据库应用的主要场景，但是少量的事务需求也是应该满足的，而Oracle也走了这个方向，应该还是很有意义的，事务会不会成为NoSQL产品的标配呢？拭目以待吧。

虽然Oracle号称提供社区版，到现在还没有下好并且安装好。

 

 

BerkeleyDB Link

既然提到Oracle的 NOSQL Database就必须提一下BerkeleyDB了。 BerkeleyDB也算是NoSQL中的元老了，即便在今天也是非常有特色的产品——它是一款可以嵌入到使用本数据库的用户进程空间内的数据库。也就是说，访问BerkeleyDB管理的数据库不需要经过数据从用户空间-> 内核空间 -> 用户空间的拷贝，相比那些通过socket甚至rest接口访问的NoSQL数据库，无疑性能上会有很大的提升。2006年被Oracle收购之后，2010年开始加入对SQL语句（子集）的支持，并且BerkeleyDB本身就是支持事务、复制等特性的，当然这也会导致其性能降低。

 

本来笔者认为BerkeleyDB一定是性能非常好的，至少应该胜过MySQL很大，但是好像事实并非如此，很多人诟病的缺点包括：数据加载过慢、数据膨胀现象严重、随机读性能一般。

笔者使用BerkeleyDB白皮书中所提到的InMemoryDB手册中的程序做了一个测试，Host系统如下：

MacOX 10.6， 4GB 1067 DDR3 Mem， 2.4GHz Core2 Duo，BerkeleyDB Log 大小100MB， Memory Cache大小1GB. key: 4bytes, value: 100bytes

10000 (1w, 1MB)
Put:  0.084836 s
Get:  0.013906 s

100000 (10w, 10MB)
Put:  0.860943 s
Get:  0.157348 s

1000000 (100w, 100MB) 
Put:  8.921107 s
Get:  2.009328 s

10000000 (1000w, 1GB)
Put:  94.209991
Get:  27.127200

看起来，总体的效率大概是：插入的话每秒约 20w左右， 读的话大约每秒 50w左右。不算差，但是比起同样是嵌入式，内存，NOSQL的Tokyo Cabinet号称的百万级/s读写来说就差远了(当然这也是号称而已，后面会提到)。

 

 

HamsterDB Link

 

HamsterDB也是一个具有悠久历史的database，他和BerkeleyDB非常相似：NoSQL、嵌入式，但是是单线程的。不过作者Christoph Rupp现在也在很努力的开发第二个版本multi-user transactional platform。该版本支持以下新特性：ACID、Lock Free、Transaction logging & fail recovery、In Memory Support、B+ Tree。当然，和BerkeleyDB一样，都不支持分布式。

 

这个DB算是很非主流了，网上相关资料也少，国内使用的人也更少。作者号称于BerkeleyDB相比，具备更好的性能优势。笔者将在同样的硬件环境下进行测试，下面是一些数据，可以和BerkeleyDB比较一下（为了公平期间，都只用memory cached来存储数据，不做持久化）。

 MacOX 10.6， 4GB 1067 DDR3 Mem， 2.4GHz Core2 Duo. key: 4bytes, value: 100bytes

10000 (1w, 1MB)
Put:  0.010676 s
Get:  0.007768 s

100000 (10w, 10MB)
Put:  0.134192 s
Get:  0.093566 s

1000000 (100w, 100MB)
Put:  1.907569 s
Get:  1.326949 s

10000000 (1000w, 1GB)
Put: 29.035508 s
Get: 19.205765 s

可以看出HamsterDB相比BerkeleyDB在最简单的应用中性能是远远超过的，甚至比TC都强。但是复杂的场景我们还没有做测试。基本上达到了每秒100w次写和将近150w次读，性能太可怕了，而且在数据量比较小的情况下性能是相当稳定的。

 

MongoDB Link

MongoDB是由10Gen公司开发，C++编写的面向文档的数据库系统。特点是，放松了的一致性要求，支持异步写和最终一致性，支持MapReduce，后台用GridFS作为持久存储。

 

MemBase

Redis

Tokyo/Kyoto Cabinet

Riak Bitcast

OrientDB

CouchDB

 

 

--- 非主流

neo4j

flockdb

flare

orientdb

 

 

----- 参考文献 ------

其实早在2009年，Sina微博的首席架构师Tim就对Memcachedb、Redis和Tokyo Tyrant做了一个评测，可以参考一下: Link

 

----- 思考 -----

1）为什么不在BerkeleyDB这样的Embedded NoSQL之上做分布式呢？

posted @ 2011-12-16 23:50  MMJX  阅读(861)  评论(0)  编辑  收藏  举报