Hai notato correttamente che i documenti avranno dimensioni diverse. Quindi risparmierai almeno 15 bytes per documento (60% per documenti simili) se si decide di adottare il secondo schema. Questo finirà in qualcosa come 140MB per i tuoi 10 million record. Questo ti darà il seguente vantaggio:
- Risparmio HDD. L'unico problema è che guardando i prezzi dell'attuale HDD questo è per lo più inutile.
- Risparmio RAM. Rispetto ai dischi rigidi, questo può essere utile per l'indicizzazione. Nel set di lavoro mongodb di gli indici dovrebbero adattarsi alla RAM per ottenere una buona prestazioni
. Quindi, se avrai indici su questi due campi, non solo risparmierai
140MBdi spazio su HDD ma anche140MBdi potenziale spazio RAM (che è effettivamente notevole). - I/O . Molti colli di bottiglia si verificano a causa della limitazione del sistema di input/output (la velocità di lettura/scrittura dal disco è limitata). Per i tuoi documenti, questo significa che con lo schema 2 puoi potenzialmente leggere/scrivere
twice as many documentsper 1 secondo. - rete . In molte situazioni la rete è ancora più lenta dell'IO e se il server DB si trova su una macchina diversa dal server delle applicazioni, i dati devono essere inviati via cavo. E potrai anche inviare il doppio dei dati.
Dopo aver parlato dei vantaggi, devo dirti uno svantaggio per i tasti piccoli:
- leggibilità del database. Quando esegui
db.coll.findOne()e vede{_id: 1, t: 13423, a: 3, b:0.2}è piuttosto difficile capire cosa sia esattamente memorizzato qui. - leggibilità dell'applicazione simile con il database, ma almeno qui puoi avere una soluzione. Con una logica di mappatura, che trasforma
currentDateacepriceappuoi scrivere un codice pulito e avere uno schema breve.
