2014-08-31 2 views
4

Я создаю пошаговую RPG на основе браузера и построил модель данных, приведенную ниже. Когда игрок участвует в бою, как чтение, так и запись будут выполняться под-документом «души» и «предметы» (массивы) и далее читаются в под-документах «навыки» и «характер». Я предполагаю, что каждый из этих массивов может быть испорчен между 1-30 поддокументами каждыйЯвляется ли эта схема с вложенными поддокументами, убивающей производительность?

Я попытался содержать почти всю логику в одной коллекции для производительности, но я зашел слишком далеко с вложением?

Я слышал, что 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 в отдельную коллекцию, а также souls и items.

Затем 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

Спасибо за ответ, Ill быть в состоянии нормализовать сбор пунктов, потому что она должна быть только около 500 документов, в большинстве, но каждый символ может иметь между 1-20 уникальными душами, поэтому это означает, что коллекция душ будет очень большой и потенциально может вызвать проблемы с производительностью при присоединении к документам? – Tarlen

+0

Когда вам нужно будет присоединиться? если вы добавите поле 'userId' (в соответствии с примером), вы можете публиковать его без использования каких-либо объединений. Если вы беспокоитесь о производительности на стороне клиента, 20 должно быть минимальным –

+0

А я был в замешательстве, мой плохой, но как вы думаете, эта модель данных будет масштабируемой, чтобы потенциально поддерживать 1000+ одновременных пользователей, причем около 500 запросов в секунду отправляются на сервер? – Tarlen

Смежные вопросы