Du märkte med rätta att dokumenten kommer att ha olika storlek. Så du kommer att spara minst 15 bytes per dokument (60% för liknande dokument) om du bestämmer dig för att använda det andra schemat. Detta kommer att hamna i ungefär 140MB för dina 10 million uppgifter. Detta ger dig följande fördel:
- Hårddiskbesparingar. Det enda problemet är att om man tittar på priserna för nuvarande hårddisk så är detta för det mesta värdelöst.
- Spara RAM. I jämförelse med hårddiskar kan detta vara användbart för indexering. I mongodb bör arbetsuppsättningar av index passa i RAM för att uppnå en bra prestanda
. Så om du kommer att ha index på dessa två fält sparar du inte bara
140MBhårddiskutrymme men också140MBav potentiellt RAM-utrymme (vilket faktiskt är märkbart). - I/O . Många flaskhalsar uppstår på grund av begränsningen av input/output-systemet (hastigheten för läsning/skrivning från disken är begränsad). För dina dokument innebär detta att du med schema 2 potentiellt kan läsa/skriva
twice as many documentsper 1 sekund. - nätverk . I många situationer är nätverket till och med mycket långsammare än IO, och om din DB-server är på en annan maskin så måste din applikationsserver data skickas över tråden. Och du kommer också att kunna skicka dubbelt så mycket data.
Efter att ha berättat om fördelar måste jag berätta en nackdel för en liten nycklar:
- läsbarhet för databasen. När du gör
db.coll.findOne()och ser{_id: 1, t: 13423, a: 3, b:0.2}det är ganska svårt att förstå exakt vad som lagras här. - applikationens läsbarhet liknande databasen, men här kan du åtminstone ha en lösning. Med en mappningslogik, som transformerar
currentDatetillcochpricetillpdu kan skriva en ren kod och ha ett kort schema.