C?digo de barras

[Mauricio Nuñez]

Hola

Gracias por el analisis:

El Jue 08 Abr 2004 00:38, Alvaro Herrera Munoz escribió:
> > | Bytes_received           | 682682891 |
> > | Bytes_sent               | 991311462 |
>
> El trafico de entrada es gigante comparado con el de salida, por lo que
> puedo inferir que las consultas retornan resultados muy chicos.

La aplicacion que corre encima esta optimizada para evitar los largos y 
reitaretivos selects

>
> > | Com_delete               | 94        |
> > | Com_delete_multi         | 0         |
> > | Com_insert               | 2546      |
> > | Com_insert_select        | 0         |
> > | Com_select               | 2063057   |
> > | Com_update               | 8835      |
>
> El trafico de SELECT es 1000 veces mayor que el de INSERT, y el de UPDATE
> es 4 veces mayor que el de INSERT (=> 250 veces menor que el de SELECT).
> Esto es una base de datos casi completamente de lectura.

Esto es lo principal a rescatar de Mysql. Es muy eficiente para utilizarlo 
como base de datos de lectura.


>
> El resto de las variables Com_ parecen indicar que MySQL tiene un monton de
> comandos no estandares para manipular los datos (esto significa que si
> quiers migrar a otro RDBMS es casi imposible porque el dialecto local de
> SQL es muy distinto)

Mysql tiene el comando replace, que es el unico no estandar que utilizo porque 
es bastante util, y es para un caso muy particular. Todo lo demas es manejado 
via un API de persistencia, por lo que no me complica migrar a otra base de 
datos. Es practicamente trasparente.

>
> > | Connections              | 456       |
>
> No hay muchas conexiones (seguramente usan conexiones persistentes).
>
Exacto. 

> > | Uptime                   | 33505     |
>
> Segun el manual, esto se mide en segundos; 33500 segundos son como 10
> horas. Es un uptime bastante pauperrimo para un servidor de bases de datos.


> (BTW, el manual no especifica ni siquiera de lejos si las variables se
> reinician en 0 al reiniciar el servidor de datos ... por lo que puedo ver,
> la documentacion de MySQL es bastante mala en general)
quedan en cero. El servidor lo reinicie ayer despues de un uptime de varios 
meses. Da pena perder el uptime :-(

>
> > 10:10:00 AM       CPU     %user     %nice   %system     %idle
> > 10:20:00 AM       all      5.47      0.00      3.14     91.40
>
> [etc, %idle se mantiene entre 84 y 95]
>
> Ok, o sea la maquina no hace casi nada ... no es lo que yo llamaria una
> base de datos de alto trafico.

Bueno, esta base de datos genera el contenido para 2 sitios web con mas de 
400.000 visitas diarias en total, aunqye es más el diseño de la aplicacion el  
que permite optimizar el uso de la base de datos. 

La velocidad para servir datos es relevante con Mysql . La version 4 incorpora 
ademas un cache interno para almacenar las consultas mas frecuentes.

Para mi caso en particular, Mysql ha servido sin problemas , pero , como 
siempre, hay que ver el tipo de aplicacion a desarrollar. Como base datos 
para un sitio web, donde las lecturas son mucho mayores a las escrituras, y 
las lecturas por lo general tienen un patron repetitivo, Mysql ofrece un buen 
rendimiento. Me gustaria probar postgresql bajo un entorno similar.

Saludos

Mauricio