MongoDB学习笔记（一）—— 初识

1、 是什么

 

MongoDB 提供灵活、可扩展的存储方式，是面向文档的数据库，而不是关系型数据库，因此被称为NoSQL 数据库（与经典的关系数据库如Oracle 、SQLServer 、DB2 新相比）。在传统的关系数据库中，用类似网格的平面模型来表示数据，现实中的数据对象映射到数据库中的行（ROW ），一系列相同类型的数据的集合映射到数据中的表（Table ），有强模式存在，即，数据所相同的类型需要在数据库中强行定义，表结构一旦确定，就确定了表中所有数据所必须遵守的模式。而在MongoDB 中，现实中的数据对象映射，从行（ROW ）变为文档（Document ），文档的键可以随意定义，而不需要强制规定，因此是无模式的。无模式的设这将给系统带来极大的扩展性和灵活性。

 

2、 有什么，没有什么

 

MongoDB 提供索引能力，可以存储JavaScript ，支持聚合（MapReduce 得过），支持集合及文件存储功能。

MongoDB 不具备关系数据库中链接（join ）和复杂的多行事务。

 

3、 适合做什么，不适合做什么

 

作为文档型的数据库，MongoDB 适合于要求频繁、快速查询业务数据，但并不经常更新数据的场景，同时非常适合分布式部署的应用。这一特性使MongoDB 非常适合社交型的网站数据库应用，如微博、SNS 应用，内容一旦发布出去后，就很少（或不能）修改，但需要频繁地查询读取。另外也比较适合应用到系统日志、用户追踪等应用中。

MongoDB 不适合应用到数据频繁修改的业务场景，如工作流，内部办公系统等。

 

 

4、 如何唯一标识文档？

 

MongoDB 是无模式的，虽然文档集合并没有确定键值约束，但每个文档都需要有一个特殊的键：“_id ”，它在文档所在的表中是唯一的，相当于关系数据库中的唯一主键。

这个键值可以是任意类型，默认情况下是ObjectId 类型。ObjectId 使用12 字节的存储空间，每个字节两位16 进制数字，是一个共24 位长的字符串。

 

5、 需要自动生成ObjectId 吗？

 

在插入操作时，如果没有指定_id 键，系统将会按照下面方式自动生成一个：

 

4 字节时间戳 + 3 字节机器码 + 2 字节进程标识符 + 3 字节计数器

 

总共12 个字节，24 位字符串。同一秒钟每一进程最多允许有256^3(16777216) 个不同的ObjectId。就一般应用来说，这种生成_id 键的方式已经足够了。但对于大型应用来说，这个方式并不是一个很好的方式。很明显，3 字节的机器码和2 字节的进程标识符总共5 个字节的内容可以说是完全浪费了的（在运行过程中是静态的），3 字节的计算器也会有大量的浪费。在大数据量（千万级以上）的应用中，_id 及其索引的存储将成为数据库性能的瓶颈。试想，如果有1 亿条记录，则仅_id将至少占用10^8*12 约1GB 的硬盘空间。

 

因此，_id 最好是在客户端由驱动程序去生成，你可以根据自己的业务需求，自己去设置_id 的生成规则。同时，在客户端生成_id 的话，也可以减少数据库的开销，而且还可以加入更友好的API ，如插入后返回_id 的值。