¿Qué es el OLTP? La columna vertebral del comercio electrónico
Los sistemas de procesamiento de transacciones online están diseñados para gestionar un gran número de movimientos realizados por un gran número de usuarios simultáneos, garantizando al mismo tiempo la integridad de los datos.
El procesamiento de transacciones online (OLTP en sus siglas en inglés) es el proceso de datos en tiempo real que está detrás de las retiradas de dinero en cajeros automáticos, los pagos con tarjeta de crédito, los sistemas de venta de billetes y reservas, las compras online y el comercio electrónico en general. Los sistemas de procesamiento de transacciones online 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 frente a 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) 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 online) 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 del 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 comfirma. Si cualquiera de las dos operaciones falla, entonces 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.
¿Qué 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 comfirmado, 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 sólo reclaman coherencia eventual, lo que les permite decir que una transacción se ha comfirmado 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 coherencia 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 sólida consistencia pueden tener latencias de transacción más altas, pero es mucho menos probable que causen fallos 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 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 los datos. Básicamente dice que cualquier tabla sólo contiene campos que son atributos de la clave principal.
Si tienes una tabla de pacientes con una clave principal 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 te encuentras en la situación de necesitar o querer una base de datos NoSQL para el procesamiento de transacciones, debes restringirte a las bases de datos NoSQL con propiedades ACID. Evita las bases de datos que se limitan a la consistencia eventual para OLTP, especialmente para las aplicaciones financieras. Consula a tus auditores antes de comprometerte 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 promocionaba un punto de referencia de rendimiento de procesamiento de transacciones diferente que había sido ajustado para su propio producto. El Transaction Processing Performance Council (Consejo de Rendimiento del Procesamiento de Transacciones) se formó para crear y auditar puntos de referencia neutrales para los proveedores. El TPC Benchmark C (TPC-C) es un punto de referencia OLTP muy utilizado. Hay otros puntos de referencia de bases de datos públicos, que pueden aplicarse a su caso; 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 deben limitarse a hacer su trabajo, que es registrar las transacciones de forma rápida y duradera. Para el análisis, considera la posibilidad de crear un lago de datos o 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.
