Tablas Particionadas

12 07 2007

TablasParticionadas

¿Cuando está haciendo una consulta en su Data Warehouse el tiempo de respuesta es lento?¿Si se para enfrente del servidor puede ver las lucecitas de los discos duros encendidas a todo lo que dá y el % del procesador se vá al 100% o a niveles altos?¿sus usuarios se quejan?

Estos son sintomas de un grave problema, el DWH ha llegado al límite de su capacidad de acuerdo a como usted ha diseñado el almacenamiento de la información. Si está ustede en este punto, ¡PARTICIONE LAS TABLAS !

El concepto es muy sencillo, en vez almacenar una sola tabla gigantesca lo que se hace es guardarla en pedacitos (particiones); en cada pedacito guardaríamos los datos de un mes, un año o una sucursal. Así, cuando lancemos una consulta que busque los datos de Enero del 2004; la base de datos solo hará la busqueda de la información en la partición que corresponde a ese mes.

Scannin all the data tomado de ibm

Los pedacitos pueden guardarse por ejemplo en diferentes discos duros; de esta forma, puede usted por ejemplo guardar los datos más accesados de la tabla en discos duros rápidos y los datos históricos de años pasados que nadie utiliza en los discos más lentos.

Esto hace que las busquedas se eficienten brutalmente. Los accesos a disco no serán tantos y probablemente se pueda olvidar por un tiempo de comprar un servidor nuevo.

Esto muy importante y critico para las bases de datos y la mayoría lo soporta (les paso las ligas a las páginas donde dice como hacerlo): ORacle, DB2, Sybase, Redbrick (tengo los manuales)….

¿SQLServer de Microsoft? Esta característica viene solo en la versión 2005. Lo que viene en la ayuda de SQLServer 2000 como Vista Particionada es un vil truco sucio para emular la partición de tablas. Lo que no me acuerdo es que versión de SQLServer 2005 se requiere ¿la Enterprise super plus edition?

Esta es una de las características que más alto impacto pueden tener en el desempeño ( o si lo prefieren, performance) de un Data Warehouse pero que por una extraña razón nadie utiliza.

Para los cubos existe el mismo concepto y el mismo impacto. Ahí sí, los Analysis Services de Microsoft soportan cubos particionados de tiempo atrás.

Technorati tags: Data Warehouse,





No use campos CHAR en los descriptores

11 07 2007

En nuestro Data Warehouse debemos omitir el utilizar el tipo de dato CHAR en las tablas de catálogos que forman nuestra base de datos. Este tipo de dato rellena con espacios el contenido de la columna.

Cuando estamos consultando la información desde nuestro query, tablero de control, reporte o Excel notará que las columnas que tienen los nombres de los empleados, ciudades, estados, etc.; tienen muchos espacios a la derecha.

EspaciosEnBlanco

Las columnas se habren demasiado y se vé muy desagradable el reporte. Habrá que entonces manualmente ajustar el ancho de las columnas.

Technorati tags: Data Warehouse, ,





No utilice llaves compuestas

10 07 2007

Cuando esté diseñando las estrellas o copos de nieve que formarán su Data Warehouse evite utilizar llaves compuestas.

LlavesCompuestas  

Simpre use llaves simples. Las llaves compuestas hacen que el servidor trabaje más a la hora de hacer querys; así que modifique su modelo para evitar las llaves compuestas. Trate de que la llave generada sea del tipo entero.

LlavesCompuestasCopo

Los querys:

  • Serán más simples …debido a que no hay que hacer join por tantas columnas
  • Consumiran menos memoria y procesador…debido a que no hay que hacer join por tantas columnas
  • Ahorrarán un poco de espacio
  • Responderán más rápido.

Technorati tags: Data Warehouse,





Use llaves numéricas

9 07 2007

CB101333_LoRes

Esto reduce la cantidad de espacio que el DWH ocupa, aumenta la velocidad de respuesta y disminuye el % de procesador ocupado.

Hace unos años participamos en la construcción de un modelo donde se usó el código de barras como llave de la tabla de productos. Si agarran la lata de refresco que tienen sobre el escritorio verán que es un texto de 13 caracteres, así que el tipo de dato lo definimos char(13). Al insertar los millones de transacciones que se generaron en las tiendas, la tabla de hechos se infló; pero no solo la estrella si no cada uno de los índices y agregados que involucraban el código del producto. Así que teníamos una tabla de hechos gigantesca, índices gigantescos y agregados gigantescos de muchos gigas de información.

