实时多人游戏使用哪个数据库（RDBMS，NoSQL和BOTH）？

我正在开发一个实时多人游戏，该游戏将需要一个数据库（用于诸如播放器配置文件，朋友，解锁，新闻等功能）。这是一个标准PC游戏（不是基于浏览器的游戏），将使用客户端服务器建筑。我刚接触数据库，过去几天，我偶然发现了激烈的争论：RDBMS与NoSQL，进行了一些研究。目前，我倾向于NoSQL，但是在阅读了每种用法（RDBMS和NoSQL）之后，我很想同时使用两者。我知道这似乎很奇怪，但让我解释一下我的情况：

我的团队有一个共享的虚拟主机程序包，该程序包提供无限的mySQL存储和带宽，唯一的警告是我们一次只能打开25个连接（共享主机规则）。我打算将其用于我的网站（无疑是一种典型用法），以便发布新闻更新，支持社区功能（例如评论，上传粉丝艺术等）等。一切都很好，但是-！这是事情变得有趣的地方...我想在游戏中显示发布在我的网站上的相同信息。这意味着我的网站和游戏都使用mySQL。除了新闻发布之类的内容外，我还计划在游戏中将其用于聊天和服务器列表之类的事情。我最关心的是25连接规则。

这就引出我问问题1：这是否可行，还有更好的选择吗？

现在，除此之外，我还阅读了有关NoSQL的性能以及适用于实时游戏的信息（我可能是错的，我经历了一场巨大的RDBMS与NoSQL的火焰之战，到达这里并可能被烧死了）。基本上，我想对所有游戏对象数据使用MongoDB。

同样，如果我提供一些背景信息将对您有所帮助：我找到了一个主机（MongoLab），该主机免费提供240MB的MongoDB软件包，我打算在需要升级之前使用它。假设有240MB，我已经计算出能够存储大约60,000个播放器（如果每个播放器大约为4KB，而我们忽略了可能存储的其他内容）。存储空间以及将来必须支付更多费用（我们的游戏应该成功）不是问题。我目前打算对所有游戏对象数据使用MongoDB的唯一原因是由于将访问该游戏对象数据的频率（例如，每当玩家被杀死，拿起物品，开枪等时）也喜欢无格式的直接文档（这使得映射游戏对象数据更加容易）。我应该注意到，一次

我打算在我的网站上使用相同的MongoDB来显示玩家资料信息（我不关心完全的一致性，可以从游戏中进行更新有些延迟）。这使我想到第二个问题，即问题2：这是个好主意还是应该做得更好？

游戏将具有类似于以下的启动体验：

1. 客户端登录（MongoDB）
2. 客户端位于带有聊天室的游戏首页（MySQL）
3. 客户端转到服务器列表（MySQL）

4. 客户端连接到服务器并在其中播放

5. 服务器传达所有播放器的更新（MongoDB）

这就是我想象中的工作方式。这对您来说看起来不错，还是对如何改进此计划有建议？

我的建议是让您的游戏与您创建的Web服务进行通信，该Web服务本身可以处理查询数据库的问题。那时，通过“切换” Web服务实现来尝试不同类型的数据库非常简单（您的Web服务界面始终保持不变，因此您的游戏不会中断），然后确定哪个数据库适合您。

不直接将您的数据库暴露给互联网也更加安全。

我们一次只能打开25个连接（共享托管规则）。

这对于您的游戏来说绰绰有余。问题是，如果您的网站使用多个连接，则可能会用完。您需要将Web服务器配置为仅使用其中的少量服务器，其余的留给游戏服务器使用。您的游戏服务器实际上并不需要多于1个连接，但是拥有少量连接可能会受益。

现在，除此之外，我还阅读了有关NoSQL的性能以及适用于实时游戏的信息（我可能是错的，我经历了一场巨大的RDBMS与NoSQL的火焰之战，到达这里并可能被烧死了）。基本上，我想对所有游戏对象数据使用MongoDB。

这是一个错误的说法，因为这两个系统都不够快，无法用作快节奏实时游戏的主要存储-您确实需要保留并操纵内存中的值。因此，仅在绝对必要时才访问数据库，这可能只是每隔一次（例如，每分钟一次）保存整个角色，此时速度差异可以忽略不计。

有趣的是，如果您调整MongoDB的最高速度，则可以使其达到足够快的速度，以至于您可以从一个节奏相当快的游戏中执行同步写入，但这是有代价的数据完整性的原因是写操作被缓冲。这意味着你失去了在发生碰撞的事件数据，所以没有执行在所有的写小点，它仍然慢于如果你只是执行在内存中的编辑，后来救了它，让您得到最糟糕的两个世界。

我目前打算对所有游戏对象数据使用MongoDB的唯一原因是因为将频繁访问此游戏对象数据（例如，每当玩家被杀死，捡起物品，开枪等时）

问问自己，当玩家开枪时，为什么需要写入数据库。为什么不能仅在游戏服务器的内存中处理该问题？如果您的游戏崩溃了，然后又重新启动，并且玩家发现他们的弹头比预期的多3个，这是否是一个关键的业务问题？

我也喜欢无格式的直接文档（这使得映射游戏对象数据更加容易）。

与性能问题相比，这是选择NOSQL方法的更好理由。

我打算在我的网站上使用相同的MongoDB来显示玩家资料信息（我不关心完全的一致性，可以从游戏中进行更新有些延迟）。

很好，很明智。稍后，您可能希望使用一个单独的实例，以使网络阅读不会与游戏读写竞争，但是与变得足够流行以至于成为一个问题的问题相比，该问题是一个微不足道的问题。

就我个人而言，我只选择两个数据库中的一个，根据这个数据库对我来说工作量会减少，并在此基础上进行标准化-但是如果您愿意的话，您没有理由不保留两个数据库。

所有的实时数据都需要保存在应用程序内存中，其他任何事情都是愚蠢的。

保持用户登录数据，统计信息等是一项非常轻松的任务，因此，我会大胆地说，您可以随意使用任何内容。尽管您可能希望对网站保持谨慎，但如果您没有适当的缓存系统，则诸如用户列表之类的东西可能会吸收很多数据库性能。

就像bummzack所说的那样，您应该将所有内容都保留在同一网络中。最重要的是，要提防免费内容，240 MB的免费数据库存储听起来不错，但是由于计算机可能是在大量免费用户之间分配的，因此运行速度可能会很慢。

您是否相信每个数据库有60,000个用户？如果不是这样，除非您对数据库软件的安全性的专业水平达到一流水平，并且您有信心可以解决所导致的任何问题，否则应该忽略“从客户端访问数据库”的想法。