0

我正在研究开发一款类似《炉石传说》的在线纸牌游戏。玩家将拥有无限的库存来存储他们拥有的所有卡片。

使用这种方法，每个玩家卡组合的 1 行数据量都会非常大，因此呈指数增长。

最初，我想要 3 张桌子：

  • 一个 Player_Table

    | Player_ID | Player_Name | Rank | Icon | ect...

  • A Card_Table

    | Card_ID | Card_Name | Attack | Defence | ect...

  • 然后是他们的 Inventory_Table

    | Player_ID | Card_ID | Quantity |

然后我可以使用 SELECT Card_ID FROM Inventory_Table WHERE Player_ID=YourID 之类的语句

显然，这里有一个缩放问题，我添加的卡越多，加入的玩家越多，获得卡列表所需的时间就越长。

我正在考虑使用 MongoDB 之类的东西作为 NoSQL 的替代品，以帮助解决这可能导致的潜在性能问题，但后来我发现它不像 mySQL 那样免费用于商业用途，所以我放弃了这个计划。

我想出的第三个也是最后一个想法是动态添加表格。当一个玩家被创建（创建一个帐户）时，我可以添加一个名为“Player_Cards_”+ Player_ID（EG Player_Cards_318）的表格，有些东西告诉我这是一个坏主意，但我不确定。

请有人指出我正确的方向。

4

2 回答 2

1

显然，这里有一个缩放问题，我添加的卡越多，加入的玩家越多，获得卡列表所需的时间就越长。

不，不是你想的那样。假设您使用指数，增长将是对数 - 不是线性的。更像是“两倍于 25 倍的条目”。

我正在考虑使用 MongoDB 之类的东西作为 NoSQL 替代品，以帮助解决这可能导致的潜在性能问题

没有。正如我所说，除了性能问题主要是一种错觉之外，nosql 对关系问题并没有特别的帮助，而且到目前为止你显示了一个现实问题；）

我想出的第三个也是最后一个想法是动态添加表格。创建玩家时（创建帐户）

对于在公司工作的任何人来说，这都是可终止的罪行。它基本上使大量分析完全无法使用，并导致很多小表通常是反模式（数据库没有为此优化，所以你最终会开始浪费资源来获得任何专业团队都会让你展示的解决方案门。

使用解决方案1，完成。你的 sacaiability 问题并不像你瘦的那么糟糕（特别是如果你添加了一个分片层），而且由于缺少用户，你可能根本不会遇到它。

于 2020-03-09T19:03:50.037 回答
1

表中的数百万行通常不是问题。数十亿行令人兴奋，但不一定是不可能的。请做数学并得出一个粗略的估计。

同时，请提供SHOW CREATE TABLE以便我们了解所涉及的数据类型、引擎和索引。

不要为每个用户（或每个用户）创建一个新表。这是一个经常被问到的问题；答案总是“不”。

SELECT Card_ID FROM Inventory_Table WHERE Player_ID=YourID

是一个非常基本的查询。任何以 开头的索引Player_ID都将允许非常快速（毫秒）地执行该查询。 INDEX(Player_ID, Card_ID)可能会更快。您还有哪些常见问题？

缩放... 一个简单的经验法则是“每行 100 个字节”。计算所有表中的所有行需要多少字节；这适合你的磁盘吗？（我怀疑它会。）

您将在一个SELECT. 所以学习如何做一个 SQL JOIN。

重新“对数”：一万亿行中的“点查询”大约是一百万行中的两倍。

我对“没有 sql”的看法——你必须重新发明 SQL 才能完成任务。在此过程中，您将学到很多有关 RDBMS 本来可以为您做的优化技术。

于 2020-03-09T19:30:08.370 回答