Almacenamiento de datos de SQL Server 2012 y diferentes versiones


8

Con Sql Server 2012 hay 3 ediciones principales: Enterprise Edition, Business Intelligence, Standard.

La comparación completa entre los tres: http://www.microsoft.com/sqlserver/en/us/future-editions/sql2012-editions.aspx

La edición de inteligencia empresarial implica que su propósito es el almacenamiento de datos y cubre lo que parece ser una preocupación clave para eso:

  • Autoservicio Business Intelligence (Alertas, Power View, PowerPivot para SharePoint Server)
  • BI corporativo avanzado (modelo semántico de BI tabular, análisis e informes avanzados, motor en memoria VertiPaq ™)
  • Integración de datos avanzada (agrupación y búsqueda difusas, cambio de captura de datos, minería de datos avanzada)
  • Gestión de datos empresariales (servicios de calidad de datos, servicios de datos maestros)

Sin embargo, la edición empresarial es la única versión que tiene:

Almacenamiento de datos (índice ColumnStore, compresión, particionamiento)

¿Qué funcionalidad implica esto que se separa entre las ediciones BI y Enterprise?


Esta información es válida para SQL Server 2014, con una adición notable (en mi humilde opinión): 2014 EE incluye controladores Attunity para SSIS, que se supone que aumentan drásticamente el rendimiento con las bases de datos Oracle. Además, en 2014, el límite de memoria para las ediciones Standard y BI aumentó a 128 GB.
Jon of All Trades

Respuestas:


18

Edición de Business Intelligence

La edición Business Intelligence tiene algunas características útiles, como Master Data Services y agregaciones no aditivas (es decir, cualquier cosa menos suma / recuento). EE tiene particiones y el resto de las características de bases de datos grandes. Las características de EE son principalmente relevantes para usuarios con grandes volúmenes de datos. Si tiene menos de (digamos) 100 GB de datos, probablemente pueda sobrevivir con la edición de BI. La edición de BI también tiene un límite en la cantidad de núcleos de CPU y memoria que puede usar el servidor de la base de datos, aunque esto no parece aplicarse a Analysis Services o Reporting Services.

Aquí puede encontrar un desglose más detallado de las características de SE, BI y EE .

Algunas cosas que estarán bien con la edición de BI

  • La mayoría de las aplicaciones OLAP: la edición BI parece brindarle los agregados inteligentes (último no vacío, etc.) y otras características que SE no tiene en el servidor OLAP. Por el aspecto del enlace, todas las características de SSAS presentes en EE están presentes en la edición de BI, lo que lo hace un poco más un competidor para los data marts.

  • Aplicaciones MDM: la edición BI viene con Master Data Services.

  • Volúmenes de datos moderados. Probablemente pueda salirse con (digamos) 100GB más o menos en BIE aplicando fuerza bruta a nivel de hardware (discos rápidos).

  • La edición de BI admite vistas particionadas distribuidas, lo que le brinda una capacidad básica de fragmentación de solo lectura. Sin embargo, el hardware y las licencias adicionales pueden no ser más baratos que morder la bala y obtener EE.

  • SSRS parece ser el mismo en las ediciones de BI y Enterprise.

  • Los límites de memoria y núcleo de la CPU no se aplican a los servidores SSAS y SSRS.

