Crecimiento o Fragmentación Horizontal

 Últimamente he estado leyendo acerca de crecimiento horizontal,  que significa eso, es poder crecer la capacidad de computo sin migrar a un nuevo servidor, distribuyendo la carga en múltiples servidores.

Conceptualmente la distribución debería ser perfecta, simétrica y balanceada. 

En la práctica tenemos Fragmentación por Esquemas, por filas, por Hash,y bueno las que vienen con el particionamiento. 

Existen bases de datos (nuevas) que naturalmente pueden manejar esto, especialmente para datawarehouse, de solo lectura y NoSql, pero por definícion su uso es limitado a tareas particulares.

En el área de las bases transaccionales, entiendo que Oracle es un capítulo aparte con la opción de RAC proveyendo Fragmentación por fila de manera bastante transparente, bueno siendo sincero esto requiere almacenamiento compartido en todos los nodos y una intensa coordinación de bloques, filas y bloqueos

De las demás bases transaccionales principales tenemos Postgresql, Mysql (en sus 3 sabores), y SQL server, ninguna tiene una solución transparente y aunque es posible dividir por filas, requiere código y planeamiento tanto para crecer, cómo para decrecer.

En general las demás soluciones no comparten el almacenamiento entre las partes requiriendo coordinadores cómo MaxScale, o Azure Elastic, Amazon Aurora, etc

El "Conjunto de Trabajo"

 

El "Conjunto de Trabajo"

Probablemente es una mala traducción del "Working Set" un concepto de sistemas operativos, aunque en realidad algo muy simple si lo relacionamos con nuestra vida diaria.

¿Quien no ha tratado de cocinar algo y cuando falta un ingrediente tiene que detener todo e ir por el ingrediente faltante ?,

o cuando uno es aficionado a arreglar cosas trata de poner todo en una mesa y olvida una herramienta en medio del proceso, o simplemente no puede tener todo a mano al mismo tiempo.

Tratar de poner todo en una mesa puede ser complicado si uno no tiene el espacio suficiente, y los Sistemas Operativos y Bases de Datos se enfrentan al mismo problema.

En el caso de la Base de Datos, una de las tareas más importantes está en lograr que la información necesaria este presente en la memoria al mismo tiempo, de esto depende la velocidad de la ejecución.

El balance a lograr no es simple, requiere una comprensión del uso de la información y de las prioridades del cliente, no todo puede estar en la RAM al mismo tiempo.

Uno de los primeros "trucos" que utilizaban los analistas de sistemas era dividir los movimientos en diarios, semanales, mensuales ... etc., de ese modo el día a día no se veía afectado por la acumulación de información, el uso de bases históricas en otros equipos, toda una administración que los DBAs y analistas realizaban por medio de procesos (y aún lo hacen).

Después vino el particionamiento y la compresión de datos, tanto a nivel del Sistema Operativo como de la base de Datos, la separación de diversas caches para garantizar que lo crítico se encontrara donde debería y lo no tan importante se relega a un segundo plano.

En otros posts voy a tratar de cubrir los mecanismos disponibles para lograr esto.