Uso de IA Generativa para Selección de Bases de Datos: un Framework Orientado a Requisitos para la Generación de Registros de Decisiones de Arquitectura (ADRs)

Geovanni de Morais Gava; Luiz Fernando Pereira Nunes

DOI: 10.22167/2675-6528-202602960

Artículo derivado de Trabajo de Fin de Curso (TCC), con contenido basado en el trabajo original del estudiante y adaptado al formato editorial de la Revista E&S con el apoyo de la herramienta ResumeAI, una solución de inteligencia artificial desarrollada por el Instituto Pecege para la síntesis y organización textual.

Resumen

El crecimiento de aplicaciones intensivas en datos y la adopción de la arquitectura de microservicios han ampliado la necesidad de persistencia políglota, imponiendo una alta carga cognitiva a los arquitectos de software en la elección y justificación de tecnologías de bases de datos. Este trabajo tuvo como objetivo proponer y desarrollar un framework basado en agentes de Inteligencia Artificial (IA) para guiar la selección tecnológica y generar Architecture Decision Records (ADRs) fundamentadas. Se empleó una metodología experimental y aplicada para construir una base de conocimiento técnico. La técnica de Retrieval-Augmented Generation (RAG), junto con las bibliotecas LangChain y LangGraph, se utilizó para orquestar agentes y anclar las respuestas de un Large Language Model (LLM). El framework extrajo requisitos en lenguaje natural, los enriqueció con RAG y los envió al LLM, que generó ADRs para auxiliar en la evaluación de trade-offs teóricos. Los resultados demostraron que el agente con RAG redujo respuestas genéricas, aumentando el fundamento teórico y la trazabilidad. El enfoque RAG demostró su eficacia frente a prompts convencionales (zero-shot), favoreciendo la generación de ADRs con menor nivel de alucinación y alto nivel de trazabilidad teórica. Se concluyó que la herramienta automatizada cumplió la función de mapeo de requisitos, resultando en documentos técnicos empíricamente fundamentados y auxiliando la gobernanza y toma de decisiones en arquitectura de software.

Palabras clave: Bases de datos; Inteligencia artificial; LangGraph; LLM; RAG.

1. Introducción

La evolución de los sistemas de información en las últimas décadas ha transformado profundamente la forma en que las organizaciones manejan el gran volumen de información generado diariamente. Para procesar estos datos de manera estructurada, la adopción de tecnologías robustas es indispensable. Una base de datos se entiende como una colección de datos que, típicamente, describe las actividades de una o más organizaciones relacionadas (Ramakrishnan y Gehrke, 2008).

Históricamente, el modelo relacional ha dominado este escenario, dictando cómo las aplicaciones empresariales abstraían y manipulaban sus registros. Sin embargo, la arquitectura de software moderna exige una comprensión cada vez más profunda sobre el modelado y las estructuras físicas de almacenamiento. Existe una brecha entre la visión del usuario y el almacenamiento físico. Ramakrishnan y Gehrke (2008) destacan que, aunque un modelo de datos oculta detalles de bajo nivel, todavía está más cerca de cómo el sistema de gestión de bases de datos almacena los datos que de cómo el usuario piensa sobre la empresa.

A pesar de la fuerte consolidación del modelo relacional, la llegada de escenarios de aplicaciones intensivas en datos, frecuentemente denominados Big Data, y la necesidad de escalabilidad horizontal a través de clústeres de servidores impulsaron el auge de las bases de datos NoSQL. Esta transición abrió puertas a un nuevo paradigma en el diseño de software. Como explican Sadalage y Fowler (2012), estamos entrando en un mundo de Persistencia Políglota, donde las empresas e incluso aplicaciones individuales utilizan múltiples tecnologías para la gestión de datos. Esta flexibilidad tecnológica, sin embargo, impone una pesada carga cognitiva a los arquitectos de software y ingenieros de datos, ya que la toma de decisiones arquitecturales exige el balanceo constante entre garantías estructurales. El choque entre propiedades transaccionales clásicas y entornos distribuidos es inevitable, dado que las bases de datos relacionales utilizan transacciones ACID para manejar la consistencia, lo que inherentemente entra en conflicto con un entorno de clúster, haciendo que las bases de datos NoSQL ofrezcan una gama de opciones para consistencia y distribución (Sadalage y Fowler, 2012).

