2014-09-12 3 views
0

Je prévois de créer une base de données pour l'historique des prix. La base de données d'historique devrait conserver les prix définis 90 jours à l'avance chaque jour de l'année. Cela signifie: 90 jours x 365 jours/an = 32850 élément de base de donnéesMongodb grand document design

Existe-t-il un moyen de concevoir un schéma pour améliorer les performances des requêtes?

ma première suggestion était de stocker des valeurs hiérarchiques comme:

{ 
    "Address": "xxxxx", 
    "City": "xxxxx", 
    "Country": "Deutschland", 
    "Currency": "EUR", 
    "Item_Name": "xxxxxx", 
    "Location": [ 
     log, lat 
    ], 
    "Postal_code": "xxxx", 
    "Price_History": [ 
     2014 : [ 
      "January" : { 
       "CW_1" : { 1: [ price1 .. price90 ], 2: [ price1 .. price90 ], }, 
       "CW_2" : {}, 
       "CW_3" : {}, 
      } , 
      "February" : {}, 
      "March" : {}, 
      ] 
      ] 
} 

Merci à l'avance!

+0

Tout dépend des requêtes qui vous intéressent. Pouvez-vous donner quelques exemples des requêtes les plus courantes que vous envisagez d'exécuter sur vos données? – Lix

+0

tout d'abord merci pour votre commentaire. Quelques exemples devraient être 1. "trouver des prix à si l'article est dans le voisinage de Location [log, lat]" 2. "trouver des endroits où les prix plus élevés que à " 3. "trouver un article si fournisseur et si la ville est xxx " – ovntatar

+0

Hmm ... ok ... donc c'est une direction différente de ce que je pensais ... Continuons dans le chat - http://chat.stackoverflow.com/rooms/ 61100/room-for-lix-and-ovntatar – Lix

Répondre

1

Tout dépend des requêtes que vous envisagez d'exécuter sur ces données. Il me semble que si vous souhaitez conserver un historique des actions, vos requêtes contiendront presque toujours un paramètre de date.

Le tableau Price_History peut être mieux formaté en tant que sous-document. Chacun de ces documents aurait une gamme variée (mais limitée) de valeurs - l'année et le mois. Ce pourrait être une bonne idée d'ajouter un index sur cet attribut. Ainsi, chaque fois que vous interrogerez sur une plage de dates donnée, vos index aideront mongo à trouver l'ensemble de données pertinent relativement rapidement.


Une autre option serait d'avoir chaque prix en soi comme un document. L'élément connecté au prix peut être un sous-document ne contenant peut-être pas toutes les données de l'article, mais suffisamment pour pouvoir effectuer les calculs et récupérer les autres données pertinentes une fois que votre ensemble de données est suffisamment petit. Pour cette utilisation, je recommanderais de créer un seul attribut des plages de dates à indexer ainsi qu'un index sur l'attribut item._id. Vous pouvez toujours avoir les composants de date individuels si vous devez toujours les interroger individuellement. Quelque chose comme ceci:

{ 
    "ind_attr": "2014_January_CW1", 
    "date": { 
    "year": 2014, 
    "month": January", 
    }, 
    "CW": 1, 
    "price": [ price1... price90 ], 
    "item": { 
    "name": ..., 
    "_id": ..., 
    // minimal data about the actual item 
    } 
} 

Avec cette structure de documents, vous pouvez facilement ajouter un index sur l'attribut ind_attr. L'attribut document.item._id peut être utilisé pour récupérer des données plus détaillées sur l'élément réel si nécessaire.

+0

Si je ne me trompe pas, le document.item._id est une référence du document parent qui inclut City, Location etc ..? – ovntatar