Tengo una tabla que tiene 1.300 millones de filas de ventas y la mayoría de las columnas están indexadas. Todavía me lleva mucho tiempo ejecutar un procedimiento o una vista incluso con condiciones. ¿Cómo resuelvo el problema?

Bienvenido al mundo de los grandes datos.

Si tiene 1.300 millones de elementos en cualquier tipo de base de datos, tendrá que resolver algún desafío de rendimiento.

Creo que probablemente deba repensar lo que está haciendo desde una perspectiva de “big data”. Big data es cualquier situación en la que el volumen de datos afecta el diseño del sistema.

Por ejemplo, en lugar de ejecutar una consulta en los 1.300 millones de filas, intente particionar lógicamente sus datos (p. Ej., Cree una tabla de resumen) para que pueda extraer la información que necesita sin reprocesar laboriosamente los datos cada vez.

Por ejemplo, tiene 1.300 millones de registros de ventas, intente resumirlos en otra tabla que contenga (digamos) 1 fila de resumen por día (o por producto por día o lo que sea) y luego use los datos de resumen para generar sus informes. Luego, puede actualizar periódicamente los datos de resumen con cualquier dato nuevo agregado a la tabla subyacente de 1.300 millones de filas.

El diseño exacto de sus datos de resumen dependerá de la naturaleza exacta de sus datos y de la información que está tratando de extraer de ellos.

Puede encontrar más información sobre este tema (Data Warehousing) aquí. Almacén de datos

Se me ocurren varias posibilidades:
1) estrategia de indexación
2) consultas eficientes
3) configuración de recursos
4) diseño de base de datos

Primero: tal vez se pueda mejorar su estrategia de indexación.

Aquí hay algunas pautas generales para considerarlas cuidadosamente: busque estos conceptos en Google para ver si se aplican a usted:

1) Definir una clave primaria (en la mayoría de los sistemas de bases de datos esto creará un índice)
2) Ponga índices en columnas usadas en uniones SQL.
3) Coloque índices en las columnas que se usan como condiciones en las cláusulas WHERE (pero si esto da como resultado la indexación de MUCHAS columnas, puede tener problemas de diseño de la base de datos).
4) Ponga índices en columnas que aparecen en GROUP BY o ORDER BY

Usted dijo, “la mayoría de las columnas están indexadas”. Es importante elegir con cuidado qué columnas se indexan y qué columnas incluir juntas en un índice.

Por ejemplo, considere una tabla CLIENTE con estas columnas:
cust_id, email, fname, lname, address_1, address_2, ciudad, estado, código postal, teléfono

Si sus consultas a menudo incluyen ciudad, estado, zip juntos en el mismo SQL, entonces sería mejor crear un índice único que incluya las tres columnas.

Pero si una consulta usa solo el zip, es posible que el índice no se use en absoluto. En ese caso, tiene sentido crear un índice solo para el zip.

Además, “la mayoría de las columnas están indexadas” me hace preguntarme si tiene muchos índices no utilizados en su tabla. Si tiene 100 columnas y la mayoría de ellas están indexadas, es una suposición razonable que la mayoría de los índices no son necesarios. Consulte su sistema de base de datos para obtener un recuento de uso de índice. Considere descartar índices no utilizados o raramente utilizados.

Segundo: consultas eficientes:
Tan importante como tener una buena estrategia de indexación: ¿se escriben sus consultas de manera eficiente? De nuevo, algunas pautas muy generales:
1) Identificar las consultas más lentas
2) examinar el plan de ejecución de la consulta para ver si se están utilizando los índices esperados; si no se están utilizando, consulte las pautas anteriores para ver por qué este podría ser el caso.
3) ¿Utiliza solo unas pocas sentencias SQL para satisfacer una gran cantidad de usos? A menudo encuentro que las VISTAS se usan de esta manera.

Y tercero: ¿tiene su plataforma suficientes recursos?
Ejecute diagnósticos para ver si su servidor de base de datos está vinculado a la CPU o a la E / S o para verificar otros problemas.

Finalmente – diseño de base de datos. Esto es el último en mi lista porque es el que consume más tiempo. Este es un gran tema que no exploraré aquí.

¿Has considerado dividir tu mesa?

Este es un tema complejo que requiere una revisión detallada caso por caso. Examine sus planes de consulta en detalle. Espero haberte dado suficiente material para comenzar tu investigación.

Quiero agradecer los consejos de los demás para pasar a otro sistema (he tenido mucho éxito con Vertica DB), pero creo que debería comenzar por analizar la eficacia de indexación y consulta para ver si hay margen para una mejora inmediata.

Puede intentar buscar DBMS orientado a columnas

Use una base de datos columnar. Uso Vertica o Redshift dependiendo de la cantidad de datos que finalmente necesito procesar con el tiempo y la complejidad de mi conjunto de datos. Redshift es el gran club para combinar conjuntos de datos gigantes. Vertica es la espada rápida para hacer cortes complejos en conjuntos de datos muy grandes. 1.300 millones es bastante pequeño para Redshift, y Vertica lo maneja fácilmente. En un clúster Vertica de tres nodos, puede agregar mil millones de filas en aproximadamente 12 segundos utilizando una herramienta de consulta ad-hoc ordinaria.

Teniendo en cuenta el bajo costo de alojar Vertica o Redshift en AWS, realmente no hay razón para pensar demasiado en el problema. Si necesita ayuda, pregúnteles a estos tipos (enchufe descarado) http://www.full360.com

1) Asegúrese de que las estadísticas / índices estén actualizados para la tabla.
2) Verifique el plan ‘EXPLICAR’ de su procedimiento.
3) Aborde el problema que es ser el cuello de botella.

La única forma posible de buscar un campo indexado (o campos) rápidamente es utilizar la base de datos de Teradata. ¡Fue hecho para VLDB (bases de datos muy grandes)! ¡He usado Teradata y busqué 4.400 millones de filas (para el CDC) y todavía obtengo menos de 1 segundo de tiempo de retorno !!! ¡¡¡Hay muy poco más, además de una pequeña normalización, o agrupar filas específicas en diferentes tablas, que se puede hacer para conjuntos de datos muy grandes !!!!!!!

intente muestreo aleatorio. ayuda estadística