Hola Daniel,

Gracias por la respuesta, pero el log no va a tener 3 campos como decis,
sino que deberia tener otros 3 o 4 campos int que indiquen Donde, Para Que,
etc..

El tema de los cubos es una muy buena idea, ya que lo normal va a ser
consultar estadisticas cada 6 meses que incluyan todos los campos del Log.

 

En fin, muchas gracias!,

Diego

  _____  

From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Aisenberg
Sent: Domingo, 03 de Junio de 2007 12:28
To: Diego Jancic
Subject: [dbms] RE: [dbms] Diseño en Performance

 

Con el volumen de datos que decís no hay ningún problema.

La tabla puede ser

Dbo.Logs( idUsuario int, Entrada datetime not null, Salida datetime null ) 

 

O sea unos 22 bytes por registro.

En 2 años de registro ocupa unos 0,6 gigabytes.

 

Estoy pensando que si Salida is null entonces está logueado.

 

Podes crear un indice con idUsuario, Entrada

O Entrada, idUsuario

O ambos

 

Pero: si por Entrada, te va a traer 25 o 26 millones de filas, el índice no
es de mucha ayuda o directamente estorba; salvo que traigas períodos
menores.

 

Traer 26 millones de filas siempre va a tardar algùn tiempo más o menos
significativo, pero la estadística de “quiénes se loguearon los últimos 2
meses y cuanto tiempo estuvieron logueados”, no creo que sea el tipo de
función donde el tiempo sea lo más crítico del universo. Si tarda un minuto
en armarla no creo que los gerentes se suiciden (o te maten). Se puede
emplear ese minuto para algo constructivo, como ser: pensar para qué les
puede ser útil semejante consulta. ;-)

 

Si no, tendrías que mantener información resumida, tipo cubos o algo por el
estilo, para que la consulta sea “instantánea”.

 

Saludos

Daniel

-----Mensaje original-----
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Diego Jancic
Enviado el: Sábado, 02 de Junio de 2007 03:14 a.m.
Para: Daniel Aisenberg
Asunto: [dbms] Diseño en Performance

 

Hola gente!

Estamos en el laburo empezando un nuevo proyecto y hay una parte en donde
hay un log de usuarios logueados (cuando se loguea y cuando se desloguea).

Esa información va a crecer muy rapido por la naturaleza de ser un log
(puede llegar a crecer unos 50000 registros por dia y si todo va muy bien
mejor aun..), y adicionalmente tiene que poder ser consultable para saber
quien esta logueado en ese momento de forma rapida. Tambien tiene que ser
viable hacer una estadistica de un periodo de 6 meses (maximo) sin que se
muera.

 

La pregunta no apunta a saber como optimizarlo, sino a saber si SQLServer
puede ser configurado para trabajar con tanta info despues de 2 años
(calculemos unos 25 millones de registros).

Puedo confiar en que contratando a un buen DBA eso se va a poder dividir en
diferentes archivos y hacer lo necesario para que funcione bien o es
conveniente copiar la información a otro lugar (otra tabla u otra DB) y
realizar las consultas hacia ahí… Básicamente lo necesito para contemplar
esa logica adicional en la aplicación.

 

Una pequeña información de cuales serian las tecnicas para optimizarlo seran
bienvenidos.

 

Muchas Gracias,

Diego


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.6/828 - Release Date: 01/06/2007
11:22 a.m.


Responder a