2014-08-31 47 views
4

我正在構建一個基於回合的基於瀏覽器的RPG,並構建了一個數據模型如下所示。當一個玩家參與戰鬥時,讀寫都將執行「靈魂」和「物品」子文檔(數組),並進一步讀取「技能」和「角色」子文檔。我想每個陣列1-30子文檔之間sporn每個此嵌套子文檔模式是否會影響性能?

我試圖包含單個集合性能幾乎所有的邏輯,但我與嵌套走得太遠了?

我聽說使用嵌套陣列時,想拿到這個數據模型是否可行的若干意見的MongoDB/MeteorJS運動表現不佳?

email: '[email protected]' 
    password: 'f321' 
    profile: 
     character: 
     _id: 'c001' 
     location: 'Isenheim' 
     name: 'Ugyr' 
     race: 'human' 
     level: 1 
     experience: 1 
     maxHealth: 10 
     curHealth: 10 
     curAp: 10 
     maxAp: 10 
     flagged: false 
     gold: 0 
     souls: [ 
      _id: 'S001' 
      name: 'Hound' 
      race: 'beast' 
      cost: 5 
      active: false 
      maxHealth: 5 
      curHealth: 5 
      maxAp: 6 
      curAp: 6 
      skills: [ 
      name: 'Bite' 
      damage: 1 
      cost: 2 
      , 
      name: 'Shred' 
      damage: 2 
      cost: 4 
      effects: 
       name: 'Bleeding' 
       duration: 2 
       type: 'subtractive' 
       stats: ['curHealth'] 
       value: 1 
      ] 
     ] 
     skills: [ 
      name: 'Slash' 
      type: 'direct' 
      damage: 2 
      cost: 2 
     , 
      name: 'Pierce' 
      type: 'direct' 
      damage: 3 
      cost: 3 
     , 
      name: 'Throwing Knives' 
      type: 'direct' 
      damage: 1 
      cost: 1 
     ] 
     items: 
      equiped: 
      weapon: 
       name: 'Rusty Knife' 
       attack: 2 
      shield: null 

      inventory: [ 
      name: 'Potion' 
      type: 'consumable' 
      effects: 
       type: 'additive' 
       stats: ['curHealth', 'curAp'] 
       value: 3 
      amount: 500 
      , 
      name: 'Minor Soul Stone' 
      type: 'consumable' 
      amount: 500 
      effects: [ 
       type: 'additive' 
       stats: ['curAp'] 
       value: 2 
      , 
       type: 'subtractive' 
       stats: ['curHealth'] 
       value: 1 
      ] 
      , 
      name: 'Health Potion' 
      type: 'consumable' 
      amount: 100 
      effects: [ 
       type: 'additive' 
       stackable: false 
       stats: ['curHealth'] 
       value: 1 
       duration: 2 
      ] 
      ] 
      conditions: [ 

      ] 

回答

5

是的,你嵌套太過分了。

流星DDP只發送第一級屬性的更改/差異。因此,要souls & items任何更改都將等同於整個profile被再次發送。

我會建議打破character到一個單獨的集合,以及soulsitems

然後,在所有這些denormalise userId和一次性發布它們,例如:

Meteor.publish("my-characters",function(){ 
    if (this.userId == null){ 
    return; 
    } 
    return [ 
    characters.find({"userId": this.userId}), 
    characterSouls.find({"userId": this.userId}), 
    characterItems.find({"userId": this.userId}) 
    ]; 
}); 

這將可能給出版光標方面的最佳性能&數據上了線。

另外,不要忘記指數userId

characters._ensureIndex({userId: 1}); 
characterSouls._ensureIndex({userId: 1}); 
characterItems._ensureIndex({userId: 1}); 
+0

感謝您的答覆,虐待能夠正常化的項目集合,因爲它應該只在最大約500文件,但每個角色可以有在1-20個獨特的靈魂之間,所以這意味着靈魂收集會非常大,並且在加入文檔時可能會導致性能問題? – Tarlen 2014-08-31 09:28:28

+0

你什麼時候需要加入?如果您添加'userId'字段(按照示例),那麼您可以發佈而不使用任何聯接。如果你擔心客戶端性能,20應該是最小的 – 2014-08-31 09:41:07

+0

啊我很困惑,我的壞,但你認爲這個數據模型可以擴展到可能支持1000+併發用戶,約500個請求/秒被髮送到服務器? – Tarlen 2014-08-31 09:49:15

相關問題