En la arquitectura de datos empresarial existe una paradoja que todo ingeniero descubre tarde o temprano: la base de datos más rápida es aquella a la que no necesitas preguntar. Las cachés y los aceleradores de datos constituyen probablemente la inversión con mayor retorno inmediato en cualquier plataforma de datos. Con una implementación correcta, es habitual ver reducciones del 70-95 % en latencia de lectura, caídas del 40-60 % en carga sobre bases de datos primarias, y una capacidad de absorción de picos de tráfico que convierte incidentes potenciales en meros incrementos logarítmicos en gráficas de monitorización..

Una de las herramientas más maduras en el mundo Big Data es el framework de licencia libre Apache Hadoop. En este post exponemos de forma resumida la integración entre Hadoop y uno de los fabricantes líder en analítica de negocio: SAS.

En primer lugar resumimos los principales componentes de la arquitectura Hadoop..

Suppose we want to update in our ORACLE database the costs fields of the fact table FAC_TABLE with the unit cost of our table COSTS.

We can do this in two ways:

1. (Slow, but valid for a few data or to sporadic uses)

update FAC_TABLE ft  set UNIT_COST = (select distinct UNIT_COST from COSTS ct  where (ft.id_article = ct.id_article);

2. (The best way is this, and the performance is ideal if you have constraints)

UPDATE ( SELECT ft.UNIT_COST AS old_cost,  ct.UNIT_COST AS new_cost FROM FAC_TABLE ft  INNER JOIN COSTS ct ON ft.id_article ct = ct.id_article) )  SET old_cost = new_cost;

To the proper functionality of this second option you need a UNIQUE or PRIMARY KEY constraint on ct.id_articulo. 
If you don't have this constraint, you can use the hint / * + BYPASS_UJVC * / after the word UPDATE (Bypass update join view constraint).

The performance increase if we have the constraint but even without it, the second option should run quite faster than the first option.

En MySQL existe un parámetro que habilita el registro de las consultas que tardan mas de x segundos en ejecutarse, las llamadas Slow Queries. Básicamente lo que hace es meterlas en un fichero de log para luego consultarlo con mysqldumpslow. Este mecanismo nos puede ser útil para mejorar el rendimiento global de la base de datos si reducimos el valor de forma progresiva para los tiempos de ejecución "no admitidos" antes de declarar una consulta como "lenta" o slow query...