阅读目录

• 一、第一个问题：Key-Value数据库可以有好多的Key，没错,但对MongoDB来说，大错特错
• 二、第二个问题：FindOne({_id:xxx})就快么？
• 三、第三个问题：精细的使用Update
• 四、2.1.1. 登录时身份认证
• 五、2.1.2. 使用软件时的界面控制
• 六、2.1.3. 提交操作请求时的许可验证
• 七、2.2.1. 角色（Role）
• 八、2.2.2. 角色（Role）与职务（Job）的关系
• 九、2.2.3. 用户帐号（User）
• 十、2.2.4. 用户组（User group）
• undefined、2.2.5. 操作权限与资源权限
• undefined、2.2.6. 菜单权限
• undefined、2.2.7. 部门权限
• undefined、2.2.8. 字段权限
• undefined、2.3.1. 组织结构树
• undefined、2.3.2. 对口业务上下级

阅读目录

• mySagasoft.MisCore 需求分析
• 1.       文档概要
• 2.       术语定义
• 3.       用例分析
• 4.       领域模型
• 5.       动态流程分析

MongoDB的真正性能-实战百万用户一-一亿的道具

上一篇为求振聋发聩的效果，有些口号主义，现在开始实战，归于实用主义。

使用情景

开始之前，我们先设定这样一个情景：

1.一百万注册用户的页游或者手游，这是不温不火的一个状态，刚好是数据量不上不下的一个情况。也刚好是传统MySql数据库性能开始吃紧的时候。

2.数据库就用一台很普通的服务器，只有一台。读写分离、水平扩展、内存缓存都不谈。一百万注册用户如果贡献度和活跃度都不高，恐怕公司的日子还不是那么宽裕，能够在数据库上的投资也有限。

以此情景为例，设每个用户都拥有100个道具，用户随时会获得或失去道具。

我们就来看看这一亿的道具怎么搞。

道具一般要使用原型、实例的设计方法，这个不属于数据库的范畴。

道具类型001 是屠龙刀，屠龙刀价格1500，基础攻击150，这些，我们把它们称为道具原型，保存在原型数据文件中。

这个原型数据文件，无论是存在何种数据库或者本地文件中，对服务器来说都不是问题，也不干扰数据库设计，所以我们不去讨论他。

关系数据库设计方法

典型的关系数据库设计方法：

用户表：字段 xxx userid xxx   ，记录数量100万

xxx是其他字段，userid标示用户

用户道具表：字段 xxx userid itemtype xxx ,记录数量一亿

xxx是其他字段，userid 标示

一个亿的记录数是不是看起来有点头疼，mysql这个时候就要想各种办法了。

MongoDB设计方法

但我们用mongoDB来实现这个需求，直接就没有问题

首先第一个集合：users集合，用UserName 作为_id ,记录数100万

然后道具的组织，我们有两种选择

1.在users集合的值中建立Items对象，用Bson数组保存道具(Mongo官方称为Bson，和Json一模一样的存储方法)

方法一，没有额外的记录数

2.新建userItems集合，同样用UserName作为_id 每个UserItems集合的值中建立一个Item对象，使用一个Bson数组来保存道具

方法二，多了一个集合和100万记录数

我们的道具数据看起来像下面这样:

{_id:xxx,Items:[

{Itemtype:xxx,ItemPower:xxx},

…

…

…

]}

测试方法

测试方法如下：测试客户端随机检查一个用户的道具数量，小于100加一个道具，大于100 删除一个道具。

连续100万次，采用10个线程并发。

如果用关系数据库设计方法+mysql来实现，这是一个很压力很大的数据处理需求。

可是用文档数据库设计方法+MongoDB来实现，这个测试根本算不上有压力。

注意事项

即使我们用了一个如此胜之不武的设计方式，你依然有可能还是能把他写的很慢。

因为MongoDB在接口设计上并没有很好的引导和约束，如果你不注意，你还是能把他用的非常慢。

返回顶部

第一个问题：Key-Value数据库可以有好多的Key，没错,但对MongoDB来说，大错特错

MongoDB的索引代价很大，大到什么程度：

