Comment gérer de grandes quantités de données pour un module de statistiques Web

Question

Je développe pour mon site Web un module de statistiques qui m'aidera à mesurer les taux de conversion et d'autres données intéressantes.

Le mécanisme que j'utilise consiste à - stocker une entrée de base de données dans un tableau de statistiques - chaque fois qu'un utilisateur entre une zone spécifique dans ma base de données (j'évite les doublons à l'aide de cookies).

Par exemple, j'ai les zones suivantes:

1. Site Web - Zone générale utilisée pour compter les utilisateurs uniques car j'ai récemment cessé de faire confiance à Google Analytics.
2. Catégorie - auto-descriptif.
3. Minisite - auto-descriptif.
4. Image du produit - chaque fois que l'utilisateur voit un produit et le formulaire de soumission de prospects.

Le problème, c'est qu'après un mois, mon tableau de statistiques contient beaucoup de lignes et les pages ASP.NET que j'ai écrites pour analyser le chargement de données vraiment .

Je pensais peut-être écrire un service qui analyserait les données, mais je ne vois aucun moyen de le faire sans perdre en flexibilité.

Mes questions:

1. Comment les applications d'analyse de données à grande échelle, telles que Google Analytics, chargent-elles les données si rapidement?
2. Quel est le meilleur moyen pour moi de le faire?
3. Peut-être que ma conception de base de données est fausse et que je devrais stocker les données dans une seule table?

Merci à tous ceux qui aident,

Eytan.

Answer 1

L'approche de base que vous recherchez s'appelle agrégation .

Vous êtes intéressé par certaines fonctions calculées sur vos données et au lieu de calculer les données " en ligne " lors du démarrage du site Web à afficher, vous les calculez hors ligne, soit via un traitement par lots dans la nuit, soit de manière incrémentielle lors de la rédaction de l'enregistrement du journal.

Une amélioration simple consisterait à stocker des comptes par utilisateur / session, au lieu de stocker et de comptabiliser chaque hit. Cela réduirait vos exigences en matière de traitement analytique d'un facteur dans l'ordre des hits par session. Bien sûr, cela augmenterait les coûts de traitement lors de l’insertion d’entrées de journal.

Un autre type d'agrégation s'appelle le traitement analytique en ligne , qui regroupe uniquement certaines dimensions de vos données et permet aux utilisateurs d'agréger les autres dimensions dans un mode de navigation. Ceci est un compromis entre performance, stockage et flexibilité.

Answer 2

Il semble que vous puissiez bien faire en utilisant deux bases de données. L'une concerne les données transactionnelles et gère toutes les instructions INSERT. L'autre est pour les rapports et gère toutes vos requêtes.

Vous pouvez indexer le snot en dehors de la base de données de rapports et / ou dénormaliser les données afin que moins de jointures soient utilisées dans les requêtes. Exportez régulièrement les données de la base de données de transactions vers la base de données de rapports. Cette loi améliorera le temps de réponse des rapports ainsi que les idées de regroupement mentionnées précédemment.

Answer 3

Une autre astuce à connaître est le partitionnement . Cherchez comment cela se fait dans la base de données de votre choix - mais l’idée est de dire à votre base de garder une table partitionnée en plusieurs sous-tables, chacune avec une définition identique, basée sur une valeur.

Dans votre cas, ce qui est très utile, c'est " range partitioning " - choisir la partition en fonction d'une plage dans laquelle une valeur se situe. Si vous partitionnez par plage de dates, vous pouvez créer des sous-tables distinctes pour chaque semaine (ou chaque jour ou chaque mois - dépend de la façon dont vous utilisez vos données et de leur quantité).

Cela signifie que si vous spécifiez une plage de dates lorsque vous émettez une requête, les données situées en dehors de cette plage ne seront même pas prises en compte. cela peut entraîner des gains de temps considérables, voire supérieurs à ceux d’un index (un index doit prendre en compte chaque ligne, il augmentera donc avec vos données; une partition est une par jour).

Cela accélère beaucoup plus les requêtes en ligne (celles qui sont émises lorsque vous cliquez sur votre page ASP) et les requêtes d'agrégation que vous utilisez pour précalculer les statistiques nécessaires.