La creación de un nuevo proyecto incluye la elección de la base de datos adecuada para almacenar los datos. Muchos desarrolladores que conozco eligen la base de datos relacional por defecto desde el principio. Pero, ¿es la mejor decisión? Por supuesto, depende de muchos factores. En este artículo, me gustaría presentarte otros tipos de bases de datos para facilitarte la elección y ayudarte a estar preparado en tus futuros proyectos.
El tipo de base de datos no es el único tema a tener en cuenta. Hay muchas otras cuestiones en las que pensar, por ejemplo, ¿cuántos usuarios activos puede tener la aplicación? ¿Necesita una gran coherencia en todas partes? ¿Bastará con la consistencia eventual en algunos casos? Hay muchas preguntas sin respuestas directas, ya que "cuanto más te metes en ello, más complicado se vuelve". Así que, por favor, ten en cuenta que este artículo se centra únicamente en los tipos de bases de datos.
Tómese una taza de café y disfrute de esta lectura.
Clasificación general de las bases de datos
Para empezar, conviene saber que existen dos tipos principales de bases de datos: relacionales (SQL) y no relacionales (NoSQL).
- Las bases de datos SQL están estructuradas de forma relacional, lo que significa que almacenan los datos en tablas y mantienen relaciones entre ellas.
- Las bases de datos NoSQL (No sólo SQL), a diferencia de las relacionales, no están bien estructuradas y, por tanto, permiten más adaptabilidad y flexibilidad.
Aparte de las dos anteriores, existe un tipo más: la base de datos en memoria. No se puede clasificar ni como relacional ni como no relacional porque tiene que ver con dónde se almacenan físicamente los datos. Toda base de datos puede almacenarse en un disco o en memoria.
Tipos de bases de datos
1. Relacional
En mi opinión, es el tipo de base de datos más popular. Funciona bien con datos estructurales en los que se desea mantener relaciones entre los registros. La estructura de la base de datos se describe en un esquema.
Las principales ventajas se refieren a las transacciones (ayudan a garantizar la integridad de los datos y siguen las reglas ACID) y a la capacidad de gestionar gran cantidad de consultas complejas.
¿Cuándo elegirlo?
Es útil para guardar datos que no cambian estructuralmente muy a menudo y que necesitas almacenar de forma permanente, por ejemplo:
- CRM (Gestión de las Relaciones con los Clientes),
- Gestión de pedidos,
- ERP (Empresa Planificación de recursos),
- almacenamiento de datos o gestión de inventarios,
- contabilidad o finanzas.
Ejemplos:
Amazon Aurora, Microsoft Azure Base de datos SQL, PostgreSQL, MySQL.
Las bases de datos relacionales son insuficientes para muchas aplicaciones nuevas y es necesario disponer de más de una base de datos. En la siguiente parte del artículo, me centraré en las bases de datos no relacionales.
2. Clave-valor
Almacena cada valor de datos con una clave única. Esto significa que se accede a los datos mediante una única clave, al igual que se hace en un mapa hash. A diferencia de las bases de datos relacionales, no aplica el esquema ni las relaciones entre registros. La mayoría de estas bases de datos no admiten normalmente operaciones de actualización. Para modificar los datos, hay que sobrescribir todo el conjunto existente.
¿Cuándo elegirlo?
Es útil para datos que se quieren leer/escribir rápidamente (pero que no se actualizan muy a menudo):
- pujas en tiempo real, ad serving,
- caché de datos,
- gestión de sesiones,
- carritos de la compra,
- preferencias de los clientes o gestión de perfiles.
Ejemplos:
Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.
3. Documento
Almacena colecciones de documentos. Cada documento contiene campos con datos, que pueden ser valores simples o elementos complejos, como listas o colecciones de hijos. Es importante saber que cada documento puede tener una estructura diferente, aunque representen lo mismo (cada documento es único y evoluciona con el tiempo). Por ejemplo, el primer documento de cliente contiene menos información que el segundo:
{
"Nombre": "John",
"LastName": "Falso",
"Motos:" [
{
"Modelo": "BMW",
"Año": 2020
}
]
}
{
"Nombre": "Alex",
"LastName": "Nolastname",
"Edad": 15,
"Dirección": {
"País": "Polonia",
"Ciudad": "Somewhere"
},
"Motos:" [
{
"Modelo": "BMW",
"Año": 2020
}
]
}
¿Cuándo elegirlo?
Es útil para datos que requieren un esquema flexible para un procesamiento rápido:
- producto catálogos,
- CMS (sistema de gestión de contenidos),
- perfiles de usuario y personalización.
Ejemplos:
Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.
4. Gráfico
Utiliza una estructura de grafos y se compone de dos elementos: nodos y aristas. Los nodos son análogos a las filas de una tabla o a los documentos JSON. Las aristas son relaciones entre los nodos - son tan importantes como los nodos. Ambos pueden tener propiedades. Además, las aristas pueden tener una dirección definida de una relación.
¿Cuándo elegirlo?
Es útil cuando sus datos son similares a un gráfico, es decir, las relaciones entre los elementos de datos son dinámicas y cambian con el tiempo. Además, es una buena opción para cuando una empresa o un técnico equipo necesitan comprender las relaciones dentro de sus datos. Algunos ejemplos destacados son:
- organigramas,
- detección del fraude,
- gráficos/redes sociales,
- recomendaciones motores,
- gráficos de conocimiento.
Ejemplos:
Amazon Neptune, Neo4j, ArangoDB, Titan.
5. 5. Series temporales
Almacena datos organizados por tiempo. Suele acumular enormes cantidades de datos en tiempo real. Se utiliza sobre todo para guardar datos, aunque su actualización es muy poco frecuente. Generalmente, se utiliza una marca de tiempo como clave principal y/o para ordenar los datos. Algunas bases de datos permiten definir etiquetas para incluir información adicional, como el origen o el tipo de datos.
¿Cuándo elegirlo?
Es útil para almacenar pequeñas cantidades de datos anexados secuencialmente en orden cronológico, por ejemplo en:
- DevOps,
- supervisión de aplicaciones,
- monitorización y telemetría de eventos,
- IoT aplicaciones (como la recogida de datos de los sensores de los dispositivos).
Ejemplos:
Azure Time Series Insights, Amazon Timestream, InfluxDB.
6. Libro mayor
Proporciona un registro de transacciones inmutable, transparente y verificable criptográficamente, propiedad de una autoridad central. - Visión general de QLDB de Amazon
Vamos a explicar brevemente cada palabra clave de la cita anterior:
- inmutable - significa que un registro creado en esta base de datos no puede ser borrado, modificado o incluso sobrescrito,
- Transparente: rastrea y mantiene un registro secuencial de cada cambio en sus datos,
- verificable criptográficamente: los datos creados en esta base de datos se verifican mediante técnicas criptográficas de hash, similares a las de las cadenas de bloques (utilizando la función hash SHA-256).
¿Cuándo elegirlo?
Es útil almacenar un historial preciso, por ejemplo, registrando la entrada secuenciada de cada cambio de datos, como en:
- finanzas (historial de transacciones de débito o crédito),
- fabricación (rastrea de dónde proceden las piezas),
- seguro,
- RRHH y nóminas,
- al por menor,
- cadenas de suministro.
Ejemplos:
Amazon QLDB
Conclusiones
No hay una respuesta sencilla a la pregunta planteada en el título de este artículo. La única manera de elegir la base de datos adecuada es conocer mejor tus datos. Responda a la pregunta: "¿Qué tipo de datos genera tu aplicación?", y podrás tomar las decisiones correctas.
Además, debe conocer muy bien los requisitos de la empresa y el dominio de la aplicación. Debe saber cómo utilizará los datos, qué consultas enviará a la base de datos, cuántas veces conservará, leerá, actualizará o eliminará los datos. Todas estas cosas importan, pero no todos los desarrolladores prestan suficiente atención a estas áreas.
Por favor, piensa en tus datos en la aplicación que desarrollas para mejorar/crear un software mejor. En general, espero que conozcas tus datos lo suficiente como para almacenarlos en un lugar donde sean felices.
Más información:
Algunos trucos para acelerar su aplicación JavaScript
Formas de aumentar el rendimiento de Rails
Hechos y mitos sobre la cooperación con un socio externo de desarrollo de software