NoSQLMongoDB 存储引擎和数据模型设计

A. 1 – 1 或者 1 – *(较少)

**

用户与账户,以及用户与收货地址都是这么情状,在这么的情况下,综上说述大家得以选用内嵌的不二法门来举办数量管理。

> db.person.findOne()
{
    _id:ObjectId("cccc"),
    name:"wddpct",
    age:22,
    location:"wenzhou",
    addresses:[
        {country:"china",city:"wenzhou",street:"chashan road"}
        {country:"china",city:"wenzhou",street:"north center road"}
    ]
}

那也引伸出一个题材,除了“1”以外的另一端的实体是否有必不可少在数额较少的时候举办单独集合的囤积。如用户和任务模块,职责是系统定期公布,分配给相应用户落成,这表示我们对职分的操作也将比较复杂。那样的境况下,显明是分离不相同集合举办仓储,然后让person集合引用task_id数组。

> db.person.findOne()
{
    _id:ObjectId("cccc"),
    name:"wddpct",
    age:21,
    location:"wenzhou",
    tasks:[
        ObjectId("xxxx"),
        ObjectId("yyyy"),
        ……
    ]
}

于是本着刚才提到的情景,大家大可以借鉴世界驱动格局中的“实体”和“值对象”的一对概念,首要仍然看那几个数据模型在系统中是或不是有较大较复杂的操作可能。

**

D. * – *

**

对此多对多涉及模型,可能又要祭出那句古语——“视具体景况而定”。然而貌似景观下,它可是就是一对多关系的多少个变种。一个中心的尺度是考虑两边统一引用对方的ObjectId,适当冗余部分音讯。

除此以外,我们还足以从以下多少个规格去考虑

  1. 两边的数码比(较大方更切合引用)
  2. 两边的翻新频率比(较大方更符合引用)
  3. 两边的读取频率比(较大方更合乎内嵌)
    ……

2.1 内嵌和引用

在MongoDB中,数据的表示方法有内嵌和引用二种。

“引用”大家相比较好了然,是指将分歧实体的数据分散不到分歧的聚集中,而在关系型数据库设计中就是将实体分别建立相应的模型表。如广大的“老师-学生”,“产品-标签”关系,只要实体间存在关联,就可以应用“引用”思想。

“内嵌”是一种反范式化的宏图,指的是将种种文档所需的数据都放到到文档内部,我想举一个“用户-账户”的涉及。大家明白在天地驱动设计中,“用户”是一个聚合根,每个用户对应一个账户,所以是“1对1”的一种关系,在关系型数据库设计中,半数以上时候都会将这多头严厉不一致开来。不过在MongoDB中,却不然,大家可以直接拔取将“用户”须要的“账户”数据内嵌到用户文档中,便于大家的增删改查。那是一种反范式化的统筹。

统筹MongoDB数据模型的时候,我们需求扭转以往设计关系型数据模型时的思辨。即使是本着一个关乎中不相同集合的多少规模,大家的模子也将有很大的例外。

B. 1 – *(较多)

**

博主以前负责过一个市级地区中小学眼视光筛查系统,里面的简化模型就比较符合拿来做例子。如高校与学员,数目多也不过数千。那样的状态下,自然也是选拔引用的点子更简单接受

> db.school.findOne()
{
    _id:ObjectId("cccc"),
    name:"middle1",
    location:"wenzhou",
    students:[
        ObjectId("xxxx"),
        ObjectId("yyyy"),
        ……
    ]
}

此间同样也引伸出一个“冗余”的标题,我们了解大多时候大家需要查询的数量属性数据是相比少的,比如对于学员而言,大家可能只要求领会他的身高体重,所以大家得以应用“冗余”思想简单修改刚才的会聚成以下格式来应付

> db.school.findOne()
{
    _id:ObjectId("cccc"),
    name:"middle1",
    location:"wenzhou",
    students:[
        {ObjectId("xxxx"),name:"wddpct",height:233,weight:233},
        {ObjectId("yyyy"),name:"wddmd",height:233,weight:233}
        ……
    ]
}

不过也要专注的少数是,那样每便换代student的音讯时,不免又要对school中的冗余音信举办立异,所以也要组成具体境况使用

**

E. 通用提出

以下给出一张较通用的提议表,仅供参考

内嵌 引用
子文档较小 子文档较大
数据不会定期更改 数据经常改变
最终数据一致即可 中间阶段数据也必须一致
文档数据小额增加 文档数据大幅增加
数据通常需要执行二次查询 数据通常不包含在查询结果中
快速读取 快速写入

1.2 MongoDB中的默许存储引擎

自MongoDB 3.2
Release版本起,MongoDB默认的积存引擎就成了WiredTiger。而在事先的版本中,它仍旧MMAPv1。但由于,ongoDB架构帮衬可插拔的存储引擎,所以利用中就是要转移也是足以成功的。至于其余的功用比较大家可以参照合法文档,如不再是In-Place
Update,新增Compression等。

俺们得以在打开mongod服务时输入相关参数调整存储引擎,如mongod
–storageEngine MMAPv1|wiredTiger
咱俩也得以采取db.collections.stats()查看当前的发动机名称

  • MMAPv1
    MMAPv1 提供集合级别锁(实际上称为collection-level locking)

  • WiredTiger
    WiredTiger 对于写操作提供文档级别并发控制(实际上称为document-level
    concurrency),由此,区其他客户端请求能够在同一时间针对一个集合中的不相同文档记性修改

C. 1 – *(非常多)

**

地区和车牌的涉及勉强属于此类,一个所在可能有几十上百万车牌,大家不容许再像刚刚那么在area中投入所有的license_id,不然可能光是单个文档大小就当先MongoDB的16MB限制了,而且对于查询也存在很大的负责。

那里大家得以一向套用关系型数据库中的外键思想,在license集合的末梢加入area_id就足以一本万利解决此类关系

> db.license.findOne()
{
    _id:ObjectId("cccc"),
    license:"middle1",
    area:ObjectId("xxxx")
}

自然,大家也足以对area举办更进一步冗余,所以就不额外表达了。

**

1. 储存引擎

2. 数据模型设计

2.2 设计规范

**

1.1 存储引擎是如何

仓储引擎是坐落持久化数据(寻常是置身磁盘或者内存中)和数据库之间的一个操作接口,它负责数据的储存和读取措施。MongoDB数据库通过存储引擎在磁盘中读取数据,而即使我们的利用是ASP.NET
MVC,我们得以采取官方的Mongo.Driver驱动,通过通讯协议(如TCP)向MongoDB数据库发送各类请求。以下是一个简易的运作图示

标签: MongoDB NoSQL

网站地图xml地图