El uso de aplicaciones en tiempo real y dispositivos Internet de las cosas (IoT) , más el crecimiento exponencial de los activos de datos no estructurados, hace que las organizaciones realicen la transición a bases de datos NoSQL cada vez más. De hecho, se prevé que el mercado NoSQL alcance los 74 500 millones de dólares para 2032, lo que representa una tasa de crecimiento (CAGR) del 24,9 % de 2024 a 2032 (Grupo IMARC, 2024).
Este crecimiento no es sorprendente dada la capacidad de los sistemas de gestión de bases de datos NoSQL (DBMS) para gestionar de forma eficaz conjuntos de datos grandes y diversos y el análisis de big data asociado necesario. Sin embargo, muchos todavía creen que NoSQL DBMS no puede abordar un requisito clave de muchas organizaciones: la gestión y el cumplimiento de las transacciones ACID . La buena noticia es que algunos DBMS NoSQL pueden hacerlo.
En este artículo, analizaremos qué son las transacciones ACID , las propiedades de las transacciones ACID , por qué son importantes estas transacciones y un ejemplo de transacción ACID en un DBMS NoSQL.
Índice
En su nivel más básico, las transacciones de bases de datos son un grupo de operaciones de lectura y escritura de bases de datos que se han completado con éxito de acuerdo con las definiciones del DBMS (p. ej., los criterios de transacción definidos). Hay dos tipos principales de transacciones:
Transacciones únicas: una transacción única se refiere a una serie de una o más operaciones de base de datos que dan como resultado una acción, completada correctamente. Una vez completada, la transacción se acepta y se puede encontrar en un registro de transacciones . Un ejemplo común de transacción única es la retirada de dinero de un cajero automático.
Multitransacciones: una multitransacción, a veces denominada transacción distributed , consiste en múltiples transacciones interdependientes repartidas en diferentes bases de datos y sistemas (p. ej., sistemas distributed ). Los registros de estas transacciones también se encuentran en un registro de transacciones. Un ejemplo de estas transacciones incluye la transferencia de dinero de una cuenta a otra o que un empleador emita a un nuevo empleado una insignia de seguridad con una foto.
Es importante tener en cuenta que algunas transacciones deben cumplir con estándares estrictos de integridad de los datos (p. ej., que los datos sean completos y correctos) y coherencia de los datos (p. ej., el valor es el mismo en todas las tablas o bases de datos). Este suele ser el caso cuando hay responsabilidad fiduciaria o cumplimiento normativo. Los ejemplos incluyen banca comercial, corretaje de inversiones y acuerdos legales. En estas situaciones, el cumplimiento de las definiciones estándar de DBMS no es suficiente y se requieren transacciones ACID .
ACID es un acrónimo que significa atomicidad, coherencia, aislamiento y durabilidad (ACID). Juntas, las propiedades de ACID garantizan que un establecer de operaciones de base de datos (agrupadas en una transacción) dejen la base de datos en un estado válido incluso en caso de errores inesperados. Además, las transacciones ACID proporcionan el nivel de garantías transaccionales que requieren muchas agencias reguladoras.
A continuación, se muestra una descripción general de cada elemento transaction de ACID , así como una descripción de cómo una base de datos de documentos NoSQL puede tratar ese elemento de ACID . A los efectos de este artículo, MongoDB Atlas será utilizado.
La atómica garantiza que todos los comandos que componen una transacción sean tratados como una sola unidad y que se ejecuten correctamente o fallen juntos. Esto es importante en caso de falla del sistema o corte de energía, ya que si una transacción no se procesó completamente, se descartará y la base de datos mantiene la integridad de sus datos.
la atomicidad: En MongoDB, una operación de escritura es atómica en el nivel de un solo documento, incluso si la operación modifica varios documentos incrustados dentro de un solo documento. Para situaciones que requieren atomicidad de las lecturas y escrituras en varios documentos (en una sola colección o en varias colecciones), MongoDB admite transacciones distributed , incluidas las transacciones en conjuntos de réplica y clústeres fragmentado .
La coherencia garantiza que los cambios realizados en una transacción se rellenen en todo el sistema de base de datos (p. ej., nodos) y en alineación con las restricciones de DBMS. Si la coherencia de los datos se verá afectada negativamente por una transacción en un estado incoherente, toda la transacción fallará.
Cómo MongoDB gestionala coherencia: MongoDB ofrece la flexibilidad necesaria para normalizar o duplicar datos para optimizar las aplicaciones. Si los datos están duplicados en el esquema, el desarrollador debe decidir cómo mantener la coherencia de los datos duplicados en varias colecciones. Algunas aplicaciones requieren que los datos duplicados sean coherentes de inmediato, mientras que otras aplicaciones pueden tolerar la lectura de datos obsoletos. A continuación se ilustran ejemplos:
Nota: Obtenga más información sobre la coherencia de datos.
Cada transacción se aísla de las demás transacciones para evitar conflictos de datos. Esto también ayuda a las operaciones de bases de datos en relación con la gestión de entradas múltiples y transacciones de varios niveles. Por ejemplo, si dos usuarios intentan modificar los mismos datos (o incluso la misma transacción), el DBMS utiliza un mecanismo llamado administrador de bloqueos para suspender a otros usuarios hasta que se completen los cambios que está realizando el primer usuario.
MongoDB emplea una técnica llamada aislamiento de instantánea (por ejemplo, cada transacción parece operar en una instantánea personal de la base de datos tomada al comienzo de la transacción). Las transacciones pueden leer datos de la “instantánea“ de los datos comprometidos en el momento en que se inicia la transacción, y cualquier actualización conflictiva hará que la transacción se cancele.
Además, las transacciones de MongoDB asistencia técnica un problema de lectura a nivel de transacción y problema de escritura a nivel de transacción. Los clientes pueden establecer un nivel apropiado de preocupación por la lectura y la escritura, siendo el más riguroso la preocupación por la lectura instantánea combinada con la preocupación por la escritura mayoritaria. Un problema de escritura de la mayoría significa que las operaciones de escritura se han comprometido de forma duradera con una mayoría calculada de los nodos que contienen datos (configurable por el desarrollador).
La durabilidad garantiza que una vez que se completa la transacción y se escriben los cambios en la base de datos, persisten. Esto garantiza que los datos dentro del sistema persistan incluso en caso de fallas del sistema como fallas o cortes de energía. El concepto de durabilidad es un elemento clave en la fiabilidad de los datos.
MongoDB crea un OpLog que contiene la ubicación del disco y los bytes cambiados para cada “escritura“. Si hay un evento imprevisto (por ejemplo, un corte de energía) durante la escritura de la transacción, se puede usar el OpLog cuando el sistema se inicia de nuevo para reproducir cualquier escritura que no se haya vaciado en el disco antes del apagado. Además, las operaciones se cambian antes de que se escriban en el OpLog, por lo que son idempotentes y se pueden reintentar varias veces. Las transacciones, o “escrituras“, se vacían en el disco aproximadamente cada 60 segundos de forma predeterminada.
Las transacciones ACID ayudan a mantener la integridad y confiabilidad de los datos, al tiempo que garantizan que los datos vitales que están sujetos a regulaciones gubernamentales o del sector (p. ej., cuentas bancarias, cartera de acciones) cumplan con los estándares requeridos. Además, el cumplimiento de ACID suele ser un requisito previo para implementar la replicación de datos y lograr una alta disponibilidad en los sistemas de bases de datos distributed .
Utilizando la base de datos de documentos NoSQL MongoDB Atlas, aquí hay un ejemplo de cómo se manejan las transacciones ACID de varios documentos y cómo las transacciones ACID garantizan la alineación con los estándares mínimos de propiedad de ACID .
Imagine que está creando una función para transferir dinero de una cuenta bancaria a otra donde cada cuenta es su propio registro. Si el dinero se retira con éxito de la cuenta de origen pero nunca se acredita en la cuenta de destino, se ha creado un problema contable grave. Por el contrario, si se acredita la cuenta de destino pero nunca se carga la cuenta de origen, se produce otro problema contable grave.
Las El diagrama muestra cómo las propiedades de ACID afectan el flujo de transferencia de dinero de una cuenta bancaria a otra.
Estas dos operaciones de escritura tienen que suceder o no ambas para mantener la coherencia del sistema y sus datos. Además, esto significa que si falla algún comando de la transacción, la base de datos debe revertir (p. ej., deshacer) todos los cambios que había escrito en el curso de la transacción.
Nota: Para obtener más información, visite la página Node.js repositorio de Github de inicio rápido para obtener una copia del código de muestra completo y ejecutarlo usted mismo.
Cuando se trate de transacciones de varios documentos en un sistema distributed , recuerde que existe un impacto en la gastos generales del rendimiento que puede afectar a las limitaciones de recursos y a los objetivos de rendimiento. Además, dado que la base de datos tiene que “bloquear“ los recursos involucrados para evitar que las escrituras concurrentes interfieran entre sí (por ejemplo, que falle la transacción), otros clientes que intenten escribir datos pueden quedarse atascados esperando a que se complete la transacción, lo que puede afectar la latencia de la aplicación y experiencia de usuario.
El modelo de documento de MongoDB permite que los datos relacionados se almacenen juntos en un solo documento. El modelo de documento, combinado con las actualizaciones de documentos atómicos, obvia la necesidad de transacciones en la mayoría de los casos de uso. No obstante, hay casos en los que las verdaderas transacciones MongoDB de varios documentos y varias colecciones son la mejor opción.
Las transacciones de MongoDB funcionan de manera similar a las transacciones de otras bases de datos. Para usar una transacción, inicie una sesión de MongoDB a través de un controlador. Luego, use esa sesión para ejecutar su grupo de operaciones de base de datos. Puede ejecutar cualquiera de las CRUD (crear, leer, actualizar y eliminar) en múltiples documentos, colecciones y fragmentos.
Para obtener ejemplos de código específicos sobre cómo implementar transacciones, vea los inicios rápidos en el Centro para desarrolladores de MongoDB :
Visite la documentación de los controladores de MongoDB para obtener guías específicas de cada idioma para cada uno de los idiomas admitidos oficialmente por MongoDB. También puede ver una lista de mejores prácticas de transacciones y consideraciones de producción.
Las aplicaciones que requieren transacciones suelen tener casos de uso en los que se intercambian valores entre diferentes partes. Por lo general, se trata de aplicaciones de "Sistema de registro" o "Línea de negocio".
Algunos ejemplos de aplicaciones que pueden beneficiarse de las transacciones de varios documentos son los siguientes:
Sistemas que mueven fondos de una cuenta a otra (p. ej., aplicaciones bancarias, sistemas de procesamiento de pagos, plataformas de negociación).
Cadena de suministro y sistemas de reserva donde la propiedad de los bienes y servicios se transfiere de una parte a otra.
Sistemas de facturación que almacenan información en registros detallados, así como registros de resúmenes.
En general, se recomienda modelar datos de modo que los datos a los que se accede en conjunto se almacenen juntos. Cuando los datos se modelan de esta manera, no solo se logrará un mejor rendimiento, sino que también no se requerirán transacciones.
Para las aplicaciones que requieren transacciones, cumpla con estas prácticas recomendadas:
Divida las transacciones de larga duración en partes más pequeñas para que no excedan el tiempo de espera predeterminado de 60 segundos. (Tenga en cuenta que este tiempo de espera puede ampliarse). Asegúrese de que las operaciones en las transacciones utilicen índices para que se ejecuten rápidamente.
Asegúrese de las inquietudes de lectura y escritura están configurados (tenga en cuenta que a partir de la versión 5.0, MongoDB se establece por defecto la preocupación por la escritura de la mayoría necesaria).
Agregar un manejo de errores apropiado y reintentar las transacciones que fallan debido a errores transitorios.
Recordar el costo de rendimiento de las transacciones que afectan a varios fragmentos. Para obtener más información sobre estas prácticas recomendadas, consulte el documento técnico sobre Transacciones ACID de varios documentos en MongoDB y la documentación de MongoDB sobre transacciones.
¿Listo para obtener más información? MongoDB Atlas es la base de datos como servicio totalmente gestionado de MongoDB y es la forma más fácil de empezar a utilizar MongoDB. Empiece a realizar transacciones creando un cluster gratuito de MongoDB Atlas.