Comment dois-je stocker des quantités extrêmement importantes de données de trafic pour les retrouver facilement?

Question

pour un système de comptabilité de trafic que je dois stocker de grandes quantités de jeux de données sur les paquets Internet envoyés par notre routeur de passerelle (contenant horodatage, ID utilisateur, IP de destination ou la source, le nombre d'octets, etc.).

Ces données doivent être stockées pendant un certain temps, au moins quelques jours. Récupération facile devrait être possible aussi bien.

Qu'est-ce qu'une bonne façon de le faire? J'ai déjà quelques idées:

• Créez un fichier pour chaque utilisateur et chaque jour et ajoutez ensemble de données à lui.

  • Avantage: Il est probablement très rapide, et des données est facile à trouver donné une mise en page de fichier cohérent
  .
  • Inconvénient: Il est pas facilement possible de voir, par exemple tout le trafic UDP de tous les utilisateurs.

• Utilisez une base de données

  • Avantage: Il est très facile de trouver des données spécifiques avec la bonne requête SQL.
  • Inconvénient:. Je ne sais pas s'il y a un moteur de base de données qui peut gérer efficacement une table avec peut-être des centaines de millions de jeux de données

• Peut-être qu'il est possible de combiner les deux approches: Utilisation d'un fichier de base de données SQLite pour chaque utilisateur.

  • Avantage: Il serait facile d'obtenir des informations pour un utilisateur en utilisant des requêtes SQL sur son dossier.
  • Inconvénient:. Obtenir des informations générales serait encore difficile

Mais peut-être que quelqu'un d'autre a une très bonne idée?

Merci beaucoup à l'avance.

Answer 1

D'abord, obtenir Data Warehouse Toolkit avant de faire quoi que ce soit.

Vous faites un travail d'entreposage de données, vous devez l'aborder comme un travail d'entreposage de données. Vous aurez besoin de lire sur les modèles de conception appropriés pour ce genre de chose.

[Note Data Warehouse ne signifie pas grand fou ou coûteux ou complexe. Cela signifie schéma en étoile et des moyens intelligents pour gérer des volumes de données qui n'a jamais mis à jour.]

1. bases de données SQL sont lents, mais lent est bon pour la récupération flexible.

2. Le système de fichiers est rapide. C'est une chose terrible pour la mise à jour, mais vous n'êtes pas mise à jour, vous êtes juste à accumuler.

Une approche DW typique est de le faire.

1. Définir le « schéma en étoile » pour vos données. Les faits mesurables et les attributs ( « dimensions ») de ces faits. Votre fait semble être # d'octets. Tout le reste (adresse, horodatage, nom d'utilisateur, etc.) est une dimension de ce fait.

2. Générer les données dimensionnelles dans une base de données de dimension principale. Il est relativement faible (adresses IP, les utilisateurs, une dimension de date, etc.) Chaque dimension aura tous les attributs que vous pourriez jamais vouloir savoir. Cela pousse, les gens sont toujours ajouter des attributs aux dimensions.

3. Créer un processus « de charge » qui prend vos journaux, résout les dimensions (fois, adresses, utilisateurs, etc.) et fusionne les clés de dimension avec les mesures (# d'octets). Cela peut mettre à jour la dimension d'ajouter un nouvel utilisateur ou une nouvelle adresse. En général, vous lisez les lignes de fait, faire des recherches et à écrire des lignes de fait qui ont toutes les années FK appropriée qui leur sont associés.

4. Enregistrer ces fichiers de charge sur le disque. Ces fichiers ne sont pas mis à jour. Ils accumulent juste. Utilisez une notation simple, comme CSV, de sorte que vous pouvez facilement en vrac les charger.

Quand quelqu'un veut faire une analyse, les construire un datamart.

Pour l'adresse IP sélectionnée ou période de temps ou autre, tous les faits pertinents, ainsi que les données de dimension maître associées et le chargement en masse d'un datamart.

Vous pouvez faire toutes les requêtes SQL que vous voulez sur ce marché. La plupart des requêtes déléguera à SELECT COUNT(*) et SELECT SUM(*) avec diverses clauses GROUP BY et HAVING et WHERE.

Answer 2

Je pense que la bonne réponse dépend vraiment de la définition d'un « ensemble de données ». Comme vous le mentionnez dans votre question que vous stockez des jeux individuels d'information pour chaque enregistrement; horodatage, code d'utilisateur, IP de destination, IP source, nombre d'octets etc ..

SQL Server est parfaitement capable de distribuer ce type de stockage de données avec des centaines de millions d'enregistrements sans aucune difficulté réelle. Certes ce type d'exploitation forestière va nécessiter un bon matériel pour le manipuler, mais il ne devrait pas être trop complexe.

Toute autre solution, à mon avis va faire des rapports très difficile, et des sons de celui-ci qui est une exigence importante.

Answer 3

Vous êtes dans l'un des cas où vous avez beaucoup plus d'activité d'écriture que lire, vous voulez que vos écritures de ne pas vous bloquer, et vous voulez que votre lit « raisonnablement rapide », mais pas critique. Il est une utilisation de l'intelligence d'affaires typique cas.

Vous devriez probablement utiliser une base de données et stocker vos données dans un schéma « dénormaliser » pour éviter jointures complexes et multiples inserts pour chaque enregistrement. Pensez à votre table comme un énorme fichier journal.

Dans ce cas, certaines des bases de données NoSQL « nouvelles et de fantaisie » sont probablement ce que vous cherchez: ils fournissent des contraintes ACID détendue, que vous devriez pas l'esprit terriblement ici (en cas d'accident, vous pouvez perdre le dernier lignes de votre journal), mais ils effectuent beaucoup mieux pour l'insertion, parce qu'ils ne doivent pas synchroniser des journaux sur le disque à chaque transaction.