MySQL: Dudas respecto al rendimiento y el volumen de informacion

[Computer XTress]

Hola muy buenas noches, soy programador y me veo frente a un proyecto que estoy realizando gratuitamente para una ONG, que manejara un volumen de datos muy grante y me gustaria saber de los expertos qué deberia tener en cuenta. Les detalle el caso y realizo abajo dos preguntas que son para mi los temas mas cruciales. Acepto todo tipo de consejo y observacion.

En mi sistema estoy capturando para cada sesion la posicion geografica desde la cual el usuario se conecta (a travez de un webservice que me da esa información para la IP que yo le paso). Esta informacion la guardo en una tabla asi:


SESION
id | id_sesion | ciudad | latitud | longitud


Cada vez que un usuario se loguea guardo estos 3 datos. Ocurre que no tengo un tabla donde almaceno las ciudades por lo que hay muchos registros con informacion repetida... ésto lo pense asi ya que sino tendria que armar una tabla con unas 250 ciudades para mi area de trabajo (gran trabajo).

Pregunta 1 - Suponiendo que voy a tener un aproximado de 50 sesiones por hora y que almacenare los ultimos 3 meses con total de 108.000 registros. ¿Este numero es un numero GRANDE para MySQL? ¿Afectará mucho el rendimiento como para considerar hacer una tabla con ciudades?

Pregunta 2 - En caso de que 108.000 sea un numero manejable por MySQL: con la información voy a armar graficos de estadisticas. ¿Sería muy pesado hacer una consulta con count y group by para traer el TOTAL de sesiones para cada CIUDAD? Esto se vería en una vitacora que se actualiza cada 15 segundos aproximadamente cuando el administrador esta logueado.

Agradezco de antemano su ayuda!

[quimfv]

108.000 registros no es una cifra grande para mysql.

Segundo como vas a guardar el nombre de la ciudad si no tienes la tabla de ciudades?
O es que el usuario va a entrar el nombre, en ese caso ojo que Sabadell es distinto de SABADELL, y Santiago distinto de Santiago de Chile o de Compostela....o London de Londres.

Luego si para guardar el nombre de la ciudad previamente debes tener la lista de ciudades, para que guardar el nombre de la ciudad, puedes guardar un identificador que simpre pesara menos, y relacionarlo con la tabla de ciudades.

Vas a trabajar con las coordenadas? Si no las vas a usar podrias actualizar el numero de sessiones de la ciudad, es decir no gardar un registro por session sino tener la tabla de ciudades y solo modificar el numero

UPDATE sesiones SET numeroSesiones=numeroSesiones+1 WHERE ciudad=X

NO TE ESCAPAS POR NINGÚN LADO DE CREAR ESA TABLA DE CIUDADES

(Por la red hay listados de ciudades por regiones.... quizas no tendrias ni que escribir las ciudades...http://es.wikipedia.org/wiki/Anexo:C...poblaci%C3%B3n)

[Computer XTress]

Hola Quimfm, gracias por tu respuesta. En realidad la forma en la que obtengo la ciudad es automática, tomo la IP del usuario y consulto un webservice de geo localizacion por IP que instalamos de forma dedicada, te paso link para que chusmees si te interesa: http://freegeoip.net/

El web service siempre da el mismo string para la ciudad asi que no voy a tener problema con ello. Lo que se me ocurre ahora, combinando con la idea que me sugeris de la tabla es crear la tabla "CIUDAD" y cada vez que se inicia sesion chequeo si la ciudad de la sesion existe en la tabla, si no existe, la inserto con sus datos (nombre, coordenadas, etc), y si existe actualizo la cantidad de sesiones que tenga ésta. Así no tengo que hacer ni el mas minimo esfuerzo :)

Me quedo tranqui entonces con los 108.000 registros... ¿a partir de qué numero podriamos decir que MySQL va a empezar a mostrar una baja en su performance? ¿500.000 por ejemplo? Soy muy ignorante respecto a estos volumenes de produccion...

Un saludo y gracias !

[gnzsoloyo]

. ¿a partir de qué numero podriamos decir que MySQL va a empezar a mostrar una baja en su performance? ¿500.000 por ejemplo?

La baja de performance tiene muchos factores, no sólo el volumen de una tabla.
El tema es lago y algo complejo. Peudes tener una pésima performance con 1000 registros, y una excelente performance con 1 tera de registros. No depende de la cantidad, sino de la optimización de los esquemas, las consultas, las tablas... y los servidores.
Es demasiado amplio, y hay que ver el caso, las consultas y el diseño de la base.