Ver Mensaje Individual
  #5 (permalink)  
Antiguo 23/02/2014, 12:22
dezagus
 
Fecha de Ingreso: abril-2010
Ubicación: Ping: BSAS - Arg
Mensajes: 791
Antigüedad: 14 años, 10 meses
Puntos: 25
Respuesta: Como reduje el consumo en más de 350%

Cita:
Iniciado por gnzsoloyo Ver Mensaje
Es relativo.
Las columnas autoincrementales son, las más de las veces, parches de programador a modelo de datos no muy bien diseñados. No son necesariamente buenas soluciones.
Es mejor un correcto modelado de datos, con consultas optimizadas, así como relevar los requerimientos del sistema y la eficiencia de la aplicación, que usar AI como solución mágica.

La solución que encontraste ´puede parecerte a ti eficiente y efectiva, pero desde nuestro lado no podemos saber con certeza si la decisión que tomaste es del todo correcta porque en realidad no conocemos ni tu modelo de datos, ni las queries que usas, ni tampoco lo bien o mal diseñada que está esa aplicación. Es información insuficiente para poder dar una opinión adecuada.
Tal es así, que a pesar de la solución que implementaste, a mi, esta frase:

me habla de tres defectos probables: exceso o mal manejo de conexiones, ineficiencia en el uso de consultas, y falta de optimización de la aplicación. Todos elementos que podrían corregirse sin necesidad de implementar AIs.
Lo que hace, si, el uso de AI como base de JOINs más eficiente es por que el acceso por claves numéricas es siempre más rápido que por claves alfanuméricas. Eso si.
Pero el hablar de claves numéricas no implica hablar de AI. Podríamos estar hablando en realidad de numeros de documento, o telefónicos, e igualmente obtener el mismo nivel de mejora.
Además, si la clave no es parte del resultado a utilizar, puedes estar usando accesos a disco innecesarios, y eso podría ser mejorado de otro modo.
Claro que estoy especulando, pero especulo en base a mi experiencia en BBDD, y he visto cambios brutales de eficiencia en consultas sin necesidad de implementar AIs...

Todo depende del contexto del sistema.
Por supuesto, todo depende del contexto. Pero esto es un TIP para un proyecto como muchos que inicia siendo amateur y comienza a ganar terreno.

Si hablamos desde el lado StartUp: Existe un "limbo" en el cual no te dá suficiente ganancia como para subcontratar todo o pagar full time. Ese período es el período de monetización en el que uno tiene que absover costos, mejorar el perfíl público del proyecto y permitirse funcionar correctamente en el aquí y ahora. Uno como emprendedor tiene múltiples conocimientos de cientas de ramas, pero no se especializa practicamente en ninguna. Ese es mi perfíl, por ejemplo. No soy Ing en Software, pero pude optimizarlo en un 350%. Se que se puede aún más, pero ya escapa de mi conocimiento y de mi necesidad, como bién dijiste: es relativo.

Obviamente, mi base de dátos no es eficiente ni en lo más mínimo, pero para proyectos similares que inician de manera similar creo que es un buén TIP el que doy. Uno cuando inicia un proyecto por su cuenta, generalmente no optimiza al extremo (generalmente no lo hace) ya que requiere más tiempo y más esfuerzo y en ocaciones dinero.

En mi caso, no optimizé al comienzo por falta de conocimiento y porque era una prueba más que otra cosa. Hoy, tiene otro enfoque.

Lo que planteo aca NO ES la panacea, sinó dos o tres pequeños TIPs que ayudan a que proyectos a nivel web crezcan más con menos. Solo eso.

============ Otro Tip ============

Lo que me sucedía es que a las 4AM se ejecutaba un cron el cual limpiaba la DB de registros con más de 5 días. Bueno, en esos 5 días puede haber más de 650 mil filas (en mi caso). Pero ántes, tenia que hacer unos COUNT de dichas filas y luego borrarlas. Eran 3 o 4 COUNTS. Como no puedo optimizar en este momento dichos count, lo que realizé fué ponerle varios sleep para separar entre count y count y evitar cuellos de botella.