En la práctica diaria, la selección de la tecnología de persistencia a menudo descuida estas restricciones teóricas, como el Teorema CAP y las propiedades ACID versus BASE. La elección termina basándose en el sesgo de popularidad de las herramientas del mercado o en pruebas de rendimiento empíricas no estandarizadas, en lugar de una fundamentación sólida. Con el auge de la Inteligencia Artificial Generativa y los Large Language Models (LLMs), surgió una oportunidad para automatizar y apoyar el diseño de sistemas de forma inteligente. Sin embargo, tales modelos sufren el fenómeno de las “alucinaciones”, generando recomendaciones técnicamente imprecisas en dominios altamente específicos cuando carecen de conocimiento y base técnica.

Para mitigar este desafío, se suele adoptar la técnica de Retrieval-Augmented Generation (RAG), que ancla el razonamiento y la generación de texto de la IA en una base bibliográfica externa enfocada en la ingeniería de datos. El uso de la técnica de RAG está fundamentado en la literatura para la resolución de fallos basados en falta de información y desactualización de los modelos, ya que enriquece la generación de respuestas con fuentes externas y factuales, mitigando el riesgo de alucinaciones técnicas y haciendo el documento final altamente rastreable (Huyen, 2025). Además, el RAG reduce el costo y la latencia al seleccionar solo la información estrictamente relevante, optimizando el uso del límite de tokens nativo de la ventana de contexto de la IA (Huyen, 2025). Ante este escenario, la presente investigación se justifica por la oportunidad de unir los avances de los agentes orquestados de IA para mejorar la gobernanza en arquitectura de software.

La necesidad de decisiones robustas y teóricamente fundamentadas en la selección de bases de datos, combinada con el potencial de los agentes de IA para superar las limitaciones de las salidas genéricas de los LLMs, resalta la relevancia de este estudio. El objetivo central de este trabajo es proponer y desarrollar un framework inteligente que, provisto de literatura clásica de bases de datos, sea capaz de interpretar requisitos en lenguaje natural, evaluar trade-offs teóricos y generar, de forma autónoma, un Architecture Decision Record (ADR) consistente, rastreable y con el menor número posible de “alucinaciones”, así como una reducción de sesgos de mercado.

2. Material y Métodos

La investigación realizada se caracterizó por su naturaleza experimental y aplicada, empleando enfoques de desarrollo de aplicaciones con agentes y Modelos Fundacionales. Los procedimientos se llevaron a cabo en simulaciones controladas de ingeniería de software, con el objetivo de construir un framework inteligente. El enfoque metodológico principal residió en la utilización de la técnica de Generación Aumentada por Recuperación (RAG) y de agentes autónomos, con el propósito de superar las limitaciones inherentes a las ventanas de contexto y la propensión de los Modelos de Lenguaje Grandes (LLMs) a generar respuestas sin trazabilidad.

La adopción de agentes de Inteligencia Artificial se justificó por la capacidad de combinar diversas herramientas, conocimientos, memoria y aprendizaje con modelos avanzados. Esta combinación permitió la resolución de problemas ambiguos y complejos a través de múltiples etapas de razonamiento, como destacó Albada (2025). La construcción del framework se estructuró en etapas operativas distintas, detalladas a continuación, para garantizar la robustez y la funcionalidad del sistema propuesto.

La primera etapa consistió en la ingesta y procesamiento de datos para la base de conocimiento del RAG. Para ello, se estableció una base de conocimiento (grounding) a partir de la literatura clásica de sistemas de bases de datos, documentaciones oficiales de herramientas y teorías específicas, como topologías, mecanismos de replicación y modelos de consistencia, incluyendo las propiedades ACID versus BASE y el Teorema CAP. Esta base fue fundamental para anclar el razonamiento de la IA.

Los textos recopilados fueron fragmentados, proceso conocido como chunking, y convertidos en embeddings. Esta conversión se realizó a través de un modelo codificador específico, Ollama con nomic-embed-text. Posteriormente, los embeddings resultantes se almacenaron en una base de datos vectorial, utilizando la combinación de PostgreSQL y la extensión pgvector, permitiendo la búsqueda indexada de información relevante.

