Guía completa para elegir Base de Datos: Todo lo que necesitas saber

Primero describiremos todas las características con las que podemos definir una base de datos, para saber qué se debe buscar al elegir una base de datos. A continuación veremos cómo elegir cuáles serían las mejores bases de datos en función de la aplicación empresarial: qué encaja mejor con el almacenamiento de datos de redes sociales, con buscadores de texto, con sistemas en real time, etc. Y para ello nos apoyaremos en varios puntos teóricos, como el teorema CAP y los modelos BASE y ACID.

Este artículo forma parte de nuestra serie donde te contamos todo lo que necesitas saber para adquirir las competencias necesarias para trabajar con bases de datos.

Si has seguido la serie de Bases de Datos, hasta ahora hemos planteado sus fundamentos teóricos, que resultan de utilidad para hacernos una idea de a lo que nos vamos a enfrentar, pero se queda insuficiente si en vez de informarnos lo que queremos es HACER.

Te recomendamos que acudas a nuestro artículo de tipos de bases de datos, si todavía no tienes muy claro cuáles son las distintas opciones de bases de datos y cómo están clasificadas.

Criterios que se utilizan para elegir una Base de Datos

Estas son las principales características que van a definir una base de datos. No vas a encontrar la base de datos perfecta y universal, puesto que hay funcionalidades incompatibles, por lo que tendrás que estudiar muy bien tu caso, ver qué necesitas, de qué recursos dispones, y en función de todo eso determinar cuál es la base (o bases) de datos que mejor encaja.

Lo que buscamos en una base de datos es:

1. Escalabilidad. Se trata de la capacidad de la base de datos para manejar eficientemente un crecimiento en el volumen de datos, el tráfico de usuarios y la demanda de rendimiento a medida que una aplicación o sistema se expande con el tiempo. Buscamos la escalabilidad en una base de datos para garantizar que pueda mantener un alto nivel de rendimiento y disponibilidad, incluso cuando la cantidad de datos y usuarios aumenta significativamente.
2. Conectividad e integración. Las bases de datos no solo están hechas para la escritura, sino también para la lectura y consulta por parte de aplicaciones analíticas. Para ello, base de datos y herramienta de explotación tienen que trabajar con los mismos protocolos de comunicación. Si no podemos acceder a una base de datos, la tendremos aislada y no va a aportar valor. Por tanto, un punto fundamental es que nos podamos conectar desde los sistemas que ya tenemos o vayamos a desarrollar.
3. SQL/Joins. No en todas las bases de datos podemos utilizar SQL (y derivados) ni operaciones como los joins. Bases de datos como las NoSQL no admiten joins. No son BBDD diseñadas para juntar documentos ni hacer consultas muy complejas.
4. Integridad. La integridad en una base de datos se refiere a la precisión, coherencia y validez de los datos almacenados en ella. Es una propiedad fundamental que se busca para garantizar que los datos sean correctos y confiables en todo momento. Es una característica propia de las bases de datos relacionales. Para asegurar la integridad de una base de datos, se utilizan diversas técnicas y restricciones, como la definición de claves primarias y foráneas, reglas de validación, restricciones de integridad referencial y procedimientos de almacenamiento que garantizan la coherencia y consistencia de los datos.
5. Rendimiento/Velocidad. Buscamos bajas latencias en una base de datos para minimizar el tiempo que tarda en responder a las solicitudes y consultas de los usuarios. Es una característica que va muy de la mano con la escalabilidad y con la que queremos garantizar una buena experiencia de usuario, mejorar los tiempos de respuesta en tiempo real, eficiencia en el trabajo y alta disponibilidad.
6. Disponibilidad. Con una alta disponibilidad aseguramos que los datos y las aplicaciones estén accesibles en todo momento, incluso en situaciones de fallo o interrupciones. La alta disponibilidad es esencial para garantizar una continuidad en el servicio, el cumplimiento de SLAs, mejora de la experiencia de usuario y resiliencia ante fallos.
7. Atomicity (ACID). Forma parte de las 4 características del modelo ACID. Es la capacidad de una transacción para ser tratada como una unidad atómica e indivisible. Esto significa que una transacción se ejecuta en su totalidad o no se ejecuta en absoluto; no puede quedar a medias ni ser interrumpida por otras transacciones. Por ejemplo, supongamos que tienes una transacción que realiza dos operaciones: transferir dinero de una cuenta a otra y actualizar el registro de la transacción. Si la transferencia de dinero se realiza con éxito, pero la actualización del registro falla, la atomicidad asegura que se revierta la transferencia y se restaure el saldo original de ambas cuentas. Se trata de una característica propia de las bases de datos relacionales.
8. Consistency (ACID). Buscamos la consistencia en una base de datos para garantizar que los datos se mantengan en un estado válido y coherente en todo momento. La consistencia es una propiedad fundamental de las bases de datos que asegura que las transacciones se realicen de manera ordenada y que los datos se actualicen de acuerdo con reglas y restricciones predefinidas.
9. Isolation (ACID). Buscamos el aislamiento en las operaciones de una base de datos para garantizar que múltiples transacciones puedan ejecutarse de manera concurrente de forma segura y sin interferir entre sí. El aislamiento se refiere a que cada transacción se ejecuta como si fuera la única en el sistema, sin ser consciente de otras transacciones que también se están llevando a cabo al mismo tiempo. Buscamos el aislamiento para prevenir conflictos, mantener la coherencia, garantizar la fiabilidad y controlar los niveles de acceso.
10. Durability (ACID). Buscamos la durabilidad en las operaciones de una base de datos para asegurar que una vez que una transacción ha sido confirmada (commit), los cambios realizados en los datos se mantengan de forma permanente y no se pierdan, incluso en caso de fallos o reinicios del sistema. Con la durabilidad buscamos conservar los cambios, recuperación ante fallos, integridad en los datos y cumplimiento normativo.
11. Facilidad de uso. Parece algo obvio, y en muchas ocasiones ni le damos importancia, pero la curva de aprendizaje también es algo a tener en cuenta. No por tener bases de datos con un lenguaje de consultas muy complejo o relaciones entre los datos muy elaboradas, va a garantizar que hagamos nuestro trabajo de forma eficiente. Hay que ser práctico y encontrar soluciones que se adapten bien a los recursos disponibles.
12. Partition Tolerance. Se trata de la capacidad del sistema para seguir funcionando incluso cuando se producen particiones o caídas parciales de la red que impiden la comunicación entre algunos nodos o componentes del sistema. Por lo tanto, el sistema puede mantener la disponibilidad y seguir respondiendo a las solicitudes de los clientes en las partes del sistema que no están afectadas por la partición, incluso si esto significa sacrificar la consistencia temporalmente.
13. Documentación/Comunidad. Bases de datos que se ajusten como un guante a tus necesidades, pero que no las use nadie, no siempre son buena idea, ya que es posible que la documentación no sea buena, o no la mantengan con asiduidad, y además no exista una comunidad grande de desarrolladores sobre la que apoyarte cuando surjan dificultades en el desarrollo.
14. Madurez. Elegir la base de datos más moderna, poderosa y con todas las funcionalidades puede ser tentador, pero mientras tu organización no tenga experiencia con esta base de datos, puedes terminar arrepintiéndote.
15. Costes. Al elegir una base de datos, es importante considerar varios costos asociados para tomar una decisión informada y adecuada para las necesidades del proyecto o aplicación. Algunos de los costes relevantes a tener en cuenta serían el coste de licencias, de infraestructura, mantenimiento, de personal, escalabilidad, rendimiento, migración, otras tecnologías para su integración, training del equipo y posibles licencias de sistema operativo asociado a esa base de datos.

Por fortuna, hay una gran variedad para escoger base de datos, y por ello la lista de características cada vez va a más. Ahora bien, no todas las características son compatibles. Apóyate en los modelos ACID y BASE para conocer en qué características tendrás que hacer más foco.

Modelo ACID

Se trata de un enfoque en el que se garantizan la integridad y consistencia eventual de las transacciones en una base de datos. Por tanto, las propiedades que la definen son Atomicity (Atomicidad), Consistency (Consistencia), Isolation (Aislamiento) y Durability (Durabilidad).

