Desde un punto de vista
arquitectural la base de datos no es una entidad. Es un detalle que no eleva el
nivel de elementos de una arquitectura. Su relación a la arquitectura de un
sistema software es más que una relación de un picaporte con la arquitectura de
tu hogar.
La estructura que tú le das a los datos dentro de la aplicación es
altamente significativa a la arquitectura de tu sistema, pero las base datos no
es el modelo. La base de datos no es el modelo de datos. La base de datos es
una pieza de software. La base de datos es una utilidad que provee acceso a los
datos. Desde un punto de vista de la arquitectura, la utilidad es irrelevante
porque esta es un mecanismo de bajo nivel. Un buen arquitecto no permite a los
mecanismos de bajo nivel expandirse por el sistema de la arquitectura.
Bases de datos relacionales
Edgar Codd definió los principios de la bases de datos relacionales
en 1970. A mitad de 1980, el modelo relacional había crecido hasta convertirse en
el almacenamiento de datos dominante. Había una buena razón para esta
popularidad: el modelo relacional es elegante, disciplinado y robusto. Este es
un excelente tecnología de almacenamiento y acceso de datos.
Pero no importa como suene de brillante y útil suene una tecnología, esta
es simplemente una tecnología y esto significa que es un detalle.
Mientras que las tablas relacionales pueden ser convenientemente para
ciertas formas de acceso de datos, no hay nada arquitecturalmente significativo
sobre ordenar datos en filas dentro de tablas. Los casos de uso de la
aplicación no deberían saber nunca ni preocuparse por tales asuntos.
En realidad, el conocimiento de la estructura tabular de los datos debería
estar restringido a las funciones de utilidad de los niveles más bajos en los
círculos más externos de la arquitectura.
Muchos datos acceden a frameworks que permiten pasar filas y tablas
de la base de datos por el sistema como objetos. Permitir esto es un error
arquitectónico. Esto acopla los casos de uso, las reglas de negocio y, en
algunos casos incluso la UI a la estructura de de los datos.
¿Por qué los sistemas de bases de datos son tan
prevalentes?
¿Porqué los sistemas software y empresas de software están dominadas por
los sistemas de bases de datos? ¿Qué explica la preeminencia por Oracle, MySql
y Sql Server? En un palabra, discos.
Los discos rotativos fueron el pilar del almacenamiento de datos por 5
décadas. Varias generaciones de programadores no han conocido otras plataformas
de almacenamiento. Tecnología de discos ha crecido desde grandes grandes platos
que pesaban miles de kilos y mantenían 20 megabytes a delgados platos con pocos
centímetros de diámetro que pesan unos pocos gramos y contienen incluso miles
de Gb. A lo largo de ese viaje, lo programadores se han visto afectados por un
rasgo fatal de la tecnología de discos: la lentitud de estos.
En un disco, lo datos están almacenados dentro de pistas circulares. Estas
pistas están divididas en sectores que contienen un determinado número de
bytes, a menudo 4K. Cada plato puede tener cientos de pistas, y puede haber una
docena de platos. Si se quiere leer un determinado conjunto de bytes se tienen
que mover la cabeza a la pista y esperar que el disco rote al sector
correspondiente, leer los 4K del sector en la RAM y entonces indexar en un
buffer RAM para obtener los bytes que se quiere. Todo este proceso requiere de
un tiempo, milisegundos de tiempo.
Aunque los milisegundos puede que no parezcan mucho pero un milisegundo es
un millón de veces más grande que el ciclo de vida de la mayoría de los
procesos. Si los datos no estuvieran en un disco, este se podría acceder en
nanosegundos y no en milisegundos.
Para mitigar el retardo impuesto por los discos, se necesitan índices, caches
y optimizar esquemas de consulta. y necesita algún tipo de medio regular para
representar los datos para que estos índices, cachés y esquemas de consulta
sepan con qué están trabajando. En resumen, se necesita un sistema de
administración y base de datos. A lo largo de los años estos sistemas se han
dividido en dos tipos: sistemas de archivos y sistemas de administración de
bases de datos relacionales.
Los sistemas de ficheros está basados en documentos. Ellos proveen una
manera natural de almacenar documentos enteros. Ellos trabajan bien cuando se
necesita salvar y recuperar un conjunto de documentos por nombre pero ellos no
ofrecen mucha ayuda cuando estás buscando aquellos contenido en esos
documentos. Es fácil encontrar un documento llamado “login.c” pero es difícil y
lento encontrar todos los archivos “.c” que contengan una variable llamada “x”.
Los sistemas de bases de datos están basadas en contenido. Estas poseen una
manera natural y conveniente de encontrar registros basados en su contenido.
Estas son muy buenas asociando múltiples registros en algún punto del contenido
que todas comparten. Desafortunadamente, estas son pobres a la hora de
almacenar y recuperar documentos opacos.
Ambos sistemas organizan los datos en el disco de manera que ésta puede
almacenarse y recuperarse de la manera más eficiente posible dadas sus
necesidades particulares de acceso. Cada una tiene su propio esquema para
indexar y ordenar los datos. Además, cada una lleva eventualmente la
información relevante a la RAM donde esta se puede manipular rápidamente.
¿Qué pasaría si no hubiera disco?
Tan prevalentes como eran los discos, ahora son una raza en extinción.
Pronto habrán seguido el camino de las unidades de cinta, las unidades de
disquete y los CD. Están siendo reemplazados por RAM.
Hazte estas preguntas: Cuando todos los discos hayan desaparecido y todos
los datos estén almacenados en RAM, ¿cómo se organizarán los datos? ¿se
organizarán en tablas y se accederán con SQL? ¿se organizarán en ficheros y se
accederán a través de un directorio?
Por supuesto que no. Se organizarán en listas enlazadas, árboles, tablas
hash, pilas, colas o cualquier otra estructura de datos y se accederá usando
punteros o referencias, porque esto es lo que los programadores hacen.
En realidad, si piensas cuidadosamente sobre este problema verás que es lo
que realmente haces ahora. Incluso aunque los datos estén guardado es en una
base de datos o el sistemas de archivos. Tú lees esto en la RAM y entonces
organizas esto para tu conveniencia en listas, conjuntos, pilas, colas, árboles
o cualquier otra estructura de datos. Es muy poco probable que dejes los datos
en la forma de ficheros o tablas.
Detalles
Esta realidad es porque digo que la base de datos en un detalle. Esta es
simplemente un mecanismo que usamos para recuperar los datos de la superficie
del disco a la RAM. La base de datos no es más que un gran cubo de datos donde
se almacenan los datos a largo plazo.
Pero rara vez usamos los datos de esa forma. Por lo tanto, desde un punto
de vista arquitectónico, no deberíamos preocuparnos por la forma que toman los
datos mientras están en la superficie de un disco magnético giratorio. De
hecho, no debemos reconocer que el disco existe en absoluto.
¿Qué hay sobre el rendimiento?
¿Es el rendimiento un aspecto arquitectónico? Por supuesto que lo es, pero
cuando este viene del almacenamiento de datos este es un aspecto que puede
estar encapsulado enteramente y separado de las reglas de negocio. Sí,
necesitamos obtener los datos y guardar los datos rápidamente pero esto es un
aspecto de bajo nivel. Podemos abordar esa preocupación con los mecanismo de
acceso de bajo nivel. Esto no tiene nada que ver con la arquitectura general de
nuestro sistemas.
Conclusión
La estructura organizativa de datos, el modelo de datos, es
arquitectónicamente significativa. Las tecnologías y los sistemas que mueven
datos en superficies magnéticas giratorias no lo son. Los sistemas de base de
datos relacionales que fuerzan los datos a estar organizados en tablas y
acceder con SQL tienen que ver más con el segundo que con el primero. Los datos
son significativos. Las bases datos un detalle.
No hay comentarios:
Publicar un comentario