La técnica de Generación Aumentada por Recuperación (RAG) se empleó para mitigar fallos derivados de la falta de información y la desactualización de los modelos, enriqueciendo la generación de respuestas con fuentes externas y factuales. Esto contribuyó a reducir el riesgo de alucinaciones técnicas y aumentar la trazabilidad del documento final (Huyen, 2025). Adicionalmente, el RAG optimizó el uso del límite de tokens de la ventana de contexto de la IA, seleccionando solo información estrictamente relevante y, consecuentemente, reduciendo costos y latencia (Huyen, 2025).

La segunda etapa implicó la implementación del agente, donde se utilizaron las bibliotecas LangChain y LangGraph para construir la orquestación y la máquina de estados del agente conversacional. Se eligió LangGraph por su capacidad de proporcionar un framework de orquestación modular basado en grafos dirigidos, soportando flujos de trabajo cíclicos y asíncronos, lo cual es crucial para arquitecturas de agentes robustas (Albada, 2025).

LangGraph modeló el proceso de generación del Architecture Decision Record (ADR) como un grafo de estados. En este flujo, un nodo ingestor fue responsable de analizar y validar la entrada del usuario, mientras que un nodo redactor ejecutó la búsqueda en RAG, evaluó la relevancia del contenido recuperado, invocó el Large Language Model (LLM) y formateó la salida final en markdown y según el estándar ABNT.

La biblioteca LangChain actuó como una capa de abstracción para los componentes de IA, ofreciendo piezas listas e intercambiables. Esto incluyó funcionalidades de carga y división de documentos, como el PyPDFLoader para cargar PDFs y el RecursiveCharacterTextSplitter para dividir el texto en fragmentos con solapamiento. Para embeddings, se utilizó OllamaEmbeddings, que abstrajo la llamada a Ollama para generar vectores.

Para el almacenamiento vectorial, se empleó PGVector, que abstrajo la lógica de inserción, selección y búsqueda por similitud en PostgreSQL, eliminando la necesidad de escribir SQL manualmente. Las interfaces comunes, definidas por langchain-core, garantizaron la flexibilidad para cambiar modelos de embedding o bases vectoriales sin alterar el resto del código del sistema.

La tercera etapa se centró en la ingeniería de prompts y la recuperación, donde los prompts del sistema establecieron reglas explícitas para la IA. Se instruyó al modelo para que descomponga el problema del usuario, identifique compensaciones basadas en los requisitos extraídos, el Teorema CAP y las restricciones arquitectónicas recuperadas por el flujo RAG, antes de tomar la decisión final. El prompt completo enviado al LLM se compuso de cuatro capas distintas.

La primera capa, el System Prompt, definió el rol del LLM como arquitecto senior, las reglas de escritura y la estructura del ADR, incluyendo secciones obligatorias como Contexto, Decisión, Consecuencias, Alternativas y Referencias, además de instrucciones de formato y citación ABNT. La segunda capa, de requisitos expandidos, consistió en seis preguntas de opción múltiple sobre estructura de datos, naturaleza de las búsquedas, proporción de operaciones, volumetría y escalabilidad, Teorema CAP y transacciones multi-registro, cuyas respuestas fueron transformadas en texto legible.

La tercera capa, de contexto de seguimiento, era opcional y se utilizaba cuando el usuario indicaba “no estoy seguro” en alguna pregunta de la capa anterior. En ese caso, se hacían dos preguntas de contexto de tipo Sí/No para clarificación, enriqueciendo el prompt. La cuarta capa, de contexto RAG, adjuntaba chunks relevantes encontrados por el RAG al final del prompt, proporcionando conocimiento técnico y referencias bibliográficas para fundamentar las respuestas.

La cuarta y última etapa comprendió la evaluación y los escenarios de validación del framework. El sistema fue sometido a pruebas simuladas basadas en tres patrones típicos de System Design: alta ingesta de eventos con prioridad en escalabilidad de escritura lineal (AP), transacciones financieras distribuidas con prioridad en fuerte consistencia y durabilidad (CP/ACID), y un catálogo de productos con búsquedas flexibles.

Para evaluar la efectividad del enfoque, los Architecture Decision Records (ADRs) generados con el soporte del flujo RAG y de los agentes se compararon con las respuestas obtenidas por el enfoque zero-shot, que se basaba únicamente en el conocimiento paramétrico del modelo. La evaluación fue de naturaleza cualitativa, centrándose en la consistencia factual y en la trazabilidad de las justificaciones, verificando la coherencia con las referencias de la arquitectura de las tecnologías. Los anexos V y VI del trabajo original contienen los ADRs generados para los escenarios sin y con la utilización del RAG, respectivamente.

