¿Cómo debo almacenar cantidades muy grandes de datos de tráfico para facilitar su recuperación?

Question

para un sistema de contabilidad del tráfico que necesito para almacenar grandes cantidades de datos acerca de los paquetes de Internet enviados a través de nuestra puerta de enlace (que contiene fecha y hora, ID de usuario, destino o de origen IP, el número de bytes, etc.).

Estos datos tiene que ser almacenado durante algún tiempo, al menos unos días. Fácil recuperación debería ser posible también.

¿Qué es una buena manera de hacer esto? Ya tengo algunas ideas:

• Crear un archivo para cada usuario y cada día y anexar datos a la misma.

  • Ventaja:. Es probable que sea muy rápido, y los datos es fácil de encontrar dado una estructura de ficheros compatibles
  • Desventaja: No es fácilmente posible ver, por ejemplo, todo el tráfico UDP de todos los usuarios.

• Usar una base de datos

  • Ventaja: Es muy fácil encontrar datos específicos con la consulta SQL derecha.
  • Desventaja:. No estoy seguro de si hay un motor de base de datos que puede manejar de manera eficiente una mesa con posiblemente cientos de millones de conjuntos de datos

• Tal vez sea posible combinar los dos enfoques: El uso de un archivo de base de datos SQLite para cada usuario.

  • Ventaja: Sería fácil obtener información de un usuario utilizando consultas SQL en su archivo.
  • Desventaja:. Obtención de información global seguiría siendo difícil

Pero tal vez alguien tiene una muy buena idea?

Muchas gracias de antemano.

Answer 1

En primer lugar, obtener El kit de herramientas de almacenamiento de datos antes de hacer nada.

Usted está haciendo un trabajo de almacenamiento de datos, es necesario abordarlo como un almacenamiento de datos de trabajo. Tendrá que leer sobre los patrones de diseño adecuados para este tipo de cosas.

[Nota de almacenamiento de datos hace grande loco no significa ni costosas o complejas. Significa esquema de estrella y formas inteligentes para manejar grandes volúmenes de datos que nunca se actualizan.]

1. bases de datos SQL son lentos, pero que lento es bueno para la recuperación flexible.

2. El sistema de archivos es rápida. Es una cosa terrible para la actualización, pero no se está actualizando, sólo está acumulando.

Un enfoque típico DW para esto es que hacer esto.

1. Definir el "Esquema de estrella" para sus datos. Los hechos medibles y los atributos ( "dimensiones") de esos hechos. Su efecto parece ser # de bytes. Todo lo demás (dirección, fecha y hora, ID de usuario, etc.) es una dimensión de ese hecho.

2. Construir los datos dimensionales en una base de datos dimensión maestra. Es relativamente pequeños (direcciones IP, los usuarios, una dimensión de fecha, etc.) Cada dimensión se tienen todos los atributos es posible que cada vez que desee saber. Esto crece, la gente siempre están añadiendo atributos de dimensiones.

3. Crear un proceso de "carga" que lleva sus registros, resuelve las dimensiones (horarios, direcciones, usuarios, etc.) y se funde en las claves de dimensión de las medidas (número de bytes). Esto puede actualizar la dimensión de añadir un nuevo usuario o una nueva dirección. En general, usted está leyendo filas de datos, haciendo operaciones de búsqueda y escribir filas de datos que tienen todas las FK adecuada de asociados con ellos.

4. Guardar estos archivos de carga en el disco. Estos archivos no se actualizan. Ellos simplemente se acumulan. Utilizar una notación simple, como CSV, por lo que puede fácilmente carga masiva ellos.

Cuando alguien quiere hacer el análisis, ellos construir una despensa de datos.

En la dirección o el tiempo de trama IP seleccionada o lo que sea, obtener todos los datos relevantes, además de la dimensión asociada de datos maestros y de carga a granel de una despensa de datos.

Se puede hacer todas las consultas SQL que desee en este centro comercial. La mayor parte de las consultas recaerá a SELECT COUNT(*) y SELECT SUM(*) con varios GROUP BY y cláusulas HAVING y WHERE.

Answer 2

Creo que la respuesta correcta en realidad depende de la definición de un "conjunto de datos". Como se menciona en su pregunta que está almacenando conjuntos individuales de información para cada registro; fecha y hora, ID de usuario, IP de destino, IP de origen, número de bytes etc ..

SQL Server es perfectamente capaz de entregar este tipo de almacenamiento de datos con cientos de millones de registros sin ninguna dificultad real. Por supuesto este tipo de registro va a requerir un poco de hardware bueno para manejarlo, pero no debe ser demasiado compleja.

Cualquier otra solución, en mi opinión va a hacer muy difícil la presentación de informes, y de los sonidos de la misma que es un requisito importante.

Answer 3

Por lo que se encuentran en uno de los casos donde se tiene más más actividad de escritura de lectura, quiere que su escritura no bloquearte, y quiere que su dice ser "razonablemente rápido", pero no crítico. Es un caso típico de uso de la inteligencia empresarial.

que es mejor usar una base de datos y almacenar los datos en un esquema de "desnormalizado" para evitar inserciones complejas combinaciones y múltiples para cada registro. Piense en su mesa como un archivo de registro enorme.

En este caso, algunos de los "nuevos y de lujo" bases de datos NoSQL son probablemente lo que estás buscando: proporcionan restricciones ACID relajado, lo que no se debe terriblemente cuenta aquí (en caso de accidente, se puede perder el último líneas de su registro), pero llevar a cabo mucho mejor para la inserción, ya que no tienen que revistas de sincronización en el disco en cada transacción.