Traduzco el artículo Paradigm Shift de plok (Jan Lehnardt):

Las bases de datos que usamos hoy se diseñaron hace 20 o 30 años. Saltemos al DeLorean y visitemos los 70.

Los ordenadores eran máquinas masivas. Eran muy caras y sólo había unas pocas, por lo que su disponibilidad era escasa. Tampoco eran rápidas (cualquier mando a distancia de hoy día es más rápido) y se usaban principalmente en un entorno científico.

Un escenario: Un científico investiga algo (ellos hacen esas cosas) y llego al punto de obtener tablas y tablas de datos y ahora quiere hacer algo de análisis. Él solicita un turno de tiempo para una de esas máquinas masivas, espera unas pocas semanas y entonces puede enviar los datos e instrucciones a ejecutar en esa máquina. Si el conjunto de datos es demasiado grande o las instrucciones demasiado chapuceras y los cálculos llevan más tiempo del asignado al turno... bueno, lo has adivinado: de vuelta a la mesa de dibujo.

Las bases de datos relacionales se diseñaron en ese mundo. Requieren enormes cantidades de trabajo en primer lugar (diseño de esquema, normalización de datos, diseño de consultas, optimización de rendimiento) para permitir que consultas simples se ejecuten a la máxima velocidad. Y esto tenía sentido. En aquella época.

El mundo de la informática y los patrones de uso de hoy son fundamentalmente diferentes. Miles de usuarios actualizan su estado en Twitter y Facebook este mismo minuto, en paralelo. Ellos lo hacen desde todas las partes del mundo sin interrupción; internet siempre está despierto.

El hardware ha cambiado también. Viniendo de enormes máquinas de una sola CPU, ahora tenemos enormes cantidades de cajas de artículo con configuraciones multi-núcleo y multi-cpu. De nuevo, hay una diferencia fundamental.

Lo que me resulta pasmoso es que aún usemos bases de datos que fueron utilizadas para unos casos de uso totalmente diferentes. Lo que resulta incluso más asombroso es que estas bases de datos están preparadas para el trabajo. Hay un montón de trabajo invertido, pero al final, todas los páginas web de alto tráfico utilizan alguna RDBMS. Y estoy muy impresionado con el hecho de que estas RDBMS realmente funcionen en este particular entorno hostil (para ellas).

Ahora esto no es enteramente cierto: "Un montón de trabajo invertido" en este caso significa romper con las leyes de diseño fundamentales del almacenamiento de datos relacionales: Desnormalización, redundancia, consistencia eventual. El resultado es escalabilidad: Hacer que un servicio se ejecute sobre suficiente hardware de forma que todos los usuarios puedan enviar sus mensajes, actualizar sus perfiles y subir sus vídeos.

---

¿Cómo puedo escribir ocho párrafos sin mencionar aquí CouchDB? Mencionaré una pequeña anécdota aunque es más sobre Erlang que sobre CouchDB: En una actuación de consultoría teníamos una hermosa imposición para ejecutar una RDBMS y con años de análisis, optimización y cacheo hemos conseguido un par de centenares de peticiones concurrentes por cada servidor. Esto es suficiente para la aplicación y, probablemente, suficiente para crecer los próximos años.

Haciendo una simple prueba de rendimiento concurrente se revela que puedo servir unas 1000 peticiones de lectura concurrente con CouchDB desde mi Mac Mini (el límite aquí es realmente la entrada/salida del disco, ya que CouchDB no realiza ningún tipo de cacheo interno por el momento (aunque lo hará pronto, no te preocupes :) Las lecturas son lo suficientemente aleatorias como para eliminar las cachés de disco y del sistema de archivos).

Pero esta no es una comparación justa, las peticiones no realizan los mismos cálculos por lo que no pueden ser comparadas. Pero tampoco son justas de la otra forma: CouchDB y los tests no están optimizados mientras que la otra instalación ha llevado unos cuantos años en realizarse.

Pero lo que hace es ilustrar perfectamente que optimizar una sola consulta en una base de datos relacional sólo te lleva a una mejora específica, y abrazar el mundo de la computación de hoy en día lleva a resultados más satisfactorios.

---

Y no, no estoy diciendo que los RDBMS sean una idea estúpida o vayan a desaparecer pronto.