Uppenbarligen är detta en gammal fråga, men jag stötte på den när jag undersökte MongoDB för tidsseriedata. Jag tänkte att det kan vara värt att dela med sig av följande tillvägagångssätt för att allokera kompletta dokument i förväg och utföra uppdateringsoperationer, i motsats till nya infogningsoperationer. Observera att detta tillvägagångssätt dokumenterades här och här.
Föreställ dig att du lagrar data varje minut. Tänk på följande dokumentstruktur:
{
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
}
Detta är jämförbart med ett standardmässigt relationellt tillvägagångssätt. I det här fallet producerar du ett dokument per registrerat värde, vilket orsakar många infogningsoperationer. Vi kan göra bättre. Tänk på följande:
{
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 kan vi skriva ett dokument och utföra 59 uppdateringar. Detta är mycket bättre eftersom uppdateringar är atomära, individuella skrivningar är mindre och det finns andra prestanda- och samtidighetsfördelar. Men tänk om vi ville lagra hela dagen, och inte bara hela timmarna, i ett dokument. Detta skulle då kräva att vi går längs 1440 poster för att få det sista värdet. För att förbättra detta kan vi utöka till följande:
{
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}
}
}
Med detta kapslade tillvägagångssätt behöver vi nu bara gå, högst, 24 + 60 för att få det allra sista värdet på dagen.
Om vi bygger dokumenten med alla värden ifyllda med utfyllnad i förväg kan vi vara säkra på att dokumentet inte kommer att ändra storlek och därför inte flyttas.