El cumplimiento de las propiedades ACID en una base de datos asegura que las transacciones sean confiables, consistentes y que los datos mantengan su integridad en todo momento. Es especialmente importante en aplicaciones y sistemas críticos donde la precisión y la seguridad de los datos son fundamentales.

Si quieres más información sobre las propiedades ACID te recomiendo que te pases por nuestro artículo de Tipos de bases de datos.

Modelo BASE

El modelo BASE es una alternativa al modelo ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) para el diseño y gestión de bases de datos en sistemas distribuidos y altamente escalables. BASE es un acrónimo que representa tres características principales:

1. Basically Available (Básicamente Disponible): Significa que el sistema estará siempre disponible para responder a las solicitudes de los usuarios, incluso en situaciones de fallos o particiones de red. A diferencia del modelo ACID, que puede sacrificar la disponibilidad en aras de la consistencia, el modelo BASE prioriza la disponibilidad para ofrecer una respuesta continua y consistente, aunque no necesariamente inmediata.
2. Soft state (Estado Suave): Implica que el sistema no siempre tiene que estar en un estado consistente, lo que significa que la consistencia puede tardar algún tiempo en alcanzarse después de una actualización de datos. Esto permite que los datos se repliquen y se propaguen gradualmente a través de nodos distribuidos, lo que puede introducir breves periodos de inconsistencia antes de alcanzar una consistencia eventual.
3. Eventually consistent (Consistencia Eventual): Indica que, a lo largo del tiempo, todos los nodos en el sistema eventualmente alcanzarán un estado consistente. No hay garantías de consistencia inmediata después de una actualización, pero mediante la propagación y reconciliación de datos entre nodos, el sistema alcanzará un estado consistente en algún momento.

El modelo BASE es especialmente adecuado para sistemas distribuidos de gran escala y alta disponibilidad, como bases de datos NoSQL y aplicaciones en la nube. Aunque puede permitir ciertos grados de inconsistencia temporal, ofrece una mayor disponibilidad y rendimiento en escenarios con alta concurrencia y particiones de red, lo que lo convierte en una opción valiosa para aplicaciones modernas que requieren escalabilidad y tolerancia a fallos. Sin embargo, es importante tener en cuenta que el modelo BASE puede requerir una mayor complejidad en la gestión de conflictos y reconciliación de datos que el modelo ACID. Ejemplos de bases de datos que se dictan por el modelo BASE serían Cassandra, DynamoDB, MongoDB o CouchDB.

Por ejemplo, aplicaciones de marketing o de redes sociales van a preferir un enfoque BASE, donde tengan un sistema de almacenamiento con alta previsión de crecimiento (escalable), alta disponibilidad y sin necesidad de una consistencia eventual muy estricta.

BASE vs ACID

El modelo BASE y el modelo ACID son dos enfoques diferentes para el diseño y gestión de bases de datos, y se utilizan en contextos específicos según las necesidades y requisitos del sistema. A continuación, te comparo ambos modelos:

• El modelo ACID garantiza la consistencia y la integridad de los datos en todo momento, priorizando la consistencia en detrimento de la disponibilidad. En cambio, el modelo BASE prioriza la disponibilidad y la tolerancia a fallos, permitiendo ciertos grados de inconsistencia temporal.
• El modelo ACID es más adecuado para aplicaciones que requieren un alto nivel de integridad y coherencia de datos, como sistemas financieros o médicos. El modelo BASE es más apropiado para sistemas distribuidos de gran escala y alta disponibilidad, como bases de datos NoSQL y aplicaciones en la nube.
• El modelo ACID puede requerir un mayor rendimiento y esfuerzo de gestión para garantizar la consistencia y la atomicidad de las transacciones. Por otro lado, el modelo BASE puede ser más complejo en la gestión de conflictos y la reconciliación de datos, pero ofrece una mayor disponibilidad y escalabilidad.

En resumen, el modelo ACID se enfoca en la consistencia inmediata y la integridad de los datos, mientras que el modelo BASE prioriza la disponibilidad y la tolerancia a fallos, permitiendo cierta inconsistencia temporal para lograr una mayor escalabilidad y disponibilidad en sistemas distribuidos. La elección entre ambos modelos dependerá de las necesidades y requisitos específicos de la aplicación y el sistema.

Teorema CAP

