Las bases de datos relacionales, como MySQL, PostgreSQL y varios productos comerciales, nos han servido bien durante muchos años. Últimamente, sin embargo, ha habido mucha discusión sobre si el modelo relacional está llegando al final de su vida útil, y qué es lo que viene después de él.
¿Qué motor de base de datos debería usar?
Por supuesto, la respuesta es “depende”, pero esto no resulta de mucha ayuda. Déjame hacerte algunas preguntas para ayudarte a averiguar que tecnología es la apropiada para tu aplicación particular. Entonces, podré darte algunos consejos para que puedas conocer más.
Ante todo, calma. Lo más probable es que la base de datos que uses actualmente funcione perfectamente bien por ahora. Pero es posible que quieras estar atento en caso de que note algunos de los síntomas que avisan que el modelo relacional está trabajando al límite. Algunos síntomas relacionados con la estructura de tus datos:
- ¿Tienes tablas con varias columnas, y sólo algunas de ellas son actualmente usadas por una fila en particular?
- ¿Tienes tablas atributo donde cada fila es
(clave foránea a una fila de otra tabla, nombre del atributo, valor del atributo)
y necesitas hacer feos joins en tus consultas para tratar con esas tablas?
- ¿Has dejado de utilizar columnas para los datos estructurados, y en su lugar los serializar (a JSON, YAML, XML y otros) y almacenas la cadena resultante en tu base de datos?
- ¿Tiene tu esquema un gran número de tablas de unión muchos-a-muchos o estructuras tipo árbol (una clave foránea que hace referencia a una fila diferente de la misma tabla)?
- ¿Encuentras que con frecuencia tienes que hacer cambios en tu esquema para poder representar adecuadamente los datos de entrada?
Otros síntomas relacionados con la escalabilidad de tu sistema:
- ¿Estás alcanzando el límite de la capacidad de escritura con un sólo servidor? (Si tu problema es la capacidad de lectura, deberías establecer una replicación maestro-esclavo. Así mismo, asegurate que primero has puesto la base de datos en el servidor mas potente que puedas pagar, de que has optimizado tus consultas y que tu esquema no pueda dividirse fácilmente en fragmentos.
- ¿Tu cantidad de datos es mayor que la que un sólo servidor puede manejar?
- ¿La carga de tus páginas se ralentizan inaceptablemente por procesamientos en lote en segundo plano sobre la inmensa base de datos?
En mi opinión, se pone demasiado énfasis en la escalabilidad, a pesar de ser un problema muy lejano en la mayoría de los proyectos. Es comprensible – los sistemas a gran escala son sexis, y a todo el mundo le gusta pensar que están creando un servicio el cual va a ser muy popular – pero en la mayoría de las veces, los desarrolladores deberían centrarse en las necesidades de sus clientes, y resolver los problemas de escalabilidad sólo si realmente estos aparecen.
Dicho esto, hay una razón más para considerar las bases de datos no relacionales: están de moda. Es una idea tonta basar una decisión técnica en una moda, pero recuerda el aspecto humano de los proyectos de gestión de software. Los desarrolladores en general queremos trabajar con gente guay en un ambiente guay y usando tecnología guay. Eso significa que si quieres contratar desarrolladores y les proporcionas todo este ambiente guay, tendrás una mejor oportunidad de conseguir a los mejores. La moda no debería ser la razón principal, pero si todo lo demás es igual, probablemente puedes tirar por el lado guay. Y ahora voy a dejar de decir guay – no es muy guay.
Bases de datos documentales y la Big Table
Este artículo sobre la BigTable describe cómo Google ha desarrollado su propia base de datos altamente escalable para uso interno, como base de varios de sus servicios. El modelo de datos es un poco diferente del relacional: las columnas no necesitan ser predefinidas, y cada fila se puede agregar con cualquier conjunto de columnas. Las columnas vacías no se almacenan en absoluto.
La BigTable ha inspirado a muchos desarrolladores a escribir su propia implementación de este modelo de datos, dónde los más populares son HBase, Hypertable y Cassandra. La falta de un esquema predefinido pueden hacer atractivas estas bases de datos en aplicaciones dónde los atributos de los objectos no son conocidos de antemano, o cambian con frecuencia.
Las bases de datos documentales poseen un modelo de datos relacionado (aunque la forma en que manejan la concurrencia y los servidores distribuidos puede ser un poco diferente): una fila en la BigTable con un número arbitrario de columnas/atributos se corresponde a un documento en una base de datos documental, que normalmente es un árbol de objetos conteniendo los valores de los atributos y listas, a menudo mapeadas a JSON o XML. Bases de datos documentales de código abierto son Project Voldemort, CouchDB, MongoDB, ThruDB y Jackrabbit.
¿Y cuál es la diferencia con almacenar cadenas JSON en MySQL? Las bases de datos documentales pueden actualmente trabajar con la estructura de los documentos, por ejemplo extrayendo, indexando, añadiendo y filtrando datos basado en el valor de un atributo dentro de los documentos. Alternativamente, tu puedes por supuesto crear la indexación de los atributos por ti mismo, pero yo no lo recomendaría a menos que esto te haga trabajar con tu código antiguo más fácilmente.
La gran limitación de las bases de datos del tipo BigTable y las documentales es que la mayoría de las implementaciones no pueden realizar uniones (joins) u operaciones de expansión entre varias filas o documentos. Esta restricción es deliberada, porque permite a la base de datos el particionado automático, el cual es importante para escalar — véase la sección de almacenamiento distribuido de parejas de clave-valor a continuación. Si la estructura de tus datos es una gran cantidad de documentos independientes, esto no es un problema — pero si tus datos se acojen a un modelo relacional y necesitas hacer uniones, por favor, no intentes forzarlo a un modelo documental.
Bases de datos de gráfos
Las bases de datos de gráfos residen en el extremo contrario del espectro. Mientras las documentales son buenas para almacenar datos estructurados en la forma de muchos documentos independientes, las basadas en gráfos se centran en las relaciones entre los elementos — un mejor ajuste para los modelos de datos altamente conectados.
El SQL estándar no permite consultar las relaciones transitivas, es decir, un encadenamiento de longitud variable entre varias uniones que continúan hasta que algún tipo de condición se cumple. Las bases de datos de gráfos están optimizadas precisamente para este tipo de datos. Estos síntomas indican que sus datos encajarían mejor en un modelo gráfico:
- Escribes grandes cadenas de uniones (unión de la tabla A con la B, B con C, C con D …) en tus consultas.
- Escribe bucles de consultas en tu aplicación para conseguir una cadena de relaciones (particularmente cuando no sabes de antemano la longitud que tomará el encadenamiento).
- Tienes varias uniones muchos-a-muchos o estructuras tipo árbol.
- Tus datos ya están en una forma gráfica (por ejemplo la información sobre quién es amigo de quién en una red social).
Hay menos opciones en las bases de datos gráficas que documentales: Neo4j, AllegroGraph y Sesame (que normalmente utiliza MySQL o PostgreSQL como back-end) son las que mirar. FreeBase y DirectEdge han desarrollado bases de datos gráficas para su uso interno.
Las bases de datos gráficas se asocian a menudo con la web semántica y almacenes de datos RDF, que es una de las aplicaciones para las que son usadas. Realmente creo que muchos datos de otras aplicaciones estarían bien representados en gráfos. Sin embargo, como ántes, no trates de forzar los datos en un gráfo si encajan mejor en tablas o documentos.
MapReduce
Muy a la ligera: si el procesamiento por lotes en segundo plano es tu problema y no conoce el modelo MapReduce, debería. Popularizado por otro artículo de Google, MapReduce es una forma de escribir trabajos de procesamiento por lotes sin preocuparse por la infraestructura. Diferentes bases de datos se prestan mejor o peor al MapReduce — algo a tener en cuenta al elegir una base de datos para satisfacer nuestras necesidades.
Hadoop es el rey entre las implementaciones de código abierto, aunque también merece la pena mirar Skynet y Disco. CouchDB también incluye algunas ideas de MapReduce en una menor escala.
Almacenamiento distribuido de clave-valor
Un almacenamiento de clave-valor es un concepto muy simple, muy similar a una tabla hash: puedes recuperar un elemento basado en su clave, puedes insertar un par de clave-valor, y puedes borrar un par de clave-valor. El valor puede ser simplemente una lista opaca de bytes, o puede ser un documento estructurado (la mayoría de las implementaciones de bases de datos documentales o basadas en la BigTable se pueden considerar como almacenamientos clave-valor).
Las bases de datos documentales, gráficas y MapReduce introducen nuevos modelos de datos y nuevas formas de pensar que pueden ser útiles incluso en una aplicación de pequeña escala; no necesitas ser Google o Facebook para beneficiarte de ellas. El almacenamiento distribuido de clave-valor, por otra parte, va en realidad acorde con la escalabilidad. Pueden escalar cantidades verdaderamente enormes de datos — muchos más de los que un sólo servidor podría soportar.
Las bases de datos distribuidas pueden transparentemente particionar y replicar tus datos a través de varias máquinas en un clúster. No resulta necesario implementar un sistema de fragmentación para decidir sobre qué determinado servidor se puede encontrar un determinado fragmento de datos; la base de datos lo hace por usted. Si un servidor muere, no hay problema — otros pueden inmediatamente empezar a funcionar. Si necesita más recursos, sólo tiene que añadir los servidores al clúster, y la base de datos le asignará automáticamente una parte de los datos y de la carga.
Al elegir un almacenamiento de clave-valor, debes decidir entre si debe estar optimizado para una baja latencia (para un rápido acceso durante el ciclo de petición-respuesta típico de un servidor web) o para un rendimiento alto (usado en los trabajos de procesamiento por lotes).
Aparte de las basadas en la BigTable y las documentales, Scalaris, Dynomite and Ringo proporcionan cierta garantía en la consistencia de los datos, mientras que se encargan del particionamiento y la distribución del conjunto de datos. MemcacheDB y Tokyo Cabinet (con Tokyo Tyrant para el servicio en red y LightCloud para que sea distribuida) se centran en la latencia.
La advertencia sobre la limitación en las transacciones y las uniones se aplica incluso más fuertemente en las bases de datos distribuidas. Implementaciones diferentes tienen enfoques distintos, pero en general, si necesitas leer varios elementos, manipularlos de alguna manera y luego volver a escribirlos, no existe garantía de que va a terminar en un estado coherente inmediatamente (aunque muchas implementaciones tratan de convertirse eventualmente consistentes resolviendo conflictos de escritura o usando protocolos de transacciones distribuidas; véase el algoritmo de Amazon Dynamo para un ejemplo). Por lo tanto, sólo deberías utilizar estas bases de datos si tus datos son elementos independientes, y si la disponibilidad y performancia son más importantes que las propiedades ACID. Para más información, lea acerca del Teorema CAP de Brewer, que establece que entre la consistencia, la disponibilidad y el particionado, sólo podemos elegir dos, y nunca ninguna base de datos podrá saltarse este hecho.
Richard Jones, co-fundador de Last.fm, ha escrito una excelente visión de conjunto de los almacenamientos de clave-valor. También, Tony Bain ofrece una introducción a las diferencias conceptuales entre las bases de datos relacionales y los almacenamientos de clave-valor, y recientemente hubo un evento NOSQL en San Francisco, donde se presentaron una serie de diferentes bases de datos no relacionales.
Los sistemas distribuidos son poco amistosos… muy poco amistosos. Sugiero que se usen sólo si realmente necesitamos los aspectos de escalado que ofrecen (o sólo por diversión fuera de un entorno de producción).
Resumiendo
En este artículo me he centrado en proyectos de código abierto. Si usted está dispuesto a usar a un determinado proveedor de alojamiento, vale la pena considerar Google Datastore, Amazon SimpleDB, Windows Azure Storage Services o Force.com. Son tecnologías buenas, pero tenga en cuenta el riesgo potencial de los negocios cerrados.
No puedo hacer juicios sobre la idoneidad de determinados proyectos para fines particulares. Hay varias aplicaciones muy decentes, pero también hay algunas aplicaciones nuevas y muy inestables. Si vas a considerar el uso de alguna de ellas, deberás realizar tu propia investigación:
- Buscar en el sitio web del proyecto una lista de sitios que utilizan la base de datos en producción (y en qué aspecto de su servicio lo utilizan).
- Comprobar si tienen una comunidad de código abierto activa, para el caso que el desarrollador original pierda el interés y deje de mantener el software.
- Tratar de encontrar algún punto de referencia (aunque ten en cuenta que muchos puntos de referencia publicados en la web usan métodos defectuosos y/o anticuados, por lo que si buscas seriedad deberás ejecutar tus propias pruebas, usando datos que coinciden con las características de tu aplicación).
Y como pasa con cualquier tema de moda, hay muchas personas con opiniones fuertes, tanto positivas como negativas, no te dejes influenciar por ellos. Espero haberte dado una visión general de los tipos de cosas que puedes hacer con diferentes tipos de bases de datos para que puedas elegir el más adecuado a tu aplicación.