部署：
MongoDB服务端可运行在Linux、Windows或IOS平台，支持32位和64位应用，默认端口为27017。推荐运行在64位平台，因为MongoDB在32位模式运行时支持的最大文件尺寸为2GB。64位系统就没有最大文件限制。
32位系统最大限制2g的原因为：32位系统下，所有地址必须能用32位系统访问到(超过2g访问不到了)。所以针对32位操作系统下的mongod最多只能处理2g的数据。
一个数据库的数据存储方式：
比如数据库test分别会有如下文件：
testabc.0，testabc.1，testabc.2
每个文件的大小都会成倍增加。第一个是16m，第二个是32m，第三个是64m。第四个是128m，.......直到最大到2g为止。
那么，2g之后会干嘛呢？
继续2g的创建下去。
疑问：既然这样子的话，为什么不一开始就创建一个2g的文件呢？
2g，2g，2g的创建下去。
php想操作这个数据库，必须下载这个数据库针对php的驱动。其实就是安装一个扩展入php中。
类似于加载php操作mysql的模块一样的。参看：http://us.php.net/manual/en/class.mongocollection.php。
联系：php操作memacache，也是需要加载一个php针对memache的扩展进去。然后有现成的函数可以拿来使用。
从现在可以理解出：mogodb的数据存储在文件系统上。并非内存上。但是速度很快，原因是什么？
1、高效的二进制数据存储方式。bson方式。没有表结构字段的限制关系。表结构扩展容易。
2、无需关联表进行查询。省去关联查询，查询数据快。
3.写入数据速度非常快。
4、有专门的商业公司进行维护和升级。10gen公司。
避免点或者缺点：
1.每个文档必须保持在16M以下
为了解决单个文件大小限制的需求，mogodb引入了gridfs文件系统，
10gen提到：如果这项设置不停的困扰到你，那么是否你的设计模式存在着问题；或者你可以使用文件无大小限制的GridFS。
2.不支持事务。需要用到事务场景的不能使用。对数据一致性要求高的不适合。
3、对磁盘的容量占用比较多。是因为其机制的特性促使的。
原因：删除记录不释放空间。mongodb每次空间不足时都会申请生成一大块的硬盘空间(就是生成一个新的文件)，而且申请的量从64M、128M、256M那样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。
它采用预先申请文件空间的方式，按照级别进行递增,64M、128M、256M,2g。
4、mogodb把所有空闲的内存当缓存使用。无法预定义申请和设置内存大小。这样
容易受到其他程序干扰出现不稳定。
适合的业务和需求类型：
1、适合作为信息基础设施的持久化缓存层。理解为，数据是存储在磁盘上。数据持久。
2、一般存储数据量大的访问日志信息，用这个比较好。入库速度快，数据量无线增大，可以支持分布式存储。
3、是为海量数据存储与查询而设计的。
我觉得，mongodb与mysql的比较不是一个层面的，无法比较。一个是nosql系列的。一个是关系型数据库。只能以nosql与关系数据库的特点去比较。
mongodb应该与其他数据库redis去比较，都是同属于nosql系列的。
比如redis就不像mogodb那样支持sql式的查询操作。他完全是key-value形式的。
不适合的业务类型：
1）要求高度事务性的系统。
2）传统的商业智能应用。
3）复杂的跨文档（表）级联查询。
一些概念与关系数据库的比较
mongodb 关系数据库
数据库 数据库
集合 表
文档 行
因为是无模式， 列
所以不需要列的概念
objectId文档编号 类似于行的唯一编号
文档：符号｛｝可以看成是一个文档。
与关系型数据库相比，为什么查询性能提到了？
存储的数据不需要分表。存在一个集合中去了。关系型数据库每个表 的数据是分开文件存储的。因而查询一个商品的全部信息，一般需要查询多个表，去多个文件中操作数据。
而mongodb可以把商品的所有数据，比如sku，属性等信息都存储在一个文档中。由于放在一个地方，查询的速度快了。