MongoDB体验

  今天闲来无事，体验了下MongoDB，测试了一下性能。
  一个mongod服务可以有建立多个数据库，每个数据库可以有多张表，这里的表名叫collection，每个collection可以存放多个文档（document），每个文档都以BSON（binary json）的形式存放于硬盘中。跟关系型数据库不一样的地方是，它是的以单文档为单位存储的，你可以任意给一个或一批文档新增或删除字段，而不会对其它文档造成影响，这就是所谓的schema-free，这也是文档型数据库最主要的优点。跟一般的key-value数据库不一样的是，它的value中存储了结构信息，所以你又可以像关系型数据库那样对某些域进行读写、统计等操作。可以说是兼备了key-value数据库的方便高效与关系型数据库的强大功能。
  跟关系型数据库类似，mongodb可以对某个字段建立索引，可以建立组合索引、唯一索引，也可以删除索引。当然建立索引就意味着增加空间开销，我的建议是，如果你能把一个文档作为一个对象的来考虑，在线上应用中，你通常只要对对象ID建立一个索引即可，根据ID取出对象某些数据放在 memcache即可。如果是后台的分析需要，响应要求不高，查询非索引的字段即便直接扫表也费不了太多时间。如果还受不了，就再建一个索引得了。默认情况下每个表都会有一个唯一索引：_id，如果插入数据时没有指定_id，服务会自动生成一个_id，为了充分利用已有索引，减少空间开销，最好是自己指定一个unique的key为_id，通常用对象的ID比较合适，比如商品的ID。
  mongodb的复制架构跟mysql也很类似，除了包括master-slave构型和master-master构型之外，还有一个Replica pairs构型，这种构型在平常可以像master-slave那样工作，一但master出现问题，应用会自动了连接slave。要做复制也很简单，只要在某一个服务启动时加上–master参数，而另一个服务加上–slave与–source参数，即可实现同步。
  gridfs是mongodb一个很有趣的类似文件系统的东西，它可以用一大块文件空间来存放大量的小文件，这个对于存储web2.0网站中常见的大量小文件（如大量的用户头像）特别有效。使用起来也很方便，基本上跟一般的文件系统类似。
  由于mongodb不支持事务操作，操作也不是原子的，所以事务要求严格的系统（如果银行系统）肯定不能用它。
  mongodb占用空间过大的原因，在官方的FAQ中，提到有如下几个方面：
  1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、 256M那样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。
  2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果 value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index，每个字段名用一个字节表示，这样就不用担心字段名取多长了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是拿空间来换取时间吧。
  3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。
  4、可以定期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢。

  MongoDB适用的场合：
  网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
  缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源过载。
  大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。
  高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。
  用于对象及JSON数据的存储：Mongo的BSON数据格式非常适合文档化格式的存储及查询。

  看网上说，插入九百万条简单数据（3个字段）：平均值大约在24000/s（最高2.8W，最低2.1W）。
  自己测试对比：插入100W简单数据
  MongoDB：  6m18.579s
  Mysql  ：  3m18.187s
  用MongoDB自带的工具测试1W条记录结果：
  encode small: 2.1333899498
  encode medium: 12.0563359261
  encode large: 62.4954781532
  decode small: 0.864869832993
  decode medium: 4.7117099762
  decode large: 25.076821804
  insert medium: 16.6013510227
  find one medium: 49.5086688995
  似乎也不是很强悍，可能机器配置有关，内存有点小，本机：
  model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
  cpu MHz         : 2992.829
  cache size      : 2048 KB
  MemTotal        : 1033908 kB

  原文见：http://www.feedzshare.com/s/s/1603304
  http://www.sh2999.com/sh/posts/list/236.page