要点

跟mysqld一样，一个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。

capped collection

capped collection是一种特殊的表，它的建表命令为：

db.createCollection("mycoll",{capped:true, size:100000})

允许在建表之初就指定一定的空间大小，接下来的插入操作会不断地按顺序APPEND数据在这个预分配好空间的文件中，如果已经超出空间大小，则回到文件头覆盖原来的数据继续插入。这种结构保证了插入和查询的高效性，它不允许删除单个记录，更新的也有限制：不能超过原有记录的大小。这种表效率很高，它适用于一些暂时保存数据的场合，比如网站中登录用户的session信息，又比如一些程序的监控日志，都是属于过了一定的时间就可以被覆盖的数据。

复制与分片

mongodb的复制架构跟MySQL也很类似，除了包括master-slave构型和master-master构型之外，还有一个Replica pairs构型，这种构型在平常可以像master-slave那样工作，一但master出现问题，应用会自动了连接slave。要做复制也很简单，我自己使用过master-slave构型，只要在某一个服务启动时加上–master参数，而另一个服务加上–slave与–source参数，即可实现同步。

分片是个很头疼的问题，数据量大了肯定要分片，mysql下的分片正是成为无数DBA的噩梦。在mongodb下，文档数据库类似key-value数据库那样的易分布特性就显现出来了，无论构造分片服务，新增节点还是删除节点都非常容易实现。但mongodb在这方面做还不足够成熟，现在分片的工作还只做到alpha2版本（mongodb v1.1），估计还有很多问题要解决，所以只能期待，就不多说了。

性能

在我的使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。mysql实际无法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能同样很令人满意，同样写入百万级别的数据，mongodb比我以前试用过的couchdb要快得多，基本10分钟以下可以解决。补上一句，观察过程中mongodb都远算不上是CPU杀手。

GridFS

gridfs是mongodb一个很有趣的类似文件系统的东西，它可以用一大块文件空间来存放大量的小文件，这个对于存储web2.0网站中常见的大量小文件（如大量的用户头像）特别有效。使用起来也很方便，基本上跟一般的文件系统类似。

用合适的数据库做适合的事情

mongodb的文档里提到的user case包括实时分析、logging、全文搜索，国内也有人使用mongodb来存储分析网站日志，但我认为mongodb用来处理有一定规模的网站日志其实并不合适，最主要的就是它占空间过于虚高，原来1G的日志数据它可以存成几个G，如此下去，一个硬盘也存不了几天的日志。另一方面，数据量大了肯定要考虑sharding，而mongodb的sharding到现在为止仍不太成熟。由于日志的不可更新性的，往往只需APPEND即可，又因为对日志的操作往往只集中于一两列，所以最合适作为日志分析的还是列存储型的数据库，特别是像infobright那样的为数据仓库而设计的列存储数据库。

由于mongodb不支持事务操作，所以事务要求严格的系统（如果银行系统）肯定不能用它。

MongoDB分布式复制

一、主从配置（Master Slave）

    主从数据库需要两个数据库节点即可，一主一从（并不一定非得两台独立的服务器，可使用--dbpath参数指定数据库目录）。一个从节点可以有多个主节点，这种情况下，local.sources中会有多条配置信息。一台服务器可以同时即为主也为从。如果一台从节点与主节点不同步，比如从节点的数据更新远远跟不上主节点或者从节点中断之后重启但主节点中相关的数据更新日志却不可用了。这种情况下，复制操作将会终止，需要管理者的介入，看是否默认需要重启复制操作。管理者可以使用{resync:1} 命令重启复制操作，可选命令行参数 --autoresync可使从节点在不同步情况发生10秒钟之后，自动重启复制操作。如果指定了--autoresync参数，从节点在10分钟以内自动重新同步数据的操作只会执行一次。
--oplogSize命令行参数（与--master一同使用）配置用于存储给从节点可用的更新信息占用的磁盘空间（M为单位），如果不指定这个参数，默认大小为当前可用磁盘空间的5%（64位机器最小值为1G，32位机器为50M）。
   
二、互为主从（Replica Pairs）
    数据库自动协调某个时间点上的主从关系。开始的时候，数据库会判断哪个是从哪个是主，一旦主服务器负载过高，另一台就会自动成为主服务器。
