Elegir entre Blobs, Tables o Files

UniversalSync será una aplicación que realizará Backups de ficheros multimedia en Cloud (en este artículo lo explico mejor) y, por mi conocimiento, he iniciado su construcción utilizando Azure Storage como repositorio en la Cloud.

He de reconocer que pensaba que conocía bastante sobre el tema, pero fíjate que cuando me pongo a investigar sobre las capacidades del servicio, me encuentro que tiene cuatro “sabores” diferentes.

¿Como elegir cuál es el que mejor se ajusta a lo que tengo en mente? Pues ya que es un proyecto personal sin presión de fechas de entrega, pienso que la mejor forma de abordarlo es haciendo un CRUD de persistencia para cada uno de ellos.

Error!!

Proceso de selección

Posiblemente he escogido el camino más largo. En vez de estudiar las características de cada “sabor” del servicio, lo que he hecho es ponerme directamente a picar el código necesario para hacer las operaciones básicas.

Pero, y eso es lo bueno,  puedo asegurar sin género de duda que para guardar ficheros de fotos y vídeos la solución más óptima es la de… spoiler.

Azure Storage ofrece cuatro servicios diferentes de almacenamiento, los cuales quiero describir sus principales características y reflexionar por qué he descartado tres de ellos.

Los blob en páginas y disco están orientados a montar discos duros virtuales para ser explotados desde máquinas virtuales de Azure. Estos los conozco de primera mano porque para migrar una vm a Azure necesitas copiarla a un blob de página, para luego utilizarla como la ISO para montar la versión en Cloud.

Los blobs en anexos, están optimizados para funcionar con bloques anexos los unos a los otros. Pero no son lo adecuado para el escenario que quiero tanto por la topología de las operaciones como las necesidades de almacenamiento.

Dada su especialidad, lo descarté desde el primer momento. Aunque son más rápidos que sus otros dos hermanos de los que hablaré al final.

El siguiente que descarté fue todo el tema de Colas ya que no es un sistema de almacenamiento si no, como indica su nombre, una forma de construir y gestionar mensajes. Pero me lo he apuntado porque sobre esto voy a montar el motor de sincronización.

Las Tablas me han sorprendido. Son una versión de NoSQL diseñada para guardar grandes volúmenes de datos estructurados, y realizar búsquedas rápidas a través de índices. Lo mejor es que permiten queries con Linq, lo malo es que las Tablas pueden almacenar millones de entidades pero estás solo pueden tener un tamaño máximo de 1Mb.

Por esto las he descartado, pero me las guardo en la memoria para construir el motor de sincronización ya que me parece una buena aproximación para el gestor de metadatos y búsqueda de ficheros. Otra opción es hacerlo en una NoSQL como MongoDB o similar, y desacoplarme un poquito de Azure, pero eso es para mucho más adelante.

Mi última esperanza era el servicio de Files. Con una capacidad máxima por “Shared” – un concepto similar a unidad de almacenamiento – de 5 Terabytes, pudiendo llegar a 1 Tb. cada fichero almacenado, tenía pinta de facilitar aún más el proceso de almacenamiento.

Pero realmente no es así. Files está pensado para ser utilizado enganchado el servicio como una unidad remota a través del protocolo SMB. Si, podría montar una capa de IO contra el servicio pero, pensándolo bien, no tiene sentido teniendo los blob.

Me dá la sensación que sería utilizar una tecnología on premise para un enfoque Cloud. Como querer un Tesla y ponerle un motor de combustión.

Y el ganador es…

Llegamos por fin al servicio de Blob de bloques. Este servicio está pensado para persistir y servir material multimedia o grandes volúmenes de binarios. También está especializado en un uso como almacenamiento de datos de procesos masivos de análisis o de otros servicios de Azure, pero a mí esa capacidad me aporta poco ahora mismo.

En cambio es perfecto que cada Blob vaya a almacenar un solo fichero, que puede llegar a ser de hasta 195 Gb. (más que suficiente para lo que yo tengo). Y cada fichero vaya a tener una url propia que me permite referenciarlo de manera inequívoca desde el futuro motor de sincronización.

Con una conexión de fibra de 300Mb/seg. los tiempos son buenos o muy buenos. Pero tengo que refactorizar a operaciones asíncronas más bien pronto.

Otra decisión que tuve que enfrentar es que hay dos tipos de Blob de bloques de acuerdo a la intensidad de su uso. El hot y el cold. Como se puede entender, el primero es para un uso de cargas y descargas intenso, y el segundo es para tener datos fríos a los que accedes de vez en cuando. De hecho, en Microsoft los describen – estos últimos – como los perfectos para almacenar Backups o datos que no se van a utilizar en tiempo.

En mi experiencia, con un Blob de bloques cold tengo más que de sobra para el tráfico que puede tener una misma persona sobre su colección de fotos y vídeos personal. Incluso en el lejano caso de que quiera construir álbumes compartidos por varios usuarios, aún así la topología del tráfico es muy, muy baja. Y el servicio de Storage dá más que de sobra.

Por último, y definitivo, este servicio es el más barato de lejos. Menos de 9€ mensuales por 1 Tb. de almacenamiento, con 10.000 operaciones de IO, y 10Gb de transferencia mensual.

He de reconocer que también ayuda el tener una suscripción de azure que me regala los primeros euros de consumo mensual, por lo cual este servicio me saldría gratis hasta los 8 primeros Terabytes.

Y por ello decidí hacer solamente la librería del CRUD para Blob de bloques clod, y el resto no me aportaba lo suficiente para dedicarle tiempo y esfuerzo.

Si quieres una revisión detallada de todo Azure Storage en español, pásate por la Introducción al Almacenamiento de blobs de Azure mediante .NET.

Espero que sea de utilidad y nos veremos en el próximo capítulo.

Anuncios

2 comentarios en “Elegir entre Blobs, Tables o Files

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s