Compartir a través de


SQL Server 2012: Mejor inteligencia de negocios

Arquitecturas de referencia preconfigurado darle un plan probado para configurar SQL Server para administrar cargas de trabajo de business intelligence.

Stephen Strong

Mal rendimiento de las consultas es la pesadilla de cualquier transacción en línea (OLTP) sistema de procesamiento. Usted podría buscar para mejorar el rendimiento del hardware, pero la mejor forma de solucionar esto es optimizar las consultas.

Podría lograr esto cambiando la estrategia de índice, para cambiar el código o, más drásticamente, cambiar el esquema del tabla. La razón de que esto funciona es que OLTP normalmente tiene una carga de trabajo predecible. Usted sabe lo que viene desde los servidores de aplicaciones y puede diseñar el sistema para atender a los.

Este enfoque rara vez funciona, sin embargo, para cargas de trabajo de almacén de datos especialmente como aumenta de tamaño y simultaneidad de base de datos. Foros de la comunidad están llenas de DBAs buscando ayuda tratar mal realizar, consultas de almacén de datos complejos.

Aunque puede haber muchos comúnmente ejecutar informes en una carga de trabajo de negocios típico intelligence (BI), es a menudo una mezcla de consultas ad hoc, procedentes de varias otras herramientas. Estos son impredecibles y difícil influir. Los usuarios también regularmente modificar sus consultas, a menudo a través de una herramienta de BI, como que perforación los datos para extraer el valor para el negocio. Intentar optimizar estas consultas puede sentirse como una batalla perdida.

Los administradores de TI, reaccionando de frustración, a menudo intentan resolver este problema por arrojar hardware al problema. Se podrá comprar un servidor de gama alta y conéctelo a la más grande empresa de almacenamiento pueden permitirse dentro de su presupuesto. Si usted quiere perder credibilidad con su comunidad de negocios, seguir este camino. Este enfoque raramente tiene éxito y es sin duda una opción costosa para aplicar una vez que el factor en los costos de licencia.

Microsoft se ha asociado con un número de proveedores de hardware muy respetado para encender este problema en su cabeza. Las empresas que plantean las preguntas: "¿Qué pasaría si aceptamos que los usuarios a menudo analizan tablas de hechos grandes y realizan consultas complejas de Group By? ¿Qué pasaría si todos los componentes de una solución fueron capaces de funcionar a toda velocidad y no estar congestionado por otro componente? ¿Cómo sería ese?"

Tomar la vía rápida

Introduzca el almacén de datos de Fast Track (vía rápida DW) para SQL Server. Desde 2005, Microsoft ha estado invirtiendo fuertemente en la optimización de SQL Server para cargas de trabajo de BI. En 2009, Microsoft lanzó su primera arquitectura de referencia de Fast Track para almacenes de datos. Hoy en día existen nuevas arquitecturas de referencia emergentes que aprovechan las nuevas características en SQL Server 2012.

DW Fast Track no es un producto. Es una serie de configuraciones bien diseñadas, probadas de hardware y software diseñado específicamente para abordar este problema. No hay ningún hardware especial y sin software mágico. Todo está construido sobre los componentes de los productos básicos, como Windows Server y SQL Server.

Probablemente ya tienes muchos de estos componentes operan dentro de su entorno. Lo que falta es ese cambio de mentalidad operativa lejos de evitar el análisis de datos de gran tamaño. Fast Track DW alienta abiertamente ese comportamiento, tanto por lo que depende realmente en él para su rendimiento ultrarrápido.

Si nunca has hecho cualquier prueba de funcionamiento de hardware, rápidamente llegó a la conclusión de que la mayoría de los sistemas como lecturas secuenciales. Si usted analiza la mayoría de las cargas de trabajo BI, verá normalmente consisten en lecturas secuenciales de 80 a 90 por ciento. ¿Qué pasaría si usted diseña su sistema para atender sólo a lecturas secuenciales? ¿Qué pasaría si sus componentes: CPU, memoria, bus PCI, host bus adapters (HBAs), red, almacenamiento, SQL Server y archivos de base de datos — fueron diseñados para esto así?

Puede haber problemas, sin embargo. ¿Qué sucede si tiene discos lentos o no suficiente memoria RAM o los HBAs no puede mantenerse al día con los discos, o un bus PCI se satura? Peor aún, como quitar un cuello de botella, añadiendo más memoria o actualización de los discos de 10.000 a 15.000 RPM, otro cuello de botella pronto aparecerá.

