El procesamiento de transacciones en línea (OLTP) es el procesamiento de datos en tiempo real detrás de los retiros de cajeros automáticos, los pagos con tarjeta de crédito, los sistemas de reserva y emisión de boletos, las compras en línea y el comercio electrónico en general. Los sistemas de procesamiento de transacciones en línea están especialmente diseñados para manejar una gran cantidad de transacciones realizadas por una gran cantidad de usuarios simultáneos.
Las bases de datos OLTP proporcionan la capa de almacenamiento o back-end para el comercio electrónico y, de hecho, para la mayoría de las aplicaciones informáticas modernas. Aunque las bases de datos OLTP son tradicionalmente bases de datos relacionales SQL, también es posible utilizar algunas bases de datos NoSQL para el mismo propósito. La mayoría de nuestras discusiones a continuación se centrarán en las bases de datos relacionales de SQL.
OLTP frente a OLAP
Las bases de datos OLTP generalmente manejan una gran cantidad de transacciones pequeñas y rápidas de muchos usuarios. Las transacciones implican la modificación de la base de datos de una manera que garantice la coherencia, utilizando operaciones CRUD (crear, leer, actualizar, eliminar) dentro de la transacción. Aunque las bases de datos OLTP a veces también admiten consultas analíticas, esta funcionalidad se realiza a menudo en bases de datos o almacenes de datos OLAP (procesamiento analítico en línea) independientes. Las bases de datos OLTP están optimizadas para la recopilación y modificación de datos. Las bases de datos OLAP están optimizadas para el análisis.
¿Qué es CRUD?
CRUD (crear, leer, actualizar y eliminar) es el conjunto básico de operaciones de base de datos. En una base de datos SQL, las sentencias INSERT crean registros, las sentencias SELECT leen registros, las sentencias UPDATE actualizan registros y las sentencias DELETE eliminan registros. Estas instrucciones incluyen DML (lenguaje de manipulación de datos). Las bases de datos SQL también admiten DDL (lenguaje de definición de datos) para definir bases de datos, tablas, índices, vistas y otros objetos de bases de datos.
¿Qué es una transacción de base de datos?
Una transacción de base de datos en una base de datos SQL es un contenedor para una secuencia de instrucciones SQL con dos puntos finales posibles: COMMIT o ROLLBACK del lote. Por ejemplo, una transferencia bancaria consiste en retirar una cantidad de una cuenta y depositar la misma cantidad en otra cuenta. Si ambas operaciones tienen éxito, la transacción se confirma. Si cualquiera de las operaciones falla, la transacción, que incluye ambas operaciones, vuelve al estado anterior al inicio de la transacción, de modo que la cantidad total de dinero en ambas cuentas es constante.
¿Qué son las propiedades de la base de datos ACID?
Las transacciones de bases de datos deben exhibir las cuatro propiedades ACID: atomicidad, consistencia, aislamiento y durabilidad. La atomicidad está garantizada por compromisos y reversiones de transacciones, como se describe anteriormente. Toda la transacción se trata como una sola operación atómica.
La consistencia es el producto final de implementar correctamente las transacciones: la cantidad total de dinero en las cuentas involucradas en la transferencia permanece constante. Aislamiento significa que otras transacciones no pueden detectar los estados intermedios de una transacción. La durabilidad significa que una vez que se ha comprometido una transacción, los nuevos valores no se revierten, incluso si el sistema falla.
Las propiedades ACID son más fáciles de garantizar en una base de datos centralizada. Son más difíciles de garantizar en una base de datos agrupada o distribuida.
Por ejemplo, algunas bases de datos distribuidas solo reclaman coherencia eventual, lo que les permite decir que una transacción se ha confirmado antes de que todos los nodos de la base de datos hayan terminado de escribir. Esto acelera las transacciones distribuidas, pero requiere transacciones posteriores que esperan coherencia para esperar a que se completen todas las escrituras o leer desde donde se originó la transacción.
Las bases de datos distribuidas que garantizan una sólida consistencia pueden tener latencias de transacción más altas, pero es mucho menos probable que causen errores en las aplicaciones que las bases de datos eventualmente consistentes, como cuando una lectura remota se completa antes de que una transacción anterior termine de escribir en todas las ranuras.
¿Qué es la latencia de transacción?
La latencia se refiere tanto al tiempo de respuesta de la base de datos como al tiempo de respuesta de la aplicación de extremo a extremo. La latencia de transacción es el tiempo que transcurre entre el inicio de la transacción y la confirmación de la transacción.
Esquemas de base de datos para OLTP
Para admitir altas tasas de transacciones, los esquemas de base de datos para bases de datos OLTP generalmente involucran tamaños de fila pequeños e índices mínimos. Históricamente, esto significaba asegurarse de que el esquema de la base de datos estuviera en la tercera forma normal.
¿Qué es la tercera forma normal?
La tercera forma normal (3NF), definida en 1971 por Edgar F. Codd, es un conjunto de requisitos para esquemas de bases de datos para reducir la duplicación de datos, evitar anomalías en los datos, garantizar la integridad referencial y simplificar la gestión de datos. Básicamente dice que una tabla determinada solo contiene campos que son atributos de la clave principal.
Si tiene una tabla de pacientes con una clave principal que es el número de paciente, sus campos deben ser para el paciente, no para el hospital, no para el médico y no para la aseguradora, aunque la tabla puede contener referencias (claves ajenas) a otras tablas. sobre estas cosas. El inteligente resumen de Bill Kent de 3NF es «[every] no clave [attribute] tiene que proporcionar un hecho sobre la clave, toda la clave y nada más que la clave, así que ayúdame, Codd.
¿Pueden las bases de datos NoSQL funcionar como OLTP?
Aunque hemos discutido principalmente las bases de datos relacionales de consistencia fuerte, algunas bases de datos NoSQL están diseñadas para OLTP. Si se encuentra en la posición de necesitar o desear una base de datos NoSQL para el procesamiento de transacciones, debe limitarse a las bases de datos NoSQL con propiedades ACID. Evite las eventuales bases de datos de consistencia limitada para OLTP, especialmente para aplicaciones financieras. Consulte con sus auditores antes de comprometerse con una base de datos para procesar transacciones financieras.
Medir el rendimiento de OLTP
Al principio de la historia de las bases de datos relacionales, cada proveedor promovía un punto de referencia de rendimiento de procesamiento de transacciones diferente que había sido modificado para su propio producto. El Consejo de Rendimiento de Procesamiento de Transacciones se formó para crear y auditar puntos de referencia independientes del proveedor. TPC Benchmark C (TPC-C) es un punto de referencia OLTP ampliamente utilizado. Hay otras referencias de bases de datos públicas que pueden aplicarse a usted; también puede crear los suyos propios, pero los puntos de referencia honestos que reflejan el uso en el mundo real son sorprendentemente difíciles de escribir y ejecutar.
En general, las bases de datos OLTP deberían hacer su trabajo, que es registrar transacciones de forma rápida y duradera. Para el análisis, considere configurar un lago de datos o almacén de datos independiente y un proceso ETL o ELT para llenar la base de datos de análisis desde la base de datos OLTP. OLTP es una cosa; OLAP es otro.
Derechos de autor © 2022 IDG Communications, Inc.
