-1

我目前使用 MySQL,在查看 Document DB 之后,这似乎是一个不错的举措。我对单个记录进行了 TON (95%) 查询。随着我的数据库变大,执行此操作的时间似乎越来越慢。既读又写。我很好奇基于下面的(简化)方案是否可以很好地转移到 DocumentDB,以及所述模式的布局是什么(我对 documentDB 有点陌生)

用户 UserID 用户名 CreatedDate

Tank TankID UserID REF User.UserID TankName Awards

地图 MapID MapName MapFIle

MapData MapID REF Map.MapID TankID REF Tank.TankID Rank 颜色 TimePlayed Equipment

每次玩家加入时,都会查询 Tank、MapaData 中的数据以收集完整的坦克对象。每次他们死亡、赢得奖励、杀死某人或退出游戏时,数据都会被写回坦克和地图数据。

该网站查询用户表进行登录,该表存储用户名和密码的哈希值。登录后,用户可以在网站上修改/删除/创建新坦克,将记录插入到坦克/地图数据表中。

该网站还存储世界前 25 名,地图中的 t25,每种颜色的 t25,每种地图的每种颜色的 t25。

这就是我目前能想到的唯一查询模式。

4

1 回答 1

2

Based on the provided information you have the choice of several schema designs (with JSON as examples). I've made some assumptions, such as that more than one tank can be on one map and map data is only linked to a single map. You have to tweak it for your needs. I also try to provide some advantages and disadvantages of every solution.

Option #1 (Single collection)

This should be the easiest, but not the best solution. Here you put everything into one document with extreme "denormalization".

{
  "mapname": "map1",
  "mapfile": "mapfile1",
  "data": {
    "rank": "rank1",
    "color": "color1",
    ...
    "tanks": [
      {
        "name": "tank1",
        ...
        "user": {
          "name": "user1",
          ...
        }
      },
      {
        ...
      }
    ]
  }
}

This solution works best when you do a lot of writes, rare updates and reads where you want to get all information together. On the other side it has a lot of disadvantages, such as storing user information directly into your application data (an example would be the password hash).

Option #2 (Two collections)

Put your user data into one collection and the other data into a second collection.

User collection

{
  "id": 1,
  "username": "user1",
  "password": "passwordhash",
  ...
}

Data collection

{
  "mapname": "map1",
  "mapfile": "mapfile1",
  "data": {
    "rank": "rank1",
    "color": "color1",
    ...
    "tanks": [
      {
        "name": "tank1",
        ...
        "user": userId
        }
      },
      {
        ...
      }
    ]
  }
}

This option is a lot better than the first one. First you don't want to have sensitive user data (such as the hash of the password) in a collection with your other data. Also this works better for reads of the user object, because you just retrieve the information you need without skipping a lot of not needed fields. A disadvantage is that heavy write operations on the tank object can become a problem.

Option #3 (Three collections)

The next step could be to move the tanks out of the data collection into their own collection.

User collection

{
  "id": 1,
  "username": "user1",
  "password": "passwordhash",
  ...
}

Tank collection

{
  "name": "tank1",
  ...
  "user": userId
}

Data collection

{
  "mapname": "map1",
  "mapfile": "mapfile1",
  "data": {
    "rank": "rank1",
    "color": "color1",
    ...
    "tanks": [
      idOfTank1,
      idOfTank2,
      ...
    ]
  }
}

This works best for a lot of writes of single objects, such as the tanks, and reading tanks from their collection. This solution has its problems when reading a lot of data together, for example if you want to get a map and all the tanks in that map. In that case you have to resolve the dependencies of the tanks and the map data.

Summary

As seen, schema design is not easy in a document-oriented database. This is the reason why I asked for the query patterns. To come up with a good design you have to know most of the query patterns in advance. To get started, you should create a simple prototype with a design you think makes sense and test your query patterns with some test data. If that works, you can make minor changes to get even better performance. If not, rethink your query patterns and how a better design could look like. Keep in mind that you don't need a full-blown application for that. Most of that can be tested before a single line of code is written, for example with the administration shell of MongoDB or a simple console application in the case of DocumentDB.

于 2014-12-30T16:51:32.853 回答