Solo piensen un momento el trabajo que le cuesta al procesador buscar la cadena ’7501071120091′ en cientos de gigas de información, esa columna lo mismo puede tener como contenido la palabra ‘Monterrey’ o mi nombre u otros códigos de barras.

El algoritmo que usan las bases de datos para textos es mucho más complicado que el que usa para los números ( donde solo tiene que averiguar si es el numero, es más pequeño o más grande ) y esto es el responsable que el mismo modelo en 2 servidores distintos, uno con las llaves varchar, char, text; y el otro con numeros, trabajarán de manera diferente. El que tiene llaves numéricas será más rapido u ocupará menos el procesador y la memoria del servidor.

“oye, pero es que las llaves que vienen del transaccional son caracteres: char o varchar…”

¡Pues inventa una! Definitivamente la carga de los catálogos por parte del ETL se complicará. Ahora tenemos que trarnos la llave original, ver cual es el número que le corresponde en el catálogo e insertarlo en la tabla de hechos. Algo que nos puede ayudar es en los catálogos tener siempre la llave original y la llave numérica generada por nosotros.

En resumen: si quieren que el tiempo de respuesta sea rápido con menos hardware use campos con el tipo de dato Entero en las tablas del data warehose en todas y cada una de las dimensiones.

PD. Por cierto, como recomendacion los campos numericos los pueden nombra con ID y los que originalmente vienen del transacciona como CVE, así tendríamos ProductoID y ProductoCVE.

Technorati tags: Data Warehouse, , , ,





Variaciones en los indicadores

6 07 2007

En Artus, cuando usamos la tabla dinámica como parte de nuestro tablero de control o cuadro de mando podemos para cada indicador activar la opción Variación. Esta es una opción visualmente agradable, sencilla y práctica que nos dice si nuestro indicador subió o bajó con respecto al periodo anterior o contra el año pasado.

Variacion

Cuando se activa esta propiedad Artus crea una columna donde con flechas hacía arriba o hacía abajo me indica la variación.

Si la tabla está mostrando un mes, entonces la variación es contra el mes pasado; si un día entonces es contra el día anterior; si un año, contra el año pasado; y así para cualquier tipo de periodo. Cuando usamos la opción año pasado entonces la comparación es contra el mismo periodo pero un año atrás. Si la tabla muestra el mes de Mayo de 2007 entonces la variación es contra el mes de Mayo de 2006.

El significado de las flechas es el siguiente:

greenup El indicador subió.
reddown El indicador bajó.
igual Se mantuvo igual.
blueup Subió pero el periodo contra el que se compara vale cero.
BlueDown Bajó pero el periodo contra el que se compara vale cero.

Cuando el indicador tiene alarmas entonces las flechas cambian un poco:

VariacionConAlarmas

greenuphol El indicador subió y además el valor contra el cual se compara para alarmar el indicador también subió.
reddownhol El indicador bajó y además el valor contra el cual se compara para alarmar el indicador también bajó.

Para activar la propiedad variación dé clic derecho en la tabla sobre el título del indicador al que desea activarle esta opción y luego seleccione Duplicar Columna -> Variación -> Periodo Anterior o Año Pasado.

VariacionAdmin

Se puede intercambiar el verde por rojo y el rojo por verde dependiendo del indicador. Esto se hace desde el Administrador de Artus en la pantalla de indicadores lógicos activando la opción Disminuir.

Technorati tags: , ,





Formatos Fecha

5 07 2007

relojes

Cuando definimos la conectividad desde Artus a un cubo de SAP, Analysis Services de Microsoft, ROLAP u otro; hay un paso en el Wizard que se utiliza para esta tarea y que nos pregunta por los periodos de Artus  a los que corresponden las dimensiones de tiempo y el formato fecha en el que vienen los valores de las dimensiones.

Es muy importante establecer bién el formato, si no lo hacemos Artus no mostrará información.

Estos formatos que Artus utiliza al importar un cubo funcionan de acuerdo al formato ISO 8601. Esto significa que son de uso común, se pueden utilizar en Excel, en SQL, en un lenguaje de programación, etc.

Los formatos son los siguientes:

Formato Descripción Ejemplo
       