1.巨大的内存占用，100万条索引约占50M内存，如果这个设计中，你一个道具一条记录，5G内存将用于索引。

我们的屌丝情景不可能给你这样的服务器，

2.巨大的性能损失，作为一个数据库，所有的东西终将被写入硬盘，没有关系数据库那样的表结构，MongoDB的索引写入性能看起来很差，如果记录数据较小的时候，你可以观测到这样震撼的景象，加一个索引，性能变成了1/2,加两个索引，性能变成了1/3。

只有当第二个索引的查询不可避免，才值得增加额外索引。因为没索引的数据，查询性能是加几个零的慢，比加索引更惨。

我们既然选择了Key-Value数据库，应尽量避免需要多个索引的情况。

所有的索引只能存在于内存中，而读取记录时，也需要将Bson在内存中处理，内存还承担着更重要的作用：读取缓存。

本来就不充裕的内存，应该严格控制我们的记录条数，能够用Bson存储的，尽量用之。

那么我们之前在MongoDB的设计中怎么还考虑第二种设计方法呢？独立一个userItems 集合，不是又多出100万条记录了吗？

这基于另两个考虑:a.Bson的处理是要反复硬盘和内存交换的，如果每条记录更小，则IO压力更小。内存和硬盘对服务器来说都是稀缺资源，至于多大的数据拆分到另一个集合中更划算，这需要根据业务情况，服务器内存、硬盘情况来测试出一个合适大小，我们暂时使用1024这个数值，单用户的道具表肯定是会突破1024字节的，所以我们要考虑将他独立到一个集合中

b.可以不部署分片集群，将另一个集合挪到另一个服务器上去。只要服务器可以轻松承载100万用户，200万还会远么？在有钱部署分片集群以前，考虑第二组服务器更现实一些。

返回顶部

第二个问题：FindOne({_id:xxx})就快么？

毋庸置疑，FindOne({_id:xxx})就是最直接的用Key取Value。

也的确，用Key取Value 就是我们能用的唯一访问Value的方式，其他就不叫Key-Value数据库了。

但是，由于我们要控制Key的数量，单个Value就会比较大。

不要被FindOne({_id:xxx}).Items[3].ItemType这优雅的代码欺骗，这是非常慢的，他几乎谋杀你所有的流量。

无论后面是什么 FindOne({_id:xxx})总是返回给你完整的Value,我们的100条道具，少说也有6~8K.

这样的查询流量已经很大了，如果你采用MongoDB方案一设计，你的单个Value是包含一个用户的所有数据的，他会更大。

如果查询客户端和数据库服务器不在同一个机房，流量将成为一个很大的瓶颈。

我们应该使用的查询函数是FindOne({_id:xxx},filter),filter里面就是设置返回的过滤条件,这会在发送给你以前就过滤掉

比如FindOne({_id:xxx},{Items:{“$slice”:[3,1]}})，这和上面那条优雅的代码是完成同样功能，但是他消耗很少的流量

返回顶部

第三个问题：精细的使用Update

这和问题二相对的，不要暴力的FindOne，也尽量不要暴力的Update一整个节点。虽然MangoDB的性能挺暴力的，IO性能极限约等于MongoDB性能，暴力的Update就会在占用流量的同时迎接IO的性能极限。

除了创建节点时的Insert或者Save之外，所有的Update都应该使用修改器精细修改.

比如Update({_id:xxx},{$set:{“Items.3.Item.Health”:38}});//修改第三把武器的健康值

至于一次修改和批量修改，MongoDB默认100ms flush一次(2.x),只要两次修改比较贴近,被一起保存的可能性很高。

但是合并了肯定比不合并强，合并的修改肯定是一起保存，这个也要依赖于是用的开发方式，如果使用php做数据客户端，缓存起来多次操作合并了一起提交，实现起来就比较复杂。

