图片 12

MongoDB更需要好的模式设计,数据模型

二  方式设计

MongoDB能够将形式设计划分为内嵌方式(Embedded)和 援引形式(References)

3.1.4数额选用和属性

设计数据模型是,思考应用程序如何利用数据,若应用程序只是用当下的片段数码,可以考虑接受Capped Collections。可能是以读为主的数量,扩大索引来坚实质量。

   

援用方式

援引情势是将数据存款和储蓄在差异会集的文书档案中,而透过关周到据举办关联。例如,这里运用援用格局将工作者消息囤积在了3个文书档案中,基本音信三个文书档案,联系方式一个文书档案,登陆权限放在了一个文书档案中。每一个文书档案之前经过user_id来关联。

图片 1

 

3.4.1.3字段名

字段名是字符串类型,不援助再一次的字符串,即使mongodb的其汉语档中有重新的字符串,可是不会让客商文书档案增加。

db.abc.find({“a”:23},{“b”:1,”c”:1}卡塔尔(قطر‎表示生龙活虎旦b,c两列

案例2

 

 三个主顾维护三个地点是十全十美的场景,回头看看我们天猫账号,就能够发觉收货地址日常都是2个以上
( 流泪 ╥╯^╰╥State of Qatar

图片 2

 

 

 patron 会集客户joe的文书档案记录

{

   _id: “joe”,

   name: “Joe Bookreader”

}

 address 集合joe顾客的地址1的文书档案记录

{

   patron_id: “joe”,

   street: “123 Fake Street”,

   city: “Faketon”,

   state: “MA”,

   zip: “12345”

}

  address 集合中joe顾客的地址2的文书档案记录

{

   patron_id: “joe”,

   street: “1 Some Other Street”,

   city: “Boston”,

   state: “MA”,

   zip: “12345”

}

 像这种1:N的关联,何况N可以见到不是无数的景象下,我们引入应用内嵌情势,

将集纳文档设计成如下方式:

{

   _id: “joe”,

   name: “Joe Bookreader”,

   addresses: [

                {

                  street: “123 Fake Street”,

                  city: “Faketon”,

                  state: “MA”,

                  zip: “12345”

                },

                {

                  street: “1 Some Other Street”,

                  city: “Boston”,

                  state: “MA”,

                  zip: “12345”

                }

              ]

 }

 与案例1的两样正是地方消息使用了数组类型,数组的字段值又为内嵌子文书档案。

 

3.2.3 GridFS

GridFS主借使来保存当先BSON文书档案的节制16MB的多少。GridFS会把二个文书分为多分,私下认可GridFS一块的大小为256KB,GridFS有2个collection,1个客户保存数据,1个顾客保存元数据。

当查问这么些GridFS的时候,驱动可能顾客端或重组那几个块。

   

 三  案例 

上边大家透过某件事务场景,一些具体的案例,来解析、品味一下MongoDB形式设计的精选。

 

3.4.1.1文书档案格式

Mongodb使用BSON格式报讯,BSON是用二进制表示JSON文书档案。

此地0 表只数组下标为0的因素

一  挑战

统筹平素正是个挑衅。

当大家先是次接触数据库,学习数据库根底理论时,都要求上学范式,老师也每每强调范式是统筹的底子。范式是那门科目中的首要部分,在期末考试中也无可批驳是个基本点考试的场馆。假设大家那个时候高校挂科了,说倒霉正是范式那道题未有做好。结束学业后,当大家面试时,往往也可以有关于表设计方面拷问。

超多时候,大家错误地感到,费用多量岁月用在设计上,难题源于在于关周密据库(福睿斯DBMS卡塔尔国,在于二维表及其之间的关系组成的多个数据协会。而实际的遭逢中,大家正在大批量利用noSQL大概NewSQL,遵照近日的趋向(DB-Engines
Ranking 得分),今后还有恐怕会愈加遍布。选取noSQL大概NewSQL
就不需求形式设计了。况且,随着公司、行当数字化程度的加深,智能化触竞争渐延长,数据量更加大,结构进一层复杂。
举个例子以往相当火的IOT行当,复杂的事情消息、二种的传导公约、不断提拔的传感器,都亟需灵活的数据模型来回复。在此种呼唤声中,MongoDB闪亮上台了。MongoDB帮衬灵活的数据模型。首要反映在偏下2点:

(1)自由情势,不供给提前评释、创设表构造,即不用先创设表、增加字段,然后手艺够Insert数据。暗中认可情状下MongoDB没有需求这样操作,除非开启了格局验证。

(2)键值类型自由,MongoDB
将数据存款和储蓄为一个文书档案,数据结构由键值(key=>valueState of Qatar对组合。字段值能够包含别的文书档案,数组及文书档案数组。

MongoDB没有必要格局设计时不当的,其实面临纷纭的组织对象,方式的轻巧带来越来越大的挑战。

情势的随机是对数据insert那些动作来说,它去除比很多范围了,能够便捷讲对象的存进来,並且易于增添。但是不自然就能拉动好的查询品质,好的查询品质还要来自于好的形式设计、来自于好的联谊文书档案的规划。

 

3.2.2.5大量的Collection

大方的Collection并不会给品质带给超大的熏陶,不过当使用大量collection的时候照旧要求思量一下几点:

         1.collection细微也好些个少个KB的高低

         2.各样索引起码要8KB的空间

         3.各类数据库都有二个称谓空间文件,保存了具备的元数据,多量collection的数据库要考虑名称空间文件的大小难题。

         4.Mongodb名号空间有节制,必要构思名称空间个数难题。查看已用的称呼空间能够用db.system.namespace.count(State of Qatar,私下认可名称空间的大小是16MB,能够行使–nssize的起步参数来配置。

db.abc.insert([

援用形式2

那会儿书局的文档记录如下:(不再使用书籍文书档案的号码)

{

*   _id: “oreilly”,*

*   name: “O’Reilly Media”,*

*   founded: 1980,*

*   location: “CA”*

}

那时图书的文书档案记录如下:(书籍为123456789,文档援用了书局的_ID)

{

*   _id: 123456789,*

*   title: “MongoDB: The Definitive Guide”,*

*   author: [ “Kristina Chodorow”, “Mike Dirolf” ],*

*   published_date: ISODate(“2010-09-24”),*

*   pages: 216,*

*   language: “English”,*

  publisher_id: “oreilly”*

}

那时图书的文书档案记录如下:(书籍为234567890,文档援引了书局的_ID) 

{

*   _id: 234567890,*

*   title: “50 Tips and Tricks for MongoDB Developer”,*

*   author: “Kristina Chodorow”,*

*   published_date: ISODate(“2011-05-06”),*

*   pages: 68,*

*   language: “English”,*

*   publisher_id: “oreilly”*

}

 

3.3.2.4Model Tree Structures with Materialized Paths

不怕把祖先节点用,拼成二个字符串组成路线

show dbs

四  后记

MongoDB的方式设计是贰个非常的大的课题,需求多看看情景案例,多品尝一些能够的文书档案设计,多问一些问什么要如此做,是或不是有更优的设计,要逐级去通晓MongoDB的历史学观念。

简单来讲,那是二个多看、多想、多思的演化羽化进程,恐怕时间相当短、进程某些哀痛。

 

3.2.2.4索引

选拔索引能够荣升部分读取质量,当然Mongodb会自动在_id上开创独一索引。在创制索引时思虑以下行为:

         1.各类索引起码8kb空间

         2.加多索引给写操作会带给消极的一面质量

         3.Collection读多写少能够使用索,Collection读少写多要尽量裁减索引

         4.各种索引都要消耗内部存款和储蓄器和磁盘空间,那上头的利用相应被追踪并杜撰到技能安插内

图片 3

案例3

 

 上面介绍的是1对多的涉嫌(1:N),不过N值不是相当大。但是现实世界中,不时候会高出N值比较大的气象。

诸如 书局和书本的关联,三个书局或然已将出版了不胜枚举本书籍了。

图片 4

 

其设计形式能够如下(内嵌格局),将书局的新闻作为几个子文书档案,来内嵌到图书的文书档案中,具体新闻如下:

以下书籍《MongoDB: The Definitive Guide》的文书档案音讯: 

{

   title: “MongoDB: The Definitive Guide”,

   author: [ “Kristina Chodorow”, “Mike Dirolf” ],

   published_date: ISODate(“2010-09-24”),

   pages: 216,

   language: “English”,

   publisher: {

              name: “O’Reilly Media”,

              founded: 1980,

              location: “CA”

            }

}

 以下书籍《50 Tips and Tricks for MongoDB Developer》的文档信息: 

{

   title: “50 Tips and Tricks for MongoDB Developer”,

   author: “Kristina Chodorow”,

   published_date: ISODate(“2011-05-06”),

   pages: 68,

   language: “English”,

   publisher: {

              name: “O’Reilly Media”,

              founded: 1980,

              location: “CA”

            }

}

从当中能够见见,publisher音讯描述比比较多,而且都相像,每一个文书档案中都寄存,浪费太多的存放空间,显得无用痴肥,还应该有个醒指标缺欠就是当publisher数据更新时,须要对富有的图书文书档案实行刷新。理之当然地,就能想到将书局独立出来,单独设计叁个文书档案。(引用方式)。

3.4.1.5_id字段

_id字段常常被用来索引,_id能够是别的项目但不能是数组,_id的值能够有以下多少个选项:

         1.使用obejctid

         2.运用唯黄金年代标记符

         3.采用自增进数

         4.应用UUID,GUID是UUID的意气风发种达成

         5.施用驱动的BSON
UUID特性生成UUID

1、增

内嵌方式

归纳来说,内嵌情势正是将涉及数据,放在二个文书档案中。举个例子以下职员和工人消息运用内嵌形式了而存款和储蓄在了二个文书档案中:

图片 5

3.2数据模型概述

在筹算数据模型时,有为数不菲筛选采纳,各样都有补益和弊病。

collection.update({},
{“$inc” : {“x” : 1}})

 案例 4

 

下边四个例证,在关系型数据库中都能够用大家上学过的关系(举例1:1;1:N)来陈说,那么大家再举三个关系型数据库难以描述的涉及
树状关系

诸如,大家在电子商务网址上布满的货物分类关系,一流商品、二级商品、三级商品、四级商品关系。大家简化此例子如下:

图片 6

 

 那么在MongoDB中得以轻巧实现他们关系的查询。

3.4.1.6点(.)字符

在Mongodb中式茶食字符用来访谈数组(array.index)和子文书档案(subdocument.田野同志卡塔尔

在数据库中询问那些变量

 援用形式1

大家能够如此设计:书局单独设计为二个会面文书档案(文书档案中引用书籍的号子),如下:

{

   name: “O’Reilly Media”,

   founded: 1980,

   location: “CA”,

   books: [123456789, 234567890, …]

}

 书籍集结中编号为123456789的图书的文档:

{

    _id: 123456789,

    title: “MongoDB: The Definitive Guide”,

    author: [ “Kristina Chodorow”, “Mike Dirolf” ],

    published_date: ISODate(“2010-09-24”),

    pages: 216,

    language: “English”

}

  书籍集合中编号为234567890的图书的文书档案:

{

   _id: 234567890,

   title: “50 Tips and Tricks for MongoDB Developer”,

   author: “Kristina Chodorow”,

   published_date: ISODate(“2011-05-06”),

   pages: 68,

   language: “English”

}

此设计中,将书局出版的书的编号,保存在了书局这一个会集中。

只是这种布置依旧不常常,举例,数组的翻新、删除相对比较艰难。还会有正是,每增加二个图书集结的文档,同一时间还要校勘这么些书局结合的文档。
所以,大家还足以将这种集结文书档案设计优化如下。

3.3.1.1嵌入1对1模型

即使用子文书档案的拜访嵌入在父文档中,尽管采取援用类型,那么会须求多趟查询才具博取结果。

三、常用的增加和删除改查

气象1  查询节点的父节点(或称为查询上一流分类);也许查询节点的子节点(可能为查询下一流分类)

文书档案的安顿性为:

 

db.categories.insert( { _id: “MongoDB”, parent: “Databases” } )
db.categories.insert( { _id: “dbm”, parent: “Databases” } )
db.categories.insert( { _id: “Databases”, parent: “Programming” } )
db.categories.insert( { _id: “Languages”, parent: “Programming” } )
db.categories.insert( { _id: “Programming”, parent: “Books” } )
db.categories.insert( { _id: “Books”, parent: null } )

 

查询节点的父节点(或称为查询上拔尖分类)的说话,举个例子查询MongoDB所属分类:

db.categories.findOne( { _id: “MongoDB” } ).parent

询问节点的子节点(可能为查询下一流分类),举例查询Database的直连的子节点(不是儿子节点)。

db.categories.find( { parent: “Databases” } )

地方的文书档案能够查询出子文书档案,然而会来得出三个文书档案,比如地点的询问语句,会回到出MongoDB
文书档案和 dbm文书档案,大家还须求还特别管理,那么可不得以在一个文书档案中显得出所以的子节点呢?

能够的。文书档案形式设计如下:

 

db.categories.insert( { _id: “MongoDB”, children: [] } )

db.categories.insert( { _id: “dbm”, children: [] } )

db.categories.insert( { _id: “Databases”, children: [ “MongoDB”,
“dbm” ] } )

db.categories.insert( { _id: “Languages”, children: [] } )

db.categories.insert( { _id: “Programming”, children: [ “Databases”,
“Languages” ] } )

db.categories.insert( { _id: “Books”, children: [ “Programming” ] }
)

 

假诺这时候查询Databases的子节点,就能够是三个文档了。查询验证语句如下:

db.categories.findOne( { _id: “Databases” } ).children

此格局也补协助调查询节点的父节点。比如查询MongoDB这几个节点的父节点:

db.categories.find( { children: “MongoDB” } )

3.1.3文书档案增加

当文书档案大小超越了分红的长空时,Mongodb会重新分配二个空间,增进的考虑会听得多了自然能详细说出来平日数据,和异形数据。

例行的闭馆措施

场景2  查询祖先节点

其文书档案设计为:

 

db.categories.insert( { _id: “MongoDB”, ancestors: [ “Books”,
“Programming”, “Databases” ], parent: “Databases” } )

db.categories.insert( { _id: “dbm”, ancestors: [ “Books”,
“Programming”, “Databases” ], parent: “Databases” } )

db.categories.insert( { _id: “Databases”, ancestors: [ “Books”,
“Programming” ], parent: “Programming” } )

db.categories.insert( { _id: “Languages”, ancestors: [ “Books”,
“Programming” ], parent: “Programming” } )

db.categories.insert( { _id: “Programming”, ancestors: [ “Books” ],
parent: “Books” } )

db.categories.insert( { _id: “Books”, ancestors: [ ], parent: null }
)

* *

例如说查询MongoDB节点的上代节点:

db.categories.findOne( { _id: “MongoDB” } ).ancestors

理当如此也得以查询 后代节点:

db.categories.find( { ancestors: “Programming” } )

3.1数据模型简单介绍

数据库模型的非常重若是平衡应用程序的要求,和数据库引擎的性情和数码取回方式。

3,multi模式

案例 1

 

 借使现在我们描述来顾客(patron)和消费者的地点(address),其E奔驰M级图如下:

图片 7

 

 

 大家得以将patron和address设计成七个汇集(collection,形似于汉兰达DBMS数据库中的table卡塔尔(قطر‎,其具体音信如下:

 patron 集合

{

*   _id: “joe”,*

*   name: “Joe Bookreader”*

}

 address 集合

{

*   patron_id: “joe”,*

*   street: “123 Fake Street”,*

*   city: “Faketon”,*

*   state: “MA”,*

*   zip: “12345”*

}

 在设计address
集合时,内嵌了patron集合的_id字段,通过那个字段实行关联。

但这种实体关系为1:1,强涉嫌的关联

引入设计成如下方式:

{

*   _id: “joe”,*

*   name: “Joe Bookreader”,*

*   address: {*

*              street: “123 Fake Street”,*

*              city: “Faketon”,*

*              state: “MA”,*

*              zip: “12345”*

*            }*

}

 固然用内嵌方式,将数据存款和储蓄在叁个成团中。

 

3.3.3一定应用程序上下文模型

   

3.2.1.2援用数据模型(normalized)

引用数据模型有弹指间益处:

         1.当嵌入模型有双重数据现身,用引用模型能够缩小重复,可是不能够提供读质量

         2.得以象征多对多涉及

         3.表示巨大的频频数据集

引用类型供给多趟执行本领收获结果那个是最大的老毛病。

db.abc.find({“a”:23},{“b”:1},{“-id”:0}卡塔尔(قطر‎表示毫不_id这一列

3.2.3.1GridFS Collection

GridFS有2个Collection,Chunks顾客保存文件的二进制,files用于保存文件的元数据。暗许这2个collection是以fs为前缀。只要file中有贰个文书档案,就证实在chunks中有一个文本。

   

3.4.1文档

在Mongodb中客商能够访问的比非常多都以文书档案:

         1.全体数据库的笔录

         2.询问选拔器,定义了要过滤那多少个数据,呈现这几个数据

         3.更新定义,定义了那么些数据要被更新

         4.索引,钦定了目录的key

         5.由Mongodb输出的配置新闻和告知音讯

   

3.3.2.1Model Tree Structures with Parent References

父节点引用,在各样节点上存上父节点的_id。轻巧的兑现了树的法力,可是相比较难查询某二个子树。

{“a”:23,”c”:37},

3.2.2.6数量生命周期管理

若数占有生命周期,能够假造使用Time to Live or TTL特性来节制数量的长久性,倘使数据只是用当下布置的,能够动用Capped Collections提供先进先出的处理。

更新

3.3.2.2Model Tree Structures with Child References

在节点上平添二个数组,把子节点参加到数组中。实现方式很契合,然而子树上边不要有退换的操作,不然比较勤奋操作。

“_id” :
ObjectId(“4b2b9f67a1f631733d917a7a”),

3.3.1.3引用1对多模型

援用格局能够减弱重复数据,若是有大气的再度数据那么可以盘算动用引用形式来收缩空间浪费。

和sql中limit相近,约定重返数据的个数

3.4.4 ObjectId

ObjectId长度12字节的BSON类型:4字节:自Unix以来的秒数,3字节:机器标志符,2字节经过id,3字节随机数。

Mongodb选取objectid是因为短,生成快,若客商端加了那么必须是独占鳌头的,若不加就私下认可会用objectid。

         1.足以用Objectid.getTimestamp(卡塔尔(قطر‎来查看Objectid的创造时间。

         2._id字段存了objectid的排序和创办时间排序同样。

唯独在相互作用状态下,Objectid不能够严厉的象征插入的逐个,用户端之间的光阴并分化,objectid是client
driver生成的。

db.blog.findOne()

3.2.2可选的特色和数据模型

格局化应用程序数据不单单是数据笔者的主题材料,还也可能有点和Mongodb的特征有关,开垦贰个数据模型,用一下块来分析读写操作。

        文档中得以松手文书档案

3.1.1.1引用

援引方式是文书档案中存了后生可畏份,别的八个文书档案的_id然后通过,_id连接相关的文书档案。

图片 8

       安全操作:顾客端将文书档案件发生给服务器,再试行getLastError操作,等待服务器反馈后再持续下风华正茂操作,如若开掘服务器反馈与预期不符,则抛出格外

3.4.2数据库引用

在数据库中援引有2种情势:手动援用,DBRef(数据库援用卡塔尔,当对于到三个collection时使用DBRef。

db.food.find({“food”:{“$size”:3}})

3.3.2树构造模型

首要介绍一下三种:

         Model Tree Structures with Parent
References援用父节点,

         Model Tree Structures with Child References
援引子节点,

         Model Tree Structures with an Array of
Ancestors用数据来记录先辈节点,

         Model Tree Structures with Materialized
Paths用字符串来记录路线,

         Model Tree Structures with Nested
Sets用前序遍历方式。

   

3.3.3.2扶植注重字查询的数据模型

要援救那个模型,先要在文书档案中国建筑工程总公司八个数组,并把注重字各种加多到数组中,然后在这里个数据方面成立索引,当数组相当的大的时候insert会带给非常的大的消极面质量。

delete joe.enemies;

3.1.1.2平放数据

正是文书档案以子文书档案的秘技存在此外八个文书档案下边。

图片 9

   

3.4.2.1手动引用

文档的_id被存在其它七个文书档案,应用程序要经过别的一个询问来获取引用的多寡。手动援引最大的毛病是无可奈何对应到数据库和collection名。所以不能够关联多个collection。若关联多少个collection可以运用DBRef。

   

3.2.3.2GridFS 索引

GridFS在chunks上运用唯大器晚成,复合索引在files_id和n 贰个字段上。files_id包含了_id的chunks的付文书档案,n表示chunks的风流倜傥生龙活虎。

collection.find_one()

3.4.1.2文书档案结构

文书档案构造是json的key-value情势,value可以是随意的数据类型。

print time.time() –
start

3.2.2.3Sharding

Sharding提供了水平扩大能力,集群能够支撑大的数据集和高吞吐量,sharding是把数量分片到不相同的实例上。shard key是分片的要害依附,所以选拔二个靠边的key是很要紧的。

4、查

3.3.3.1原子操作数据模型

当您保存在一个文书档案之后,你能够使用db.collection.findAndModify(State of Qatar方法来保险原子性,如:

db.books.findAndModify ( {

         query: {

                   _id: 123456789,

                   available: { $gt: 0 }

         },

         update: {

                   $inc: { available: -1 },

                   $push: { checkout: { by: “abc”, date: new Date() } }

         }

} )

db.blog.find();

3.2.2.2原子性

Mongodb原子性只提供到文书档案等级,全部之上的等级都不援助原子性,能够把要保管原子性的数目放到同一个文书档案中,没有要求的就放到任何文书档案。用文书档案的原子性来拍卖很有利,否则要把数量按读写分开管理多少(相仿二品级提交的方法)。

2.upsert模式

3.3数据模型的例证和方案

   

3.2.2.1文档增加

文书档案增加以致空间重新分配,招致品质难点,能够行使padding,预分频,或许重构数据模型来管理。

用法:

3.4.2.2DBRef

DBRef会多一下几个字段:$ref 保存collection的名字,$id保存关联的_id,$db
可选取于保存db名。

“username” : “joe”,
“relationships” :

3.4.5 BSON类型

  1. MinKey (internal type)
  2. Null
  3. Numbers (ints, longs, doubles)
  4. Symbol, String
  5. Object
  6. Array
  7. BinData
  8. ObjectID
  9. Boolean
  10. Date, Timestamp
  11. Regular Expression
  12. MaxKey (internal type)

 

Objectid:小,唯意气风发,快速生成,顺序的

String:BSON字符串是UTF-8

Timestamps:Mongodb内部使用BSON有特定的timestamp数据类型并非用Date类型来做扶持,在复制中oplog的ts字段也是timestamp类型。

Date:日期类型,陆拾叁个人微秒级表示从Unix发生到现行反革命。

   

首要字查询的限量:

         1.词干:关键字查询不可能解析有些词的词根恐怕连带的词

         2.相近词:不可能提供相近词查询,要在应用层达成

         3.权重:未有权重计算

         4.异步索引:Mongodb上索引都以二只的,不过对于全文索引来讲异步索引提升质量

数组改善器

3.4.1.4文书档案的一对限量

1.BSON文书档案最大为16MB,若超过这些到校能够用GridFS保存

2.字段名_id是保留的,无法以$作为字段的早先,字段不能够富含字符“.”

3.Mongodb没办法承保BSON文书档案中字段的次第

此地2 表只数组下标为2的因素

3.3.1.2内置1对多模型

同嵌入1对1

db.hits.update({“_id” :
ObjectId(“5161a3056b432e29748b2164”)},{“$set”:{“ip”:20}});

3.3.2.5Model Tree Structures with Nested Sets

这种措施是存入父节点之外,用前序遍历的点子,把步入时,和退出时的步数记录下来,如:

db.categories.insert( { _id: “Books”, parent: 0, left: 1, right: 12 } )

db.categories.insert( { _id: “Programming”, parent: “Books”, left: 2, right: 11 } )

db.categories.insert( { _id: “Languages”, parent: “Programming”, left: 3, right: 4 } )

db.categories.insert( { _id: “Databases”, parent: “Programming”, left: 5, right: 10 } )

db.categories.insert( { _id: “MongoDB”, parent: “Databases”, left: 6, right: 7 } )

db.categories.insert( { _id: “Postgres”, parent: “Databases”, left: 8, right: 9 } )

图片 10

这种措施得以高速的询问出子树,可是朝气蓬勃旦改造树结构就不是很有益于。

db.users.update({ “name” : “joe” },
joe,true, true);

3数据模型(Data Models卡塔尔国

Mongodb Manual阅读笔记:CH2 Mongodb
CRUD 操作 Mongodb
Manual阅读笔记:CH3 数据模型(Data ModelsState of Qatar Mongodb
Manual阅读笔记:CH4 管理 Mongodb
Manual阅读笔记:CH5 安全性 Mongodb
Manual阅读笔记:CH6 聚合 Mongodb
Manual阅读笔记:CH7 索引 Mongodb
Manual阅读笔记:CH8 复制集 Mongodb
Manual阅读笔记:CH9
Sharding

 

多少在Mongodb中是定点框架,不过Collection不强迫任何文书档案布局

3数据模型(Data Models卡塔尔国1

3.1数据模型简要介绍…
2

3.1.1数据布局…
2

3.1.1.1引用…
2

3.1.1.2放权数据…
3

3.1.2 写操作的原子性…
3

3.1.3文书档案增加…
3

3.1.4数量应用和脾性…
3

3.2数据模型概述…
3

3.2.1数据模型设计…
4

3.2.1.1停放数据模型…
4

3.2.1.2援引数据模型(normalized)…
4

3.2.2可选的特征和数量模型…
4

3.2.2.1文书档案拉长…
4

3.2.2.2原子性…
4

3.2.2.3Sharding.
5

3.2.2.4索引…
5

3.2.2.5大量的Collection.
5

3.2.2.6数不熟悉命周期管理…
5

3.2.3 GridFS.
5

3.2.3.1GridFS Collection.
6

3.2.3.2GridFS 索引…
6

3.3数据模型的事例和方案…
6

3.3.1文书档案间关系模板…
6

3.3.1.1嵌入1对1模型…
6

3.3.1.2平放1对多模型…
6

3.3.1.3引用1对多模型…
6

3.3.2树布局模型…
6

3.3.2.1Model Tree Structures with Parent
References.
7

3.3.2.2Model Tree Structures with Child
References.
7

3.3.2.3Model Tree Structures with an Array of
Ancestors.
7

3.3.2.4Model Tree Structures with Materialized
Paths.
7

3.3.2.5Model Tree Structures with Nested Sets.
7

3.3.3一定应用程序上下文模型…
8

3.3.3.1原子操作数据模型…
8

3.3.3.2支撑至关心注重要字查询的数据模型…
8

3.4数据模型 Reference.
9

3.4.1文档…
9

3.4.1.1文书档案格式…
9

3.4.1.2文书档案构造…
9

3.4.1.3字段名…
9

3.4.1.4文书档案的部分限定…
9

3.4.1.5_id字段…
9

3.4.1.6点(.)字符…
10

3.4.2数据库引用…
10

3.4.2.1手动引用…
10

3.4.2.2DBRef10

3.4.3 GridFS Reference.
10

3.4.4 ObjectId.
10

3.4.5 BSON类型…
11

 

   

3.3.2.3Model Tree Structures with an Array of Ancestors

把祖先节点用在三个数组里面,使用这么些情势,超级轻巧寻找子树的节点,并且能够即时意识到祖先节点。

collection.insert({“x”: 1})

3.2.1.1放到数据模型

嵌入数据模型是非符合规律(denormalized)的数据模型。嵌入数据模型,能够存相关的音讯到同多少个笔录,用少之又少的操作就会产生查询,更新。以下场景使用嵌入数据模型:

         1.目的之间是带有关系,1对1涉及

         2.对象时期是1对多关系

不认为奇嵌入格局能够通过相比较好的读质量,也足以成功原子性,然则文书档案的增加会成为叁个属性难点。而且亟需小于BSON文书档案的最大值。

内置文书档案的拜望能够通过.(点)符号来贯彻。

“name” : “joe”,

3.1.2 写操作的原子性

写操作的原子性是在文档次和等第别的,只对单个文书档案内的支撑。一些有益的原子写会约束应用程序使用数据,或许约束应用程序的退换。

   

3.3.1文档间关系模板

最首要介绍:使用嵌入的1对1模子,使用嵌入的1对多模型,使用引用的1对多模型

图片 11

3.4数据模型 Reference

原则性更改 ,

3.1.1数据结构

数据构造有援引和放手2种文书档案。

{

3.2.1数据模型设计

多少安登时重点思忖的难点是:援引照旧嵌入。

   

3.4.3 GridFS Reference

GridFS保存2个collection,chunks,files,以fs为前缀。能够用非fs前缀,能够在叁个数据库中开创八个前缀。

定个三个变量,并为那么些变量扩大贰特性质,值为空数组

use admin //那一个时怎么着意思

db.blog.findOne()

   

db.addUser(“root”,”abcd”)

db.blog.find()

5.正则表明式

{“a”:31,”c”:34}])

db.blog.findOne();

$inc

1.在shell中查阅扶助消息

        区分抑扬顿挫写,

直接设定键值,如若原来有 ip 这一个键,就把原本的这几个键的值设为20,若无就大增叁个键,并把值设为20.

此地的$正是一定操作符,那样就绝不人工直接输入地点了。

db =
Connection().performance_test

   

图片 12

“_id” :
ObjectId(“4b2b9f67a1f631733d917a7a”),

      须臾时达成:客商端将文书档案件发生给服务器,无须等待服务器有别的响应(实际上也尚未),就能够开展下后生可畏操作。(相同于互连网契约中的UDP,称为”离弦之箭”)

        数据库本人内置的复制与高可用

用$ where 前边加上javascrip函数。

“enemies” : 2

db.abc.find({“a”:23},{“b”:0}State of Qatar 表示大家毫不b列,其余的都要

   

db.blog.insert(x);

$all

$push:为数组追港成分

   

把Ip这些键值删除,后边这几个1是无论写的

joe.username =
joe.name;

图片 13

$slice

–config
这里能够指定配制消息

   

db.abc.find({“b”:{“$in”:[25,32]}})

改善记录属性,很置之不顾的JavaScript语法

操作:首先查找记录

   

db.math.updat({“count”:25},{“$inc”:3},true)

_id
用于唯少年老成标示文书档案,借使插入七个文书档案的_id已存在于数据库中,假设用insert
插入则会产生特别,尽管用save(卡塔尔(قطر‎进行封存,则不会发出卓殊,可是会覆盖原本的数据.

原文档

2.Mongodb查询:find

发表评论

电子邮件地址不会被公开。 必填项已用*标注