remoteserver组中的其他服务器host，可加:port指定端口。
arbiterserver 仲裁（arbiter ）的host，也可指定端口。仲裁是一台mongodb服务器，用于协助判断某个时间点上的数据库主从关系。如果同组服务器在同一个交换机或相同的ec2可用区域内，就没必要使用仲裁了。如果同组服务器之间不能通信，可是使用运行在第三方机器上的仲裁，使用“抢七”方式有效地敲定主服务器，也可不使用仲裁，这样所有的服务器都假定是主服务器状态，可通过命令人工检测当前哪台数据库是主数据库：
$ ./mongo 
> db.$cmd.findOne({ismaster:1});
{ "ismaster" : 0.0 , "remote" : "192.168.58.1:30001" , "ok" : 1.0 } 
一致性：故障转移机制只能够保障组中的数据库上的数据的最终一致性。如果机器L是主服务器，然后挂了，那么发生在它身上的最后几秒钟的操作信息就到达不了机器R，那么机器R在机器L恢复之前是不能执行这些操作的。
安全性：同主从的操作相同。
数据库服务器替换。当一台服务器失败了，系统能自动在线恢复。但当一台机器彻底挂了，就需要替换机器，而替换机器一开始是没有数据的，怎么办？以下会解释如何替换一组服务器中的一台机器。

MongoDB语法与现有关系型数据库SQL语法比较

MongoDB语法                                  MySql语法

db.test.find({'name':'foobar'})<==> select * from test where name='foobar'

db.test.find()                            <==> select *from test

db.test.find({'ID':10}).count()<==> select count(*) from test where ID=10

db.test.find().skip(10).limit(20)<==> select * from test limit 10,20

db.test.find({'ID':{$in:[25,35,45]}})<==> select * from test where ID in (25,35,45)

db.test.find().sort({'ID':-1})  <==> select * from test order by IDdesc

db.test.distinct('name',{'ID':{$lt:20}})  <==> select distinct(name) from testwhere ID<20

db.test.group({key:{'name':true},cond:{'name':'foo'},reduce:function(obj,prev){prev.msum+=obj.marks;},initial:{msum:0}})  <==> select name,sum(marks) from testgroup by name

db.test.find('this.ID<20',{name:1})  <==> select name from test whereID<20

db.test.insert({'name':'foobar','age':25})<==>insertinto test ('name','age') values('foobar',25)

db.test.remove({})                        <==> delete * from test

db.test.remove({'age':20})            <==> delete test where age=20

db.test.remove({'age':{$lt:20}})   <==> elete test where age<20

db.test.remove({'age':{$lte:20}})  <==> delete test where age<=20

db.test.remove({'age':{$gt:20}})  <==> delete test where age>20

db.test.remove({'age':{$gte:20}})<==> delete test where age>=20

db.test.remove({'age':{$ne:20}})  <==> delete test where age!=20

db.test.update({'name':'foobar'},{$set:{'age':36}})<==> update test set age=36 where name='foobar'

db.test.update({'name':'foobar'},{$inc:{'age':3}})<==> update test set age=age+3 where name='foobar'

Mongodb亿级数据量的性能测试

进行了一下Mongodb亿级数据量的性能测试，分别测试如下几个项目：
（所有插入都是单线程进行，所有读取都是多线程进行）
1） 普通插入性能 （插入的数据每条大约在1KB左右）
2） 批量插入性能 （使用的是官方C#客户端的InsertBatch），这个测的是批量插入性能能有多少提高
3） 安全插入功能 （确保插入成功，使用的是SafeMode.True开关），这个测的是安全插入性能会差多少
4） 查询一个索引后的数字列，返回10条记录（也就是10KB）的性能，这个测的是索引查询的性能
5） 查询两个索引后的数字列，返回10条记录（每条记录只返回20字节左右的2个小字段）的性能，这个测的是返回小数据量以及多一个查询条件对性能的影响
6） 查询一个索引后的数字列，按照另一个索引的日期字段排序（索引建立的时候是倒序，排序也是倒序），并且Skip100条记录后返回10条记录的性能，这个测的是Skip和Order对性能的影响
7） 查询100条记录（也就是100KB）的性能（没有排序，没有条件），这个测的是大数据量的查询结果对性能的影响
8） 统计随着测试的进行，总磁盘占用，索引磁盘占用以及数据磁盘占用的数量