MongoDB 浅谈设计和使用 1 2 3

MONGODB 在不少公司应用的场景越来越多,实际上有这样一个观念, MONGODB 无法存储核心数据, 无法接触核心业务,核心的数据还应该是传统数据库的天下. REALLY ?

首先要弄清这个问题,需要搞清楚到底谁会这样想? 搞清楚谁会这样想,那么可以从某些角度来改变或影响.  我第一个想法就是 开发,  一个项目中可以没有架构师,可以没有DB ,可以没有项目经理 .....   但唯独不会没有开发

Massive arrays  &  Massive number of collections 是今天要说的 WHY 

在数据存储中,传统的数据存储有一个想法核心的想法,数据的存储和他所承载的业务和逻辑等有关,而我们要通过某种人为的方式去把他们分开? 通过设计,或者在没有设计,你也不会将所有的数据都存到一张表,,例如 订购的产品的信息,至少你会想到  顾客, 产品, 销售的流程, 等等和整体订购有关的信息,会分门别类的存储在传统数据库的不同的表中,然后在通过 join 的方式来联合查询.得到你要的数据.

MONGODB 的想法是数据如果要被访问,他们就应该在一起,而不是分开他们.

在mongodb的应用中数组的应用中和索引之间的性能是成反比的. 在设计中有两种思路, 其实也就是数据的存储的主导性.  第一种是以部门为主导进行员工的存储,第二种是以员工为主导,其中附带部门的信息

两种设计中第一种设计,

优点:数据的提取和处理可以通过程序来进行一次性读取,一次性更改,如果有员工改变部门,只需要清理数组中的某人的信息, 在另一个数组中添加某人的信息即可.  

缺点: 数据变动频繁,消耗系统的资源大,处理速度慢

第二种设计,

优点: 数据的提取简单,但如果有多个人频繁的进行修改,则修改的次数多,消耗的资源低,修改的速度快. 更有利于使用索引进行查询和数据的处理

缺点: 大部分信息为重复和冗余的信息

那么到底我应该在什么情况用那种设计, 

1  如果你的数据不经常被修改,并且数组里面的组员是少数的情况下,例如 3个以内,则第一个设计是一个好的方法

2  如果你的数据经常变动,并且有大量的无法评估的无边界的数组,则使用数组的设计方式,是不适合的.

根据MONGODB的原理,过多的collecitons和无用的索引会导致会降低MONGODB 的处理数据的速度.

在建立索引的同时需要考虑索引的利用率,过多的使用率较低的索引会影响

1  写入的速度

2  Wiretiger 的数据处理的速度, 内存的消耗

MONGODB中对于多余的索引和空的或建立大量无用的collection是比较反感的，我们尽量还是有效的利用内存和减少无用的collection的使用。

那么在MONGODB 中如果我的确有两个collection的数据进行分析，我怎么办， $lookup 的方式可以对这样的需求进行相关的解决，但缺点是这样的解放方案会引起资源的消耗和较慢的速度。

那么我们可以总结一下，我们整篇在说什么，设计，到底一个搭建在MONGODB的设计应该是什么样子的。

在以查询为基础的设计想，我们的数据存储在一起，或者可以有相关的数据的冗余， 例如 如果我们有一个关于销售有关的信息系统

包含了销售的人员，销售的订单信息， 我们则不在将销售人员和销售的订单信息 以及销售的货品信息，在分成三个表，而是以查询为基础的设计模式，我们查询中是以订单为基础的的，其中订单包含商品的信息，以及销售人员的信息，则以显示信息为准的情况下，我们直接将这些信息，通过嵌套数组等方式组合在一起，在查询这个订单信息的时候，这些信息将一并带出，MONGODB 的查询速度的保证也是相关的数据应该一次性杯带入，而不是类似于MYSQL的多个表JOIN 后，带出全部的信息。

所以MONGODB 是一个以最终目的和结果为导向的数据库，贴近的业务和良好的设计的模式，以及进入的大量的数据，MONGODB 都可以非常良好的处理和完成。