Un escenario típico podría pasar algo como esto: Un DBA pide el equipo de infraestructura más memoria RAM en un servidor SQL Server. Agregar el RAM resuelve el primer problema, pero sólo aumenta la performance en un 3 por ciento. Inmediatamente después de agregar la memoria RAM, se revela un cuello de botella en el subsistema de disco. Cuando a continuación pide el dueño del negocio para una gran parte del dinero, ¿cómo calificaría sus posibilidades de obtener financiación adicional?

Para superar esto, ingenieros de hardware y software han desarrollado una serie de sistemas balanceados que puede dar servicio a los almacenes de datos de diferentes tamaños. Sistemas de nivel de entrada desde 5 TB, mientras que los sistemas de mayor tamaño pueden dar servicio a casi 100 TB las bases de datos. Para almacenes de datos de cientos de terabytes, Microsoft y sus socios de hardware han montado un producto empaquetado llamado el Paralelo Data Warehouse.

Muchos equipos de infraestructura podrían construir un sistema equilibrado como este, sin embargo, rara vez tienen tiempo para investigar y combinar componentes para lograr el máximo rendimiento posible. Si usted tiene 20 TB de almacenamiento en discos de 600 GB, por ejemplo, debe determinar cuántos HBAs necesitará sobre cuántos puertos de switch a dos procesadores de ocho núcleos unidad al 100 por ciento. También tienes plan tales problemas de capacidad como muchos procesadores de almacenamiento que se necesita para lograr 6 GB por segundo de rendimiento sostenido.

Aunque muchos equipos de infraestructura consideren y plan para estas cuestiones, sistemas balanceados rara vez convertirla en un entorno de producción. La arquitectura de referencia saca todas las conjeturas.

Problemas de implementación de infraestructura son reconocidos por causando retrasos en los proyectos. Fast Track DW está diseñado para mejorar el tiempo de aplicar métricas. Cada arquitectura de referencia viene con una lista de piezas de hardware de productos básicos predefinidos. Rápidamente puede convertir esto en una lista de materiales para enviar a su proveedor de hardware.

Porque los proveedores de hardware participaron en la elaboración de estas arquitecturas de referencia, deben tomar menos tiempo realmente cumplir la orden. Ya no necesita ir hacia adelante y hacia atrás con su proveedor de la lista de pedidos. No hay más discusiones sobre el uso de un procesador de 2,4 GHz o un procesador de 2,5 GHz, Fibre Channel o iSCSI — la especificación está predefinida.

Cuando el hardware llega en sitio, los chicos de infraestructura no es necesario discutir cómo implementar la mejor solución, ya claramente se articula en la arquitectura de referencia. Estos datos incluyen colocación de disco físico, cableado, software y las versiones del controlador, firmware, configuración del almacenamiento, profundidades de cola HBA, configuración de SQL Server y ubicación del archivo de base de datos incluso.

Operador rápido

Fast Track DW opera sobre el concepto de tasa máxima de núcleo (MCR). Esto describe el número máximo de megabytes por segundo, que el núcleo del procesador puede consumir dentro de la CPU. Procesadores de múltiples núcleos de hoy pueden consumir 300 MB a 400 MB de datos por segundo por núcleo. Por ejemplo, en un servidor con dos zócalos de CPU y ocho núcleos por CPU, se traduce en aproximadamente 6 GB por segundo. Para, usted tendrá cuatro HBAs de doble puerto capaces de un rendimiento total máximo sostenido de 6,4 GB por segundo. Cada arreglo de discos de almacenamiento subyacente contiene cuatro conjuntos de discos físicos en una configuración RAID 10, que puede generar 1,6 GB por segundo para un total de 6,4 GB por segundo.

Arquitecturas de referencia de Fast Track suele especificar 10Gbit iSCSI o 8Gbit Fibre Channel para la red de almacenamiento en un interruptor dedicado. A diferencia de un entorno típico de SAN — donde el almacenamiento es compartido con múltiples cargas de trabajo como servidores de archivos, servidores de base de datos y hosts de máquina virtual — todo el almacenamiento de información está dedicado al servidor Fast Track.

Nada se deja al azar. En muchas arquitecturas de referencia, trazados LUN se asignan a HBAs, puertos de switch, procesadores de almacenamiento y sistemas de disco físico. Esto reduce la contención que puede ocurrir cuando dejas tráfico de E/S de un disco conjunto compartir una ruta con tráfico de E/S de la otra. Ningún componente se debe a inundar el canal de otro componente. Todo debe ser capaz de ejecutar en paralelo a la velocidad máxima.

