El otro día asistí a una presentación que dieron en la universidad en la que trabajo. La presentación era parte de un evento que se realiza todos los años para los estudiantes que están terminando sus estudios de informática. Entre otras cosas, empresas lider en el sector vienen a presentarse y a dar charlas sobre temas relacionados con su actividad.

El título de una de las presentaciones de este año me llamó la atención y por ello decidí asistir para ver de que trataba, el titulo de la misma era ¿Va siendo hora de tirar nuestra base de datos relacional?, fue dada por el CTO y desarrollador de software de una empresa importante de consultoria en Noruega.

La presentación se dividio en tres partes, en la primera se trataron todos los "problemas" que ocasiona una base de datos relacional a un desarrollador, en la segunda parte se trató brevemente el teorema CAP de Eric Brewer y al final se habló de las alternativas a bases de datos relacionales que grandes empresas de Internet usan, como "Google BigTable", "Amazon SimpleDB" y "Yahoo PNUTS" y los servicios que estas empresas dan basados en estos productos.

El tema como tal es bastante interesante para los interesados en computación distribuida, pero la presentación dio, bajo mi punto de vista, una imagen a los estudiantes totalmente erronea de la situación actual. El ponente dio a entender que un sistema como el de Google, Amazon ó Yahoo es la panacea y que la 'computación en nube' (cloud computing) es la solución a todos los problemas, desde los tecnológicos a los económicos. ¿Por qué tener una base de datos relacional local cuando puedes utilizar uno de estos servicios para almacenar datos en Internet?. Además, de esta manera los desarrolladores no tienen que aguantar las manias y requerimientos que los administradores de bases de datos suelen tener.

El teorema CAP viene a decir a grandes rasgos que, si asumimos que todo sistema distribuido tiene tres requerimientos: consistencia, disponibilidad y tolerancia a la división del sistema en particiones, no podremos nunca cumplir más de dos de estos tres requerimientos, llegados a ciertos niveles de actividad del sistema en los que el volumen de datos, la latencia del sistema y la disponibilidad del mismo se convierten en factores críticos.

Los sistemas que hemos citado antes son ejemplos en los que el teorema CAP se aplica a la perfección. Ademas estos sistemas no utilizan 'relaciones' sino llaves/valores, y se basan en mayor ó menor medida en lo que se denomina BASE (Basically Available, Soft state, Eventually consistent) como contraposición a ACID (Atomicity, Consistency, Isolation, Durability).

En estos sistemas la disponibilidad total del sistema se alcanza con la inconsistencia temporal de los datos y terminos como ACID, integridad referencial, joins ó tipos de datos son terminos desconocidos y no disponibles.

Es verdad que algunos sistemas, en especial sitios web, que necesitad valores especiales de latencia y disponibilidad, se pueden permitir esta inconsistencia y la falta de muchas caracteristicas disponibles en las bases de datos relacionales, pero también es verdad que la gran mayoria de sistemas no tienen estos requerimientos.

En mi opinión este tipo de bases de datos arreglan los problemas de un pequeño grupo pero no de la gran mayoria. Sinceramente, todavia nos quedan bases de datos relacionales por muchos años, sobre todo si la integridad y la consistencia de tus datos es una característica fundamental de tu sistema.

Yo por ahora lo tengo claro, ¿Y tú?,¿estas listo para tirar tu base de datos relacional?

--
Rafael Martinez
Webmaster