lukaliou123
commented
2 years ago 3.为什么游戏开发选择MongoDB
第一个原因来自于关系型数据库的痛点——SQL维护成本比较高，也会给开发效率带来一定的影响。
以游戏中的装备为例，每个装备的不同等级都会有不同的属性。使用关系型数据库来存储装备需要两张表，第一张是装备表，主键是装备ID，还有一列是装备的等级；第二张是装备的属性表，装备ID和属性ID组成联合主键，还需要一列装备的属性值。通过这个例子我们会发现，使用关系型数据库需要维护数据库的表结构，而且数据库的表结构往往跟业务层的数据结构是有差异的，它的维护是需要一定成本的。
其次，在玩家登录的时候，需要把数据从数据库里加载到游戏服务器内存。但随着游戏复杂度的增加，表的个数也逐渐增加，就会导致加载速度减慢。为了保证玩家的登录速度，我们引入了异步加载机制，但同时这也会提高编码的复杂度
第二个原因是文档的结构更适合游戏数据的建模。
还是以装备为例子，如果使用文档结构，在设计的时候可以直接将装备的属性作为子文档嵌到装备文档中，这个数据模型跟业务模块中使用的数据模型是一致的。文档结构的优势有以下几点：
l 嵌套的文档模型天然适合描述游戏数据。
l 使用嵌套的文档模型对游戏数据进行建模之后，我们发现，只需要少量的文档就可以去描述整个游戏数据，可以提高加载效率，还可以去掉异步加载机制，进而简化业务代码，提高开发效率。
l 文档模型非常灵活，能够支撑游戏高速迭代的需求。
第三个原因是MongoDB提供的Sharding模式。
我们游戏架构是一个全区全服的分布式架构，玩家的数据在游戏集群中也是分片的。这种架构能够和Sharding模式非常完美地结合。Sharding模式主要有以下几个优点：
l 高可扩展。游戏公测初期会有大量玩家涌入到服务器，可以利用Sharding模式多部署一些分片实例，来保证公测的顺利。
l 高可用。MongoDB的副本集模式，可以保证服务的高可用。
l 方便合服。游戏往往都有合服的需求，我们需要保证玩家的ID是唯一的。采用Sharding模式合服的时候，只需要配置游戏区服之间的映射关系，不需要做任何物理层的数据迁移，使得够做到秒级的合服。
1.mongodb是什么？
MongoDB 是由 C++语言编写的，是一个基于分布式文件存储的开源数据库系统。 再高负载的情况下，添加更多的节点，可以保证服务器性能。 MongoDB 旨在给 WEB 应用提供可扩展的高性能数据存储解决方案。
MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。 MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。
它支持的数据结构非常松散，是一种类似于 JSON 的 格式叫BSON，所以它既可以存储比较复杂的数据类型，又相当的灵活。
MongoDB中的记录是一个文档，它是一个由字段和值对（field:value）组成的数据结构。MongoDB文档类似于JSON对象，即一个文档认为就是一个对象。字段的数据类型是字符型，它的值除了使用基本的一些类型外，还可以包括其他文档、普通数组和文档数组。
2.应用场景
传统的关系型数据库（如MySQL），在数据操作的“三高”需求以及应对Web2.0的网站需求面前，显得力不从心。 解释：“三高”需求： • High performance - 对数据库高并发读写的需求。 • Huge Storage - 对海量数据的高效率存储和访问的需求。 • High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求。 而MongoDB可应对“三高”需求。
具体的应用场景如：
1）社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引实现附近的人、地点等功能。 2）游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存储，方便查询、高效率存储和访问。 3）物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。 4）物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这些信息进行多维度的分析。 5）视频直播，使用 MongoDB 存储用户信息、点赞互动信息等。
这些应用场景中，数据操作方面的共同特点是： （1）数据量大 （2）写入操作频繁（读写都很频繁） （3）价值较低的数据，对事务性要求不高 对于这样的数据，我们更适合使用MongoDB来实现数据的存储。
什么时候选择MongoDB 在架构选型上，除了上述的三个特点外，如果你还犹豫是否要选择它？可以考虑以下的一些问题： 应用不需要事务及复杂 join 支持 新应用，需求会变，数据模型无法确定，想快速迭代开发 应用需要2000-3000以上的读写QPS（更高也可以） 应用需要TB甚至 PB 级别数据存储 应用发展迅速，需要能快速水平扩展 应用要求存储的数据不丢失 应用需要99.999%高可用 应用需要大量的地理位置查询、文本查询 如果上述有1个符合，可以考虑 MongoDB，2个及以上的符合，选择 MongoDB 绝不会后悔。