El futuro de las bases de datos

14 Feb 2009

Me he pasado toda la tarde leyendo artículos sobre distintas bases de datos, esquemas relacionales vs key/value, normalización vs desnormalización, etc. Soy un novato pero me gustaría compartir algunos enlaces y conclusiones que he sacado, por si a alguien le interesa o puede aportar algo más al asunto.

El esquema más usado sin duda alguna es el relacional. En mi ejemplo, tendría países, regiones, ciudades y lugares de interés. Cada lugar tendría un campo country_id, region_id, town_id. Es un esquema ordenado (normalizado), bien claro y que funciona perfectamente con la mayoría de frameworks. El punto negativo es que para saber el nombre de la ciudad debemos unir (join) dos tablas (la de places y la de towns). Si tenemos pocas entradas y pocas visitas no hay problema. Sin embargo si tenemos éxito se puede convertir en una pesadilla (sobre todo si tenemos que usar varios servidores). Se puede cachear está claro, pero aquí estoy hablando de la base de datos en concreto.

Por eso, para webs que necesitan escalar sí o sí, se usa más un esquema key/value. En mi ejemplo, una sola tabla con la información del lugar, nombre de la ciudad, region y país. No hay que unir tablas ya que está todo en el value. Este esquema también se puede llamar document-oriented. El punto positivo es la escalabilidad, que las consultas a la BD son mucho más rápidas. Lo negativo es que te cambia el modelo al que estamos acostumbrados y tienes que rehacer muchos de los frameworks MVC.

Lo que recomiendan es empezar usando el modelo relacional (more tables). Si ves que tu tráfico crece, romper este esquema normalizado e incluir en la tabla de lugares, los campos que necesitamos al unir las tablas. En mi caso, meter country_id, country_name, region_id, region_name, town_id, town_name dentro de la tabla places; manteniendo las otras tablas (sólo que no las usaríamos ya tanto). Tendríamos información duplicada (los nombres) por lo que tendríamos que reformar nuestra lógica interna para actualizar esa información si cambiamos los nombres. Otra opción es crear tablas de las vistas (al estilo key/value). Y si tu tráfico crece demasiado, quizás te conviene rehacer de nuevo el modelo de la base de datos e ir enteramente al modelo key/value.

Y esta recomendación es sobre todo porque las bases de datos no relacionales, no están tan avanzadas porque las relacionales (MySQL y similares). Sin embargo hay algunas que hay que ver su evolución:

CouchDB es la niña bonita y donde más esperanzas se están poniendo, aunque ahora mismo está en alfa y supuestamente no está lista para producción. Apache lo seleccionó en Noviembre como uno de sus proyectos más importantes, en los que poner más energías. Se define como ” a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API“. hecha sobre Erlang. Perfecto para la nueva generación de servicios web REST-oriented.
Tokyo Cabinet, hacen una buena explicación de cómo funciona y sus características. Está desarrollado por Mixi (el Facebook japonés). Página oficial.
Scalaris, contruida también sobre Erlang.
Project Voldemort, usada en LinkedIn. Java
Hypertable intenta imitar a la base de datos de Google (BigTable). Está patrocinada por Baidu, el mayor buscador Chino. C++
SimpleDB, de Amazon. Tienes que usar su hardware, no puedes instalártelo en tus servidores.

No todas las webs funcionarían mejor con bases de datos no relacionales, pero muchísimos servicios web sí que lo harían. Por eso tras haber leído un poco intuyo que un breve futuro veremos muchos cambios en este terreno. Ya dije hace tiempo que me gustaba el enfoque de BigTable de Google y hoy lo repito. Ellos por supuesto, juegan en otro liga; pero hay conceptos que se pueden aplicar a menor escala para estar preparados.

Otros artículos y discusiones interesantes: