¿Cuál es una buena forma de estructurar una tabla de registros de 100M para consultas rápidas ad-hoc?

Question

El escenario es bastante simple, hay aproximadamente 100M de registros en una tabla con 10 columnas (tipo de datos analíticos), y necesito poder realizar consultas en cualquier combinación de esas 10 columnas. Por ejemplo, algo como esto:

• ¿Cuántos registros con a = 3 && b > 100 hay en los últimos 3 meses?

Básicamente todas las consultas van a ser una especie de el número de registros con atributos X hay en intervalo de tiempo Y, donde X puede ser cualquier combinación de las 10 columnas.

Los datos seguirán llegando, no es solo un conjunto predeterminado de registros de 100M, sino que está creciendo con el tiempo.

Dado que la selección de columna puede ser completamente aleatoria, la creación de índices para combinaciones populares probablemente no sea posible.

La pregunta tiene dos partes:

• ¿Cómo debo estructurar esto en una base de datos SQL para realizar las consultas lo más rápido posible, y cuáles son algunos pasos generales que pueda tomar para mejorar el rendimiento?
• ¿Hay algún tipo de base de datos NoSQL que esté optimizado para este tipo de búsqueda? Solo puedo pensar en ElasticSearch, pero no creo que funcione muy bien en este gran conjunto de datos.

Answer 1

debe construir un cubo SSAS y utilizar MDX para consultarlo.

El cubo tiene "agregaciones" que significa que los resultados se calculan por adelantado.Dependiendo de cómo configure su cubo (y sus agregaciones), puede tener un atributo SUMA (A por ejemplo) en un grupo de medida y cada vez que pregunte al cubo cuántos registros tiene A, simplemente leerá la agregación en lugar de leer toda la tabla y calcularla.

Answer 2

Sin índices, sus opciones para sintonizar un RDBMS para admitir este tipo de procesamiento son muy limitadas. Básicamente se necesita un paralelismo masivo y un kit súper rápido. Pero es evidente que no está almacenando datos reales, por lo que un RDBMS no encaja.

Siguiendo la ruta paralela, el estándar de la industria es Hadoop. Aún puede usar consultas de estilo SQL a través del Hive.

Otra opción noSQL sería considerar una base de datos en columnas. Estas son una forma alternativa de organizar datos para análisis sin usar cubos. Son buenos para cargar datos rápidamente. Vectorwise es el último jugador en la arena. No lo he usado personalmente, pero alguien en la reunión de LondonData anoche me estaba entusiasmando al respecto. Check it out.

Por supuesto, alejarse de las bases de datos SQL, en cualquier dirección que vaya, incurrirá en una curva de aprendizaje abrupta.

Answer 3

Por lo que respecta a Oracle esto probablemente estaría estructurado como una tabla de particiones de intervalo con índices de mapa de bits locales en cada columna que podría consultar y nuevos datos agregados a través de una inserción de ruta directa o intercambio de partición.

Las consultas para combinaciones populares de columnas podrían optimizarse con un conjunto de vistas materializadas, posiblemente mediante consultas de acumulación o de cubo.

Answer 4

para que estas consultas se ejecuten rápidamente utilizando soluciones SQL, use estas reglas básicas. Sin embargo, hay muchas advertencias con esto, y el motor de SQL real que está utilizando será muy relevante para la solución.

Supongo que sus datos son enteros, fechas o escaladores cortos. cadenas largas, etc. cambian el juego. También asumo que solo está utilizando comparaciones fijas (=, <,>, <>, etc.)

a) Si el intervalo de tiempo Y estará presente en cada consulta, asegúrese de que esté indexado, a menos que el predicado Y está seleccionando un gran porcentaje de filas. Asegúrese de que las filas estén almacenadas en orden "Y", de modo que se empacan en el disco junto a la otra. Esto sucederá naturalmente de todos modos con el tiempo para nuevos datos. Si el predicado Y es muy ajustado (es decir, pocas cientos de filas), entonces esto podría ser todo lo que necesita hacer.

b) ¿Estás haciendo un "select " o "select count ()"? Si no es "select *", entonces la partición vertical PUEDE ayudar dependiendo del motor y otros índices presentes.

c) Cree índices de columnas individuales para cada columna donde los valores se distribuyan ampliamente y no tengan demasiados duplicados. El índice YEAR_OF_BIRTH generalmente estaría bien, pero indexar FEMALE_OR_MALE a menudo no es bueno, aunque esto es altamente específico para el motor de la base de datos.

d) Si tiene columnas como FEMALE_OR_MALE y "predicados Y" son anchas, tiene un problema diferente: seleccionar el recuento del número de hembras de la mayoría de las filas será difícil. Puedes intentar indexar, pero depende del motor.

e) Intente hacer que las columnas sean "NOT NULL" si es posible, generalmente guarda 1 bit por fila y puede simplificar el funcionamiento interno del optimizador.

f) Actualizaciones/inserciones. La creación de índices a menudo perjudica el rendimiento de inserción, pero si su tasa es lo suficientemente baja, puede no importar. Con solo 100M filas, asumiré que su tasa de inserción es razonablemente baja.

g) Las claves de varios segmentos ayudarían, pero ya has dicho que no se van.

h) Obtener discos de alta velocidad (RPM) - el problema para este tipo de consultas es por lo general IO (puntos de referencia TPC-H están a punto IO, y que están sonando como un problema de "H")

Hay Hay muchas más opciones, pero depende de cuánto esfuerzo quieras gastar "para hacer las consultas lo más rápido posible". Hay muchas opciones de No-SQL y otras para resolver esto, pero dejaré esa parte de la pregunta a otros.

Answer 5

Además de las sugerencias anteriores, considere consultar una vista materializada actualizada. Creo que solo crearía una vista materializada de seleccionar, contar (*) por cubo() en la tabla.

Esto le dará un cubo completo para trabajar. Juega con esto en una pequeña mesa de pruebas para tener una idea de cómo funcionan los acumuladores de cubos. Consulte los libros de Joe Celko para ver algunos ejemplos o simplemente consulte su documentación RDBMS específica para obtener ejemplos.

Usted está un poco atascado si siempre tiene que poder consultar los datos de hasta el microsegundo en su tabla. Pero si puede relajar ese requisito, encontrará que un cubo de vista materializada es una opción bastante decente.

¿Está absolutamente seguro de que sus usuarios llegarán a las 10 columnas de manera uniforme? Me he acosado con la optimización prematura en el pasado para este tipo de situación, solo para encontrar que los usuarios realmente usaron una o dos columnas para la mayoría de sus informes y que rodar hasta esas uno o dos colunmns era 'lo suficientemente bueno'.

Answer 6

Si no puede crear un cubo OLAP a partir de los datos, puede crear una tabla de resumen basada en las combinaciones únicas de X e Y. Si el período Y es de una gran granularidad suficiente, su tabla de resumen podría ser razonablemente pequeño. Obviamente depende de los datos.

Además, debe capturar las consultas que ejecutan los usuarios. En general, los usuarios dicen que quieren todas las combinaciones posibles, cuando en la práctica esto rara vez sucede y la mayoría de las consultas de los usuarios pueden satisfacerse con los resultados precalculados. La tabla de resumen sería una opción aquí otra vez, obtendrá cierta latencia de datos con esta opción, pero podría funcionar.

Si es posible, otras opciones serían mirar el hardware. He tenido buenos resultados en el pasado con unidades de estado sólido como Fusion-IO. Esto puede reducir el tiempo de consulta masivamente. Esto no es un reemplazo para un buen diseño, pero con un buen diseño y el hardware adecuado funciona bien.