Rendimiento MDX vs. T-SQL

Question

Tengo una base de datos que contiene tablas con más de 600 millones de registros y un conjunto de procedimientos almacenados que realizan operaciones de búsqueda complejas en la base de datos. El rendimiento de los procedimientos almacenados es muy lento incluso con índices adecuados en las tablas. El diseño de la base de datos es un diseño db relacional normal. Quiero cambiar el diseño de la base de datos para que sea multidimensional y use las consultas MDX en lugar de las consultas tradicionales de T-SQL, pero la pregunta es: ¿La consulta MDX es mejor que la consulta tradicional T-SQL con respecto al rendimiento? y, en caso afirmativo, ¿en qué medida mejorará el rendimiento de las consultas?

Gracias por cualquier ayuda.

Answer 1

Manzanas y naranjas: un servicio de análisis OLAP cubo es un tipo de almacenamiento fundamentalmente diferente que una base de datos SQL Server, y están diseñados para hacer cosas diferentes. Técnicamente, MDX no es "más rápido" que T-SQL, o viceversa, son solo idiomas, pero están diseñados para diferentes necesidades.

Habiendo dicho eso, un cubo es usualmente lo que funciona mejor para hacer numérico análisis de datos estáticos, como agregar un gran número de ventas/transacciones/cualquier registro a lo largo del tiempo. Por el contrario, una base de datos relacional tradicional generalmente funciona bien, si el esquema y los índices están bien construidos, para la búsqueda. Una forma sencilla de juez: si sus consultas SQL tienen que hacer un montón de

select grock, sum/min/max/avg(foo) 
from bar 
group by grock -- Ideal Analysis Services problem 

continuación, un cubo puede ayudar (que está diseñado para funciones matemáticas agregados - suma() y el grupo por). Otoh si sus consultas hacen un montón de

select cols 
from foo 
where <complicated search> -- Not so much 

entonces un cubo probablemente no va a ayudar, y me gustaría centrarse en afinar el esquema, las consultas y la indexación, y la partición quizá mesa si los datos se pueden dividir convenientemente.

¿Tiene un índice agrupado y cubre los índices no agrupados que coinciden con las consultas?

Answer 2

"El rendimiento de los procedimientos almacenados es tan lento incluso con índices adecuados"

Me sorprendería si el procedimiento almacenado es el verdadero problema, tal vez el camino se utilizan los procedimientos es lento, pero una procedimiento almacenado por definición no lo hace lento. ¿Has descubierto qué pasa con tus procedimientos es lento? ¿Los has perfilado? Miraría profundamente esa ruta antes de rediseñar mi base de datos. Las bases de datos multidimensionales son para OLAP ¿su base de datos es estrictamente una base de datos OLAP o es un híbrido de OLAP y OLTP? ¿Quizás necesites desregularizar y replicar los datos en tu diseño OLTP en la estructura desnormalizada d? 600 millones de registros en una tabla no es de ninguna manera enorme, no es pequeño, pero eso no me lleva a creer que abandonar procedimientos almacenados mágicamente hará las cosas más rápido. Perfile sus procesos almacenados y vea dónde están los cuellos de botella de rendimiento antes de saltar a un proyecto más grande para solucionar el problema.

Answer 3

cubo MS SSAS OLAP se puede utilizar en varios modos de almacenamiento:

1. Relacional (OLAP) - los datos y metadatos se queda en su base de datos y unos cuantos más se materializó se añaden puntos de vista. Puede o no ser más rápido.

2. Híbrido (HOLAP): las agregaciones de metadatos y (precalculadas) se almacenan en un nuevo servidor que ejecuta una instancia de SSAS. Esto debería acelerar todas las consultas utilizando agregaciones, como "horas totales de empleado para el último año por mes", pero las consultas que se redireccionan a registros específicos pueden ser como antes.

3. OLAP multidimensional (MOLAP) donde todos sus datos más metadatos y agregaciones se copian en el servidor SSAS. Este suele ser el más rápido, pero duplica el almacenamiento.

Antes de comenzar este, se debe considerar que la optimización de diseño de la tabla de informes y análisis, en otras palabras, utilizan un almacén de datos (DW) - introduzca sus datos en una dimensión estrella Kimball y tablas de hechos. A continuación, cargue el DW utilizando ETL (SSIS) periódicamente y apunte sus informes y análisis al DW. Puede ser que no necesite usar SSAS en absoluto: las consultas SQL que se ejecutan en una disposición de tabla en estrella suelen ser considerablemente más rápidas que en una base de datos operacional DB. Si esto es demasiado lento, construya cubos de SSAS encima del DW. Una vez que comience a cargar su DW, es posible que pueda eliminar registros de su base de datos operativa, haciéndolo más rápido para su uso diario.

En resumen, mi regla general sería:
1. Cree un DW y establezca su proceso de ETL
2. Pruebe los informes de T-SQL contra el DW, puede ser suficiente.
3. Si aún es lento, construya cubos SSAS (en la parte superior del DW) en modo HOLAP y use MDX para consultarlos.

Answer 4

¿Has considerado PowerPivot (el complemento de Excel)? Utiliza compresión vertical para comprimir datos en un 95%, localmente, para que pueda analizar el contenido de su corazón.

http://technet.microsoft.com/en-us/library/ee210692.aspx