KBEngine官方论坛

 立即注册

QQ登录

只需一步,快速开始

搜索
热搜: 配置 开服
123
返回列表 发新帖
楼主: CC2012520

PY_DICT数据存盘

[复制链接]

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-2 17:42:28 | 显示全部楼层
对于主表, 存一个字段和多个性能没什么变化, 都是一次性存。

要优化的仅仅是数组
QQ:3603661
3603661@qq.com
回复

使用道具 举报

68

主题

247

帖子

977

积分

高级会员

Rank: 4

积分
977
 楼主| 发表于 2019-4-2 18:07:41 | 显示全部楼层
柯标 发表于 2019-4-2 17:42
对于主表, 存一个字段和多个性能没什么变化, 都是一次性存。

要优化的仅仅是数组 ...

对于mysql而言,可能性能问题不大,但要把所有属性都序列化好是要消耗性能的吧,比如我例子里每次用packle去序列化sm_py_item和sm_py_friend这两个字段,每次其他字段变更这两个字段就要跟着序列化,一旦这样需要序列化的字段多了就很耗性能吧
回复

使用道具 举报

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-2 18:10:05 | 显示全部楼层
引擎本身就不推荐使用python类型作为传输和存储。

服务器存档序列化本身不是高频也不是瓶颈, 占用不了多少cpu。
QQ:3603661
3603661@qq.com
回复

使用道具 举报

68

主题

247

帖子

977

积分

高级会员

Rank: 4

积分
977
 楼主| 发表于 2019-4-2 18:26:04 | 显示全部楼层
柯标 发表于 2019-4-2 18:10
引擎本身就不推荐使用python类型作为传输和存储。

服务器存档序列化本身不是高频也不是瓶颈, 占用不了多 ...

所以总结下来,对于一对多的数据结构,引擎建议开发者自己建表自己维护是吧?可以的,不过既然python类型挺好用的,期待引擎能优化下这里的update,改哪些属性就存哪些属性。

另外,我理解引擎开发FIXED_DICT结构,目的是为了解决一对多的问题,这个在使用层面已经非常好用了,期待引擎能把sql交互这一块降下来,做到改哪条更新哪条,这样即使1对1000的结构,也不是很受影响,不然玩家数量起来了数据库肯定扛不住
回复

使用道具 举报

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-3 10:45:02 | 显示全部楼层
python类型好用是有代价的, python类型可以是任意类型, 并且没有标准, 只能依赖py自身的打包。
所以是无法优化的。

FIXED_DICT也很少会有人弄1000个key, 有几个key就不错了。
重点问题是array带来的量级消耗
QQ:3603661
3603661@qq.com
回复

使用道具 举报

68

主题

247

帖子

977

积分

高级会员

Rank: 4

积分
977
 楼主| 发表于 2019-4-3 11:12:56 | 显示全部楼层
柯标 发表于 2019-4-3 10:45
python类型好用是有代价的, python类型可以是任意类型, 并且没有标准, 只能依赖py自身的打包。
所以是无 ...

可能之前表达上有误差

<!-- 物品信息 -->
<THING_INFO>        FIXED_DICT
        <implementedBy>THING_INFO.thing_info_inst</implementedBy>
    <Properties>
        <id>
            <Type>        INT32        </Type>
        </id>
        <count>
            <Type>        INT32        </Type>
        </count>
    </Properties>
</THING_INFO>

<THING_INFO_DICT>        FIXED_DICT
        <implementedBy>THING_INFO.thing_info_dict_inst</implementedBy>
        <Properties>
                <values>
                        <Type>        ARRAY <of> THING_INFO </of>        </Type>
                </values>
        </Properties>
</THING_INFO_DICT>       

<THING_INFO>        FIXED_DICT这里的字段确实就几个,不是大问题,你说的array是指<THING_INFO_DICT>        FIXED_DICT中的<Type>        ARRAY <of> THING_INFO </of>        </Type>这个吧,这个array带来的是数据库行的增加,和我之前表达的应该是一个意思了,就是对这个array的优化

如果之前没理解错的话,目前的策略是这个array里有一千个物品种类,那么就会在数据库里生成1000条记录,如果玩家每次修改一种物品的数量的话,还是会产生1000条update语句

我之前的意思是,如果能做到修改一条就只更新一条,不修改就不更新,那sql就不会太多,这种设计就会回到传统的多表设计了,数据库执行也会降到最低,将彻底解决依赖py_dict对象存一对多结构的问题

python类型确实没法优化,但主要损耗在序列化上,如果做到update 实体数据时改动哪个字段更新哪个字段的话,那python对象的序列化需求也会降下来,这种级别的损耗基本就是写正常脚本逻辑的损耗了,也没有优化的空间和必要了吧

以上是我对引擎处理一对多的两种方法的理解,不知道对不对,优化的方向建议有没有问题,望指点
回复

使用道具 举报

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-3 11:55:39 | 显示全部楼层
嗯, 差不多跟你一个意思
py_dict 应该称为FIxed_dict,  所有带有PY开头的类型都是python类型, 而FIxed_dict是确定性的类型, 序列化能根据具体的key类型直接序列化。 应该是称呼上的误解
QQ:3603661
3603661@qq.com
回复

使用道具 举报

68

主题

247

帖子

977

积分

高级会员

Rank: 4

积分
977
 楼主| 发表于 2019-4-3 13:53:00 | 显示全部楼层
柯标 发表于 2019-4-3 11:55
嗯, 差不多跟你一个意思
py_dict 应该称为FIxed_dict,  所有带有PY开头的类型都是python类型, 而FIxed_di ...

我说的py_dict指的如下这个
<careerPrize>
    <Type> PY_DICT </Type>
    <Flags>                        BASE                                </Flags>
        <Default>                {}                                </Default>
    <Persistent>                true                                </Persistent>