Año
yyyy 4 dígitos del año 2007, 2006
yy 2 dígitos del año 07,06
Mes
MMMM Nombre completo del mes.
Hay que usar la configuracion regional en el wizard para definir el idioma.
Enero, January
MMM 3 primeras letras del mes ENE, JAN, APR
MM El # del mes con un 0 al principio 01,02,03
M El # de mes 1,2,3,4
Día
dd El dia con un cero al principio 01,02,03,04
d el día del mes 1,2,3,4
ddd El día de la semana Miercoles, Martes
Semana      
w El # de Semana
Trimestre      
q El trimestre 1,2,3

 Y estos formatos se pueden combinar, por ejemplo:

Leer el resto de esta entrada »





Auditando el uso de Artus

4 07 2007

Si queremos saber quienes han utilizado artus, que pantalla consultaron, cual fue el tiempo de respuesta, desde que IP lo hicieron y a que hora; se puede saber. La tabla SI_AUDIT forma parte de la metadata de Artus. En esta tabla es donde Artus almacena un registro cada vez que un usuario utiliza la herramienta, consulta un escenario, entra al Administrador, se usa el migrador, etc.

La definición de la tabla es la siguiente:


CREATE TABLE SI_AUDIT (
FECHA smalldatetime NOT NULL ,
CLA_USUARIO int NOT NULL ,
CLA_ESCENARIO int NOT NULL ,
PRODUCTO varchar (1) NOT NULL ,
SEGUNDOS int NULL)

Y los campos son:

FECHA. Almacena la fecha y hora a la cual se produjo el acceso. Por ejemplo si hoy 4 de Julio a las 8:15 AM usé una de las herramientas de artus el campo almacenará: ’2007-07-04 08:15:00′

CLA_USUARIO. Almacena el consecutivo que corresponde al usuario que utilizo la herramienta. Para saber que consecutivo corresponde a cada usuario consulte la tabla SI_USUARIO ( también de la metadata de Artus ), el consecutivo vienen en el campo CLA_USUARIO y en los campos NOM_LARGO y NOM_CORTO vienen el nombre largo del usuario y el nombre corto que Artus usa como Login.

CLA_ESCENARIO. El consecutivo que corresponde al escenario que el usuario consultó. Esto solo aplica si el usuario entró al Designer o al Desktop a consultar un escenario. Consulte en la tabla SI_ESCENARIO los campos CLA_ESCENARIO y NOM_ESCENARIO para saber cual es el nombre del escenario(o viceversa) que corresponde a la clave guardada en la tabla.

PRODUCTO. El producto de Artus que se usó según la siguiente tabla:

  M- Artus Migrador
  E- Artus Desktop ( antes Ejecutivo)
  O- Artus Designer (antes OLAP)
  A- Artus Administrator
  W- Runtime Artus Web OCX
  H- Runtime Web HTML

SEGUNDOS. Es el tiempo que le tomó a Artus el mostrar el escenario. Excelente columna para obtener un tiempo de respuesta promedio de la herramienta.

Ya que hemos conocido que información se almacena en la tabla se pueden hacer querys interesantes.

Leer el resto de esta entrada »





La dimensión Tiempo. Los otros campos

3 07 2007

Continuando con la dimensión de tiempo, también están los otros campos que son muy importantes. Debemos considerar el campo Fecha que dependiendo de la base de datos será de tipo DATE, DATETIME o algo parecido.

tiempo2

Debemos de incluir un campo Año donde se almacenarán los valores 2006, 2007, etc. Aquí no hay mucho que decir.

Para el campo mes muchas veces me he topado con que los valores que se guardan ahí son: Ene, Feb, Mar; o Enero, Febrero, Marzo. Si hacemos esto de guardar solo la parte mes, cuando lancemos un query sobre la estrella deberemos poner en el where la parte año para que la consulta no sume los datos de los mismos meses de todos los años.

Un ejemplo de como se vería el query sería:

SELECT MES, SUM( VENTAS)
FROM HECHOS A, TIEMPO B
WHERE A.TiempoID = B.TiempoID
AND AÑO IN (2006,2007)

En este ejemplo, estaría sumando ENERO del 2006+ENERO del 2007. Para que esto no ocurra es mejor guardar en el campo mes el valor junto con el año en la siguiente forma: YYYY MMM. Por ejemplo, 2006 Ene, 2006 Feb, 2007 Ene. También se vale poner el nombre completo del mes: 2006 Enero.

