MongoDB als een tijdreeksdatabase

Dit is natuurlijk een oude vraag, maar ik kwam hem tegen toen ik MongoDB aan het onderzoeken was voor tijdreeksgegevens. Ik dacht dat het misschien de moeite waard zou zijn om de volgende benadering te delen voor het vooraf toewijzen van volledige documenten en het uitvoeren van update-bewerkingen, in tegenstelling tot nieuwe invoegbewerkingen. Let op, deze aanpak is hier en hier gedocumenteerd.

Stel je voor dat je elke minuut gegevens opslaat. Overweeg de volgende documentstructuur:

{
  timestamp: ISODate("2013-10-10T23:06:37.000Z"),
  type: ”spot_EURUSD”,
  value: 1.2345
},
{
  timestamp: ISODate("2013-10-10T23:06:38.000Z"),
  type: ”spot_EURUSD”,
  value: 1.2346
}

Dit is vergelijkbaar met een standaard relationele benadering. In dit geval produceert u één document per geregistreerde waarde, wat veel invoegbewerkingen veroorzaakt. Wij kunnen het beter. Overweeg het volgende:

{
  timestamp_minute: ISODate("2013-10-10T23:06:00.000Z"),
  type: “spot_EURUSD”,
  values: {
    0: 1.2345,
    …  
    37: 1.2346,
    38: 1.2347,
    … 
    59: 1.2343
  }
}

Nu kunnen we één document schrijven en 59 updates uitvoeren. Dit is veel beter omdat updates atomair zijn, individuele schrijfbewerkingen kleiner zijn en er andere prestatie- en gelijktijdigheidsvoordelen zijn. Maar wat als we de hele dag, en niet alleen de hele uren, in één document willen opslaan. Dit zou dan vereisen dat we langs 1440 vermeldingen lopen om de laatste waarde te krijgen. Om dit te verbeteren, kunnen we het volgende uitbreiden:

{
  timestamp_hour: ISODate("2013-10-10T23:00:00.000Z"),
  type: “spot_EURUSD”,
  values: {
    0: { 0: 1.2343, 1: 1.2343, …, 59: 1.2343},
    1: { 0: 1.2343, 1: 1.2343, …, 59: 1.2343},
    …,
    22: { 0: 1.2343, 1: 1.2343, …, 59: 1.2343},
    23: { 0: 1.2343, 1: 1.2343, …, 59: 1.2343}
  }
}

Met deze geneste benadering hoeven we nu nog maar maximaal 24 + 60 te lopen om de allerlaatste waarde van de dag te krijgen.

Als we de documenten van te voren met alle waarden gevuld met opvulling bouwen, kunnen we er zeker van zijn dat het document niet van grootte verandert en dus niet wordt verplaatst.