¿Cómo debo almacenar cantidades extremadamente grandes de datos de tráfico para una fácil recuperación?

Question

para un sistema de contabilidad de tráfico Necesito almacenar grandes cantidades de conjuntos de datos sobre paquetes de internet enviados a través de nuestro enrutador de puerta de enlace (que contiene marca de tiempo, ID de usuario, IP de destino o de origen, cantidad de bytes, etc.).

Estos datos tienen que almacenarse durante un tiempo, al menos unos días. La recuperación fácil también debería ser posible.

¿Cuál es una buena manera de hacer esto? Ya tengo algunas ideas:

• Cree un archivo para cada usuario y día y anexe a él cada conjunto de datos.

  • Ventaja: Probablemente sea muy rápido, y los datos son fáciles de encontrar dado un diseño de archivo consistente.
  • Desventaja: no es fácil ver, p. todo el tráfico UDP de todos los usuarios.

• utiliza una base

  • 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 pueda manejar de manera eficiente una tabla con posiblemente cientos de millones de conjuntos de datos.

• Quizás sea posible combinar los dos enfoques: Usar un archivo de base de datos SQLite para cada usuario.

  • Ventaja: Sería fácil obtener información para un usuario que utiliza consultas SQL en su archivo.
  • Desventaja: Obtener información global aún sería difícil.

Pero tal vez alguien más tiene una muy buena idea?

Muchas gracias de antemano.

Answer 1

Creo que la respuesta correcta realmente depende de la definición de "conjunto de datos". Como mencionas en tu pregunta, estás almacenando conjuntos individuales de información para cada registro; timestamp, 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. De acuerdo, este tipo de registro requerirá un buen hardware para manejarlo, pero no debería ser demasiado complejo.

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

Answer 2

Primero, obtenga The Data Warehouse Toolkit antes de hacer cualquier cosa.

Usted está haciendo un trabajo de almacenamiento de datos, debe abordarlo como un trabajo de almacenamiento de datos. Deberá leer los patrones de diseño adecuados para este tipo de cosas.

[Nota Data Warehouse no significa loco, caro o complejo. Significa esquema de estrella y formas inteligentes para manejar grandes volúmenes de datos que nunca se actualiza.]

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

2. El sistema de archivos es rápido. Es algo terrible para actualizar, pero no estás actualizando, solo estás acumulando.

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

1. Defina el "Star Schema" para sus datos. Los hechos mensurables y los atributos ("dimensiones") de esos hechos. Su hecho parece ser # de bytes. Todo lo demás (dirección, marca de tiempo, identificación de usuario, etc.) es una dimensión de ese hecho.

2. Cree los datos dimensionales en una base de datos de dimensiones maestras. Es relativamente pequeño (direcciones IP, usuarios, una dimensión de fecha, etc.). Cada dimensión tendrá todos los atributos que quizás desee conocer. Esto crece, las personas siempre agregan atributos a las dimensiones.

3. Cree un proceso de "carga" que tome sus registros, resuelva las dimensiones (tiempos, direcciones, usuarios, etc.) y fusione las claves de dimensión con las medidas (n. ° de bytes). Esto puede actualizar la dimensión para agregar un nuevo usuario o una nueva dirección. En general, estás leyendo filas de hechos, haciendo búsquedas y escribiendo filas de hechos que tienen todas las FK apropiadas asociadas a ellas.

4. Guarde estos archivos de carga en el disco. Estos archivos no están actualizados. Simplemente se acumulan Use una notación simple, como CSV, para que pueda cargarlos de forma masiva.

Cuando alguien quiere hacer un análisis, compilar una datamart.

Para la dirección IP o el marco de tiempo seleccionados o lo que sea, obtenga todos los datos relevantes, además de los datos de la dimensión maestra asociados y la carga masiva de una datamart.

Puede hacer todas las consultas SQL que desee en este mercado. La mayoría de las consultas pasarán a SELECT COUNT(*) y SELECT SUM(*) con varias cláusulas GROUP BY y HAVING y WHERE.

Answer 3

Así que usted está en uno de los casos donde tiene mucho más actividad de escritura que lectura, desea que sus escrituras no le bloqueen, y quiere que sus lecturas sean "razonablemente rápidas" pero no críticas. Es un caso típico de uso de inteligencia empresarial.

Probablemente deberías utilizar una base de datos y almacenar tus datos como un esquema "desnormalizado" para evitar combinaciones complejas y varias inserciones para cada registro. Piensa en tu tabla como un gran archivo de registro.

En este caso, algunas de las "nuevas y lujosas" bases de datos NoSQL son probablemente lo que está buscando: proporcionan restricciones ACID relajadas, lo cual no debe tenerse en cuenta aquí (en caso de falla, puede perder el últimas líneas de su registro), pero funcionan mucho mejor para la inserción, ya que no tienen que sincronizar diarios en el disco en cada transacción.