Cómo manejar grandes cantidades de datos para un módulo de estadísticas web

Question

Estoy desarrollando un módulo de estadísticas para mi sitio web que me ayudará a medir las tasas de conversión y otros datos interesantes.

El mecanismo que uso es, para almacenar una entrada de la base de datos en una tabla de estadísticas, cada vez que un usuario ingresa a una zona específica en mi base de datos (evito duplicar registros con la ayuda de cookies).

Por ejemplo, tengo las siguientes zonas:

1. Sitio web: una zona general utilizada para contar usuarios únicos, ya que últimamente dejé de confiar en Google Analytics.
2. Categoría - autodescriptiva.
3. Minisite - autodescriptivo.
4. Imagen del producto: cada vez que el usuario ve un producto y el formulario de envío de clientes potenciales.

El problema es después de un mes, mi tabla de estadísticas está llena de muchas filas, y las páginas ASP.NET que escribí para analizar la carga de datos realmente son lentas.

Pensé que tal vez escribir un servicio que de alguna manera analizara los datos, pero no veo ninguna forma de hacerlo sin perder flexibilidad.

Mis preguntas:

1. ¿Cómo las aplicaciones de análisis de datos a gran escala, como Google Analytics, cargan los datos tan rápido?
2. ¿Cuál es la mejor manera de hacerlo?
3. ¿Quizás mi diseño de base de datos es incorrecto y debo almacenar los datos en una sola tabla?

Gracias por cualquiera que ayude,

Eytan.

Answer 1

El enfoque básico que está buscando se llama agregación .

Está interesado en ciertas funciones calculadas sobre sus datos y en lugar de calcular los datos " en línea " al iniciar el sitio web de visualización, los calcula fuera de línea, ya sea a través de un proceso por lotes en la noche o de forma incremental cuando se escribe el registro de registro.

Una mejora simple sería almacenar conteos por usuario / sesión, en lugar de almacenar cada golpe y contarlos. Eso reduciría sus requisitos de procesamiento analítico por un factor en el orden de los hits por sesión. Por supuesto, aumentaría los costos de procesamiento al insertar entradas de registro.

Otro tipo de agregación se llama procesamiento analítico en línea , que solo se agrega a lo largo de algunas dimensiones de sus datos y permite a los usuarios agregar las otras dimensiones en un modo de navegación. Esto compensa el rendimiento, el almacenamiento y la flexibilidad.

Answer 2

Parece que podrías hacerlo bien usando dos bases de datos. Uno es para datos transaccionales y maneja todas las declaraciones INSERT. El otro es para informar y maneja todas sus solicitudes de consulta.

Puede indexar los mocos de la base de datos de informes y / o desnormalizar los datos para que se usen menos uniones en las consultas. Periódicamente exporte datos de la base de datos de transacciones a la base de datos de informes. Este acto mejorará el tiempo de respuesta de los informes junto con las ideas de agregación mencionadas anteriormente.

Answer 3

Otro truco para saber es particionamiento . Busque cómo se hace en la base de datos que elija, pero básicamente la idea es que le diga a su base de datos que mantenga una tabla particionada en varias subtablas, cada una con una definición idéntica, basada en algún valor.

En su caso, lo que es muy útil es & "; particionamiento de rango &"; - elegir la partición en función de un rango en el que cae un valor. Si particiona por rango de fechas, puede crear sub-tablas separadas para cada semana (o cada día, o cada mes, depende de cómo use sus datos y de la cantidad de datos que haya).

Esto significa que si especifica un rango de fechas cuando emite una consulta, los datos que están fuera de ese rango ni siquiera serán considerados; eso puede conducir a un ahorro de tiempo muy significativo, incluso mejor que un índice (un índice debe considerar cada fila, por lo que crecerá con sus datos; una partición es una por día).

Esto hace que las consultas en línea (las que se emiten cuando accede a su página ASP) y las consultas de agregación que utiliza para calcular previamente las estadísticas necesarias, sean mucho más rápidas.