部署：

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，属性等信息都存储在一个文档中。由于放在一个地方，查询的速度快了。