Estamos buscando desarrollar una herramienta para capturar y analizar datos de flujo de red, de los cuales reunimos enormes cantidades de. Cada día capturamos alrededor de ~ 1.400 millones de registros de flujo que se verían así en formato json:
{
"tcp_flags": "0",
"src_as": "54321",
"nexthop": "1.2.3.4",
"unix_secs": "1352234521",
"src_mask": "23",
"tos": "0",
"prot": "6",
"input": "105",
"doctets": "186",
"engine_type": "0",
"exaddr": "2.3.4.5",
"engine_id": "2",
"srcaddr": "9.8.7.6",
"dst_as": "12345",
"unix_nsecs": "752265174",
"sysuptime": "2943529544",
"dst_mask": "24",
"dstport": "80",
"last": "2943523241",
"srcport": "52672",
"dpkts": "4",
"output": "111",
"dstaddr": "6.5.4.3",
"first": "2943517993"
}
Nos gustaría poder realizar búsquedas rápidas (menos de 10 segundos) en el conjunto de datos, muy probablemente en intervalos de tiempo estrechos (intervalos de 10 a 30 minutos). También queremos indexar la mayoría de los puntos de datos para poder hacer búsquedas en cada uno de ellos rápidamente. También nos gustaría tener una vista actualizada de los datos cuando se ejecutan las búsquedas. Sería genial permanecer en el mundo del código abierto, pero no nos oponemos a buscar soluciones patentadas para este proyecto.
La idea es mantener aproximadamente un mes de datos, que serían ~ 43.2 mil millones de registros. Una estimación aproximada de que cada registro contendría aproximadamente 480 bytes de datos equivaldría a ~ 18.7 terabytes de datos en un mes, y tal vez tres veces más que con los índices. Finalmente, nos gustaría aumentar la capacidad de este sistema para almacenar billones de registros.
Hemos evaluado (muy básicamente) couchbase, cassandra y mongodb en la medida de lo posible como candidatos para este proyecto, sin embargo, cada uno propone sus propios desafíos. Con couchbase, la indexación se realiza a intervalos y no durante la inserción de los datos, por lo que las vistas no están actualizadas, los índices secundarios de cassandra no son muy eficientes para devolver resultados, ya que generalmente requieren escanear todo el clúster en busca de resultados, y mongodb parece prometedor, pero parece ser mucho más difícil de escalar ya que es maestro / esclavo / fragmentado. Algunos otros candidatos que planeamos evaluar son elasticsearch, mysql (no estoy seguro de si esto es aplicable) y algunas bases de datos relacionales orientadas a columnas. Cualquier sugerencia o experiencia del mundo real sería apreciada.
Respuestas:
En una empresa para la que trabajo, estamos tratando con una cantidad similar de datos (alrededor de 10 TB de datos de búsqueda en tiempo real). Resolvemos esto con Cassandra y me gustaría mencionar un par de ideas que le permitirán hacer una búsqueda O (1) en una base de datos de múltiples TB. Sin embargo, esto no es específico de Cassandra db, también puede usarlo con otros db.
Teoría
Práctica
No trabajo para Amazon y no tengo relaciones con los equipos HAProxy y Ubuntu. Esta es una opinión personal en lugar de cualquier tipo de promoción.
fuente
O(1) search <=> unbounded storage space <=> unlimited supply of cash
Si fuera a poner esto en SQL Server, sugeriría una tabla similar a:
Esto da como resultado un requisito de almacenamiento total estimado para la tabla individual, sin índices adicionales de 5.5 TB para 43.2 registros de beeellion (su requisito especificado). Esto se calcula como 130 bytes para los datos en sí, más 7 bytes por fila de sobrecarga, más 96 bytes por página de sobrecarga. SQL Server almacena datos en páginas de 8 KB, lo que permite 59 filas por página. Esto equivale a 732,203,390 páginas para un solo mes de datos.
A SQL Server le gusta escribir en el disco en fragmentos de 8 páginas (64 KB), lo que equivale a 472 filas por E / S física. Con 16,203 registros de flujo generados por segundo, necesitará una tasa de E / S mínima de 34 IOps, garantizada cada segundo. Aunque esto por sí solo no es una gran cantidad, otras E / S en el sistema (SQL Server y otros) no deben infringir nunca esta tasa necesaria de IOps. Por lo tanto, necesitaría diseñar un sistema capaz de al menos un orden de magnitud más IOps, o 340 IOps sostenidas. Tendería a estimar que necesita 2 órdenes de magnitud de IOps más sostenibles para garantizar el rendimiento.
Notará que no estoy almacenando las direcciones IP en su forma decimal punteada. Esto ahorra una gran cantidad de almacenamiento (7 bytes por dirección), y también hace que la indexación, recuperación, clasificación y comparación de direcciones IP sean mucho, mucho más eficientes. La desventaja aquí es que necesita convertir las IP decimales punteadas en enteros de 8 bytes antes de almacenarlas, y volver a las IP decimales punteadas para su visualización. El código para hacerlo es trivial, sin embargo, su velocidad de fila esto agregará una cantidad sustancial de sobrecarga de procesamiento a cada fila de flujo que se procesa; es posible que desee realizar este proceso de conversión en una máquina físicamente diferente de SQL Server.
Discutir los índices que necesita es una cuestión totalmente diferente, ya que no ha enumerado ningún requisito específico. El diseño de esta tabla almacenará las filas de flujo en el orden físico en que las recibe SQL Server, el
tcp_traffic_id
campo es único para cada registro y permite ordenar las filas por el orden en que se registraron (en este caso, lo más probable es que se relacionen uno a uno a la hora del evento de flujo).fuente
binary(4)
obinary(16)
, respectivamente. 4 bytes / fila agrega mucho almacenamiento cuando se multiplica por 1,000,000,000,000.SMALLINT
pero también tiene que haber una rutina de conversión.Yo recomendaría HBase . Puede almacenar todos los datos sin procesar en una o más tablas de HBase, según lo que necesite consultar. HBase puede manejar grandes conjuntos de datos y se auto-fragmenta a través de divisiones de región.
Además, si diseña bien las teclas de fila, puede obtener consultas extremadamente rápidas, incluso O (1). Tenga en cuenta que si está recuperando un conjunto de datos grande, eso seguirá siendo lento ya que recuperar datos es una operación O (n).
Como desea consultar en cada campo, le recomendaría crear una tabla única para cada uno de ellos. Ejemplo para los datos de src_address, tenga una tabla que se vea así:
Entonces, si desea consultar todos los datos en 1.2.3.4 a partir del 27 de marzo a las 12:00 a.m. hasta el 27 de marzo a las 12:01 a.m., puede hacer un escaneo de rango con las filas de inicio y detención especificadas.
En mi humilde opinión, el diseño de la clave de fila es la parte más crítica del uso de HBase: si lo diseña bien, podrá realizar consultas rápidas Y almacenar grandes volúmenes de datos.
fuente
Dijo esto :
Sugiero considerar IBM Informix base de datos + TimeSeries DataBlade. Frente a lo que dicen algunas personas, Informix está vivo y va muy bien. La última versión se lanzó el mes pasado (marzo / 2013, versión 12.10).
TimeSeries es como un "complemento" (sin costo) capaz de manejar situaciones como la suya.
Y puede usarlo en producción con la versión gratuita de la base de datos Informix ( edición Innovator-C ). (por supuesto, solo para evaluar las partes técnicas ya que la versión gratuita tiene muchos recursos limitados)
Aquí puede consultar un PDF de referencia que se puede utilizar como referencia. Aquí dos presentaciones con más ejemplos técnicos: guía de maniquíes y otros consejos.
No tengo experiencia personal con TimeSeries , por lo que no puedo aceptar que sea "la solución", solo una sugerencia para evaluar.
fuente
Secundo la recomendación de mirar Informix TimeSeries. La literatura de IBM afirma que TimeSeries puede almacenar este tipo de información en 1/5 del espacio y funcionar 5 veces más rápido que las tablas relacionales tradicionales.
Beneficios adicionales serían la Interfaz de tabla virtual que puede hacer que los datos de TimeSeries aparezcan como tablas relacionales tradicionales para el usuario final (simplificando el desarrollo de la aplicación y al mismo tiempo obteniendo los beneficios de TimeSeries), HA simple con nodos HDR que ahora admiten datos de TimeSeries en la versión 12.1 y el integración de datos de TimeSeries en Informix Warehouse Accelerator que puede usarse para acelerar informes complicados de almacenamiento de datos y la capacidad de crear prototipos de una solución TimeSeries en Informix utilizando las ediciones gratuitas Informix Developer o Innovator-C.
fuente