3. Resultados y Discusión

La implementación del framework propuesto demostró la viabilidad del uso de agentes conversacionales, guiados por la técnica de Retrieval-Augmented Generation (RAG), para la ejecución de tareas analíticas complejas, como la selección y la justificación técnica de bases de datos. Las rondas de ejecución, realizadas en escenarios de validación controlados, evidenciaron diferencias significativas entre las recomendaciones generadas por un Large Language Model (LLM) en enfoque zero-shot y aquellas enriquecidas con contexto bibliográfico externo, proporcionado por el RAG. Esta distinción resaltó la capacidad del framework para mitigar sesgos y alucinaciones, promoviendo decisiones más fundamentadas y rastreables.

Las pruebas se estructuraron en tres escenarios distintos, cada uno representando un patrón común de diseño de sistemas, permitiendo una evaluación exhaustiva del rendimiento del framework. El análisis comparativo se centró en la consistencia fáctica, la profundidad de la justificación y la trazabilidad de las fuentes teóricas utilizadas. Se observó que la ausencia del RAG a menudo conducía a elecciones basadas en la popularidad o analogías superficiales, mientras que su aplicación dirigía al LLM hacia soluciones más robustas y alineadas con los requisitos técnicos específicos de cada contexto.

Ingesta de Eventos (Escritura Lineal / AP)

En el escenario que simulaba la ingesta masiva de telemetría y logs, donde la escala de datos podía alcanzar Petabytes y la disponibilidad (AP) era la máxima prioridad frente a fallos parciales de red, el enfoque zero-shot del LLM sugirió Redis. Esta recomendación se basó en la velocidad de escritura y la simplicidad de la estructura clave-valor, pero ignoró las restricciones físicas de memoria RAM y la persistencia para volúmenes tan elevados, lo que haría el coste prohibitivo y aumentaría el riesgo de pérdida de datos en caso de fallo de energía. Alternativas como MySQL, PostgreSQL y MongoDB fueron descartadas por no soportar el volumen de escritura o no estar optimizadas para operaciones puras de clave-valor.

En contraste, el framework enriquecido con RAG, al procesar los mismos requisitos, recomendó ScyllaDB. La decisión se fundamentó en la capacidad de ScyllaDB para manejar grandes volúmenes de datos a través de su modelo de familia de columnas y clave-valor, optimizado para acceso a altísima velocidad por clave primaria (Sadalage; Fowler, 2012). El agente destacó la arquitectura “shard-per-core” de ScyllaDB, ideal para cargas intensas de escritura (ScyllaDB, 2023), y su escalabilidad lineal en múltiples servidores (Scabora, 2016). Además, la implementación del modelo masterless favorece la disponibilidad en el teorema CAP, con consistencia eventual ajustable (ScyllaDB, 2023; Sadalage; Fowler, 2012).

Las consecuencias positivas de la elección de ScyllaDB incluyeron alta disponibilidad nativa y escalabilidad lineal a Petabytes, junto con una latencia de escritura extremadamente baja debido a la ausencia de bloqueos globales (ScyllaDB, 2023). Sin embargo, se identificaron desventajas, como la inadecuación para consultas que requieren múltiples JOINs complejos (Scabora, 2016) y la necesidad de un modelado de datos orientado a las consultas. Las alternativas consideradas y descartadas por el agente con RAG fueron Redis, debido al costo inviable de memoria RAM para volúmenes masivos; PostgreSQL, ya que su control de concurrencia limita la escritura masiva (Ramakrishnan; Gehrke, 2008); y Neo4j, por estar optimizado para conexiones y no para alta ingesta de logs (Robinson et al., 2015).

Transacciones Financieras (Fuerte Consistencia / CP)

Para el escenario de transacciones financieras distribuidas, que exigía un alto grado de consistencia (CP) y garantía de transacciones aisladas, el LLM en enfoque zero-shot sugirió MongoDB. Aunque el modelo intentó justificar la elección basándose en la capacidad de organizar datos como tablas y soporte para transacciones multi-documento, las descripciones sobre recuperación ante fallos y la superioridad del modelo relacional para integridad referencial rígida fueron imprecisas, caracterizando una alucinación de conocimiento no paramétrico. MongoDB no es una base de datos relacional nativa, lo que podría causar ineficiencia en JOINs complejos, y garantizar ACID estricto exigiría configuraciones que reducirían el rendimiento. Alternativas como Cassandra, SQLite y Neo4j fueron descartadas por no soportar transacciones ACID estrictas o no ser adecuadas para el contexto financiero.

