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。