Finalmente llegó el resumen del capítulo 2 de este fascinante libro: Diseño de Aplicaciones intensivas en datos, les aconsejo que lean el capítulo 1 antes de empezar con esta nueva lectura…
Modelos de datos y lenguajes de consulta
Los modelos de datos son quizá la parte más importante en el desarrollo de software porque tienen un efecto muy profundo, no sólo en cómo el software es escrito sino en cómo se piensa en el problema que se está intentando resolver.
La mayoría de las aplicaciones están construidas en capas de modelos de datos, una sobre otra y cada capa esconde la complejidad de la capa que está debajo proveyendo un modelo de datos limpio. Estas abstracciones permiten que diferentes grupos de personas, por ejemplo los ingenieros de bases de datos y los desarrolladores de aplicaciones que usan la base de datos, trabajen juntos de una manera efectiva.
Hay muchos tipos de modelos de datos, cada uno con su respectiva complejidad. En este capítulo exploraremos algunos modelos de datos de propósito general para almacenamiento y consultas.
Modelo relacional VS Modelo de documentos
El modelo de datos más conocido es probablemente SQL, que está basado en el modelo relacional. Aquí, los datos son organizados en relaciones (tablas) donde cada relación es una colección desordenada de tuplas (registros).
El modelo relacional fue una propuesta teórica, pero a mediados de los años 80´s, los sistemas relacionales de administración de bases de datos (RDBMSes) y SQL fueron las herramientas que la mayoría de la gente elegía en base a sus necesidades de almacenar y consultar datos con algún tipo de estructura. El dominio de las bases de datos relacionales ha durado alrededor de 25-30 años (una eternidad en la historia de la computación).
Con el paso de los años ha habido mucha competencia en cuanto al almacenamiento de los datos y su consulta. En los años 70 ́s y principios de los 80 ́s el modelo de red y el modelo jerárquico fueron las principales alternativas, pero el modelo relacional vino a desplazarlos. Las bases de datos de objetos aparecieron a finales de los 80´s y principios de los 90´s. Las bases de datos XML aparecieron a principios de 2000´s. En fin, cada competidor para el modelo relacional generó cierto hype en su tiempo pero ninguno duró.
En cuanto las computadoras se volvieron más poderosas, empezaron a ser utilizadas para una gran variedad de propósitos. Remarcablemente, el modelo relacional tendía a acoplarse muy bien a diversos casos de uso. Mucho de lo que vemos hoy en día en la web, tiene sus bases en el modelo relacional.
El nacimiento de NoSQL
El nuevo competidor, NoSQL, llega en 2010´s. Su nombre es infortunado porque no se refiere a ninguna tecnología en particular, originalmente fue usado como un hashtag en twitter para convocar a una meetup sobre una open source y distribuía base de datos no relacional en 2009. En nuestros días, un gran número de sistemas de bases de datos están asociados al hashtag #NoSQL, que ha sido interpretado como No solo SQL.
Hay muchos aspectos detrás de la adopción de las bases de datos NoSQL:
- Necesidad de escalabilidad.
- Preferencia por herramientas open source.
- Operaciones de consulta especializadas que no cubre el modelo relacional.
- Frustración por las restricciones que implica usar el modelo relacional y el deseo de un modelo de datos más libre.
Importante: diferentes aplicaciones tienen diferentes requerimientos y por tanto la tecnología usada puede variar según los casos de uso.
El desajuste del objeto-relacional
La mayoría de las aplicaciones son desarrolladas con el paradigma orientado a objetos, lo cual nos hace criticar el modelo de datos SQL: si los datos son almacenados en tablas relacionales, una incómoda capa de traducción es requerida entre los objetos de la aplicación y las tablas del modelo de base de datos. Esta desconexión entre modelos es comúnmente llamada: desajuste de impedancia. (spoiler: es por eso que muchos desarrolladores sienten que el modelo JSON reduce esta impedancia entre el código de la aplicación y la capa de almacenamiento… y les gusta mas :P).
¿Están las bases de datos de documentos repitiendo la historia?
Mientras las relaciones muchos-a-muchos y los joins son rutinariamente usados en las bases de datos relacionales, las bases de datos de documentos y las NoSQL re-abren el debate por saber cual es la mejor manera de representar las relaciones en las bases de datos. Este debate es más viejo que NoSQL…
La base de datos más popular para procesamientos de datos de negocio en los 70´s es Information Management System (IMS), de IBM, su diseño era relativamente un simple modelo de datos llamado modelo jerárquico, el cual tiene varias similitudes al modelo JSON (base de datos de documentos).
Al igual que las bases de datos de documentos, IMS trabajaba bien con relaciones uno-a-muchos, pero las relaciones muchos-a-muchos se volvían más complejas y además no soportaba joins. Los desarrolladores tenían que decidir si denormalizaban la información o manualmente resolvían las referencias de un registro a otro…. Estos son los mismos problemas a los que nos enfrentamos hoy en dia.
Bases de datos relacionales VS bases de datos de documentos: hoy en día.
Hay muchas diferencias a considerar cuando hablamos de estos dos tipos de bases de datos, en esta ocasión hablaremos de las diferencias en el modelo de datos.
Los principales argumentos a favor del modelo de datos de documentos es la flexibilidad del esquema, mejor performance debido a la localidad, y que para algunas aplicaciones esto es más parecido a las estructuras de datos que estas usan. Por otra parte, el modelo relacional provee un mejor soporte para joins, relaciones muchos-a-uno y muchos-a-muchos.
¿Qué modelo de datos conduce a un código de aplicación más simple?
Si los datos en tu aplicación tienen una estructura de documento (por ejemplo JSON) entonces probablemente sea una buena idea usar el modelo de documentos. El modelo relacional podría agregar más complejidad debido a la capa de transformación que se tiene que agregar para enviar los datos a tablas.
El modelo de documentos tiene limitaciones, por ejemplo el acceso a ciertos registros puede ser tan complicado como este anidado. También maneja muy pobremente los joins (en caso de ser necesarios). Igualmente, si la aplicación necesita relaciones muchos-a-muchos, el modelo de documentos puede no ser la mejor opción ya que añade más complejidad a la aplicación
No es posible determinar de una manera general cuál modelo de datos es el que mejor nos conviene. Todo depende del tipo de relaciones que tengan nuestros datos y cómo se adapta a la aplicación.
Flexibilidad del esquema en el modelo de documentos
La mayoría de las bases de datos de documentos no obliga a tener un esquema definido. Estas bases de datos suelen ser llamadas “schemaless”, aunque no es del todo real, puesto que al leerlas se asume cierto tipo de estructura, es decir, hay un esquema implícito pero no obligado. Un término más acertado es “schema-on-read” (la estructura del esquema está implícito y es interpretado sólo cuando se lee), en contraste “schema-on-write” (el modelo relacional tradicional de bases de datos, donde el esquema es explicito y la base de datos se asegura de que todos los datos escritos lo conformen).
Localidad de datos para consultas
Un documento normalmente es almacenado en una sola cadena continua (JSON, XML, etc). Si tu aplicación necesita acceder al documento entero (por ejemplo renderizarlo en una página web), hay una ventaja en performance debido a su almacenamiento local. Si los datos se encuentran esparcidos en multiple tablas, multiple index son requeridos para regresar los datos completos, lo cual podría requerir más búsquedas en disco y podría tomar más tiempo.
La ventaja de localidad solo aplica si se necesita gran parte del documento al mismo tiempo. Por eso se recomienda mantener los documentos relativamente pequeños.
Convergencia de las bases de datos de documentos y las bases de datos relacionales
Algunas bases de datos relacionales como Postgresql desde la versión 9.3 soportan un tipo de dato JSON, donde se pueden almacenar documentos. Por otro lado, RethinkDB, que es una base de datos orientada a documentos, soporta joins.
Parece ser que las bases de datos relacionales y las de documentos están llegando a ser más similares con el paso del tiempo, y lo bueno de esto es que los modelos de datos se complementan uno con otro.
Lenguajes de consulta para datos
Tenemos varios lenguajes para hacer consultas:
- SQL: el más popular y utilizado. 😛
- CSS-HTML: para queries/consultas en la web.
- MapReduce: un modelo de programación para procesar grandes cantidades de datos en bulks sobre diferentes máquinas.
- Grafos: nodos y relaciones. Una gran variedad de datos puede ser modelada bajo este esquema.
- Cypher: para propiedades de grafos, fue desarrollado por Neo4j.
- Triple-stores: es más o menos equivalente al modelo de grafos, usando diferentes palabras para expresar las mismas ideas.
- SPARQL: es un lenguaje de consulta para triple stores usando el modelo RDF.
- Datalog: similar al de triple store.
Resumen
Los modelos de datos es un tema de suma importancia, en este capítulo exploramos algunos de ellos. Empezamos con el modelo jerárquico que debido a sus carencias dio pie al modelo relacional y este a su vez dio pie al modelo no relacional, este último lo podemos dividir en bases de datos de documentos y bases de datos de grafos. Estos tres modelos son extensamente usados al dia de hoy y todos son buenos en su respectivo dominio.
Recuerda que para saber cual modelo de datos te conviene usar, es importante que evalúes el tipo de relaciones que tengan los datos y cómo se adaptan a la aplicación. Afortunadamente los modelos de datos se complementan y en nuevas versiones el modelo relacional soporta tipo de datos para documentos y el modelo no relacional soporta algunos joins y referencias.
Aquí concluye el resumen del segundo capítulo, espero les cause interés y esperen con ansia (como yo) el capítulo número 3 😀
De-todología 