|
|
大家好,我是逍遥,今天分享关于MongoDB是否适合在游戏开发中使用.
近几年来随着手游的爆发,越来越多的项目使用了MongoDB作为游戏后端的数据库. 手游相比端游而言规模会小许多,生命周期也会短一些,同时更新频率又会比较高. 而MongoDB作为一个文档型数据库,也更加适合游戏这种业务类型.所以这几年MongoDB在游戏项目中的使用得到了快速增长.
文档型存储结构(JSON)
MongoDB是以JSON结构来进行数据存储, 无须定义表结构. 非常适合对于游戏这种更新频繁,需要经常变更字段的业务类型. 使用MySQL的同学应该都知道,在数据量较大的情况,对表结构增加/删除一个字段简直是一个噩梦(MySQL8已经优化了这个问题).而游戏数据通常是一整块的加载到内存中进行读写操作的,然后在一整块的存储到数据库中. 使用JSON结构进行集中存储就非常贴切游戏的业务开发.
备注: MySQL也提供了对JSON结构的数据存储
天然的分布式支持(Sharding)
MongoDB本身就支持分布式,有效的解决了数据库多点部署的问题. 能更好的支持数据库的伸缩和容灾. 相比游戏后端中被广泛使用的MySQL,没有了分库分表的烦恼.只需要关心业务开发就好, 无须关心数据库部署在那个节点,也不需要担心数据库的扩展问题,特别是对于一些全球同服的游戏.
内存和磁盘占用较高
我在使用了一番之后, 我发现相比MySQL而言, MongoDB的资源占用是比较高的. MongoDB是利用内存换取速度,所以会把热数据,以及索引之类的数据缓存到内中,以便加快查询速度,所以对内存是极其贪婪的. 数据量大的情况会导致几乎把整个系统的内存都给占用了. 此外就是其存储结构也导致了需要更多的内存和磁盘. 所以说很多事务都是有具有两面性,带来有些优势的同时,也会带来一些缺点.
关于运维
目前大部分运维人员熟悉的都是MySQL等占有率比较高的数据库,而MongoDB在运维人员中还没普及开来. 从而相关的工具和脚本配套也会相应的有所缺失. 以上种种直接导致了运维的效率以及遇到问题时候的解决速度. 例如数据的备份和恢复, 日志的查询,性能的监控等等,这些都需要对数据库有一定程度的掌握,以及相关脚本和工具的支持.
总结
MongoDB是一款瑕不掩瑜的数据库,也非常适合游戏开发的数据库. 如果之前对于游戏后端开发经验比较少, 或者团队中有人比较熟悉MongoDB,那么是可以选择使用的.可以极大的提高开发效率. 而资源占用问题也根本不是问题,等项目成功了那点硬件资源花不了多少钱. 相反的,对于已经积累一定的游戏开发经验的团队,MongoDB的优势并不明显,其实没有很大的必要切换过来,贸然切换数据库反而带来一定的风险和成本. 接下来我还会分享一些关于数据存储方案的文章,到时候在详细说说其它的数据存储方案. |
|
窥视卡
雷达卡
发表于 2022-8-29 18:25
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