Recabamos por diferentes foros para así tener para ti la respuesta para tu problema, en caso de alguna inquietud déjanos tu duda y contestaremos porque estamos para ayudarte.
Solución:
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 realizar una búsqueda O (1) en una base de datos de varios TB. Sin embargo, esto no es específico de Cassandra db, también puede usarlo con otras bases de datos.
Teoría
- Comparta sus datos. No hay forma de que un solo servidor retenga de manera confiable y realista tal volumen de datos.
- Esté preparado para fallas de hardware y fallas de nodos completos, duplique los datos.
- Empiece a utilizar muchos servidores back-end desde el principio.
- Utilice muchos servidores básicos más baratos, en comparación con los de alto rendimiento de gama alta.
- Asegúrese de que los datos se distribuyan por igual en los fragmentos.
- Dedique mucho tiempo a planificar sus consultas. Derive la API de las consultas y luego diseñe cuidadosamente las tablas. Ésta es la tarea más importante y prolongada.
- En Cassandra, puede diseñar una columna compuesta key y obtén acceso a eso key en O (1). Dedique tiempo a trabajar en ellos. Esto se utilizará para acceder a registros de búsqueda en lugar de un índice secundario.
- Utilice filas anchas. Son útiles para almacenar eventos con marca de tiempo.
- Nunca realice un escaneo completo o, de hecho, cualquier operación que supere O (Log N) en dicho volumen. Si necesita algo más que O (Log N), descargue dichas operaciones a los algoritmos Map-Reduce.
Práctica
- No pierda tiempo creando imágenes de SO o instalando servidores en máquinas físicas. Utilice proveedores basados en la nube para la creación rápida de prototipos. Trabajé con Amazon EC2 y puedo recomendarlo por su simplicidad, confiabilidad y velocidad de creación de prototipos.
- Las máquinas con Windows tienden a ser más lentas durante el tiempo de arranque y consumen considerablemente más recursos cuando están en estado inactivo. Considere utilizar un sistema operativo basado en Unix. Personalmente, encontré que el servidor Ubuntu es un sistema operativo confiable, pero además hay una comunidad bastante buena en askubuntu
- Piense en la creación de redes, lo ideal es que los nodos estén cerca unos de otros para permitir un rápido intercambio de cotilleos y metadatos.
- No entre en casos extremos: filas de columnas realmente anchas o familias de columnas (tablas) excepcionalmente largas. El mejor rendimiento se logra en los límites cuerdos, si db admite tantos norte filas por diseño, no significa que funcione bien.
- Nuestra búsqueda toma alrededor de 3-5 segundos, mucho se debe a los nodos intermedios entre la interfaz de usuario y la base de datos. Considere cómo acercar las solicitudes a la base de datos.
- Utilice un equilibrador de carga de red. Elija uno establecido. Usamos HAProxy, que es simple, pero muy rápido. Nunca tuve problemas con eso.
- Prefiera la simplicidad a las soluciones complejas.
- Busque soluciones gratuitas de código abierto, a menos que esté respaldado por el presupuesto de tamaño de una corporación. Una vez que utiliza más de varios servidores, los costos de infraestructura pueden subir por las nubes.
No trabajo para Amazon y no tengo relaciones con los equipos de HAProxy y Ubuntu. Esta es una opinión personal más que cualquier tipo de promoción.
Si fuera a poner esto en SQL Server, sugeriría una tabla como:
CREATE TABLE tcp_traffic
(
tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
, tcp_flags smallint /* at most 9 bits in TCP, so use SMALLINT */
, src_as int /* Since there are less than 2 billion A.S.'s possible, use INT */
, netxhop bigint /* use a big integer for the IP address instead of storing
it as dotted-decimal */
, unix_secs bigint
, src_mask int /* an assumption */
, tos tinyint /* values are 0-255, see RFC 791 */
, prot tinyint /* values are 0-255, see RFC 790 */
, input int /* an assumption */
, doctets int /* an assumption */
, engine_type int /* an assumption */
, exaddr bigint /* use a big integer for the IP address instead of storing
it as dotted-decimal */
, engine_id int /* an assumption */
, srcaddr bigint /* use a big integer for the IP address instead of storing
it as dotted-decimal */
, dst_as int /* Since there are less than 2 billion A.S.'s possible, use INT */
, unix_nsecs bigint /* an assumption */
, sysuptime bigint /* an assumption */
, dst_mask int /* an assumption */
, dstport smallint /* ports can be in the range of 0 - 32767 */
, [last] bigint /* an assumption */
, srcport smallint /* ports can be in the range of 0 - 32767 */
, dpkts int /* an assumption */
, output int /* an assumption */
, dstaddr bigint /* use a big integer for the IP address instead of storing
it as dotted-decimal */
, [first] bigint /* an assumption */
);
Esto da como resultado un requisito de almacenamiento estimado total para la tabla única, sin índices adicionales de 5,5 TB para los registros de 43,2 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 que se generan por segundo, necesitará una tasa de E / S mínima de 34 IOps, garantizada todos y cada uno de los segundos. Aunque esto en sí mismo no es una gran cantidad, otras E / S en el sistema (SQL Server y otros) nunca deben infringir 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 más IOps sostenibles para garantizar el rendimiento.
Notará que no estoy almacenando las direcciones IP en su forma decimal con puntos. 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 sea mucho, mucho más eficiente. La desventaja aquí es que necesita convertir las direcciones IP decimales con puntos en enteros de 8 bytes antes de almacenarlas y volver a las direcciones IP decimales con puntos para su visualización. El código para hacerlo es trivial, sin embargo, su tasa 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 un tema totalmente independiente, ya que no ha enumerado ningún requisito específico. El diseño de esta tabla almacenará filas de flujo en el orden físico en que las recibe SQL Server, el tcp_traffic_id El campo es único para cada registro y permite clasificar las filas por el orden en que se registraron (en este caso, lo más probable es que se relacione uno a uno con la hora del evento de flujo).
Recomendaría HBase. Puede almacenar todos los datos sin procesar en una o más tablas HBase, según lo que necesite consultar. HBase puede manejar grandes conjuntos de datos y realiza fragmentación automática a través de divisiones de regiones.
Además, si diseña una fila keys bueno, puede obtener consultas extremadamente rápido, incluso O (1). Tenga en cuenta que si está recuperando un gran conjunto de datos, seguirá siendo lento, ya que la recuperación de datos es una operación O (n).
Dado que desea realizar consultas en cada campo, le recomendaría crear una tabla única para cada uno de ellos. Por ejemplo, para los datos src_address, tenga una tabla que se vea así:
1.2.3.4_timestamp1 : data
1.2.3.4_timestamp2 : data
Entonces, si desea consultar todos los datos en 1.2.3.4 a partir del 27 de marzo a las 12:00 a. M. Al 27 de marzo a las 12:01 a. M., Puede hacer un escaneo de rango con las filas de inicio y parada especificadas.
En mi humilde opinión, la fila key El diseño 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.