tiempo3 Podemos mejorar el diseño de la tabla de tiempo como se muestra a la derecha. Se añadió a la tabla el campo MesID. De esta forma en el campo mes guardamos 2006 Ene y en el MesID guardamos 200601. Así podremos decirle en el query que me muestre el campo Mes pero que lo agrupe y ordene por el MesID.

SELECT MAX( Mes ), SUM( VENTAS)
FROM HECHOS A, TIEMPO B
WHERE A.TiempoID = B.TiempoID
GROUP BY B.MesI
D
ORDER BY B.MesID ASC

Lo mismo ocurre para la Semana, Trimestre, Época del año, Quincena y cualquier otro campo que se quiera añadir para agrupar los días. Tendré el campo por el que lo visualizo y el campo por el que lanzo el query y lo controlo.

Respecto al día de la Semana ahí no es necesario concatenarle el año o mes o semana en el valor por que lo que normalmente queremos hacer es agrupar los lunes con los martes y miércoles para ver como se comportan. Aquí si se quieren agrupar los Sábados de todo el año por ejemplo.

Observen como se ha cuidado que los campos ID sean de tipo INT. Esto debido que a la base de datos le es más fácil trabajar con números.

Para obtener un script que cree la tabla de tiempo y la llene dé clic aquí.

Technorati tags: , , Data warehouse





La dimensión Tiempo

2 07 2007

Estrella

Cuando estamos diseñando las estrellas o copos de nieve que formarán nuestro data warehouse, hay que tener mucho cuidado con la dimensión de tiempo. Hay varias formas de hacerlo y para mi gusto unas mejores que otras. La forma más común de encontrar es una en la que el campo llave es la fecha.

tiempo1

Aquí a la izquierda está el típico diseño. El problema aquí es que a las bases de datos les cuesta trabajo hacer búsquedas por campos datetime o date, al menos más que un campo entero. Otro punto es que el campo fecha ocupa más espacio que un campo entero. Hay que tomar muy en cuenta que el campo fecha, que es la llave, formará parte de la tabla de hechos; y con millones y millones de registros un byte o dos es mundo de espacio, tal vez un disco duro :) .

tiempo2

Podemos mejorar el diseño cambiando el campo llave por un campo entero como en la figura de la derecha. Esto hará que:

  • las búsquedas sean más rápidas sobre todo en la tabla de hechos. Esto por que a las bases de datos les cuesta menos trabajo manejar números que fechas, o sea ocuparemos menos el procesador y ocuparemos menos memoria.
  • Que el tiempo de respuesta sea más rápido. No es redundancia, este punto es una consecuencia de lo anterior.
  • Que físicamente los datos ocupen menos espacio. De nuevo, el servidor trabaja menos con menor volumen de información y se requieren menos procesador y menos memoria o sea que la ganancia es doble. 

En este diseño hay 2 corrientes, los que usan un numero consecutivo como llave y los que usamos un numero en el formato yyyyMMdd. Para mi gusto es muy frustrante encontrarse una estrella donde la llave de la tabla tiempo es un 1,2,3,4…34560,34561,….@#$%#$$% ¡para saber a que fecha corresponden el 34561!…pues hay que hacerle un query a la tabla de tiempo.

Yo prefiero de llave un numero con el formato yyyyMMdd, así para el 31 de diciembre del 2007 guardo 20071231 en el campo TiempoID, sigue siendo un numero entero y es mucho más legible que un simple 1-2-3. Con solo ver que valor tiene el campo TiempoID puedo saber a que fecha corresponde el registro. Además funciona perfectamente en el where con un between:

SELECT *
FROM HECHOS
WHERE TIEMPOID BETWEEN 20070101 AND 20070131

Hay un punto no tan visible con el campo llave:  la tabla de hechos tiene índices para acelerar el tiempo de respuesta. Los índices ocupan espacios y si usamos un campo entero en vez de un datetime estaremos ahorrando espacio y haciéndole la vida más fácil al servidor.

En bases de datos pequeñas 1 a 10 gigas da lo mismo usar uno u otro. En bases de datos gigantes como las de grandes tiendas departamentales o tiendas de conveniencia donde la base de datos del data warehouse mide teras usar un campo entero es de vital importancia.

En otro post analizaremos los demás campos de la tabla de tiempo.

Para obtener un script para crear y llenar la tabla de tiempo dé clic aquí.

Technorati tags: , , Data Warehouse








Seguir

Get every new post delivered to your Inbox.