El teorema CAP, también conocido como el teorema de Brewer, es un principio fundamental en el diseño y desarrollo de sistemas distribuidos y bases de datos. Fue propuesto por Eric Brewer en 2000 y establece que en un sistema distribuido, es imposible garantizar simultáneamente las tres siguientes propiedades:

1. Consistencia (Consistency): Todos los nodos del sistema ven los mismos datos al mismo tiempo. Esto significa que, cuando se realiza una actualización en un nodo, todos los demás nodos ven esa actualización inmediatamente.
2. Disponibilidad (Availability): Cada solicitud de los clientes recibe una respuesta (ya sea éxito o error) sin garantías de que la respuesta contenga los datos más actualizados. En otras palabras, el sistema está siempre disponible para responder a las solicitudes de los clientes.
3. Tolerancia a la Partición (Partition Tolerance): El sistema continúa funcionando incluso si ocurren particiones o divisiones en la red que impiden la comunicación entre algunos nodos del sistema. En situaciones de particiones de red, el sistema puede seguir operando y atendiendo solicitudes locales.

El teorema CAP establece que un sistema distribuido solo puede garantizar dos de las tres propiedades mencionadas simultáneamente. En otras palabras, en una situación en la que el sistema se enfrenta a una partición de red (P), la elección está entre la consistencia (C) y la disponibilidad (A). Si se prioriza la consistencia, la disponibilidad puede verse afectada, y viceversa.

El teorema CAP ha sido fundamental para el diseño de sistemas distribuidos y bases de datos, ya que permite a los diseñadores y desarrolladores comprender las limitaciones y los compromisos que deben hacer para lograr un equilibrio entre consistencia y disponibilidad en entornos distribuidos.

Es importante destacar que el teorema CAP se aplica a sistemas altamente distribuidos y complejos. En sistemas más simples y centralizados, es posible alcanzar las tres propiedades (C, A, P) al mismo tiempo, ya que no enfrentan los mismos desafíos de comunicación y coordinación que los sistemas distribuidos más grandes.

Qué tenemos que plantearnos cuando escogemos una Base de Datos

Si ya tienes claro qué características estás buscando en una base de datos, lo siguiente será definirla. Es conveniente llevar a cabo un pequeño checklist de características que debe cumplir tu base de datos, de tal forma que te ayude a acotar más las opciones.

Los datos

1. ¿De qué tipo son los datos? ¿Estructurados, semi-estructurados, no estructurados?
2. ¿Vamos a almacenar datos sensibles? ¿Los podré alojar en la nube?
3. ¿Necesito un modelo de datos? Va a aportar más rigidez. ¿Cada cuánto podría cambiar ese modelo de datos?

Escalabilidad

1. ¿Qué volumen de datos tengo?, y lo más importante, ¿qué volumen de datos epsero tener en un futuro? ¿Cómo de rápido se espera ese crecimiento?
2. ¿Cuál va a ser la media de usuarios usando la base de datos y cuál será el pico de carga?
3. ¿Voy a necesitar una base de datos distribuida?
4. ¿Cuantos usuarios la van a utilizar?
5. ¿Qué ratio de lecturas/escrituras tendrás en producción?

Explotación del dato

1. ¿Qué carga media por usuario tendremos en las peticiones a la base de datos?
2. ¿Cómo voy a consumir los datos? ¿Necesito realizar consultas complejas con joins o simplemente acceder a los datos?
3. ¿Con qué frecuencia llegarán peticiones? ¿Y si se trata de un OLTP, con qué frecuencia llegarán las transacciones?
4. ¿En qué lenguaje vamos a realizar las consultas?

Acceso y disponibilidad

1. ¿Desde qué aplicaciones accederé a la base de datos?
2. ¿Cuál es su SLA?
3. Si estamos en la nube, ¿habrá periodos de apagado de las máquinas para ahorrar costes?

Arquitectura y diseño

