MongoDB jako databáze časových řad

Zjevně je to stará otázka, ale narazil jsem na ni, když jsem zkoumal MongoDB pro data časových řad. Myslel jsem si, že by možná stálo za to sdílet následující přístup pro přidělování úplných dokumentů předem a provádění operací aktualizace, na rozdíl od nových operací vkládání. Všimněte si, že tento přístup byl zdokumentován zde a zde.

Představte si, že ukládáte data každou minutu. Zvažte následující strukturu dokumentu:

{
  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
}

To je srovnatelné se standardním relačním přístupem. V tomto případě vytvoříte jeden dokument na každou zaznamenanou hodnotu, což způsobuje mnoho operací vkládání. Můžeme to udělat lépe. Zvažte následující:

{
  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
  }
}

Nyní můžeme napsat jeden dokument a provést 59 aktualizací. To je mnohem lepší, protože aktualizace jsou atomické, jednotlivé zápisy jsou menší a jsou zde další výhody výkonu a souběžnosti. Ale co kdybychom chtěli uložit celý den, nejen celé hodiny, do jednoho dokumentu. To by pak vyžadovalo, abychom prošli 1440 záznamů, abychom získali poslední hodnotu. Abychom to vylepšili, můžeme se dále rozšířit na následující:

{
  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}
  }
}

Pomocí tohoto vnořeného přístupu nyní musíme chodit maximálně 24 + 60, abychom získali úplně poslední hodnotu dne.

Pokud sestavíme dokumenty se všemi hodnotami předem vyplněnými paddingem, můžeme si být jisti, že dokument nezmění velikost a tudíž se ani nepřesune.