Con la integración de RAG, el framework recuperó con éxito fragmentos de la literatura de Ramakrishnan y Gehrke (2008) sobre el Protocolo de Bloqueo de Dos Fases (2PL) y las propiedades ACID. Basado en este fundamento, el agente recomendó PostgreSQL, priorizando la “Consistencia” frente a la falla de particiones en el Teorema CAP. La decisión fue justificada por el modelo relacional que garantiza la integridad a través de esquemas fijos (Ramakrishnan; Gehrke, 2008), soporte para JOINs y agregaciones complejas vía SQL, y eficiencia con carga mixta bajo concurrencia. PostgreSQL está optimizado para servidores únicos de alto rendimiento e implementa protocolos de bloqueo que garantizan la Consistencia CP (Ramakrishnan; Gehrke, 2008), con garantías ACID nativas y fundamentales para operaciones financieras (Hiremath, 2018).

Las consecuencias positivas de la elección de PostgreSQL incluyeron robustez en el control de transacciones concurrentes a través del aislamiento (Ramakrishnan; Gehrke, 2008) y la madurez del ecosistema para la auditoría financiera (Hiremath, 2018). Como puntos negativos, se señalaron la menor disponibilidad en caso de fallos severos de red, comparado con sistemas AP, y la dificultad de escalabilidad horizontal en relación con bases NoSQL (Sadalage; Fowler, 2012). Las alternativas descartadas por el RAG fueron MongoDB, ya que la estructura tabular rígida y los JOINs son nativamente superiores en RDBMS (Ramakrishnan; Gehrke, 2008); Cassandra, por priorizar la disponibilidad en lugar de la consistencia fuerte ACID (Sadalage; Fowler, 2012); y ScyllaDB, por no estar enfocado en transacciones ACID multi-tabla (ScyllaDB, 2023).

Catálogo de Productos (Búsquedas Flexibles / AP)

En el escenario de un catálogo de productos con búsquedas flexibles, donde la prioridad era la disponibilidad (AP) y la necesidad de manejar datos flexibles (JSON) y búsquedas textuales, el enfoque zero-shot del LLM sugirió Neo4j. Esta elección se basó en la premisa superficial de que “los productos tienen categorías”, lo que llevó a una analogía inadecuada con bases de datos de grafos. Aunque Neo4j es excelente para sistemas de recomendación y visualización intuitiva de árboles de productos, no está optimizado para búsquedas textuales del tipo “fuzzy search” a gran escala, y su rendimiento puede degradarse en búsquedas que no utilizan las relaciones. Alternativas como Elasticsearch, PostgreSQL y Cassandra fueron descartadas por ser solo motores de búsqueda, demasiado rígidos para atributos dinámicos o complejos para búsquedas textuales.

El framework enriquecido con RAG, a su vez, identificó correctamente MongoDB como la solución más adecuada. La decisión se basó en la capacidad de MongoDB para almacenar atributos dinámicos de productos en documentos JSON (Sadalage; Fowler, 2012) y ofrecer índices de texto para búsquedas flexibles (Płuciennik; Zgorzałek, 2017). El agente destacó la eficiencia de MongoDB para cargas de trabajo de lectura masiva, su soporte para sharding para volúmenes masivos de datos (Sadalage; Fowler, 2012), la posibilidad de configuración para alta disponibilidad (AP) y la aceptabilidad de la consistencia eventual para catálogos de productos.

Las consecuencias positivas de la elección de MongoDB incluyeron agilidad en el desarrollo debido al mapeo directo entre objetos y documentos (Płuciennik; Zgorzałek, 2017), además de la facilidad de expansión a nuevos mercados y categorías de productos. Sin embargo, se observaron desventajas, como el consumo de espacio en disco superior al modelo relacional debido a la desnormalización (Sadalage; Fowler, 2012) y la falta de optimización para consultas de relaciones complejas, típicas de grafos (Robinson et al., 2015). Las alternativas descartadas por el RAG fueron Neo4j, ya que la complejidad de grafos no era necesaria para búsquedas textuales de catálogo (Robinson et al., 2015); ScyllaDB, por no poseer la flexibilidad de campos dinámicos del modelo de documentos (ScyllaDB, 2023); y PostgreSQL, debido a la rigidez del esquema que dificulta atributos variables (Płuciennik; Zgorzałek, 2017).