注意以上三点，一百万注册用户并不算很多，4G内存，200G硬盘空间的MongoDB服务器即可轻松应对。性能瓶颈是硬盘IO，可以很容易的使用Raid和固态硬盘提升几倍的吞吐量。不使用大量的Js计算，CPU不会成为问题，不要让索引膨胀，内存不会成为问题。你根本用不着志强的一堆核心和海量的内存，更多的内存可以让缓存的效果更好一些，可是比读写分离还是差远了。如果是高并发时查询性能不足，就要采用读写分离的部署方式。当IO再次成为瓶颈时，就只能采用集群部署MongoDB启用分片功能，或者自行进行分集合与key散列的工作。

,

阅读目录

• 一、第一个问题：Key-Value数据库可以有好多的Key，没错,但对MongoDB来说，大错特错
• 二、第二个问题：FindOne({_id:xxx})就快么？
• 三、第三个问题：精细的使用Update
• 四、2.1.1. 登录时身份认证
• 五、2.1.2. 使用软件时的界面控制
• 六、2.1.3. 提交操作请求时的许可验证
• 七、2.2.1. 角色（Role）
• 八、2.2.2. 角色（Role）与职务（Job）的关系
• 九、2.2.3. 用户帐号（User）
• 十、2.2.4. 用户组（User group）
• undefined、2.2.5. 操作权限与资源权限
• undefined、2.2.6. 菜单权限
• undefined、2.2.7. 部门权限
• undefined、2.2.8. 字段权限
• undefined、2.3.1. 组织结构树
• undefined、2.3.2. 对口业务上下级

阅读目录

• mySagasoft.MisCore 需求分析
• 1.       文档概要
• 2.       术语定义
• 3.       用例分析
• 4.       领域模型
• 5.       动态流程分析

MongoDB的真正性能-实战百万用户一-一亿的道具

上一篇为求振聋发聩的效果，有些口号主义，现在开始实战，归于实用主义。

使用情景

开始之前，我们先设定这样一个情景：

1.一百万注册用户的页游或者手游，这是不温不火的一个状态，刚好是数据量不上不下的一个情况。也刚好是传统MySql数据库性能开始吃紧的时候。

2.数据库就用一台很普通的服务器，只有一台。读写分离、水平扩展、内存缓存都不谈。一百万注册用户如果贡献度和活跃度都不高，恐怕公司的日子还不是那么宽裕，能够在数据库上的投资也有限。

以此情景为例，设每个用户都拥有100个道具，用户随时会获得或失去道具。

我们就来看看这一亿的道具怎么搞。

道具一般要使用原型、实例的设计方法，这个不属于数据库的范畴。

道具类型001 是屠龙刀，屠龙刀价格1500，基础攻击150，这些，我们把它们称为道具原型，保存在原型数据文件中。

这个原型数据文件，无论是存在何种数据库或者本地文件中，对服务器来说都不是问题，也不干扰数据库设计，所以我们不去讨论他。

关系数据库设计方法

典型的关系数据库设计方法：

用户表：字段 xxx userid xxx   ，记录数量100万

xxx是其他字段，userid标示用户

用户道具表：字段 xxx userid itemtype xxx ,记录数量一亿

xxx是其他字段，userid 标示

一个亿的记录数是不是看起来有点头疼，mysql这个时候就要想各种办法了。

MongoDB设计方法

但我们用mongoDB来实现这个需求，直接就没有问题

首先第一个集合：users集合，用UserName 作为_id ,记录数100万

然后道具的组织，我们有两种选择

1.在users集合的值中建立Items对象，用Bson数组保存道具(Mongo官方称为Bson，和Json一模一样的存储方法)

方法一，没有额外的记录数

2.新建userItems集合，同样用UserName作为_id 每个UserItems集合的值中建立一个Item对象，使用一个Bson数组来保存道具

方法二，多了一个集合和100万记录数

我们的道具数据看起来像下面这样:

{_id:xxx,Items:[

{Itemtype:xxx,ItemPower:xxx},

…

…

…

]}

测试方法

测试方法如下：测试客户端随机检查一个用户的道具数量，小于100加一个道具，大于100 删除一个道具。

连续100万次，采用10个线程并发。

如果用关系数据库设计方法+mysql来实现，这是一个很压力很大的数据处理需求。

可是用文档数据库设计方法+MongoDB来实现，这个测试根本算不上有压力。

注意事项

