¿Acortar los nombres de propiedad MongoDB vale la pena?

En Blog rodando con mongoDB, express y Node.js, el autor menciona que es una buena idea acortar los nombres de propiedad:

…. el problema reportado con frecuencia con mongoDB es el tamaño de los datos en el disco … cada registro almacena todos los nombres de campo … Esto significa que a menudo puede ser más eficiente en el uso del espacio tener propiedades como ‘t’, o ‘b’ en lugar de ‘título’ o ‘cuerpo’; sin embargo, por miedo a la confusión, ¡evitaría esto a menos que sea realmente necesario!

Estoy al tanto de las soluciones de cómo hacerlo. Estoy más interesado en cuándo es esto realmente necesario?

Para citar a Donald Knuth :

La optimización prematura es la raíz de todo mal (o al menos la mayor parte) en la progtwigción.

Cree su aplicación, sin embargo, parece más sensato, sostenible y lógico. Entonces, si tiene problemas de rendimiento o de almacenamiento, trate con aquellos que tienen el mayor impacto hasta que el rendimiento sea satisfactorio o la ley de rendimientos decrecientes significa que no tiene sentido optimizar aún más.

Si no está seguro del impacto de determinadas decisiones de diseño (como los nombres de propiedades largos), cree un prototipo para probar varias hipótesis (como “los nombres de propiedades más cortos ahorran mucho espacio”). No espere que el resultado de las pruebas sea concluyente, sin embargo, le puede enseñar cosas que no esperaba aprender.

Mantenga la prioridad para los nombres significativos por encima de la prioridad para los nombres cortos a menos que su propia situación y las pruebas proporcionen una razón específica para alterar esas prioridades.

Tal como se menciona en los comentarios de SERVER-863 , si está utilizando MongoDB 3.0+ con la opción de almacenamiento WiredTiger con la compresión snappy activada, los nombres de campo largos se vuelven un problema menor ya que la compresión se encarga de la reducción para usted.

En pocas palabras: manténlo tan compacto como sigue siendo significativo.

No creo que esto sea realmente necesario para ser abreviado con nombres de una letra. De todos modos, debes acortarlos tanto como sea posible, y te sientes cómodo con eso. Digamos que usted tiene un nombre de usuario : {FirstName, MiddleName, LastName}; puede ser útil incluso con el nombre: {first, middle, last} . Si se siente cómodo, puede estar bien con el nombre: {f, m, l} .
Debería usar nombres cortos: ya que consumirá espacio en disco, memoria y puede ralentizar su aplicación (menos objetos para mantener en la memoria, tiempos de búsqueda más lentos debido a mayor tamaño y tiempo de consulta más largo ya que la búsqueda de datos lleva más tiempo).
Una buena documentación de esquema puede decirle al desarrollador que t significa ciudad y no título. Dependiendo de tu stack, incluso podrás ocultar al desarrollador el problema de trabajar con estos atajos mediante algunos utilitarios auxiliares para mapearlo.

Finalmente, diría que no hay pautas sobre cuándo y cuánto debe acortar sus nombres de esquema. Depende en gran medida de su entorno y requisitos. Pero es bueno mantenerlo compacto si puede proporcionar una buena documentación explicando todo y / u ofreciendo utilidades para facilitar la vida de los desarrolladores y administradores. De todos modos, es probable que los administradores interactúen directamente con mongodb, así que supongo que no se debe perder una buena documentación.

Si usa verbose xml, tratar de mejorar eso con nombres personalizados podría ser muy importante. Un comentario del usuario en el boleto SERVER-863 dijo en su caso; Estoy ‘almacenando objetos XML definidos externamente, con nomenclatura detallada: los nombres de campo son, tal vez, el 70% del tamaño total del registro. Así que la tokenización de nombre de campo podría ser una gran victoria, tanto en términos de E / S como de eficiencia de memoria.

Agregando mis 2 centavos en esto …

Los atributos con nombre largo (o “Anormalmente atributos de nombre largo”) se pueden evitar al diseñar el modelo de datos. En mi organización anterior probamos mantener la estrategia de atributos con nombre corto, como por ejemplo cadenas definidas por la organización de 4 a 5 letras, por ejemplo:

  1. Nombre = FSTNM,
  2. Apellido = LSTNM,
  3. Porcentaje de pérdida de ganancias mensual = MTPCT,
  4. Proyección de Ventas Año por Año = YOYSP, y así sucesivamente …)

Si bien observamos una mejora en el rendimiento de las consultas, en gran parte debido a la reducción en el tamaño de los datos transferidos a través de la red, o (ya que usamos JAVA con MongoDB) la reducción en la longitud de “claves” en el espacio MongoDB document / Java Map la mejora general en el rendimiento fue inferior al 15%.

En mi opinión personal, esta fue una micro-optimización que tuvo un costo adicional (y un gran dolor de cabeza) de mantener / diseñar un sistema adicional de administración de Diccionario de atributos de datos para cada uno de los modelos de datos. Se requería que este sistema tuviera una transparencia amplia en la organización mientras se depuraba la aplicación / respondía a las consultas de los clientes.

Si se encuentra en una posición en la que hasta 20% de aumento en el rendimiento con esta estrategia le resulta lucrativo, puede ser el momento de ampliar sus servidores MongoDB / elegir alguna otra estrategia de modelado / consulta de datos, o bien elegir una diferente base de datos en total.

    Intereting Posts