Néstor Daniel Lara Medina Administración de Base de Datos sección D01 Las bases de datos en el futuro. Actualidad Las economías alrededor del cómputo han cambiado gracias a los avances en hardware. Son comunes los servidores con múltiples procesadores/núcleos, los sistemas de 4 y 8 vías son accesibles, la memoria es mucho más económica, los discos duros son de mayor capacidad y mucho menor costo. Aún así, esta tercera generación de gestores de base de datos opera básicamente de la misma forma que la anterior, aunque los efectos de escalabilidad, desempeño, administración y ahorro en costo son dramáticamente mayores gracias a los avances de la tecnología. Futuro cercano La nube. Ofrece por primera vez la verdadera posibilidad de almacenamiento ilimitado. Bases de datos en data centers internos pueden “extenderse” a operar en centros de datos públicos. Microsoft SQL Azure es el mejor ejemplo. Sensores y tiempo real. En el mundo de los sistemas embebidos que manejan tecnologías como RFID y eventos en Internet, se hace necesario analizar la información y tomar acción en memoria y antes de almacenar datos. StreamInsight es una nueva característica en la reciente liberación de Microsoft SQL Server 2008 “R2”. Las bases de datos noSQL como futuro Hablar hoy de NoSQL como el futuro de los sistemas de bases de datos puede sonar un poco apresurado, pero hay movimientos importantes: el notable afán de Facebook por crear motores de bases de datos como Cassandra y RocksDB, y el uso de NoSQL en otras redes sociales como Twitter y Linkedin, que indican que todo apunta hacia servicios que usen repositorios datos con NoSQL únicamente. Pero hay dos problemas que retrasan este hecho. El primero es la resistencia al cambio pues se piensa que los motores de bases de datos no pueden resolver muchos problemas de la vida real (cabe señalar que la mayoría de los proyectos no usan ni el 50% de las bondades que ofrece SQL), un ejemplo concreto radica en los nuevos desarrollos, muchos piensan que con NoSQL no se garantiza la integridad de los datos, o la consistencia, pero hay métodos para poder hacer esto con bases de datos documentales por nombrar alguna. El origen de este problema, en mi opinión es tomar el tema de NoSQL desde un punto de vista SQL: es como comparar un automóvil con un helicóptero, ambos sirven para transportarse hasta la ciudad, pero el funcionamiento de cada uno de ellos no es similar, pilotar un helicóptero pensando que es automóvil es un grave error. El segundo gran problema es la diversidad de tipos de NoSQL que existen: clave/valor, documentos, grafos, tabular, entre otras. Las personas se confunden y abruman al tener que decidir cuál usar. Esa elección puede ser errada. Siempre será una apuesta muy fuerte saber si tu proyecto se alineará adecuadamente con el tipo de base de datos que se ha elegido. Para hacer esta elección es recomendable tener claro lo siguiente: 1. Qué tipo de proyecto se hará, si es para Internet o para el uso en intranet. 2. Cuál es la cantidad esperada de usuarios y si muchas de las funciones deben hacer uso de las transacciones complejas, o si, de lo contrario son escrituras y lecturas manejadas desde el software. 3. Qué tecnología se va a usar para el desarrollo (si usa Django por ejemplo, lo recomendable es usar BD Relacional, ya que es más natural el manejo de los datos en aplicaciones hechas en ese framework).