U hebt terecht opgemerkt dat de documenten een ander formaat zullen hebben. U bespaart dus minimaal 15 bytes per document (60% voor vergelijkbare documenten) als u besluit het tweede schema te gebruiken. Dit zal eindigen in iets als 140MB voor uw 10 million verslagen. Dit geeft u het volgende voordeel:
- Besparing op HDD. Het enige probleem is dat kijkend naar de prijzen voor de huidige HDD dit meestal nutteloos is.
- RAM-besparing. In vergelijking met harde schijven kan dit handig zijn bij het indexeren. In mongodb-werkset van moeten indexen in RAM passen om een goede prestatie
. Dus als u indexen op deze twee velden heeft, bespaart u niet alleen
140MBHDD-ruimte maar ook140MBvan potentiële RAM-ruimte (wat eigenlijk merkbaar is). - I/O . Er doen zich veel knelpunten voor door de beperking van het invoer/uitvoersysteem (de snelheid van lezen/schrijven vanaf de schijf is beperkt). Voor uw documenten betekent dit dat u met schema 2 potentieel
twice as many documentskunt lezen/schrijven per 1 seconde. - netwerk . In veel situaties is het netwerk zelfs veel langzamer dan IO, en als je DB-server op een andere machine staat dan je applicatieserver, moeten de gegevens over de draad worden verzonden. En u kunt ook twee keer zoveel gegevens verzenden.
Nadat ik over voordelen heb verteld, moet ik je een nadeel voor kleine toetsen vertellen:
- leesbaarheid van de database. Wanneer u
db.coll.findOne(). doet en ziet{_id: 1, t: 13423, a: 3, b:0.2}het is vrij moeilijk te begrijpen wat hier precies is opgeslagen. - leesbaarheid van de applicatie vergelijkbaar met de database, maar hier heb je tenminste een oplossing. Met een mapping-logica, die
currentDate. transformeert naarcenpricenaarpje kunt een schone code schrijven en een kort schema hebben.