</careerPrize>

array的优化方向是指把变动的记录update吗?
PY_DICT的优化方向希望是实体只update变更的字段,未变更的不update,做到与数据库的交互最小(无论是次数还是一次的字段量或者数据量)
回复

使用道具 举报

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-3 14:53:32 | 显示全部楼层
这个不可能优化, 只能整存整取, 每个字典的key和值都不知道是什么, 要存只能每个值都用python序列化, 不如整个序列化一次
QQ:3603661
3603661@qq.com
回复

使用道具 举报

68

主题

247

帖子

977

积分

高级会员

Rank: 4

积分
977
 楼主| 发表于 2019-4-3 15:09:14 | 显示全部楼层
柯标 发表于 2019-4-3 14:53
这个不可能优化, 只能整存整取, 每个字典的key和值都不知道是什么, 要存只能每个值都用python序列化,  ...

可能表达不正确,前面有个问题说到这个了,我指的字段是mysql数据表里的字段

比如数据表是 (id, sm_autoLoad, sm_nick, sm_sex, sm_plat, sm_py_items, sm_py_friend)

现在改变nick的值,存盘产生的sql是
update tbl_Account set sm_autoLoad=xx, sm_nick=xx, sm_sex=xx, sm_plat=xx, sm_py_items=xx, sm_py_friend=xx where id=xx;

在这个sql里,sm_py_items和sm_py_friend都是py_dict,为了生成这个sql,都需要用pickle序列化一下,造成了损耗

因为只有nick值发生了变化,如果生成的sql如下的话:
update tbl_Account set sm_nick=xx where id=xx;

那sm_py_items和sm_py_friend就不需要序列化了,这样tbl_Account表中多用py_dict类型的字段也不会有太多问题了

目前是前一种情况吧,优化方向是后一种情况吗?
回复

使用道具 举报

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-3 15:19:13 | 显示全部楼层
pickle在服务器内部迁移打包都会用到。  使用频率决定了不是什么性能瓶颈, 你profile看不到这块的消耗。
上面已经说了这个问题。

整体存这块不是什么问题,  唯一的问题是数组带来的量级变化才是比较麻烦的, 一般是mysql扛不住, 引擎看不到多大消耗
QQ:3603661
3603661@qq.com
回复

使用道具 举报

68

主题

247

帖子

977

积分

高级会员

Rank: 4

积分
977
 楼主| 发表于 2019-4-3 15:38:39 | 显示全部楼层
柯标 发表于 2019-4-3 15:19
pickle在服务器内部迁移打包都会用到。  使用频率决定了不是什么性能瓶颈, 你profile看不到这块的消耗。
...

也就是说,目前用
<careerPrize>
    <Type> PY_DICT </Type>
    <Flags>                        BASE                                </Flags>
        <Default>                {}                                </Default>
    <Persistent>                true                                </Persistent>
</careerPrize>
这种结构来存一对多没啥问题,性能损耗也还好,

而用
<THING_INFO>        FIXED_DICT
        <implementedBy>THING_INFO.thing_info_inst</implementedBy>
    <Properties>
        <id>
            <Type>        INT32        </Type>
        </id>
        <count>
            <Type>        INT32        </Type>
        </count>
    </Properties>
</THING_INFO>

<THING_INFO_DICT>        FIXED_DICT
        <implementedBy>THING_INFO.thing_info_dict_inst</implementedBy>
        <Properties>
                <values>
                        <Type>        ARRAY <of> THING_INFO </of>        </Type>
                </values>
        </Properties>
</THING_INFO_DICT>      
的方式来存一对多有数组带来的mysql性能问题


我目前项目全用的第二种方案,调整到第一种方案应该就没啥问题了吧,等第二种方案的组数优化问题解决了如果项目还处于测试阶段还是有机会调整回来的,毕竟第二种方案直接操作数据库查数据比较方便
回复

使用道具 举报

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-3 15:55:27 | 显示全部楼层
只有<Type>        ARRAY <of> 任意类型 </of>        </Type>量级大了有问题
QQ:3603661
3603661@qq.com
回复

使用道具 举报

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-3 15:56:14 | 显示全部楼层
第一种, 如果你在其中存了超大的数据也会撑爆buffer。

大数组只有你自己维护存档才行, 不需要定义。
QQ:3603661
3603661@qq.com
回复

使用道具 举报

68

主题

247

帖子

977

积分

高级会员

Rank: 4

积分
977
 楼主| 发表于 2019-4-3 16:23:48 | 显示全部楼层
柯标 发表于 2019-4-3 15:56
第一种, 如果你在其中存了超大的数据也会撑爆buffer。

大数组只有你自己维护存档才行, 不需要定义。 ...

第一种的buff一般多大呢,我看看是否合适

自己维护有一个大问题,玩家初始化数据后来登录可能要用上这些数据,如果在实体创建到玩家登录这一段时间内,数据没有加载好的话,就要等待加载了,如果需要维护的表有10张,在没有async await的情况下,嵌套顺序加载数据表数据的代码也挺复杂的,还要考虑加载错误的情况

不知道引擎建议的buff量是多大,一般也不会有巨量数据,真有就必须分表自己维护了
回复

使用道具 举报

5

主题

5699

帖子

214748万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2147483647

引擎扛把子

发表于 2019-4-3 17:56:53 | 显示全部楼层
你百度一下mysql命令支持的长度吧。   引擎支持65535以内大小一个数据包。
总之太大自己优化, 不要偷懒, 量上去了肯定容易出问题
QQ:3603661
3603661@qq.com
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

手机版|小黑屋|KBEngine Forum

GMT+8, 2019-8-25 10:37 , Processed in 0.032038 second(s), 19 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表