Continuamos con esa serie que ya lleva una y dos entregas de soluciones de común aplicación en cualquier entorno pero especialmente en los entornos de nube. Hoy veremos el particionado, que aunque es una solución generalmente poco eficiente, nos puede salvar el culo más de una vez.

El particionado es una técnica que se aplica generalmente a los almacenamientos de datos y muy habitualmente a las BBDD relacionales, aunque es algo que se utiliza naturalmente en otros sistemas como en muchos de los sistemas de almacenamiento NoSQL como el Storage de Azure que para localizar un registro debes (deberías) proporcionar un PartitionKey y un RowKey, sabiendo que todas las filas de una partición se almacenan juntas respondiendo a la lectura en un tiempo constante o permitiendo escrituras transaccionales siempre que te mantengas en la misma partición.

Básicamente se basa en coger un conjunto de «cosas» que tienen mucha carga de «acciones» y los separas en varios conjuntos de «cosas» para que se mitigue la carga de «acciones». En esta definición cosas y acciones puede ser lo que sea, desde superhéroes y detención de villanos, a datos y operaciones de lectura.

Por ejemplo en el caso tan típico de las BBDD relacionales -al menos yo, por desgracia, lo he visto hacer más de una vez-, tienes un motor de base de datos que almacena una base de datos con unos cuantos gigas y algunos millones de registros y parece que ya no da más de si. En lugar de ver que pasa y optimizar las consultas que es el modo difícil y que lleva tiempo (y el tiempo es de lo poco que puede justificar esta acción) decides hacer un particionado y separas la base de datos en dos permitiéndote incluso montarla en otro servidor. Eliges un campo del que dependan casi todas tus tablas, por ejemplo la fecha, y estableces un punto de tal modo que todos los registros anteriores a esa fecha se quedan en la base de datos A y los superiores a esa fecha se pasan a la base de datos B. Luego sólo tienes que incluir la limitación en la lógica de acceso a datos un filtro adicional para que si una operación (selección, inserción, actualización…) es anterior de la fecha vaya a la base de datos A y si no vaya a la B.

¿Lo veis claro? Es fácil, sencillo y para toda la familia. Pero… ¿cómo podemos aplicar esto a nuestro caso? Recordemos:

…cuando intentas probar el servicio ves que no llegas a Infinitext. Dándole vueltas, hablando con expertos y amigos y leyendo un poco de literatura parece ser que tu proveedor de la Nube™ tiene el mismo canal de comunicaciones en todos los tipos de máquina y que en cuanto solucionaste lo del límite de memoria superaste el límite de conexiones que podía manejar tu sistema. El escalado vertical ha sido inútil, tienes que hacer un escalado horizontal, meter más máquinas pero ¿que pasará con la caché y el sistema de cobro tan chulo que habías montado?

Bien, si aquí como «cosa» identificamos nuestro servidor y «accion» el procesamiento de cada una de las llamadas, el particionamiento es facilito.

Sólo tienes que ver como vas a partir esto en trozos. Por suerte ¡montaste tu proyecto en la Nube™! No te va a costar mucho ya que, casi todos, los servicios tienen ya un gateway para manejar el tráfico y poderlo mandar para un servidor u otro.

Un caso muy típico de particionado es cuando quieres mitigar al máximo la latencia y montas un servidor en USA, otro en Brasil, otro en Irlanda, otro en la India y uno último en Japón y en función de la ubicación de la petición, la mandas al que tengas más cercano.

En este caso aun no necesitas hacer algo así, tu lo que no quieres tocar es la maravilla de sistema de cache que maneja las credenciales y el sistema de pago que montaste ¡que te llevó dos noches programarlo! Si te lo pudieses permitir comprabas un Redis Cache o similar para que todos los servidores accedan a la misma cache y listo, pero se te va completamente de presupuesto. Por tanto, decides separa alfabéticamente y además te curras un script en el gateway que haga que sea un particionado dinámico y que si tienes dos servidores mande a cada uno a los usuarios que empiecen por una mitad u otra del alfabeto, pero que si levantas tres divida el alfabeto en tres partes. Lo echas a andar y funciona, otra vez se puede conectar todo el mundo a la vez.

Eres un puto crack, vale que has perdido unos cuantos usuarios por el camino pero ahora tienes un sistema a prueba de bombas, y a medida que va creciendo el número de usuarios nuevamente vas levantando máquinas y duermes tan tranquilo.

Todo parece ir guay, pero un día te echas a dormir y no puedes, estas intranquilo. No paras de darle vueltas a la idea de que ya no estás ganando dinero como hacías antes ¿puede ser eso posible? Como no puedes dormir, te lías la manta a la cabeza, enciendes el ordenador aun tapado con la manta en la cama y te pones a revisar los números. ¡Efectivamente! No llegas a palmar pasta (menos mal) pero no estás haciendo nada de dinero. Resulta que los malditos usuarios no distribuyen sus nombres de un modo uniforme, así que algunos servidores están mucho más cargados que otros. Para mantener esta estructura tendrías que hacer que las particiones no fuesen uniformes y no ves manera de como hacerlo con los simples scripts que te permite hacer el gateway de la Nube™ ¿ahora qué?

Tranquilos que como para casi todo hay una solución fácil y sencilla. En la próxima entrega de esta serie la veremos, por el momento daros por contentos ¡que no estáis perdiendo dinero!

Post By Javi López (27 Posts)

Arquitecto/desarrollador, creativo, buscador de nuevas soluciones y modelos de negocio, crítico constructivo y ex muchas cosas

Website: → JaviLopezG

Connect

cloud, nube, Particionado, Patrones