1. ¿Para qué necesito la base de datos? ¿Transaccional, analítica? ¿OLTP u OLAP?
2. ¿Es imprescindible garantizar una consistencia eventual en los datos? ¿Quizá sea más interesante priorizar disponibilidad?
3. ¿De qué presupuesto dispones? ¿Qué recursos tienes disponibles? Tanto tecnológicos como humanos.
4. ¿Nube o on premise?
5. ¿Hot o cold storage?
6. En caso de partición en la red, ¿qué priorizamos? ¿consistencia o disponibilidad?
7. Geografía de la base de datos. ¿Será necesaria una replicación multizona en cloud?
8. El resto de sistemas que integren la base de datos, ¿serán compatibles?
9. Tenemos datos en varios formatos y departamentos que los explotan de varias formas. ¿Sería interesante desplegar dos o más bases de datos con otros formatos?
10. ¿Cómo se realiza un backup y un restore de la base de datos? ¿Cuento con los recursos?
11. ¿Tenemos en la empresa ya un acuerdo con algún vendor o plataforma cloud que nos ofrezca mayores descuentos?

Cómo escoger Base de Datos en función de tu aplicación empresarial

Vayamos a la parte práctica, es decir, ¿cuál es el sistema de almacenamiento que mejor se ajusta a la aplicación que estamos desarrollando? Tenemos una gran cantidad de opciones, y cada caso es muy diferente, ya que las bases de datos se tienen que integrar con otros recursos, y los datos que se manejan son cada vez más variados. Vamos a presentar algunas soluciones que se aplican habitualmente en arquitecturas donde se integran una o más bases de datos.

En este apartado se han incluido sistemas de almacenamiento digital, y no estrictamente una base de datos como tal, de tal forma que podamos ver la foto completa de los sistemas de almacenamiento de datos y componentes de software en un proyecto técnico.

Datos de aplicaciones

1. Web/App móvil. Para datos transaccionales de la web (ventas, pedidos, etc…) y usuarios, lo mejor es una base de datos relacional como Oracle, SQL Server, PostgreSQL (también compatible con JSON) o MySQL. Esta opción es especialmente útil si luego vamos a analizar los datos y ejecutar joins entre tablas, aunque no es de las más escalable. Si no queremos ceñirnos a un esquema de datos, tener mayor flexibilidad en las entradas de datos y mayores posibilidades de escalado, quizá sea más interesante una base de datos NoSQL como MongoDB, basada en documentos y con el formato JSON por defecto. Otra opción muy interesante con escalado horizontal en NoSQL sería Couchbase. Para el almacenamiento de imágenes y otros archivos se puede usar el propio servidor de la Web, un Storage de la nube como Amazon S3, Azure Blob Storage o Google Cloud Storage, o un CMS como veremos más adelante. Por último, también mencionar que existen soluciones más integrales, como Firestore de Google, donde están incluidos un conjunto de recursos para el desarrollo de nuestras aplicaciones.
2. Media. Base de datos para almacenamiento de audio y vídeo. Para ambos casos, tenemos la opción de un Storage en la nube. También hay otras alternativas en el caso del audio, pues bases de datos como MySQL o MongoDB son compatibles con este formato. Siempre es recomendable tener una tabla con los metadatos de lo que hemos almacenado, así como la URL de alojamiento del archivo. Siempre que el archivo sea susceptible de ser cambiado, lo mejor es que estén accesibles desde un servidor, mientras que si son imágenes que no van a cambiar nunca, las podemos empaquetar en la propia aplicación (en el caso de una app móvil). Otra opción sería tener un servidor/contenedor dedicado con un servicio de búsqueda de archivos.
3. Videojuegos. Va a depender mucho del tipo de juego y los objetivos a cubrir. Por ejemplo, para datos estáticos del juego como características de personajes, puede servir una base de datos relacional, incluso un SQLite, que se trata de un SQL pensado para ir embebido en aplicaciones. Por otro lado, puede resultar crítica la velocidad y latencia, por lo que bases de datos extremadamente rápidas como Redis, Google Spanner o incluso MongoDB, pueden servir. No obstante, el desarrollo de un videojuego es complejo e implica mucho contenido, por lo que hay que estudiar cuidadosamente cada caso, y lo normal es utilizar más de una base de datos.
4. Base de datos compartida con app y web. Es muy común tener una base de datos de usuarios/clientes compartida por varios microservicios. Para este caso tendríamos que seguir el mismo criterio que en los apartados 1 y 2, pero en este caso añadiríamos una capa por encima de la BD, una API que se encargue de recibir todas las peticiones de los servicios y repartirlas entre las BBDD. Se suelen desarrollar en Node.js, Ruby, Django (Python) o C#. De esta forma establecemos un único punto de entrada de las bases de datos. Aunque no se ha comentado por simplicidad en los apartados 1 y 2, toda arquitectura productiva con base de datos tiene que llevar un backend con una API que sirva de conexión.
5. OLTP. Los gestores de bases de datos de OLTP son sistemas de bases de datos diseñados para el procesamiento eficiente de transacciones en tiempo real en aplicaciones comerciales y en línea, donde se requiere un alto rendimiento y una concurrencia de múltiples usuarios. DBMS que nos sirven como OLTP son SQL Server, MySQL, PostgreSQL, Oracle Database o SAP HANA. Estas bases de datos tienen que asegurar la atomicidad, consistencia, aislamiento y durabilidad de las transacciones (ACID).