即使我们用了一个如此胜之不武的设计方式，你依然有可能还是能把他写的很慢。

因为MongoDB在接口设计上并没有很好的引导和约束，如果你不注意，你还是能把他用的非常慢。

返回顶部

第一个问题：Key-Value数据库可以有好多的Key，没错,但对MongoDB来说，大错特错

MongoDB的索引代价很大，大到什么程度：

1.巨大的内存占用，100万条索引约占50M内存，如果这个设计中，你一个道具一条记录，5G内存将用于索引。

我们的屌丝情景不可能给你这样的服务器，

2.巨大的性能损失，作为一个数据库，所有的东西终将被写入硬盘，没有关系数据库那样的表结构，MongoDB的索引写入性能看起来很差，如果记录数据较小的时候，你可以观测到这样震撼的景象，加一个索引，性能变成了1/2,加两个索引，性能变成了1/3。

只有当第二个索引的查询不可避免，才值得增加额外索引。因为没索引的数据，查询性能是加几个零的慢，比加索引更惨。

我们既然选择了Key-Value数据库，应尽量避免需要多个索引的情况。

所有的索引只能存在于内存中，而读取记录时，也需要将Bson在内存中处理，内存还承担着更重要的作用：读取缓存。

本来就不充裕的内存，应该严格控制我们的记录条数，能够用Bson存储的，尽量用之。

那么我们之前在MongoDB的设计中怎么还考虑第二种设计方法呢？独立一个userItems 集合，不是又多出100万条记录了吗？

这基于另两个考虑:a.Bson的处理是要反复硬盘和内存交换的，如果每条记录更小，则IO压力更小。内存和硬盘对服务器来说都是稀缺资源，至于多大的数据拆分到另一个集合中更划算，这需要根据业务情况，服务器内存、硬盘情况来测试出一个合适大小，我们暂时使用1024这个数值，单用户的道具表肯定是会突破1024字节的，所以我们要考虑将他独立到一个集合中

b.可以不部署分片集群，将另一个集合挪到另一个服务器上去。只要服务器可以轻松承载100万用户，200万还会远么？在有钱部署分片集群以前，考虑第二组服务器更现实一些。

返回顶部

第二个问题：FindOne({_id:xxx})就快么？

毋庸置疑，FindOne({_id:xxx})就是最直接的用Key取Value。

也的确，用Key取Value 就是我们能用的唯一访问Value的方式，其他就不叫Key-Value数据库了。

但是，由于我们要控制Key的数量，单个Value就会比较大。

不要被FindOne({_id:xxx}).Items[3].ItemType这优雅的代码欺骗，这是非常慢的，他几乎谋杀你所有的流量。

无论后面是什么 FindOne({_id:xxx})总是返回给你完整的Value,我们的100条道具，少说也有6~8K.

这样的查询流量已经很大了，如果你采用MongoDB方案一设计，你的单个Value是包含一个用户的所有数据的，他会更大。

如果查询客户端和数据库服务器不在同一个机房，流量将成为一个很大的瓶颈。

我们应该使用的查询函数是FindOne({_id:xxx},filter),filter里面就是设置返回的过滤条件,这会在发送给你以前就过滤掉

比如FindOne({_id:xxx},{Items:{“$slice”:[3,1]}})，这和上面那条优雅的代码是完成同样功能，但是他消耗很少的流量

返回顶部

第三个问题：精细的使用Update

这和问题二相对的，不要暴力的FindOne，也尽量不要暴力的Update一整个节点。虽然MangoDB的性能挺暴力的，IO性能极限约等于MongoDB性能，暴力的Update就会在占用流量的同时迎接IO的性能极限。

除了创建节点时的Insert或者Save之外，所有的Update都应该使用修改器精细修改.

比如Update({_id:xxx},{$set:{“Items.3.Item.Health”:38}});//修改第三把武器的健康值

至于一次修改和批量修改，MongoDB默认100ms flush一次(2.x),只要两次修改比较贴近,被一起保存的可能性很高。

但是合并了肯定比不合并强，合并的修改肯定是一起保存，这个也要依赖于是用的开发方式，如果使用php做数据客户端，缓存起来多次操作合并了一起提交，实现起来就比较复杂。

