¿Por qué los nombres clave se almacenan en el documento en MongodDB?

A lo que te refieres a menudo se le llama "compresión de clave"*. Hay varias razones por las que no se ha implementado:

1. Si desea hacerlo, actualmente puede hacerlo en el nivel de Aplicación/ORM/ODM con bastante facilidad.
2. No es necesariamente una ventaja de rendimiento** en todos los casos:piense en colecciones con muchos nombres clave y/o nombres clave que varían mucho entre documentos.
3. Es posible que no proporcione una ventaja de rendimiento medible** hasta que tenga millones de documentos.
4. Si el servidor lo hace, los nombres completos de las claves aún deben transmitirse a través de la red.
5. Si los nombres de clave comprimidos se transmiten a través de la red, entonces la legibilidad realmente sufre usando la consola javascript.
6. Comprimir todo el documento JSON podría ofrecer ofrece una ventaja de rendimiento aún mejor.

Al igual que todas las funciones, hay un análisis de costo-beneficio para implementarlo y (al menos hasta ahora) otras funciones han ofrecido más "beneficio por el dinero".

La compresión completa del documento [se está considerando][1] para una futura versión de MongoDB. disponible a partir de la versión 3.0 (ver más abajo)

* Una tabla de búsqueda en memoria para nombres clave es básicamente un caso especial de compresión de estilo LZW; eso es más o menos lo que hacen la mayoría de los algoritmos de compresión.

** La compresión proporciona tanto una ventaja de espacio como una ventaja de rendimiento. Documentos más pequeños significa que se pueden leer más documentos por IO, lo que significa que en un sistema con IO fijo, se pueden leer más documentos por segundo.

Actualizar

Las versiones 3.0 y posteriores de MongoDB ahora tienen una capacidad de compresión de documentos completa con WiredTiger motor de almacenamiento.

Hay dos algoritmos de compresión disponibles:snappy y zlib . La intención es que snappy sea la mejor opción para un rendimiento general y que zlib sea la mejor opción para obtener la máxima capacidad de almacenamiento.

En mi experimentación personal (no científica, pero relacionada con un proyecto comercial), la compresión rápida (no evaluamos zlib) ofreció una densidad de almacenamiento significativamente mejorada sin un costo de rendimiento neto notable. De hecho, hubo un rendimiento ligeramente mejor en algunos casos, más o menos en línea con mis comentarios/predicciones anteriores.