La calidad de la salida final de la herramienta se expresó en la generación de Architecture Decision Records (ADRs) con rigor analítico. El modelo fue guiado por instrucciones explícitas insertadas en el prompt, limitando su uso únicamente a la base de conocimiento extendida. Esto permitió que el framework superara la inestabilidad común de la generación sintética, atestiguando que la arquitectura sistémica intrínseca del software sirve como criterio primario de elección, mitigando la dependencia de benchmarks empíricos de internet, que son frecuentemente inconsistentes. La capacidad de generar ADRs rastreables y teóricamente fundamentados representa un avance significativo en la gobernanza y toma de decisiones en arquitectura de software, validando la eficacia del enfoque RAG para mejorar la inteligencia generativa en dominios técnicos específicos.

4. Conclusión

El presente estudio tuvo como objetivo proponer y desarrollar un framework inteligente, basado en agentes de Inteligencia Artificial, para guiar la selección de tecnologías de bases de datos y generar Architecture Decision Records (ADRs) fundamentados. Se verificó que el enfoque de Retrieval-Augmented Generation (RAG), junto con la orquestación de agentes, demostró ser eficaz en la interpretación de requisitos en lenguaje natural y en la evaluación de trade-offs teóricos. Los resultados evidenciaron una reducción significativa de respuestas genéricas y “alucinaciones” en comparación con modelos de lenguaje en enfoque zero-shot, aumentando el fundamento teórico y la trazabilidad de las recomendaciones. Se observó que el framework fue capaz de proporcionar soluciones robustas y alineadas a los requisitos técnicos específicos en escenarios diversos, como la ingesta masiva de eventos, transacciones financieras con fuerte consistencia y catálogos de productos con búsquedas flexibles, recomendando ScyllaDB, PostgreSQL y MongoDB, respectivamente, con justificaciones ancladas en la literatura.

La principal contribución de este trabajo reside en la creación de una herramienta automatizada que mejora la gobernanza en la arquitectura de software, al mapear requisitos y generar documentos técnicos empíricamente fundamentados. La capacidad de producir ADRs con rigor analítico y trazabilidad teórica representa un avance significativo, ya que mitiga la dependencia de sesgos de mercado o de benchmarks empíricos inconsistentes, priorizando la arquitectura sistémica intrínseca del software como criterio primario de elección. Así, el framework desarrollado auxilia directamente a los arquitectos de software en el complejo proceso de toma de decisiones, promoviendo elecciones más informadas y confiables.

Referencias Bibliográficas

Abhinav Hiremath; Comparative Analysis of Relational vs NoSQL Databases in Web Applications Dataset. Vol. 06, Issue: 03, March: 2018

ALBADA, Michael. Building Applications with Al Agents: Designing and Implementing Multiagent Systems. 1. ed. Santa Rosa: O’Reilly Media, 2025

HUYEN, Chip. Al Engineering: Building Applications with Foundation Models. 1. ed. [S. I.]: O’Reilly Media, 2024.

PŁUCIENNIK, E.; ZGORZAŁEK, K. The multi-model databases-a review. In: SPRINGER. 2017.

Ramakrishnan, R.; Gehrke, J. Sistemas de gerenciamento de banco de dados. 3. ed. McGraw Hill Brasil, 2008.

ROBINSON, I.; WEBBER, J.; EIFREM, E. Graph databases: new opportunities for connected data. [S.I.]: “O’Reilly Media, Inc.”, 2015.

Sadalage, P. J.; Fowler, M. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley, 2012.

SCABORA, L. D. C. Avaliação do Star Schema Benchmark aplicado a bancos de dados NoSQL distribuídos e orientados a colunas. 2016.

ScyllaDB. ScyllaDB Architecture Overview. ScyllaDB Documentation, 2023.

Artículo originado del Trabajo de Conclusión de Curso de la Especialización en Ingeniería de Software del MBA USP/Esalq

Para saber más sobre el curso, haga clic aquí y acceda a la plataforma MBX Academy