MongoDB数据模型和索引学习总结
1. MongoDB数据模型：
-
MongoDB数据存储结构：
MongoDB针对文档（大文件採用GridFS协议）採用BSON（binary json，採用二进制编码）数据格式来存储和交换数据。Bson吸收了JSON schema-less的特点，存储结构松散，不须要像RDB（关系数据）那样事先定义数据存储的元数据结构。另外添加了多种数据类型的支持和优化，使读写更加高效。
(1) BSON 支持的数据类型：
Double、String、Object、Array、Binary Data、Undefined、Object id、Boolean、Date、Null、Regular Expression、JavaScript、Symbol、JavaScript（with scope）、32-bit integer、Timestamp、64-bitInteger、Min key、Max key(2) BSON 在表现形式例如以下：
{ "_id" : ObjectId("542c2b97bac0595474108b48"), "ts" : Timestamp(1412180887, 1)，"name":"steven"}(3) BSON 是MongoDB中的通信协议和数据存储格式： 在MongoDB中client和服务端通信採用的是BSON的文档格式。比如查询一段数据。须要这样写：
db.steven.find({"name":"steven"})更新一段数据须要这样写：
db.steven.update({"name":"steven"},{$set:{"name":"jianying"}})删除一段数据须要这样写：
db.steven.remove({"name":"steven"})总之MongoDB中针对文档的CRUD的RPC通信格式均支持採用了BSON的数据格式。而且其存储格式也採用了BSON的格式类似：
{ "_id" : ObjectId("542c2b97bac0595474108b48"), "ts" : Timestamp(1412180887, 1)，"name":"steven"}(4) BSON数据格式的编码：
BSON的String类型均採用UTF-8编码。当中KV结构中 K值 和 字符串类型的V值，均採用UTF-8格式编码。假设使用的是其它格式则须要转码。而且针对K 值能够採用除下面要求外的随意UTF-8字符：a.键不能含有o(空字符) b.$和.有特殊的含义，仅仅有在特定环境下採用使用 c.下面划线"_"开头的键是保留的（不是严格要求的）而其他值类型的编码则依照详细数据类型的内置协议编码。
MongoDB在数据模型的组织方式上，支持文档的引用和嵌套。详细介绍例如以下。
-
数据模型设计模式 - 引用 和 嵌套：
以引用的方式存储数据是一种MongoDB组织数据存储结构的模式，即一个文档中存储了检索还有一个文档须要的必要信息，举比例如以下：{ _id: "joe", name: "Joe Bookreader" } { patron_id: "joe", street: "123 Fake Street", city: "Faketon", state: "MA", zip: "12345" }上面的文档是用户joe的信息。而以下那个文档则记录了他的地址信息。要依据joe的name检索地址信息。则须要先检索第一个文档，然后再检索第二个文档。而设计成 嵌套模式则表现为：
{ _id: "joe", name: "Joe Bookreader", addresses: [ { street: "123 Fake Street", city: "Faketon", state: "MA", zip: "12345" } ] }这两种设计模式的均有各自的优缺点，引用模式被觉得是规范化的模式。减小了数据存储的冗余，结构设计清爽简单。
符合我们一般设计原则，可是要获取完整数据的通信开销比較大，并且多个文档操作的原子性在MongoDB层面无法保证。 而被觉得非规范化的嵌套设计模式。则具备相反的特性。其有点是降低了通讯的成本，并且原子性在单条文档得以保证，缺点就是数据存在冗余。选择哪种数据组织方式事实上是一种权衡（trade-off）。
-
注意点：
(1) MongoDB 文档的大小必须小于16M，超过这个大小的话，要考虑使用GirdFs。
(2) 增加的文档大小超出原先分配给它的空间，MongoDB会把这个文档移动到磁盘的另外一个位置。迁移文档比原位更新更要耗时，也会因此导致磁盘碎片问题。
(3) 在MongoDB里面，操作的原子性级别保证到 document级别。
(4) Bson 字符串採用UTF-8编码。
2. MongoDB索引结构：
-
MongoDB支持索引的类型:
MongoDB採用B树的结构来组织索引（有效的支持等值查询和范围查询）。支持针对文档中随意字段构建索引，不论是单值、数组、文本、嵌套结构的字段，均可构建索引。MongoDB 针对BSON存储格式是一种全索引的支持策略。
面对多而强大的Mongo索引，索引的设计对性能的提升有比較大的影响。眼下最新MongoV3.0版本号支持的索引类型有例如以下几种：
索引类型 简述 Default _id 默认ID索引：Mongo默认构建唯一性索引的id字段，每一个文档都有一个_id字段。 Single Field 单值索引：针对文档的某一字段或或嵌套文档的某一字段构建索引。Compound Index 组合索引：将多个字段放在一起构建索引。字段索引间组成上下层的树形结构。
Multikey Index 多值索引：针对数组类型的索引结构，为数组的每一个值建立一个索引。
Geospatial Index 地理位置索引： 针对地理坐标结构，构建索引。能高效定位坐标范围，属额外福利。 Text indexes 文本索引：类似搜索引擎的文本检索，涉及到分词操作，可惜不支持中文，并且查询语法的支持相对单一。 Hashed Indexes 哈希索引：为了支持 基于Hash的Sharding（一种部署方式）而生。仅仅支持等值检索，不支持范围检索。
以上介绍了索引的类型，而不同类型的索引又能够带有下面属性,间接例如以下：
- 索引的属性：
(1) 唯一索引： 和RDB（关系型数据库）的唯一性索引的概念一致。为了避免出现反复的值而设计。
构建方式如：
db.members.createIndex( { "user_id": 1 }, { unique: true } )
(2) 稀疏索引： 稀疏索引的稀疏性体如今，其仅仅为那些包括索引字段的文档构建索引Entry。
忽略那些不包括索引字段的文档。
构建方式如：
db.addresses.createIndex( { "xmpp_id": 1 }, { sparse: true } )
(3) TTL索引： TTL顾名思义是生命周期的意思。即存储的document存储带有过期时间属性，超过生命周期自己主动删除。像日志数据、系统自己主动产生的暂时数据、会话数据等均符合这一场景。
构建方式如：
db.log_events.createIndex( { "createdAt": 1 }, { expireAfterSeconds: 3600 } )
- 索引结构和特性：
(1) B树结构，顺序存储：MongoDB的索引均採用B树的结构组织，支持高效的等值查询和范围查询。
且内部索引项（entry）是默认有序的，能够天然保证返回结果有序。
(2) 索引的排序：构建索引是能够指定索引项是依照升序或降序构建。升序或降序的选择对于单值索引来说是等效的，可是对于组合索引则不等学效，组合索引被组织成上下级的树形结构，升序或降序选择错误。会对性能产生较大影响。
(3) 索引的交集：2.6版本号以后，索引的查询优化策略支持索引的交集，能够将多条索引组合来使用，最高效的检索数据。
比如能够构建两条单独的索引。当查询条件关联到这两条索引的时候。索引优化计划会自己主动组合这两条索引来检索。
比如构建了例如以下2条索引：
{ qty: 1 }
{ item: 1 }
则下面查询语句会命中以上两条索引：
db.orders.find( { item: "abc123", qty: { $gt: 15 } } )
另外索引的交集和包含：
索引的前缀交集：主要针对组合索引，查询计划会优化组合索引的前缀来查询。
- 索引分析方法：
(1) 评估RAM容量，尽量保证索引在内存中：
查询索引大小的命令（单位是字节）：
db.collection.totalIndexSize()
db.collection.stats()
(2) 分析查看索引的计划：
MongoDB中使用explain和hint能够查看索引的策略：
db.collection.find().explain()
能够看出那条索引策略生效，以及索引交集的使用情况。
db.collection.find().hint({"name":1})
hint的命令则能够指定强制使用某条索引。
(3) 索引的管理信息: 每一个DB以下都会有一个system.indexes集合，这个集合记录着DB下，索引构建的元数据信息。
db.system.indexes.find()
- 注意点：
(1) 每一个索引须要至少8K的空间。
(2) MongoDB 会对 _id字段自己主动创建唯一索引。
(3) 一个特别的索引类型支撑了TTL集合的实现，TTL依赖一个在Mongod中的后台线程。该线程读取索引中日期类型的值并从集合中删除过期的documents。