Compartir a través de

Procesamiento de transacciones en línea (OLTP)

  • Artículo

La administración de datos transaccionales mediante sistemas de equipos se conoce como procesamiento de transacciones en línea (OLTP). Los sistemas de OLTP registran interacciones empresariales a medida que se producen en el funcionamiento diario de la organización y admiten consultas de estos datos para realizar inferencias.

Datos transaccionales

Los datos transaccionales son información que realiza un seguimiento de las interacciones relacionadas con las actividades de una organización. Estas interacciones normalmente son transacciones comerciales, tales como pagos recibidos de los clientes, pagos realizados a los proveedores, movimiento de productos en el inventario, pedidos obtenidos o servicios entregados. Los eventos transaccionales, que representan a las transacciones, normalmente contienen una dimensión de tiempo, algunos valores numéricos y referencias a otros datos.

Normalmente, las transacciones deben ser atómicas y coherentes. Atomicidad significa que una transacción completa siempre se realiza, correctamente o con error, como una unidad de trabajo y nunca se deja en un estado medio completado. Si no se puede completar una transacción, el sistema de base de datos debe revertir todos los pasos que se han hecho como parte de esa transacción. En los sistemas de administración de bases de datos relacionales (RDBMS) tradicionales, esta reversión sucede automáticamente si no se puede finalizar una transacción. Coherencia significa que las transacciones dejan siempre los datos en un estado válido. (Estas son descripciones muy informales de atomicidad y coherencia. Hay definiciones más formales de estas propiedades, por ejemplo, ACID).

Las bases de datos transaccionales posibilitan una coherencia alta de las transacciones mediante el uso de diversas estrategias de bloqueo, como el bloqueo pesimista, para asegurarse de que todos los datos son altamente coherentes dentro del contexto de la empresa, para todos los usuarios y procesos.

La arquitectura de implementación más común que utiliza datos transaccionales es el nivel de almacén de datos en una arquitectura de 3 niveles. Una arquitectura de 3 niveles normalmente consta de un nivel de presentación, un nivel de lógica de negocios y un nivel de almacén de datos. Una arquitectura de implementación relacionada es la arquitectura de n niveles, que puede tener varios niveles intermedios para el control de la lógica de negocios.

Rasgos típicos de los datos transaccionales

Los datos transaccionales suelen tener los siguientes rasgos:

Requisito Descripción
Normalización Muy normalizados
Schema Esquema durante la escritura, altamente aplicado
Coherencia Coherencia alta, garantías ACID
Integridad Integridad alta
Usa transacciones Sí
Estrategia de bloqueo Optimista o pesimista
Actualizable Sí
Anexable Sí
Carga de trabajo Grandes escrituras, lecturas moderadas
Indización Índices principales y secundarios
Tamaño de los datos Pequeño a mediano tamaño
Modelo Relacional
Forma de los datos Tabular
Flexibilidad de consulta Muy flexible
Escala Pequeño (MB) a grande (algunos TB)

Cuándo se debe utilizar esta solución

Elija OLTP cuando necesite procesar y almacenar eficazmente transacciones comerciales, y que estén inmediatamente disponibles para las aplicaciones cliente de una manera coherente. Use esta arquitectura cuando cualquier retraso tangible en el procesamiento pueda tener un impacto negativo en el funcionamiento diario de la empresa.

Los sistemas de OLTP están diseñados para procesar y almacenar de forma eficaz las transacciones, así como para consultar los datos transaccionales. El objetivo de que un sistema de OLTP procese y almacene eficazmente las transacciones individuales se logra parcialmente mediante la normalización de datos (es decir, la división de los datos en fragmentos más pequeños que sean menos redundantes). La eficacia se debe a que permite que el sistema de OLTP procese grandes cantidades de transacciones de forma independiente y evita el procesamiento adicional necesario para mantener la integridad de los datos en presencia de datos redundantes.

Desafíos

La implementación y el uso de un sistema de OLTP pueden crear algunos problemas:

  • Los sistemas de OLTP no siempre son buenos para controlar acumulaciones en grandes cantidades de datos, aunque hay excepciones, como una solución basada en SQL Server bien planificada. Los análisis de los datos, que se basan en cálculos agregados de millones de transacciones individuales, hacen un uso muy intensivo de los recursos en un sistema de OLTP. Pueden tardar en ejecutarse y puede provocar una ralentización porque bloqueen otras transacciones de la base de datos.

  • Si se realizan informes y análisis de los datos que estén muy normalizados, las consultas tienden a ser complejas, ya que la mayor parte de ellas tienen que anular la normalización de los datos mediante réplicas. Además, las convenciones de nomenclatura de los objetos de base de datos en los sistemas de OLTP tienden a ser breves y concisas. El aumento de la normalización, junto con unas convenciones de nomenclatura breves, hacen que sea difícil para los usuarios empresariales realizar consultas en los sistemas de OLTP sin la ayuda de un DBA o desarrollador de datos.

  • El almacenamiento del historial de transacciones de forma indefinida y el almacenamiento de demasiados datos en cualquier tabla puede provocar una ralentización del rendimiento de las consultas, en función del número de transacciones almacenadas. La solución habitual consiste en mantener una ventana de tiempo relevante (por ejemplo, el año fiscal actual) en el sistema de OLTP y descargar los datos históricos a otros sistemas, como un data mart o un almacenamiento de datos.

