Compartir
Contenidos contratados por la marca que se menciona

Almacenamiento en Azure, ¿relacional vs no relacional?

Almacenamiento en Azure, ¿relacional vs no relacional?
Guardar
1 Comentarios
Publicidad
\"The \"Prueba \"Conviértete

La persistencia de los datos es una de las partes imprescindibles en cualquier desarrollo de software. Para ello, en las últimas décadas, ha ido evolucionando la tecnología de las bases de datos relacionales y el lenguaje de SQL es sus múltiples implementaciones y sabores.

La llegada de nuevas necesidades y requisitos orientados a la escabilidad y la computación en paralelo, han echo emerger nuevos paradigmas centrados en las llamadas bases de datos NoSQL, que manejan los datos de forma estructurada pero no relacional. Priorizados en la simplicidad y el rendimiento.

Para explicar estas dos tecnologías de almacenamiento de datos desde el punto de vista de un desarrollador en Windows Azure voy a utilizar como ejemplo el desarrollo de una aplicación de una agenda de contactos, compuesta por un formulario de inserción de datos del contacto, un listado de contactos y un formulario de detalles del contacto.

SQL Azure

En un desarrollo normal, crearíamos una estructura de datos en nuestra base de datos relacional y realizaríamos nuestro CRUD de toda la vida. Insertando y recuperando información por medio de sentencias SQL. Y haciendo nuestros Join, Group y demás operaciones de lenguaje SQL entre tablas, para recuperar los campos que se muestren en las pantallas de listado y detalles de contactos. Esto en Azure, sería muy sencillo de realizar utilizando una Azure SQL.

La ventaja principal es que es una tecnología que conocemos al dedillo desde hace muchos años. Es muy sencillo migrar nuestras aplicaciones actuales basadas en SQL Server o cualquier otro motor de base de datos relacional. Y que utiliza el lenguaje SQL, del cual tenemos toneladas de información.

La desventaja son los dolores de cabeza que nos causará si nos enfrentamos con una previsión de miles o cientos de miles de usuarios concurrentes, tanto por rendimiento como por escalabilidad.

Azure Tables

Estructura de Azure Table
En un desarrollo para Azure, podríamos olvidarnos del almacenamiento relacional y utilizar almacenamiento estructurado no relacional, lo que se ha dado en llamar bases de datos NoSQL. La característica diferenciadora es que aquí no tenemos una estructura de datos compleja, ni el potente motor relacional, ni el lenguaje SQL para la interacción transaccional con el motor de base de datos. Aquí tenemos la sencillez personalizada en forma de tablas de entidades, las cuales tienen propiedades públicas. Es tan simple la estructura, que cada entidad puede tener sus propias propiedades, sin que tengan que ser igual que la del resto de entidades de la tabla. Esto es posible porque internamente Azure utiliza un par de propiedades para identificar de forma inequívoca los registros. Así las propiedades de cada registro no son dependientes de los demás registros de la tabla, a diferencia que en una base de datos relacional en donde los registros de una tabla tienen todos los mismos campos.

Al no haber lenguaje SQL, la forma más cómoda de trabajar contra este tipo de repositorio es por medio de la propia API de Azure y LinQ. Ya que trabajaremos nuestros datos con clases que heredan IQueryable, y que tan cómodos son de utilizar.

La ventaja es la velocidad. La simplicidad. La poca necesidad de mantenimiento, ya que no hay procedimientos almacenados, relaciones, etc.

La desventaja es todo lo correspondiente a la integridad referencial, ya que no tenemos un motor relacional que se encargue de ello de forma transparente, sino que tendremos que desarrollarlo en nuestra capa de datos específicamente para nuestras necesidades.

Hay que tener en cuenta que las tablas funcionan muy bien con estructuras simples. Pero si tenemos una estructura de datos compleja, las ventajas del almacenamiento no estructurado se diluyen y gana la opción de un buen motor DRBMS.

Command and Query Responsibility Segregation

Procesos CQRS en Azure
Analizando un poquito estos dos sistemas de almacenamiento que nos permite Azure, más los blob de los cuales hablaré en otro momento, nos percatamos que es la estructura ideal para poner en práctica el patrón CQRS(Command and Query Responsibility Segregation), que tiene como origen el Principio de CQS (Command and Query Separation) escrito por Bertrand Meyer.

Esto sería, volviendo a nuestra aplicación contactos, que cuando introdujéramos un nuevo contacto, la información introducida en la UI se escribiría en una SQL Azure (relacional solo de escritura). Al finalizarse la escritura de los datos, se lanzaría un mensaje y se actualizaría la base de datos no relacional (solo escritura internamente, solo lectura desde la UI) en las tablas de listado de contactos y de de detalle de contacto.

Así, cuando el usuario quisiera obtener el listado de contactos o el detalle, la aplicación no tendría que construir una transacción SQL para recuperar los datos de diferentes tablas y formatear para visualizarlo. Si no que simplemente, llamando a un tabla “que ya tiene los datos que se necesita y en el formato requerido”, obtendría el resultado.

Y esa es la gran ventaja, la velocidad de recuperación de datos. La mayor de las operaciones en las bases de datos son de lectura, y están muy optimizadas en las bases de datos NoSQL. Por lo cual obtenemos resultados a una gran velocidad. Además, este tipo de estructuras nos permite escalarlas simplemente creando una nueva instancia. Sin los dolores de cabeza, por ejemplo, que nos podrían causar los bloqueos durante una escritura transaccional o las reglas de integridad referencial.

Lo malo, es que hay una latencia entre la escritura y la disponibilidad de lectura. Entre que escribo un contacto y me aparece en la lista pasa un lapso de tiempo que tendremos que tener muy en cuenta dependiendo de la criticidad del sincronismo que defina la aplicación. Pero si esto no es problema, las ventajas son muchas.

Y cómo se comunican las bases de datos entre ellas? Por medio las colas y mensajes de Azure. Pero eso es otro capítulo del cual hablaré más adelante…

Publicidad

También te puede gustar

Ver más artículos