bacterio77
08/03/23 19:17
Ha respondido al tema MongoDB
Ir a respuesta
EXTENSION ACTUAL DEL USO DE BASES DE DATOS EN LA WEBComo hemos visto, esa base de datos de nuestro ejemplo, que inicialmente empezó en una pequeña cadena de tiendas físicas, se puede modificar para albergar información de los usuarios, como comentarios, valoraciones, etc y dar el salto a una plataforma de ventas web.Pero esto se puede utilizar también para todo tipo de diseños web.Para quien haya creado una pequeña web estática (es decir, que no use bases de datos), sabrá que en realidad se trata de un conjunto de páginas, hasta cierto punto parecidas a un documento de Word, interconectadas por hipervínculos. Estas páginas se suben al servidor, pero también podrían usarse desde una carpeta de un pc y se podría navegar entre ellas de forma similar. Todas las páginas web han sido creadas explícitamente por una persona y se localizan en el servidor. Pero en realidad esto no es lo habitual.En la mayoría de webs comerciales, con cantidades de productos y otros tipos de información que se actualiza constantemente (pongamos el ejemplo de Amazon, para seguir con las “librerías”) el funcionamiento es distinto. Cuando entramos en la descripción de un producto, donde nos aparecen las valoraciones, especificaciones, foto, precio, vinculo al carro de la compra…. En realidad se trata de una plantilla que accede a una base de datos en un servidor y utiliza la información que extrae de ésta para reconstruir la página web.En realidad, podemos ir más allá del comercio electrónico y pensar en cualquier red social, como por ejemplo la misma Rankia. Cuando escribimos un post como este, no se está generando una página nueva, sino que guardando información en una base de datos. Cuando se actualiza la página de los foros, se recurre a una base de datos para regenerar la página con los últimos hilos en los que se ha escrito.En realidad, prácticamente cualquier servicio basado en la web va a requerir este tipo de tecnología. COMPLEJIDAD Y ESCALABILIDAD LIMITADA DE BASES DE DATOS TRADICIONALESEste apartado es importante para entender una de las ventajas de MongoDB, la ESCALABILIDAD de las bases de datos.Según el tamaño y complejidad de la base de datos, aumenta la cantidad de trabajo que el ordenador (o más concretamente el servidor) tiene que realizar.Y aquí volvemos al principio: tenemos instalado un programa de gestión en nuestro PC, o en nuestro móvil, que accede a la nube, donde hay una base de datos de la que extrae información. ¿Pero dónde está, físicamente, esa base de datos?. En un servidor o unos pocos servidores. Ahí tenemos un problema, puesto que el numero de servidores no puede ser infinito: en una red grande (pensemos de nuevo en Amazon o Facebook) hay muchos usuarios accediendo al mismo tiempo a los datos, modificando esta información, haciendo compras, escribiendo comentarios, valorando (puntuando) esos productos… El archivo que contiene todos estos datos se va actualizando en tiempo real, y si hay muchos servidores con copias de ese archivo, los cambios que se hacen en uno deben trasladar a los demás de una forma rápida para evitar inconsistencias en la información de la web.Supongamos por ejemplo que en una gran red social se crea una funcionalidad que permite ver todos los “me gusta” que ha indicado un usuario. Existiría una enorme tabla de “me gustas”, en los que cada “me gusta” escrito por cada usuario aparecería como un registro independiente. Cada registro tendría, al menos, además del identificador propio del registro, un campo con el identificador del comentario al que se refiere y otro campo con un identificador del usuario. Imaginad el enorme tamaño de una tabla como esta. Pues bien, si entramos en nuestro usuario y revisamos nuestros “me gusta”, estamos obligando al servidor a buscar en esa enorme tabla todos y cada uno de los registros en los que aparece nuestro identificador. Aunque la capacidad de procesamiento de los ordenadores actuales permite realizar la búsqueda relativamente pronto, teniendo en cuenta que ese servidor tiene que dar servicio a muchos usuarios, es fácil imaginar la sobrecarga que este tipo de procesos.Además, según como esté organizada la base de datos, ciertos tipos de búsquedas pueden ser bastante complicadas: por ejemplo, podríamos tener que acceder a un usuario y cruzar su id con una tabla en la que aparezcan todos los comentarios escritos en esa web y tener que separar aquellos hechos por este usuario, y cruzar con una tercera tabla para ver las valoraciones que han hecho otros usuarios de ese comentario… y el proceso se podría hacer tan complejo como se quiera imaginar.Concluyo este apartado con una matización que quizás se salga del tema principal, porque muchos preferirán saltar hasta el siguiente apartado.En realidad, existe algún truco para agilizar este tipo de búsquedas, que consistiría en guardar información redundante, pero que nos permitiría reducir el número de búsquedas realizadas por el servidor. Por ejemplo, para la forma teóricamente idónea para saber cuantos me gusta ha recibido uno de nuestros estados en Facebook sería que el servidor buscara el código interno de ese estado y lo usara para, en esa tabla enorme de “me gustas”, contara cuantos hay referidos a ese estado. Pero una alternativa sería que en la tabla donde se almacena la información del estado se añadiera un campo que indicara el número de “Me gustas”, y cada vez que un usuario hiciera click, se incrementara en 1. Solo en el caso de que alguien quisiera comprobar a quien le ha gustado el comentario sería necesario recurrir a la otra tabla. Pero eso, en teoría, violaría uno de los principios ideales de las bases de datos relacionales, la normalización, que viene a decir que la información no debería aparecer de forma redundante (duplicada).Desde el punto de vista teórico, la normalización puede estar bien, pero en la práctica, conforme aumenta el tamaño (numero de registros por tabla) y la complejidad (número de tablas relacionadas) de nuestra base de datos, aumenta ingentemente el consumo de recursos que el servidor dedica a las búsquedas. Sin embargo, el hecho de tener que realizar este tipo de “arreglos” (saltarse las reglas de “normalización”) para mejorar el rendimiento ya indica que el modelo original empieza a tener problemas.