¿Qué es el OLTP? La columna vertebral del comercio electrónico

0
49

El procesamiento de transacciones en línea (OLTP, por sus siglas en inglés) es el proceso de datos en tiempo real que está detrás de las retiradas en cajeros automáticos, los pagos con tarjeta de crédito, los sistemas de venta de billetes y reservas, las compras en línea y el comercio electrónico en general. Los sistemas de procesamiento de transacciones en línea están diseñados para gestionar un gran número de transacciones realizadas por un gran número de usuarios simultáneos.

Las bases de datos OLTP constituyen el back-end o capa de almacenamiento del comercio electrónico y, de hecho, de la mayoría de las aplicaciones informáticas modernas. Aunque las bases de datos OLTP han sido tradicionalmente bases de datos relacionales SQL, también es posible utilizar algunas bases de datos NoSQL para los mismos fines. La mayor parte de nuestra discusión a continuación será en términos de bases de datos relacionales SQL.

OLTP vs. OLAP
Las bases de datos OLTP suelen manejar un gran número de transacciones pequeñas y rápidas de muchos usuarios. Las transacciones implican la modificación de la base de datos de forma que se garantice su coherencia, utilizando operaciones CRUD (crear, leer, actualizar, eliminar, por sus siglas en inglés) dentro de la transacción. Aunque las bases de datos OLTP a veces también admiten consultas analíticas, esa funcionalidad suele realizarse en bases de datos OLAP (procesamiento analítico en línea) o almacenes de datos independientes. Las bases de datos OLTP están optimizadas para recoger y modificar datos. Las bases de datos OLAP están optimizadas para el análisis.

¿Qué es el CRUD?
CRUD es el conjunto básico de operaciones de bases de datos. En una base de datos SQL, las sentencias INSERT realizan la creación de registros, las sentencias SELECT leen registros, las sentencias UPDATE actualizan registros, y las sentencias DELETE eliminan registros. Estas sentencias conforman el 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 la base 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 una envoltura para una secuencia de sentencias SQL con dos posibles puntos finales: COMMIT o ROLLBACK el lote. Por ejemplo, una transferencia bancaria implica retirar una cantidad de una cuenta y depositar la misma cantidad en otra cuenta diferente. Si ambas operaciones tienen éxito, entonces la transacción se compromete. Si cualquiera de las dos operaciones falla, la transacción -que incluye ambas operaciones- retrocede al estado anterior al inicio de la transacción, de modo que la cantidad total de dinero en las dos cuentas es constante.

¿Cuáles son las propiedades de las bases de datos ACID?

Las transacciones de bases de datos deben presentar las cuatro propiedades ACID: atomicidad, consistencia, aislamiento y durabilidad. La atomicidad está garantizada por los commits y rollbacks de las transacciones, como se ha descrito anteriormente. Toda la transacción se trata como una única operación atómica.

La consistencia es el producto final de una correcta implementación de la transacción: la cantidad total de dinero en las cuentas involucradas en la transferencia permanece constante. El aislamiento significa que otras transacciones no pueden detectar ningún estado intermedio de una transacción. La durabilidad significa que una vez que una transacción se ha comprometido, los nuevos valores no se deshacen, 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 afirman la consistencia eventual, lo que les permite decir que una transacción se ha comprometido antes de que todos los nodos de la base de datos hayan terminado de escribir. Esto acelera las transacciones distribuidas, pero requiere que las transacciones posteriores que esperan consistencia esperen a que se completen todas las escrituras, o que lean desde la ubicación original de la transacción.

Las bases de datos distribuidas que garantizan una fuerte consistencia pueden tener latencias de transacción más altas, pero es mucho menos probable que causen fallas en la aplicación, que las bases de datos eventualmente consistentes; por ejemplo, cuando una lectura remota se completa antes de que una transacción anterior termine de escribir en todas las ubicaciones.

¿Qué es la latencia de las transacciones?
La latencia se refiere tanto al tiempo de respuesta de la base de datos como al tiempo de respuesta de extremo a extremo de la aplicación. La latencia de la transacción es el tiempo que transcurre desde el inicio de la transacción hasta que ésta se confirma.

Esquemas de base de datos para OLTP
Para poder soportar altas tasas de transacción, los esquemas de las bases de datos OLTP suelen incluir tamaños de fila pequeños e índices mínimos. Históricamente, esto significaba asegurarse de que el esquema de la base de datos estaba en 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 que los esquemas de las bases de datos reduzcan la duplicación de datos, eviten las anomalías de datos, garanticen la integridad referencial y simplifiquen la gestión de datos. Básicamente dice que cualquier tabla solo contiene campos que son atributos de la clave primaria.

Si tiene una tabla de pacientes con una clave primaria que es el número de paciente, sus campos deben ser sobre el paciente, no sobre el hospital, ni sobre el médico, ni sobre la aseguradora; aunque la tabla puede contener referencias (claves externas) a otras tablas sobre esas cosas. El ingenioso resumen de Bill Kent sobre 3NF es «[cada] [atributo] no clave debe 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 hablado sobre todo de bases de datos relacionales con fuerte consistencia, hay algunas bases de datos NoSQL que están diseñadas para OLTP. Si se encuentra en la situación de necesitar o querer una base de datos NoSQL para el procesamiento de transacciones, debe restringirse a las bases de datos NoSQL con propiedades ACID. Evite las bases de datos que se limitan a la consistencia eventual para OLTP, especialmente para las aplicaciones financieras. Consulte a sus auditores antes de comprometerse con una base de datos para el procesamiento de transacciones financieras.

Medición del rendimiento OLTP

Al principio de la historia de las bases de datos relacionales, cada proveedor promovía una referencia de rendimiento de procesamiento de transacciones diferente, que había sido ajustada para su propio producto. El Transaction Processing Performance Council (TPC) se formó para crear y auditar los puntos de referencia neutrales de los proveedores. TPC Benchmark C (TPC-C) es una referencia OLTP muy utilizada. Hay otros benchmarks públicos de bases de datos que pueden aplicarse a su caso; también puede crear los suyos propios, pero los benchmarks honestos que reflejan el uso en el mundo real son sorprendentemente difíciles de escribir y ejecutar.

En general, las bases de datos OLTP deben limitarse a hacer su trabajo, que es registrar las transacciones de forma rápida y duradera. Para el análisis, considere la posibilidad de crear un lago de datos o un almacén de datos independiente, y un proceso ETL o ELT para rellenar la base de datos de análisis a partir de la base de datos OLTP. OLTP es una cosa; OLAP es otra.

 

Martin Heller InfoWorld.com

 

Artículo anteriorLa actualización de Visual Studio 2022 mejora la búsqueda
Artículo siguienteLa aplicación de las redes sociales de Trump entra en la App Store de Apple