Datos para analítica

1. OLAP. Es un tipo de gestor de base de datos que se utiliza para el análisis y procesamiento de datos. Se enfoca en consultas complejas y en generación de informes basados en grandes volúmenes de datos. En este apartado encontramos una gran cantidad de proveedores. Podemos encontrar sistemas OLAP tradicionales como IBM Cognos, Pentaho o Apache Kylin, aunque los sistemas OLAP están evolucionando en o bien soluciones integrales de Big Data tipo Snowflake o (datamarts + herramienta de BI). Esta segunda opción es de lo más habitual, y podemos tener simplemente una base de datos relacional con los datos agregados y destinados para la analítica, y conectada a una herramienta de BI como Talbeau, Power BI o QlikSense.
2. Buscadores/Texto. Si la aplicación se centra en la búsqueda y recuperación de información, las bases de datos de búsqueda como Elasticsearch, Apache Solr o PostgreSQL FTS son buenas opciones. Estas bases de datos están diseñadas específicamente para indexar y buscar grandes volúmenes de datos no estructurados o semiestructurados.
3. Modelos de Machine Learning. Los modelos de Machine Learning simplemente son objetos, binarios, archivos que se pueden almacenar en cualquier Storage en Cloud. Otra cosa son los datos con los que se entrenan, que para ello están el resto de soluciones que se describen en este apartado. También podemos utilizar una solución PaaS como Vertex de Google, con la que ahorramos ciertas tareas en la puesta en producción, entrenamiento y el versionado de los modelos.
4. Bases de datos para análisis masivos. Cuando empezamos a tener un gran volumen de datos, ya no nos vale un simple SQL, puesto que no son bases de datos diseñadas para escalar con Tb de información, y por tanto hay que acudir a otras soluciones. El ecosistema de Apache es el más extendido, utilizando el sistema de ficheros distribuido de Hadoop, el HDFS y el motor de procesado Spark. Otras opciones sería utilizar un SaaS en la nube como Snowflake, Amazon Redshift, Google Big Query o Azure Synapse Analytics, que no solo nos ofrecen computación altamente escalable en la nube, sino también storage y herramientas para la analítica.
5. Mapas/Datos geográficos (GIS). Por un lado se almacenan los datos espaciales, que se componen de capas, polígonos y vectores, los cuales pueden ser imágenes o archivos con un formato específico como .SHP .GLM o .KLM, orientados a los software de análisis de mapas. También están los formatos orientados al desarrollo de software como .JSON o .GEOJSON. Y por otro lado, se encuentran los atributos de los objetos y polígonos, que pueden ir o bien a una base de datos SQL/NoSQL, o bien directamente integrados en los archivos con extensiones mencionados anteriormente. Por tanto, soluciones como MongoDB o CosmosDB son perfectamente válidas, incluso una base de datos relacional como PostgreSQL, con su extensión PostGIS. Ahora bien, si simplemente tenemos que almacenar archivos con información no estructurada, lo más cómodo es un Storage done almacenar archivos no estructurados. Otras opciones interesantes podrían ser Snowflake, Teradata o Esri.

Archivos y backups