OLTP en Azure

Aplicaciones como los sitios web hospedados en App Service Web Apps, REST API que se ejecutan en App Service o las aplicaciones de escritorio o móviles se comunican con el sistema de OLTP normalmente a través de una REST API intermediaria.

En la práctica, la mayoría de las cargas de trabajo no son OLTP puras. Tiende a haber también un componente analítico. Además, hay una creciente demanda de informes en tiempo real, como los informes activos en el sistema operativo. Esto también se conoce como procesamiento analítico y transaccional híbrido (HTAP. Para más información, consulte Online Analytical Processing (OLAP) (Procesamiento analítico en línea [OLAP]).

En Azure, todos los almacenes de datos siguientes cumplen los requisitos principales para OLTP y para la administración de datos de transacciones:

Principales criterios de selección

Para restringir las opciones, empiece por responder a estas preguntas:

  • ¿Quiere un servicio administrado en lugar de administrar sus propios servidores?

  • ¿Tiene la solución dependencias específicas para Microsoft SQL Server, MySQL, o compatibilidad con PostgreSQL? La aplicación puede limitar los almacenes de datos que puede elegir en función de los controladores que admite para la comunicación con el almacén de datos o las suposiciones que este hace sobre qué base de datos se utiliza.

  • ¿Son especialmente importantes sus requisitos de rendimiento de escritura? En caso afirmativo, elija una opción que proporcione tablas en memoria.

  • ¿Su solución es multiinquilino? Si es así, considere la posibilidad de usar grupos de capacidad, donde varias instancias de bases de datos parten de un grupo elástico de recursos, en lugar de recursos fijos por base de datos. Esto puede ayudarle a distribuir mejor la capacidad entre todas las instancias de bases de datos y puede hacer que la solución sea más rentable.

  • ¿Hace falta que los datos sean legibles con una latencia baja en varias regiones? En caso afirmativo, elija una opción que admita réplicas secundarias legibles.

  • ¿Necesita que la base de datos tenga alta disponibilidad entre regiones geográficas? En caso afirmativo, elija una opción que admita la replicación geográfica. Considere también las opciones que admiten la conmutación automática por error desde la réplica principal a una réplica secundaria.

  • ¿La base de datos tiene necesidades específicas de seguridad? Si es así, examine las opciones que proporcionan funcionalidades como la seguridad de nivel de fila, el enmascaramiento de datos y el cifrado de datos transparente.

Matriz de funcionalidades

En las tablas siguientes se resumen las diferencias clave en cuanto a funcionalidades.

Funcionalidades generales

Capacidad Azure SQL Database SQL Server en una máquina virtual de Azure Azure Database for MySQL Azure Database for PostgreSQL
Es un servicio administrado Sí No Sí Sí
Se ejecuta en una plataforma N/D Windows, Linux, Docker N/D N/D
Capacidad de programación 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

[1] No incluye compatibilidad con controladores de cliente, lo que permite a muchos lenguajes de programación conectarse y usar el almacén de datos de OLTP.

Funcionalidades de escalabilidad

Capacidad Azure SQL Database SQL Server en una máquina virtual de Azure Azure Database for MySQL Azure Database for PostgreSQL
Tamaño máximo de la instancia de base de datos 4 TB 256 TB 16 TB 16 TB
Es compatible con grupos de capacidad Sí Sí No No
Es compatible con el escalado horizontal de clústeres No Sí No No
Escalabilidad dinámica (escalado vertical) Sí No Sí Sí

Funcionalidades de cargas de trabajo de análisis

Capacidad Azure SQL Database SQL Server en una máquina virtual de Azure Azure Database for MySQL Azure Database for PostgreSQL
Tablas temporales Sí Sí No No
Tablas en memoria (optimizadas para memoria) Sí Sí No No
Compatible con almacén de columnas Sí Sí No No
Procesamiento de consultas adaptable Sí Sí No No

Funcionalidades de disponibilidad

Capacidad Azure SQL Database SQL Server en una máquina virtual de Azure Azure Database for MySQL Azure Database for PostgreSQL
Réplicas secundarias legibles Sí Sí Sí Sí
Replicación geográfica Sí Sí Sí Sí
Conmutación automática por error en replicación secundaria Sí No N.º No
Restauración a un momento dado Sí Sí Sí Sí

Funcionalidades de seguridad

Capacidad Azure SQL Database SQL Server en una máquina virtual de Azure Azure Database for MySQL Azure Database for PostgreSQL
Seguridad de nivel de fila Sí Sí Sí Sí
Enmascaramiento de datos Sí Sí No No
Cifrado de datos transparente Sí Sí Sí Sí
Restricción del acceso a determinadas direcciones IP Sí Sí Sí Sí
Restricción del acceso para permitir solo el acceso de la red virtual Sí Sí Sí Sí
Autenticación de Microsoft Entra Sí No Sí Sí
Autenticación de Active Directory No Sí No No
Autenticación multifactor Sí No Sí Sí
Compatible con Always Encrypted Sí Sí No No
Dirección IP privada No Sí No No

Pasos siguientes