MongoDB数据结构设计中6条重要的经验法则

很多初学者认为在MongoDB中针对一对多建模唯一的方案就是在父文档中内嵌一个数组子文档,但是这是不准确的。因为你可以在MongoDB内嵌一个文档不代表你就必须这么做。

当你设计一个MongoDB数据库结构,你需要先问自己一个在使用sql时不会考虑的问题:这个关系中集合的大小是什么样的规模?你需要意识到一对很少,一对许多,一对非常多,这些细微的区别。不同的情况下你的建模也将不同。

一对很少

一个人的地址为例,这时候使用内嵌文档是很合适,可以在person文档中嵌入数组地址文档:

< db.person.findOne()

{

name: ‘Kate Monster’,

ssn: ’123-456-7890′,

addresses : [

{ street: '123 Sesame St', city: 'Anytown', cc: 'USA' },

{ street: '123 Avenue Q', city: 'New York', cc: 'USA' }

]

}

这种设计拥有内嵌文档设计中所有的优缺点。最主要的优点就是不需要单独执行一条语句去获取内嵌的内容。最主要的缺点是你无法把这些内嵌文档当做单独的实体去访问。

一对多

以商品替换零件订货系统为例。每个商品有数百个可替换的零件,但是不会超过数千个。这个用例很适合使用间接引用-将零件的objectid作为数组存放在商品文档中(在这个例子中我使用更加易读的2字节的ObjectID,现实世界中他们可能是由12个字节组成的)。

< db.parts.findOne()

{

_id : ObjectID(‘AAAA’),

partno : ’123-aff-456′,

name : ‘#4 grommet’,

qty: 94,

cost: 0.94,

price: 3.99

}

< db.products.findOne()

{

name : ‘left-handed smoke shifter’,

manufacturer : ‘Acme Corp’,

catalog_number: 1234,

parts : [ // array of references to Part documents

ObjectID('AAAA'), // reference to the #4 grommet above

ObjectID('F17C'), // reference to a different Part

ObjectID('D2AA'),

// etc

]

在获取特定产品中所有零件,需要一个应用层级别的join

< product = db.products.findOne({catalog_number: 1234});

< product_parts = db.parts.find({_id: { $in : product.parts } } ).toArray() ;

为了能快速的执行查询,必须确保products.catalog_number有索引。当然由于零件中parts._id一定是有索引的,所以这也会很高效。

这中引用的方式是对内嵌优缺点的补充。每个零件是个单独的文档,可以很容易的独立去搜索和更新他们。使用这种建模方式需要考虑的一个问题是需要一条单独的语句去获取零件的具体内容

这种建模方式中的零件部分可以被多个产品使用,所以在多对多时不需要一张单独的连接表。

一对很多

我们用一个收集不同机器日志的例子来讨论一对很多的问题。由于每个mongodb的文档有16M的大小限制,所以即使你是存储ObjectID也是不够的。我们可以使用很经典的处理方法“父级引用”—用一个文档存储主题,在每个日志文档中保存这个主机的ObjectID。

< db.hosts.findOne()

{

_id : ObjectID(‘AAAB’),

name : ‘goofy.example.com’,

ipaddr : ’127.66.66.66′

}

<db.logmsg.findOne()

{

time : ISODate(“2014-03-28T09:42:41.382Z”),

message : ‘cpu is on fire!’,

host: ObjectID(‘AAAB’) // Reference to the Host document

}

以下是个稍微不同的应用级别的join用来查找一台主机最近5000条的日志信息

< host = db.hosts.findOne({ipaddr : ’127.66.66.66′});

< last_5k_msg = db.logmsg.find({host: host._id}).sort({time : -1}).limit(5000).toArray()

所以,即使这种简单的讨论也有能察觉出mongobd的建模和关系模型建模的不同之处。你必须要注意一下两个因素:

一对多中的多是否需要一个单独的实体。

这个关系中集合的规模是一对很少,很多,还是非常多。

基于以上因素来决定采取一下三种建模的方式

一对很少且不需要单独访问内嵌内容的情况下可以使用内嵌多的一方的方案。

一对多且多的一段内容因为各种理由需要单独存在的情况下可以使用通过数组的方式引用多的一方的方案。

一对非常多的情况下,请将一的那端引用签入进多端的方案。

原文发布于微信公众号 - php(phpdaily)

原文发表时间:2015-11-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏互联网杂技

Angular2 脏检查过程

在本文中我将会深入讨论Angular 2 中的变更检测系统。 高层次概览 一个Angular 2 应用就是一颗组件树。 ? Angular 2 应用是一个反馈系...

3788
来自专栏游戏杂谈

Unity中巧用协程和游戏对象的生命周期处理游戏重启的问题

主要用到协程(Coroutines)和游戏对象的生命周期(GameObject Lifecycle)基础知识,巧妙解决了游戏重启的问题。

1372
来自专栏颇忒脱的技术博客

面向程序员的网络基本知识 - 子网分割

本系列文章旨在向程序员分享一些网络基本知识,让程序员具备基本的网络常识,以便与网络工程师沟通。本系列文章不会涉及如何组建网络、如何配置交换机/路由器等硬件相关的...

823
来自专栏架构师之路

业界难题-“跨库分页”的四种方案

一、需求缘起 分页需求 互联网很多业务都有分页拉取数据的需求,例如: (1)微信消息过多时,拉取第N页消息 (2)京东下单过多时,拉取第N页订单 (3)浏览58...

5124
来自专栏Python中文社区

Python量子力学计算模拟以及数据可视化

專 欄 ❈Pytlab,Python 中文社区专栏作者。主要从事科学计算与高性能计算领域的应用,主要语言为Python,C,C++。熟悉数值算法(最优化方法,...

4808
来自专栏Java技术栈

5分钟带你理解一致性Hash算法。

一致性Hash算法背景 一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的,设计目标是为了解决因特网中的热点(Hot s...

3458
来自专栏木子昭的博客

<技巧>python模块性能测试以python列表的内置函数append和insert为例以python列表insert方法和append方法快速创建1至1000的列表为例:

算法是程序的灵魂,优秀的算法能给程序的效率带来极大的提升,而算法的优劣,往往要经过大量的测试. 在硬件环境基本不变的前提下,对算法实验的次数越多,测试算法运...

3056
来自专栏Crossin的编程教室

【每周一坑】螺旋矩阵

今天这题,看起来挺简单,实际写出来并不容易。在以前公司我曾把它做过招聘的笔试题,结果惨不忍睹,不得不拿掉。 输出如图的螺旋矩阵: 1 2 3 4...

3387
来自专栏吉浦迅科技

在cuda的核函数中可以按地址调用普通变量么?

请问在cuda的核函数中可以按地址调用普通变量么? GPU世界论坛 bbs.gpuworld.cn Hi, 楼主, 完全无问题,从Fermi起引入卡内统...

3597
来自专栏linux驱动个人学习

Linux CFS调度器之虚拟时钟vruntime与调度延迟--Linux进程的管理与调度(二十六)

CFS为了实现公平,必须惩罚当前正在运行的进程,以使那些正在等待的进程下次被调度。

954

扫码关注云+社区