1. Ingesta de archivos. Cuando tenemos un Data Lake, es necesario volcar todas las fuentes de información, para que estén disponibles desde el mismo sistema. Las fuentes origen pueden ser bases de datos SQL o NoSQL, archivos, APIs o incluso sistemas de volcado automáticos como los conectores de Big Query. Aquí lo recomendable primero es ver si en la solución Cloud del Data Lake ya tiene un conector que permite realizar el volcado automáticamente. De no ser así, se podría atacar a la API con consultas HTTP o a la base de datos. En cuanto a la fuente destino, puedes o bien transformar los datos para que se encuentren en un formato similar a los datos de destino, o mantener el formato de fuente origen en el caso de que en destino tengas el mismo DBMS. Dependerá del caso, puede que no tengas que ingestarlo y lo consumas dese su database original.
2. Mails/tweets/mensajes. El tipo de almacenamiento va a depender de cómo lo vayamos a explotar, del volumen de datos y de si hay metadatos asociados. Si los datos son muy masivos, lo más lógico sería descartar una base de datos SQL, al no ser éste su fuerte. Muchas aplicaciones y librerías están configuradas para trabajar con sistemas estructurados de archivos, por lo que mantener la estructura en un Storage puede resultar interesante. No obstante, si hay previsiones de que vaya a aumentar considerablemente el volumen de datos de la aplicación, existen metadatos y se pretende usar los datos para analítica, lo más cómodo sería un NoSQL como MongoDB.
3. Backup de bases de datos y otras aplicaciones. Siempre que empecemos a utilizar una aplicación, como por ejemplo un RDBMS, tenemos que configurar la forma de realizar backups, ya que en cualquier momento se puede producir una pérdida de información, un error humano o corrupción en el software, por lo que es posible que haya que recuperar los datos de la base de datos desde el punto en el que estaba estable. Los backups no son más que archivos donde se aloja el estado en el que se encuentra el software en un momento determinado. Se recomienda hacer dos tipos de backups, uno en local y el otro en la nube. Lo ideal es que en el DBMS se pueda configurar directamente el backup o de lo contrario tendremos que desarrollar nuestro propio sistema de backups.

Real-time

En el almacenamiento de datos en real-time tenemos que diferenciar entre hot storage y cold storage, es decir, datos a los que necesitamos acceder de forma rápida vs datos almacenados que se emplearán en la analítica posterior. El hot storage garantiza una alta disponibilidad, se utiliza para acceder con frecuencia y se suelen usar cache databases y BBDD que tengan SSD, mientras que para el cold storage los datos no precisan de una respuesta inmediata y pueden tardar más tiempo en estar disponibles.

1. IoT/Sensores/Logística. Las BBDD forman un componente esencial de una red IoT. Buscamos flexibilidad, alta disponibilidad, escalabilidad y tolerancia al fallo. Normalmente una base de datos SQL no encaja en este modelo, pues son más rígidas, no sabemos exactamente lo que recibiremos de los sensores en un futuro, y ofrecen peor escalabilida. Por tanto, en este caso encajan mejor las BBDD no relacionales como Cassandra, Influxdb, CrateDB, Riak TS o MongoDB. Aunque si buscamos soluciones con mayor abstracción gracias a la nube, podemos usar Google IoT Core, Azure IoT o AWS IoT Platform. Para el hot data es muy habitual tener cloud functions o recursos de análisis en real time para el lanzamiento de alertas.
2. Mensajería/Eventos. No son bases de datos como tal, ya que no tienen un sistema de consultas y la estructura de la información viene dada por el proveedor de servicios, pero sí se trata de recursos cloud muy utilizados, empleados para conectar dos piezas de software mediante colas de mensajes que desencadenan procesos. Algunas soluciones de este tipo serían Pub/Sub de Google Cloud, Event Hub de Azure o Apache Kafka.
3. Datos de Redes Sociales. Una base de datos relacional podría servir perfectamente si tenemos claro el modelo de datos. Ahora bien, un SQL tradicional no escala bien y resultaría complejo introducir nuevos cambios. Por otro lado, una base de datos NoSQL como MongoDB quizá resulte más interesante al ser más flexible, pues es probable que los datos que recojamos cambien con el tiempo. También podríamos considerar bases de datos de grafos, que se utilizan en aplicaciones con modelos de datos complejos, donde se le da el protagonismo a las relaciones entre las entidades.