注意以上三点，一百万注册用户并不算很多，4G内存，200G硬盘空间的MongoDB服务器即可轻松应对。性能瓶颈是硬盘IO，可以很容易的使用Raid和固态硬盘提升几倍的吞吐量。不使用大量的Js计算，CPU不会成为问题，不要让索引膨胀，内存不会成为问题。你根本用不着志强的一堆核心和海量的内存，更多的内存可以让缓存的效果更好一些，可是比读写分离还是差远了。如果是高并发时查询性能不足，就要采用读写分离的部署方式。当IO再次成为瓶颈时，就只能采用集群部署MongoDB启用分片功能，或者自行进行分集合与key散列的工作。

,

上一篇为求振聋发聩的效果，有些口号主义，现在开始实战，归于实用主义。

使用情景

开始之前，我们先设定这样一个情景：

1.一百万注册用户的页游或者手游，这是不温不火的一个状态，刚好是数据量不上不下的一个情况。也刚好是传统MySql数据库性能开始吃紧的时候。

2.数据库就用一台很普通的服务器，只有一台。读写分离、水平扩展、内存缓存都不谈。一百万注册用户如果贡献度和活跃度都不高，恐怕公司的日子还不是那么宽裕，能够在数据库上的投资也有限。

以此情景为例，设每个用户都拥有100个道具，用户随时会获得或失去道具。

我们就来看看这一亿的道具怎么搞。

道具一般要使用原型、实例的设计方法，这个不属于数据库的范畴。

道具类型001 是屠龙刀，屠龙刀价格1500，基础攻击150，这些，我们把它们称为道具原型，保存在原型数据文件中。

这个原型数据文件，无论是存在何种数据库或者本地文件中，对服务器来说都不是问题，也不干扰数据库设计，所以我们不去讨论他。

关系数据库设计方法

典型的关系数据库设计方法：

用户表：字段 xxx userid xxx   ，记录数量100万

xxx是其他字段，userid标示用户

用户道具表：字段 xxx userid itemtype xxx ,记录数量一亿

xxx是其他字段，userid 标示

一个亿的记录数是不是看起来有点头疼，mysql这个时候就要想各种办法了。

MongoDB设计方法

但我们用mongoDB来实现这个需求，直接就没有问题

首先第一个集合：users集合，用UserName 作为_id ,记录数100万

然后道具的组织，我们有两种选择

1.在users集合的值中建立Items对象，用Bson数组保存道具(Mongo官方称为Bson，和Json一模一样的存储方法)

方法一，没有额外的记录数

2.新建userItems集合，同样用UserName作为_id 每个UserItems集合的值中建立一个Item对象，使用一个Bson数组来保存道具

方法二，多了一个集合和100万记录数

我们的道具数据看起来像下面这样:

{_id:xxx,Items:[

{Itemtype:xxx,ItemPower:xxx},

…

…

…

]}

测试方法

测试方法如下：测试客户端随机检查一个用户的道具数量，小于100加一个道具，大于100 删除一个道具。

连续100万次，采用10个线程并发。

如果用关系数据库设计方法+mysql来实现，这是一个很压力很大的数据处理需求。

可是用文档数据库设计方法+MongoDB来实现，这个测试根本算不上有压力。

注意事项

即使我们用了一个如此胜之不武的设计方式，你依然有可能还是能把他写的很慢。

因为MongoDB在接口设计上并没有很好的引导和约束，如果你不注意，你还是能把他用的非常慢。

返回顶部

第一个问题：Key-Value数据库可以有好多的Key，没错,但对MongoDB来说，大错特错

MongoDB的索引代价很大，大到什么程度：

1.巨大的内存占用，100万条索引约占50M内存，如果这个设计中，你一个道具一条记录，5G内存将用于索引。

我们的屌丝情景不可能给你这样的服务器，

2.巨大的性能损失，作为一个数据库，所有的东西终将被写入硬盘，没有关系数据库那样的表结构，MongoDB的索引写入性能看起来很差，如果记录数据较小的时候，你可以观测到这样震撼的景象，加一个索引，性能变成了1/2,加两个索引，性能变成了1/3。

