subdocumentos - mongodb consulta like
¿Por qué los nombres de clave se almacenan en el documento en MongodDB? (3)
Tengo curiosidad por esta cita de MonsterDB en acción de Kyle Banker:
Es importante tener en cuenta la longitud de los nombres de clave que elija, ya que los nombres de clave se almacenan en los propios documentos. Esto contrasta con un RDBMS, donde los nombres de columna siempre se mantienen separados de las filas a las que hacen referencia. Entonces, al usar BSON, si puede vivir con dob en lugar de date_of_birth como nombre de clave, ahorrará 10 bytes por documento. Puede que no parezca mucho, pero una vez que tenga mil millones de documentos de este tipo, habrá ahorrado casi 10 GB de espacio de almacenamiento con solo usar un nombre de clave más corto. Esto no significa que deba ir a longitudes irrazonables para garantizar nombres de clave pequeños; ser sensible. Pero si espera grandes cantidades de datos, economizar en nombres clave ahorrará espacio.
Me interesa la razón por la que esto no está optimizado en el lado del servidor de la base de datos. ¿Una tabla de búsqueda en la memoria con todos los nombres clave de la colección sería una penalización de rendimiento que no vale la pena el potencial ahorro de espacio?
A lo que se refiere a menudo se le llama "compresión de clave" *. Hay varias razones por las que no se ha implementado:
- Si lo desea, puede hacerlo en el nivel de Aplicación / ORM / ODM con bastante facilidad.
- No es necesariamente una ventaja de rendimiento ** en todos los casos: piense en colecciones con muchos nombres de claves y / o nombres de claves que varían enormemente entre los documentos.
- Es posible que no proporcione una ventaja de rendimiento ** mensurable hasta que tenga millones de documentos.
- Si el servidor lo hace, los nombres de las claves completas aún deben transmitirse a través de la red.
- Si los nombres de las claves comprimidas se transmiten a través de la red, la legibilidad realmente se resiente con la consola javascript.
- La compresión de todo el documento JSON
podría ofreceruna ventaja de rendimiento aún mejor.
Al igual que todas las características, hay un análisis de costo-beneficio para implementarlo, y (al menos hasta ahora) otras características han ofrecido más "bang for the buck".
La compresión completa del documento está [siendo considerada] [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 la memoria para los nombres de claves 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 capacidad de compresión de documentos con el motor de almacenamiento WiredTiger .
Hay dos algoritmos de compresión disponibles: snappy y zlib . La intención es que snappy sea la mejor opción para un rendimiento completo, y que zlib sea la mejor opción para la máxima capacidad de almacenamiento.
En mi experimentación personal (no científica, pero relacionada con un proyecto comercial), la compresión snappy (no evaluamos zlib) ofreció una densidad de almacenamiento significativamente mejorada sin un costo neto de rendimiento notable. De hecho, hubo un rendimiento ligeramente mejor en algunos casos, más o menos en línea con mis comentarios / predicciones anteriores.
Creo que una de las razones originales detrás de almacenar los nombres de las claves con los documentos es permitir una base de datos sin schema-less más escalable. Cada documento es autónomo en mayor medida, ya que si lo mueve a otro servidor (por ejemplo, a través de la replicación o fragmentación), puede indexar el contenido del documento sin tener que hacer referencia a metadatos separados o centralizados, como una asignación de nombres de clave a ID de claves más compactas.
Como no hay un esquema forzado para una colección de MongoDB, los nombres de los campos pueden ser diferentes para cada documento en la misma colección. En un entorno sharded , las inserciones en cada fragmento son (intencionalmente) independientes, por lo que, a nivel de documento, los datos sin procesar podrían ser diferentes a menos que el mapeo de claves sea consistente por fragmento.
Dependiendo de su caso de uso, los nombres clave pueden o no consumir una cantidad significativa de espacio en relación con los datos que lo acompañan. Siempre puede solucionar el problema de almacenamiento de la aplicación / implementación de ODM asignando YourFriendlyKeyNames a equivalentes de claves de DB más cortos.
Hay un problema abierto de MongoDB Jira y un poco más de discusión para tener los nombres de campo de tokenize del servidor , que puede votar para ayudar a priorizar la inclusión de esta característica en una versión futura.
Los objetivos de diseño actuales de MongoDB incluyen desempeño con esquemas dinámicos, replicación y alta disponibilidad, fragmentación automática y actualizaciones en el lugar ... con un posible compromiso es el uso adicional de disco.
Tener que buscar esto en la base de datos para todas y cada una de las consultas sería un castigo grave.
La mayoría de los controladores le permiten especificar ElementName, de modo que MyLongButReadablePropertyName en su modelo de dominio se convierta en mlbrpn en mongodb.
Por lo tanto, cuando consulta en su aplicación, es la aplicación que transforma la consulta que habría sido:
db.myCollection.find({"MyLongButReadablePropertyName" : "some value"})
dentro
db.myCollection.find({"mlbrpn" : "some value"})
Los controladores eficientes, como el controlador C # almacenan en caché esta asignación, por lo que no es necesario buscar esto para todas y cada una de las consultas.
Volviendo al título de tu pregunta:
¿Por qué los nombres de clave se almacenan en el documento en MongodDB?
Esta es la única forma en que se pueden buscar documentos?
Sin los nombres de clave almacenados, no habría ninguna clave para buscar.
Espero que esto ayude