Cómo escoger la mejor base de datos para tu empresa (I)

Escoger la base de datos adecuada tiene una importancia crítica para el posible éxito de una aplicación. No es lo mismo una BBDD SQL que una NoSQL, si los usuarios de la misma pertenecen a la misma empresa o se encuentran distribuidos a nivel global, si vamos a trabajar con información estructurada o también no estructurada, o el volumen de información que necesitamos manejar…

A menudo sin embargo, las empresas no hacen demasiadas preguntas y acaban por trabajar bien con la que ya conocen, bien con las que les ofrece su proveedor «de siempre» y aunque a veces eso funciona, en otras los resultados dejan mucho que desear.

Para evitarlo, antes de desplegar una nueva aplicación, conviene preguntarse qué base de datos puede cumplir mejor con nuestros requisitos. Y es que como explican en Infoworld, antes de escoger una solución hay que ser capaces de responder adecuadamente a algunas preguntas. En la primera parte de este respondemos a las seis primeras.

¿Qué cantidad de datos vas a almacenar?

Si la cantidad de datos con las que vas a trabajar puede medirse fácilmente en gigabytes de información (o una medida menor), prácticamente cualquier base de datos moderna va a funcionar sin problemas. Incluso si la información se puede medir en terabytes, es fácil encontrar una gran cantidad de soluciones interesantes.

Ahora bien, si la cosa se pone seria y empezamos a hablar de petabytes (millones de gigabytes), solo unas pocas nos darán el servicio que precisamos. A esta escala deberemos estar preparados además para afrontar costes importantes, ya sea en el «hierro» necesario si lo vamos a hacer en nuestro propia data center, bien en los gastos operativos derivados del procesamiento de datos en la nube.

¿Cuántos usuarios se van a conectar de forma simultánea?

Estimar la cantidad de usuarios que se van a conectar de forma concurrente a una BBDD suele ser tratado por los departamentos de TI como un ejercicio de dimensionamiento de las capacidades del servidor, sin tener en cuenta el tipo de base de datos que se va a instalar.

Y esto es un error, porque hay que tener en cuenta que muchas soluciones no son capaces de dar respuesta a entornos en las que miles de usuarios consultan de forma concurrente terabytes o petabytes de datos, debido a problemas de escalabilidad.

Por supuesto, estimar el número de usuarios concurrentes es mucho más sencillo en el caso de una BBDD corporativa, restringida a los empleados de una empresa, que si ésta es pública. En este caso hay que asegurarse que la solución que se escoge es capaz de escalar a múltiples servidores, por ejemplo en periodos de tráfico realmente intenso (en un eCommerce podría ser el Blackfriday).

Desafortunadamente, no todas las bases de datos soportan este «escalado horizontal» sin llevar a cabo previamente una costosa tarea de mantenimiento manual para redimensionar las tablas más grandes.

¿Qué otros requisitos tienes?

En esta categoría entrarían requisitos como disponibilidad, escalabilidad, latencia, rendimiento y consistencia de datos. Veamos cómo afectan cada uno de estos requisitos a la elección de la base de datos.

La disponibilidad pesa sobre todo sobre las bases de datos transaccionales. Aunque no todas las aplicaciones necesitan tener un ratio de ejecución de 24/7 y el 99.99999% de disponilidad, para algunas otras es inevitable. Algunas bases de datos que se ejecutan en cloud ofrecen ese rendimiento de cinco nueves, siempre y cuando se ejecuten en distintas zonas de disponibilidad.

Si la intención es que la instalación sean on premises, pueden configurarse para ofrecer esa tasa de alta disponibilidad fuera de los períodos de mantenimiento programados, sobre todo si se pueden configurar dos nodos activos-activos.

En el caso de que nuestra principal preocupación sea la escalabilidad, conviene tener en cuenta que históricamente las bases de datos NoSQL han mostrado un rendimiento mayor, pese que algunas bases de datos SQL están mejorando en los últimos años. La escalabilidad dinámica se alcanza de forma más sencilla en un entorno cloud, donde puede resultar más fácil ampliar a nuevos servidores, hasta que el rendimiento sea suficiente para cumplir con la carga de trabajo en tiempo real.

La latencia se refiere tanto al tiempo de respuesta de la base de datos como al tiempo de respuesta de extremo a extremo de la aplicación. Lo ideal es que cada acción del usuario tenga un tiempo de respuesta de menos de un segundo, lo que a menudo se traduce en la necesidad de que la base de datos responda en menos de 100 milisegundos por cada transacción simple. Las consultas analíticas a menudo pueden tardar segundos o minutos.

Para el rendimiento en cambio, se tiene en cuenta el número de transacciones por segundos. Las bases de datos con mayor rendimiento son aquellas que además son capaces de gestionar un mayor número de usuarios de forma simultánea. Finalmente en el caso de la consistencia, esta suele ser más fuerte en las bases de datos SQL, lo que significa que todas las lecturas devuelven siempre los datos más recientes. En el caso de las bases de datos NoSQL, esta consistencia puede ser en ocasiones «eventual» lo que implica que a cambio de una latencia menor se corre el riesgo de leer datos obsoletos.

¿Tu base de datos va a tener una estructura estable?

Si la estructura de tu base de datos no va a cambiar de forma significativa a lo largo del tiempo y lo que deseas es que la mayoría de los campos incluyan características consistentes de registro a registro, entonces probablemente lo ideal sería decantarse por una base de datos SQL.

En caso contrario, tiene más sentido utilizar un base de datos NoSQL, alguna de las cuales ni siquiera soportan estructuras concretas.

Distribución geográfica de los usuarios

Hay que tener en cuenta que si los usuarios de la BBDD se encuentran distribuidos a lo largo del mundo, será imposible ofrecer la misma latencia a todos ellos a menos que establezcamos servidores adicionales en cada una de las regiones en las que se encuentran.

Algunas bases de datos permiten servidores de lectura-escritura distribuidos; otras en cambio ofrecen servidores de solo lectura distribuidos, y todas las escrituras se ven obligadas a pasar por un único servidor maestro.

La distribución geográfica provoca en este sentido, que el equilibrio entre consistencia y latencia sea aún más difícil. Solo algunas BBDD soportan nodos distribuidos a nivel global ofreciendo a la vez una consistencia fuerte de los datos. La mayoría de las bases de datos que soportan esta estructura, utilizan grupos de consenso para acelerar la escritura sin degradar la consistencia.

Estructura de los datos

Habitualmente, las bases de datos SQL almacenan datos estructurados, normalmente alojados en tablas con sus filas y sus columnas. Este tipo de bases de datos se basan en relaciones definidas entre las distintas tablas, utilizan índices para acelerar las consultas y funciones específicas que permiten consultar varias tablas a la vez.

Las bases de datos de documentos suelen almacenar archivos JSON de escritura débil que puede incluir matrices y documentos anidados. Las bases de datos gráficas almacenan vértices y bordes, triples, quads, etc. Otras categorías de bases de datos NoSQL también incluyen campos de valores clave y columnas.

A veces los datos se generan en una forma que facilitarán se se puedan analizar; a veces no, y será necesario transformarlos. Y a veces un tipo de base de datos se construirá sobre otra.

En la segunda parte de este artículo hablaremos además de otros factores determinantes como la importancia del ratio lectura/escritura, los distintos tipos