Media

1. CMS (Content Management System). Los CMS son aplicaciones que permiten crear, manejar y modificar contenido en una web o app sin necesitar conocimiento técnico. Son desarrollos que llevan meses, además del posterior mantenimiento y actualizaciones, por lo que quizá resulte interesante contratar una plataforma SaaS que nos ofrezca todo el CMS, de tal forma que lo gestionemos todo desde ahí. Buenas opciones para gestionar el CMS serían Hubspot, Joomla o Drupal. Son soluciones que normalmente cuentan con APIs de tal forma que podamos acceder a la información desde otras piezas de software.
2. Bancos de imágenes. Aquí no hay mucho misterio. Lo más cómodo sería un Storage bien estructurado donde almacenar las imágenes. Incluso se podría establecer una estructura en función del tamaño/resolución.
3. Streaming de vídeo. Estas aplicaciones forman parte de una arquitectura compleja donde se da prioridad a la alta disponibilidad y bajas latencias. Podemos tener los vídeos almacenados en un Storage con sus metadatos en una base de datos SQL o NoSQL. Preferiblemente NoSQL por su rápido acceso. Por otro lado habrá que almacenar diferentes versiones de los vídeos en función de su calidad y resolución. También ten en cuenta que la localización geográfica es clave para reducir las latencias, por lo que quizá tengas que replicar los vídeos geográficamente en función de la localización de tus usuarios.

Desarrollo de software

1. Artefactos/piezas de software. Cuando desarrollamos software tenemos por un lado el código fuente y por otro lado sus versiones ya paquetizadas en un archivo binario. Algunos de estos archivos pueden ser un jar, zip o un pkl. Necesitamos un sistema de almacenaje para todos estos artefactos de tal manera que podamos desplegarlos y acceder a los mismos de la forma más cómoda y automatizada posible. Para ello existen repositorios como Helix Core, NuGet, npm, CloudSmith, Azure Artifacts, AWS CodeArtifact o Artifact Registry de GCP.
2. Contenedores. Los contenedores son unidades de software que encapsulan una aplicación, y todas sus dependencias en un entorno aislado y portátil. Una vez ya sabemos cómo va a ser nuestro contenedor de desarrollo o de puesta en producción de alguna aplicación, podemos desplegarlo en un repositorio para llevar un seguimiento del versionado, y para que todos los usuarios con acceso puedan utilizar dicho entorno. El hub de contenedores más famoso es Docker Hub, aunque también tienes otras coluciones como el Container Registry de GCP.
3. Código. Un repositorio de código es una plataforma o sistema que almacena y gestiona el código fuente de un proyecto de software. Necesitarás una plataforma que te permita gestionar todos los repositorios de código de la organización. GitHub, Bitbucket o GitLab son las tres plataformas más utilizadas. Tenemos un curso de Git abierto y comletamente gratuito.
4. Logs. Lo primero, no reinventes la rueda, porque muchas plataformas ya incluyen un sistema de logs y monitorización, así que aprovéchate de todo lo que esté incluido. Dicho esto, lo mejor es tener un servidor, o un punto centralizado donde escribas los logs, de tal manera que puedas consultarlos fácilmente. Normalmente se almacenan en archivos, aunque también puedes utilizar una base de datos NoSQL, ya que son datos que van a ir a más con el tiempo.
5. Monitorización. Como en el punto anterior, vamos a tener que utilizar los logs, pero en este caso en real time para enterarnos al momento de qué está pasando y corregir potenciales errores lo antes posible. Para ello podríamos tener un sistema de colas como Kafka, sincronizado con un script en Python encargado de mandar mails o escribir en un chat de Slack. Normalmente esto es más efectivo que un dashboard pues el dashboard hay que estar mirándolo constantemente.

Como has podido comprobar, no existe una solución perfecta que se ajuste a todos los proyectos, sino que la oferta y diversidad de bases de datos es muy grande, por lo que es muy importante tener bien claro lo que estamos buscando y cuáles son las especificaciones del proyecto. Y a continuación, sabiendo los teoremas y los tipos de bases de datos que existen, escoger la/las que mejor encaje/n.