Notaste correctamente que los documentos tendrán un tamaño diferente. Por lo tanto, ahorrará al menos 15 bytes por documento (60% para documentos similares) si decide adoptar el segundo esquema. Esto terminará en algo así como 140MB por tus 10 million registros. Esto le dará la siguiente ventaja:
- Ahorro de disco duro. El único problema es que mirar los precios de los discos duros actuales es prácticamente inútil.
- Ahorro de memoria RAM. En comparación con los discos duros, esto puede ser útil para la indexación. En el conjunto de trabajo de mongodb de los índices deben caber en la RAM para lograr una buena rendimiento
. Entonces, si tiene índices en estos dos campos, no solo ahorrará
140MBde espacio en disco duro pero también140MBde espacio RAM potencial (que en realidad es notable). - E/S . Muchos cuellos de botella ocurren debido a la limitación del sistema de entrada/salida (la velocidad de lectura/escritura del disco es limitada). Para sus documentos, esto significa que con el esquema 2 puede leer/escribir potencialmente
twice as many documentspor 1 segundo. - red . En muchas situaciones, la red es incluso mucho más lenta que IO, y si su servidor DB está en una máquina diferente, entonces su servidor de aplicaciones, los datos deben enviarse por cable. Y también podrá enviar el doble de datos.
Después de contarte las ventajas, tengo que decirte una desventaja de las teclas pequeñas:
- legibilidad de la base de datos. Cuando haces
db.coll.findOne()y ve{_id: 1, t: 13423, a: 3, b:0.2}es bastante difícil entender qué se almacena exactamente aquí. - legibilidad de la aplicación similar con la base de datos, pero al menos aquí puede tener una solución. Con una lógica de mapeo, que transforma
currentDateacypriceappuede escribir un código limpio y tener un esquema breve.
