我的头因阅读有关数据库而爆炸。我知道您选择哪一个取决于具体的用例。所以这是我的：
- 我有一个网络应用程序。一个游戏。
- 它是基于级别的，你只能前进不能后退。但是您可以继续玩每个级别。例如，您完成 Level2，然后玩 Level3。然后再次启动 Level3 并将其保存为 Level3b。您现在可以继续离开 Level3 和 Level3b。
- 任何时候都只能玩一个级别。
- 服务器上存储了三个数据数组：'progress'、'choices' 和 'vars'
- 在您玩关卡时会修改它们，然后在您可能想要开始使用它们时放入冷藏库。
当前的 MySQL 设置是这样的：
- 一个“saves”表保存了每个存档游戏的元数据，重要的是它所属的存档 ID 和用户 ID。
- 每个数据数组都有一个对应的表格。
如果玩家做出选择，插入看起来像这样：
INSERT INTO choices VALUES saveid=:saveid, choice=:choice因此，可以通过执行以下操作来重建数组
SELECT * FROM choices WHERE saveid=:saveid- 关卡完成后，数据数组通过序列化并存储在“保存”表中而被放入冷存储，该表有 3 列专用于此。
- 它们的值已从其他三个表中清除。
- 如果玩家从 Level3b 开始 Level4，序列化的数组将从“saves”表中获取，取消序列化并放回各自的表中，尽管新的 saveID 为 Level4。
我希望这有点可以理解。我认为：
- 写入次数将多于读取次数
- 如果我理解正确的话，我不需要一致性，因为玩家只能操纵自己的数据
- 我不认为我会做（m）任何 JOINS，因为每个表都需要单独读取以填充其各自的数据数组
- 所以我认为我不需要太多关系数据库
在大多数情况下，对于 DB 来说，它应该是非常轻的负载，因为插入很小
数据存储必须可靠！如果我们开始定期丢失他们的存档游戏，我认为玩家不会坚持使用我们。虽然我认为 Redis 每秒刷新到磁盘就足够了，因为我们在这里不处理关键任务的东西。如果游戏忘记了玩家的最后一两个动作，这还不错，只是不要忘记整个存档游戏。
你能为我的用例提供关于数据库的建议吗？我从 MySQL 开始，现在我读到了 CouchDB、MongoDB、Riak、Cassandra。我认为 Redis 是不可能的，因为一旦数据集超出你的 RAM，Redis 似乎会严重退化。但我对一切都持开放态度。我也对人们说：坚持使用 MySQL 或转到 PostgreSQL。
我也会接受对我设置存储方式的批评。如果你说：选择 Cassandra 并这样存储，我会听的。
这是一个健全性检查，因为现在是我最后一次能够在游戏上线之前更改数据库，而我想做的最后一件事是不得不在 3 个月内更换数据库，因为它的扩展性很差。
哦，是的，App 是用 Javascript 编写的，与服务器的通信是通过 PHP 进行的。