只有当第二个索引的查询不可避免，才值得增加额外索引。因为没索引的数据，查询性能是加几个零的慢，比加索引更惨。

我们既然选择了Key-Value数据库，应尽量避免需要多个索引的情况。

所有的索引只能存在于内存中，而读取记录时，也需要将Bson在内存中处理，内存还承担着更重要的作用：读取缓存。

本来就不充裕的内存，应该严格控制我们的记录条数，能够用Bson存储的，尽量用之。

那么我们之前在MongoDB的设计中怎么还考虑第二种设计方法呢？独立一个userItems 集合，不是又多出100万条记录了吗？

这基于另两个考虑:a.Bson的处理是要反复硬盘和内存交换的，如果每条记录更小，则IO压力更小。内存和硬盘对服务器来说都是稀缺资源，至于多大的数据拆分到另一个集合中更划算，这需要根据业务情况，服务器内存、硬盘情况来测试出一个合适大小，我们暂时使用1024这个数值，单用户的道具表肯定是会突破1024字节的，所以我们要考虑将他独立到一个集合中

b.可以不部署分片集群，将另一个集合挪到另一个服务器上去。只要服务器可以轻松承载100万用户，200万还会远么？在有钱部署分片集群以前，考虑第二组服务器更现实一些。

返回顶部

第二个问题：FindOne({_id:xxx})就快么？

毋庸置疑，FindOne({_id:xxx})就是最直接的用Key取Value。

也的确，用Key取Value 就是我们能用的唯一访问Value的方式，其他就不叫Key-Value数据库了。

但是，由于我们要控制Key的数量，单个Value就会比较大。

不要被FindOne({_id:xxx}).Items[3].ItemType这优雅的代码欺骗，这是非常慢的，他几乎谋杀你所有的流量。

无论后面是什么 FindOne({_id:xxx})总是返回给你完整的Value,我们的100条道具，少说也有6~8K.

这样的查询流量已经很大了，如果你采用MongoDB方案一设计，你的单个Value是包含一个用户的所有数据的，他会更大。

如果查询客户端和数据库服务器不在同一个机房，流量将成为一个很大的瓶颈。

我们应该使用的查询函数是FindOne({_id:xxx},filter),filter里面就是设置返回的过滤条件,这会在发送给你以前就过滤掉

比如FindOne({_id:xxx},{Items:{“$slice”:[3,1]}})，这和上面那条优雅的代码是完成同样功能，但是他消耗很少的流量

返回顶部

第三个问题：精细的使用Update

这和问题二相对的，不要暴力的FindOne，也尽量不要暴力的Update一整个节点。虽然MangoDB的性能挺暴力的，IO性能极限约等于MongoDB性能，暴力的Update就会在占用流量的同时迎接IO的性能极限。

除了创建节点时的Insert或者Save之外，所有的Update都应该使用修改器精细修改.

比如Update({_id:xxx},{$set:{“Items.3.Item.Health”:38}});//修改第三把武器的健康值

至于一次修改和批量修改，MongoDB默认100ms flush一次(2.x),只要两次修改比较贴近,被一起保存的可能性很高。

但是合并了肯定比不合并强，合并的修改肯定是一起保存，这个也要依赖于是用的开发方式，如果使用php做数据客户端，缓存起来多次操作合并了一起提交，实现起来就比较复杂。

注意以上三点，一百万注册用户并不算很多，4G内存，200G硬盘空间的MongoDB服务器即可轻松应对。性能瓶颈是硬盘IO，可以很容易的使用Raid和固态硬盘提升几倍的吞吐量。不使用大量的Js计算，CPU不会成为问题，不要让索引膨胀，内存不会成为问题。你根本用不着志强的一堆核心和海量的内存，更多的内存可以让缓存的效果更好一些，可是比读写分离还是差远了。如果是高并发时查询性能不足，就要采用读写分离的部署方式。当IO再次成为瓶颈时，就只能采用集群部署MongoDB启用分片功能，或者自行进行分集合与key散列的工作。