Algunas cosas que necesitará Enterprise Edition para

  • Si tiene requisitos de cumplimiento para datos físicamente seguros, entonces las instalaciones de encriptación y auditoría de EE pueden ser deseables. Tenga en cuenta que esto es nuevo en 2012.

  • El particionamiento de tablas es una característica única de EE. Si desea utilizar particiones de tabla para administrar grandes volúmenes de datos, necesitará EE.

  • Las transformaciones de unión en estrella solo son compatibles con EE. Si tiene una aplicación con muchas consultas altamente selectivas (<1% de cobertura) en una tabla de hechos muy grande, puede obtener una ganancia de las transformaciones en estrella. Sin embargo, esta característica no está realmente bien documentada en los círculos de SQL Server, por lo que es difícil saber qué tan bien funciona en la práctica.

  • Índice de almacén de columnas: si desea utilizar esto para aplicaciones ROLAP rápidas (utilizando el generador de informes o una herramienta ROLAP de terceros, como Business Objects), puede obtener un kilometraje significativo de esta función en EE.

  • La compresión de tablas puede ser útil para archivar datos antiguos.

  • La edición BI solo admite servidores de cierto tamaño: 64 GB de RAM, 4 sockets o 16 núcleos para el servidor de la base de datos. Si desea escalar por encima de una máquina de dos sockets, probablemente necesite EE.

  • La edición de BI solo se otorga bajo la licencia 'Servidor + CAL'.

  • Las compilaciones paralelas de DBCC e índice solo son compatibles con EE. Si desea descartar y volver a crear índices para cargas ETL, esto puede reducir sus tiempos de ejecución, particularmente en cargas incrementales en grandes conjuntos de datos existentes.

  • EE tiene una función de reescritura de consultas (llamada 'uso automático de la vista indizada por el optimizador de consultas'). Si desea utilizar estos para aumentar el rendimiento de ROLAP, puede que desee EE. Sin embargo, aunque esta es una característica bastante madura en Oracle, realmente no puedo dar fe de lo bien que funciona en SQL Server en la práctica, aunque SQL Server tiene un operador CUBE en GROUP BY, que está principalmente destinado a esta aplicación.

  • EE tiene adaptadores rápidos de Oracle y Teradata para SSIS, y adaptadores para varias otras fuentes 'empresariales' como SAP BW.

  • Algunas de las características MDM-ish de SSIS, por ejemplo, búsquedas difusas, solo están disponibles en EE.

  • Change Data Capture es una característica exclusiva de Enterprise Edition.


+1 ... Gracias por la información. Entonces, esencialmente para una tienda con enormes cantidades de datos, ejecutaría EE para el ODS y luego separaría las instancias de BI para el análisis. ¿Es una aplicación justa para tomar de su información?
swasheck

1
Dependiendo del tamaño de los data marts, es posible que también necesite EE para esos. Los índices del almacén de columnas no harán nada para acelerar su ETL, solo son buenos para consultas rápidas. Yo diría que la edición de BI sería buena para volúmenes de datos más pequeños en lugar de mercados de datos en un sistema de depósito más grande, a menos que los mercados de datos estuvieran muy agregados. En la práctica, una vez que se está preparando para EE, entonces el ahorro de costos de la edición de BI para los mercados de datos podría ser un poco menor.
Preocupado por

1
@swascheck - Encontré un desglose más detallado aquí
ConcernedOfTunbridgeWells

1
@swascheck: BI Edition admite cubos SSAS particionados, por lo que podría ser más útil para los data marts de lo sugerido anteriormente.
Preocupado por

debes amar estas cosas o ser extremadamente útil. Quizás sea ambas / y. De cualquier manera, muchas gracias.
swasheck

5

"Business Intelligence" cubre todo, desde el diseño de la base de datos hasta el monke de Excel.

Basado en esto, mi interpretación de la nueva edición de BI es características "más geniales" en el lado OLAP / cubo / análisis / minería en comparación con el lado RDBMS.

Podría decirse que solo el "almacén de columnas" es realmente relevante para BI. El particionamiento en sí puede ser solo la edición Enterprise, pero ALTER TABLE..SWITCH se puede ejecutar en la edición Standard.

La edición de BI tampoco tiene límite de uso de memoria para SSAS y SSRS


1
¿Podría dar más detalles sobre la tienda de columnas? Especialmente en la línea de por qué me lo perdería en la versión de BI, ¿podría esa característica por sí sola ser motivo para justificar el uso de la empresa?
Chris Marisic

55
El índice del almacén de columnas implementa una estructura de datos de 'columna' que almacena datos en un formato más compacto y es mucho más rápido consultar una sola columna que una exploración de tabla en una tabla que contiene esa columna. Esencialmente, una estructura de datos de almacén de columnas era el truco principal de Sybase IQ, y IIRC, la estructura de datos nativa utilizada por SSAS para conservar los datos es un formato de tipo de almacén de columnas.
Preocupado por
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.