聊聊手游数据库的选择

Steven 2017-08-13

只是聊聊自己的理解,有认识错误的地方还请指正,谢谢!

到底NoSQL还是SQL?

我的回答是,看你的游戏类型。这不等于是废话么,我个人更倾向于使用SQL,为什么?

因为更利于运维进行运营平台的开发,另外像SQL的工具链实在太多了,例如MySQL,工业级产品,稳定性,可维护性,以及支持事务,这些都非常重要!工具链多,就不怕数据库慢,各种Proxy,中间件多得是,而且SQL协议的衍生产品非常多,例如分布式的TIDB,不用太担心性能,SQL前期开发慢,因为有一层映射到数据库,但这点开发量能忍受。

NoSQL,如果你的游戏规模很小,且实时性要求很高,基本都需要热数据,可以选择redis,但是一定要对数据有前期预估,而且还要做好预警方案,必须要对数据量有足够的把握,否则是灾难,redis对运营成本很低,迁移和扩容及其方便。

如果觉得内存成本太高,可以选择mongodb/ssdb,虽然我个人没在生产环境中用过mongodb,对于用mongodb和mariadb之间选择,我不太倾向mongodb,文档型数据库前期唯一的优势省去了映射这层,游戏开发对性能存储要求并不高,而这些mariadb足以胜任,跟一些朋友聊过(道听途说,全当没说),mongodb运营成本及其高,而且容易出错,踩过坑的朋友可以补充下。

说下ssdb,笔者线上是用了这个数据库的,怎么说呢,没发现过大问题,但工具链实在太少了,后期很累,很多工作很难开展,比如合服,数据修改,数据汇总和查询等等,一系列的工具链都是要从头做,而且运维部门几乎不熟悉,另外协议不兼容redis,协议解析看似简单,但费内存,作者只是兴趣来了发明了个轮子,但事实证明这个轮子是个画蛇添足,另外作者还发明了自己的pyc语言(其实是个python变种,想给他写工具都难,作者你出来,保证不打死你。(论一个协议有多重要,论一个工具链的架构有多重要,TIDB要不是走MySQL协议,用MySQL测试用例能这么快的迭代么?),我想当时作者也可能是玩票性质做了这个项目,给作者提过几个PR,不过作者也在维护这个项目,代码风格结构不算差,如果让我现在选择数据库,肯定不能用ssdb。只能说,不要用来存储关键数据,底层是基于leveldb,可靠性也来自leveldb,其实就是底层封装了两个leveldb,而上层数据结构提供跟redis类似的数据结构,运营成本高,相关工具链几乎没有,入坑前请三思。

笔者觉得游戏本身是非常适合采用nosql数据结构进行存储的,但是用nosql也要考虑其数据量,用redis对游戏来说是很贵的(冷数据落地是个大问题,很多都是基于leveldb或者rocksdb做落地),但是考虑其运营成本和工具链,还是建议采用sql,因为很多工具不一定是由游戏内容开发来提供,而需要运维部门来做,综合考虑sql对游戏后期优势明显。

说到数据存储,逻辑层跟数据接口层一定是分离的,如果你做的更好一些,最好是分独立的服务器。

另外关于数据存储和读取的api调用这层,也是进行二次封装,不要直接拿来用,这样保证你即便换掉底层数据库也不会影响你的上层逻辑,这算是常识吧,自己的项目中引用第三方lib,一定进行二次封装,以方便日后重构。

自己比较浅显的理解,抛砖引玉,有想法的朋友留言讨论下:)

查看更多主题的豆瓣日记和相册

Steven
作者Steven
44日记 4相册

全部回应 0 条

添加回应

Steven的热门日记

值得一读

    豆瓣
    我们的精神角落
    免费下载 iOS / Android 版客户端
    App 内打开