Administración de la base de datos de eventos del sitio web

Question

¿Cómo debo administrar las tablas que hacen referencia a los "eventos" del sitio? es decir, ciertas actividades que un usuario ha realizado en un sitio web que uso para rastrear. Quiero ser capaz de hacer todo tipo de datamining y correlación entre las diferentes actividades de los usuarios y lo que han hecho.

Hoy solo agregué 107,000 filas a mi tabla SiteEvent. ¡No creo que esto sea sostenible!

La base de datos es SQL Server. Me refiero principalmente a las actividades de mejores prácticas con respecto a la administración de grandes cantidades de datos.

Por ejemplo:

• ¿Debo mantener estas tablas en todas sus propias instituciones una base de datos? Si necesito unirme a otras tablas, esto podría ser un problema. Actualmente solo tengo una base de datos con todo en.
• ¿Cómo debo depurar los registros anteriores? Quiero asegurarme de que mi archivo db no siga creciendo.
• Mejores prácticas para hacer copias de seguridad y truncar los registros de
• ¿Agregar índices adicionales aumentar drásticamente el tamaño de la base de datos con tantos registros?
• ¿Hay alguna otra cosa que necesite para SQL Server que pueda volver a afectarme más tarde?

FYI: Estas son las tablas

CREATE TABLE [dbo].[SiteEvent](
    [SiteEventId] [int] IDENTITY(1,1) NOT NULL, 
    [SiteEventTypeId] [int] NOT NULL, 
    [SiteVisitId] [int] NOT NULL, 
    [SiteId] [int] NOT NULL, 
    [Date] [datetime] NULL, 
    [Data] [varchar](255) NULL, 
    [Data2] [varchar](255) NULL, 
    [Duration] [int] NULL, 
    [StageSize] [varchar](10) NULL, 

y

CREATE TABLE [dbo].[SiteVisit](
    [SiteVisitId] [int] IDENTITY(1,1) NOT NULL, 
    [SiteUserId] [int] NULL, 
    [ClientGUID] [uniqueidentifier] ROWGUIDCOL NULL CONSTRAINT [DF_SiteVisit_ClientGUID] DEFAULT (newid()), 
    [ServerGUID] [uniqueidentifier] NULL, 
    [UserGUID] [uniqueidentifier] NULL, 
    [SiteId] [int] NOT NULL, 
    [EntryURL] [varchar](100) NULL, 
    [CampaignId] [varchar](50) NULL, 
    [Date] [datetime] NOT NULL, 
    [Cookie] [varchar](50) NULL, 
    [UserAgent] [varchar](255) NULL, 
    [Platform] [int] NULL, 
    [Referer] [varchar](255) NULL, 
    [RegisteredReferer] [int] NULL, 
    [FlashVersion] [varchar](20) NULL, 
    [SiteURL] [varchar](100) NULL, 
    [Email] [varchar](50) NULL, 
    [FlexSWZVersion] [varchar](20) NULL, 
    [HostAddress] [varchar](20) NULL, 
    [HostName] [varchar](100) NULL, 
    [InitialStageSize] [varchar](20) NULL, 
    [OrderId] [varchar](50) NULL, 
    [ScreenResolution] [varchar](50) NULL, 
    [TotalTimeOnSite] [int] NULL, 
    [CumulativeVisitCount] [int] NULL CONSTRAINT [DF_SiteVisit_CumulativeVisitCount] DEFAULT ((0)), 
    [ContentActivatedTime] [int] NULL CONSTRAINT [DF_SiteVisit_ContentActivatedTime] DEFAULT ((0)), 
    [ContentCompleteTime] [int] NULL, 
    [MasterVersion] [int] NULL CONSTRAINT [DF_SiteVisit_MasterVersion] DEFAULT ((0)), 

Answer 1

Repensando el problema podría ser justo lo que recetó el doctor. ¿Pueden ser realmente útiles 100k registros por día? Parece una sobrecarga de información para mí. ¿Tal vez comiences por reducir la granularidad de tu seguimiento de uso?

Answer 2

En términos de volver a pensar el problema, puede explorar uno de los muchos paquetes de estadísticas web que existen. Solo hay unos pocos campos en su tabla de muestra que no son parte de una implementación lista para usar de WebTrends o Google Analytics o muchos otros. También se pueden configurar los otros elementos en su tabla, pero piense un poco más y investigue qué paquete satisfará todas sus necesidades. La mayoría de las cosas listas para usar pueden ocuparse del seguimiento de campañas, etc. en estos días.

Otra opción sería descargar lo común a un paquete web-stats estándar y luego analizarlo de nuevo en SQL Server con sus datos personalizados fuera de banda.

No sé cuántos otros datos tiene, pero si los 107K + registros diarios representan la mayor parte, podría terminar gastando su tiempo tratando de mantener sus estadísticas web funcionando en lugar de la funcionalidad real de sus aplicaciones.

Answer 3

Los mantendría en la misma base de datos, a menos que pueda purgar/almacenar de forma segura los registros antiguos para consultar OLAP y luego mantener la base de datos primaria para propósitos de OLTP.

Asegúrese de establecer un tamaño inicial grande para la base de datos y establecer un gran valor de crecimiento automático, y asegúrese de que no se quede sin espacio en disco. 107k registra al día es va a ocupar espacio sin importar cómo lo almacene.

En cuanto a las copias de seguridad, eso depende completamente de sus requisitos.Una diferencia semanal completa, diaria y una/dos hora debería funcionar bien siempre que el subsistema IO pueda hacer frente a ella.

Los índices adicionales ocuparán espacio, pero de nuevo, depende de qué columnas agregue. Si tiene 10^6 filas y agrega un índice no agrupado, ocupará 10^6 * 4 * 2. Eso es 10^6 para la columna indexada real, y 4 bytes adicionales para la clave principal también, para cada entrada de índice. Entonces, por cada millón de registros, un índice no agrupado en una columna int ocupará aproximadamente 8 MB.

Cuando la tabla crece, puede agregar servidores y realizar particiones horizontales en la tabla para distribuir los datos en varios servidores.

En cuanto al IO, que probablemente sea el obstáculo más grande, asegúrese de tener suficientes ejes para manejar la carga, preferentemente con los índices en su propio disco/LUN y los datos reales en su propio conjunto de discos/LUN.

Answer 4

Personalmente, me gustaría mantener absolutamente los registros de registro fuera de la base de datos principal. El rendimiento de su aplicación tendría un gran impacto al tener que escribir constantemente.

Creo que el camino a seguir es crear una base de datos secundaria en una máquina diferente, publicar una API de SOAP que sea irrelevante para el esquema de base de datos subyacente y hacer que la aplicación informe a eso. También sugeriría que la semántica de escritura quizás (no espere la respuesta de confirmación) podría hacer por usted, si puede arriesgarse a perder parte de esta información.

En la base de datos secundaria puede hacer que sus llamadas a la API desencadenen algún tipo de procedimiento de poda o desacoplamiento/copia de seguridad/recreación de la base de datos. Si necesita un registro, entonces no debe renunciar a la posibilidad de que sea útil en el futuro.

Si necesita algún tipo de servicio de análisis sobre eso, la mejor manera de hacerlo es SQL Server. De lo contrario, MySQL o PostGREs harán el trabajo mucho más barato.

Answer 5

Dijiste dos cosas que están en conflicto entre sí.

1. Quiero ser capaz de hacer todo tipo de datamining y la correlación entre las diferentes actividades de los usuarios y lo que han hecho.
2. Quiero asegurarme de que mi archivo db no siga creciendo.

También soy un gran admirador de la minería de datos, pero usted necesita datos para los míos. En mi opinión, cree un diseño de base de datos escalable y planifique para que crezca TENDEMENTE. Luego, ve a buscar todos los datos que puedas. Entonces, finalmente, podrás hacer toda la interesante minería de datos con la que estás soñando.