Crear y configurar su propia solución de almacén de datos de alto rendimiento en el hardware más reciente sería una tarea significativa. Para crear una compilación repetible, equipos de infraestructura a menudo pasan horas trolling a través de guías de instalación, blogs y foros de la comunidad con el fin de crear los scripts complejos requeridos.

Las arquitecturas de referencia son más que listas de piezas y algunas estadísticas de rendimiento. Aunque hay algunas variaciones entre los proveedores de hardware, arquitecturas de referencia también incluir secuencias de comandos para configurar el hardware. Si el pensamiento de todos los componentes de montaje parece un poco desalentador, hay algunos proveedores que tienen programas para enviar todo lo atormentado y premontado.

Mejoras de índice

SQL Server 2012 introduce a un nuevo tipo de índice llamado un ColumnStore. ColumnStores son todos sobre el rendimiento y mejorar el precio del cociente del funcionamiento. Cada fila de datos se procesa en una consulta no ColumnStore. Con ColumnStore, usted puede tener filas de proceso de SQL Server en lotes. No sólo son los datos de una columna en varias filas almacenados en una página de datos único, pero también puede hacer que se procesan en lotes. De los datos está fuertemente comprimidos. Esto resulta ser aproximadamente en una proporción de 7-1.

ColumnStore ofrece mucho mejor rendimiento porque la CPU de carga se reduce durante la ejecución de consultas. Procesamiento requiere menos E/S y la memoria RAM, que se adecua perfectamente a la arquitectura de DW de Fast Track. Índices de ColumnStore proporcionan una mejora de rendimiento de 10 a 100 veces masiva sobre índices normales basados en la fila.

Tenga en cuenta que no todas las consultas pueden aprovechar de los índices de ColumnStore. Recientes pruebas de rendimiento han demostrado un promedio general mejora en el rendimiento de dos tiempos es más razonable a través de una carga de trabajo mixto. Aún así, un aumento de rendimiento de 100 por ciento para relativamente poco esfuerzo es sin duda vale la pena. ¿Qué es la captura? No se pueden actualizar índices de ColumnStore. Pero la mayoría de las aplicaciones de almacén de datos puede hacer frente con esta limitación durante la su extracción, transformación y carga de proceso.

Nuevas arquitecturas de referencia también están empezando a soporte de alta disponibilidad para DW de Fast Track. Como BI se vuelve más crítica para el negocio, esto es, sin duda, buenas noticias. Arquitecturas de referencia disponibles utilizan actualmente la tecnología de clústeres de conmutación por error de servidor de Windows siempre confiable, que ha sido utilizada en los círculos OLTP durante más de una década.

Un beneficio clave del uso de arquitecturas de referencia de Fast Track es que usan regular software como Windows Server y SQL Server. Esto es útil para administradores de sistemas, administradores y personal de apoyo. Aunque los desarrolladores deben empezar a pensar en adoptar un enfoque de índice-luz, regular T-SQL seguirá funcionando en Fast Track. Porque el Fast Track es una arquitectura de referencia y no un producto empaquetado, gestión de parches también es sencillo. Simplemente, puede agregar el servidor a su proceso de administración de revisiones regulares.

Integración de Fast Track

Porque Fast Track se basa en SQL Server 2012, se integra bien en la mayoría de las arquitecturas de BI. Sistemas de fuente pueden alimentar el DW de Fast Track a través de un servidor dedicado de integración de servidor de SQL o un almacén de datos operacionales. Puede exponer datos a través de almacenes de datos departamentales construidas sobre SQL Server Analysis Services o tienen sus herramientas de BI acceso acelerado directamente.

Existe una tendencia creciente para dar a los usuarios acceso a portales de datos con paneles y PowerPivot o PowerView con SharePoint. SQL Server Reporting Services puede exponer informes estructurados a través de cubos de análisis services. Los usuarios pueden crear informes ad hoc en Report Builder o utilizar PowerPivot para Excel. Con estas opciones y mejoras de rendimiento, es fácil ver cómo una plataforma escalable como Fast Track DW para SQL Server 2012 puede convertirse en un componente esencial de su estrategia de BI.

Stephen Strong

Stephen Strong tiene más de 25 años de experiencia con sistemas de base de datos, desde la arquitectura de aplicación y DBA mentoring para diseño y arquitectura de la infraestructura. En los últimos nueve años, trabajando en conjunto con Microsoft Services, ha sido instrumental en el diseño arquitectónico y el apoyo de algunas de las implementaciones de SQL Server del australiano más grandes y complejas.

Contenido relacionado