Recientemente, probamos el enfoque que llamamos QDM cuando trabajamos con grandes cantidades de datos: cientos de gigabytes. Como parte de la tarea, procesamos entre 12 y 24 millones de registros y comparamos el rendimiento de la solución de quinteto con una funcionalidad similar en las tablas comunes.
No hicimos ningún descubrimiento nuevo, pero confirmamos las hipótesis que expresamos anteriormente: cuánto pierde el diseñador universal en manos de la "tetera" condicional en una base de datos configurada profesionalmente.
Ahora también sabemos qué hacer en tal situación: la solución es bastante simple y confiable, y tenemos experiencia en la organización de una solución de compromiso para datos arbitrariamente grandes.
Durante el desarrollo del sistema de conciliación de informes, necesitábamos descargar los datos de uno de los formularios de informes, que contienen hasta 24 millones de registros en cada fecha de informe. Debe haber datos para 7 años de cálculos diarios. Francos, francamente, no para un diseñador universal, sino para un sistema altamente especializado, pero ya nos involucramos en esta empresa y tuvimos que buscar una solución.
Los usuarios trabajan con este gran conjunto de datos solo dentro de una fecha de informe, por lo tanto, en el sistema de referencia, todo esto se almacena en una tabla dividida en esta fecha. Los índices para los 26 campos de datos restantes no se utilizan para este formulario.
Lo primero que hicimos, por supuesto, fue crear la estructura de datos deseada en el constructor y cargar varias fechas allí. La descarga de una de las fechas más pequeñas lleva aproximadamente 14 horas, lo que es inaceptablemente largo: 12.5 millones de registros con 27 atributos, colocados en medio billón de registros de 5 campos con la construcción de tres índices, dos de los cuales son compuestos.
La cantidad total de estos datos en el disco es un poco más de 18 GB.
Vale la pena señalar dos características de este formulario:
- Casi no se presta a la normalización, en contraste, por ejemplo, del Formulario 110, discutido en una publicación anterior
- No utiliza índices en los atributos de los registros: es más rentable para el usuario esperar un minuto que gastar dinero en índices
Este puede ser el caso más radical que puede elegir para comparar. En la mayoría de los casos, la diferencia en el volumen de datos QDM y la base de datos habitual no es tan dramática, ni siquiera bastante pequeña .
A modo de comparación, los mismos datos cargados en una tabla normal en una base de datos relacional toman 2,3 GB (8 veces menos) junto con el índice por fecha, y su descarga tarda menos de media hora (28 veces más rápido). En ambos casos, los datos se insertaron directamente desde el archivo en porciones de 100 mil registros, sin desactivar los índices.
Teniendo en cuenta que no es práctico utilizar un constructor para tales volúmenes de datos, sin embargo, realizamos pruebas de rendimiento: para diferentes casos, comparamos el procesamiento masivo de registros con el constructor y nuestra tabla no indexada. Necesitábamos determinar el límite de la cantidad de datos para los que en adelante utilizaremos una tabla regular, y no nuestro constructor.
Como esperábamos, trabajar con pequeños conjuntos de datos, por ejemplo, en una cuenta o cliente por separado, en el diseñador se ve bastante cómodo (tiempo de respuesta en un segundo), en contraste con una tabla sin índices, donde debe esperar unos minutos para responder. Al mismo tiempo, la tarea principal de la aplicación (muestreo masivo y agregación de datos en varias secciones) puede llevar varias veces más tiempo en el diseñador.
A continuación se presentan los resultados resumidos de las muestras que hicimos para un volumen creciente de datos agregados:
Donde fue posible, realizamos varias mediciones, después de seleccionar estadísticas y seleccionar el número de registros por la máscara de número de cuenta.
La tabla y el gráfico a continuación muestran que la agregación de un conjunto completo de datos en un día lleva mucho menos tiempo que tomar muestras de más del 5% de los datos utilizando el índice. Es por eso que los optimizadores de consultas RDBMS ignoran el índice en tal situación, mientras que el motor de nuestro servicio en este momento está privado de tal oportunidad.
Visualización gráfica de los mismos resultados utilizando una escala logarítmica para comparar números de diferentes órdenes:
La velocidad del diseñador al procesar un conjunto de datos completo es casi un orden de magnitud menor que la de una tabla normal, lo cual es bastante normal para el diseñador; es importante evitar una degradación del rendimiento similar a una avalancha, y este objetivo se ha logrado.
El estudio mostró que el número de registros en la base de datos prácticamente no tiene ningún efecto sobre la velocidad de creación de páginas, navegación y pequeñas muestras en un modelo de datos de quinteto. Con la cantidad de datos procesados de hasta 10,000 registros (y esta es la selección máxima de datos relacionados para una instancia de cualquier entidad comercial en el sistema de información), puede trabajar cómodamente con una base de datos de cientos de gigabytes o más.
A continuación, enseñamos a nuestro complemento de tabla (descrito aquí ) a llamar a un conector a una base de datos arbitraria para que funcione de manera transparente tanto con el modelo de datos de quinteto como con las tablas tradicionales.
Desde el punto de vista del usuario, no le importa con qué fuente de datos trabaja mientras puede hacer el trabajo importante para él en la interfaz familiar, recibiendo sus informes:
Ahora sacaremos las tablas enormes similares restantes, que en nuestra base de datos son solo dos docenas de cientos, en un almacenamiento separado para trabajar con ellas cómodamente.
Por lo tanto, podemos usar el constructor para tablas pequeñas y medianas que requieren una búsqueda y agregación intensivas por atributos arbitrarios, y almacenar grandes objetos no indexados en tablas tradicionales planas, llamarlos desde almacenamiento de terceros o bases de datos especializadas (Hadoop y otros NoSQL).
El diseñador es el más adecuado para sistemas CRM y productos similares, donde el usuario trabaja con un solo cliente, cuenta u otra entidad, y las funciones analíticas se trasladan a un almacenamiento especializado separado.