Supongo que su pregunta es: “¿Cuál es la diferencia entre el procesamiento de transacciones en línea (OLTP) y el procesamiento analítico en línea (OLAP)?” Explicaré y contrastaré cada uno.
Procesamiento de transacciones en línea (OLTP):
El procesamiento de transacciones en línea es la metodología de arquitectura de base de datos utilizada para admitir aplicaciones en tiempo real. La mayoría (posiblemente todas) de las aplicaciones web que utiliza habitualmente son compatibles con las bases de datos OLTP. La palabra clave aquí es Transacción , y el objetivo es mantener la arquitectura Normalizada al menos a la 3ra Forma Normal (3NF) o superior. Aquí no entraré en los detalles técnicos de la normalización de la base de datos, excepto para decir que el beneficio de una base de datos normalizada es garantizar que las inserciones, actualizaciones y eliminaciones siempre sean precisas, livianas y rápidas. Este es el objetivo de los sistemas OLTP, y es fundamental para las aplicaciones con muchos usuarios concurrentes porque las inserciones, actualizaciones y eliminaciones provocan bloqueos, bloqueos y posibles interbloqueos , lo que puede generar problemas de concurrencia si tienen demasiada latencia. Las bases de datos altamente normalizadas tienen muchas tablas de búsqueda, prácticamente sin redundancia con la excepción de claves externas , y son más difíciles de consultar desde una perspectiva analítica porque no están diseñadas para lecturas agregadas, lo que la mayoría de las cargas de trabajo analíticas tienden a hacer. Los procesos que ocurren en los sistemas OLTP se denominan Transacciones, que es donde una serie de comandos (inserciones, actualizaciones o eliminaciones) se envuelven en un bloque de transacciones, y generalmente involucran solo unas pocas filas en la base de datos. Piense que los sistemas OLTP tienen un gran volumen de transacciones realmente pequeñas y rápidas contra la base de datos, cada una de las cuales dura solo unos pocos milisegundos.
- Cómo cuidar sus datos de aprendizaje automático cuando hay demasiados experimentos
- ¿Qué es la curva ROC?
- ¿El plan de estudios de Hack Reactor cubre alguna ciencia de datos?
- ¿GoLang es una mejor opción de lenguaje de programación para proyectos de aprendizaje automático manteniendo el rendimiento y la escala horizontal como las principales preocupaciones de diseño?
- ¿Cómo es seguro un hilo de datos en Spring Framework?
Cada transacción no es necesariamente una transacción comercial donde el dinero intercambia manos, aunque puede serlo. El ejemplo más utilizado de una transacción OLTP es una transferencia bancaria. Suponga que transfiere $ 100 a su amigo que usa el mismo banco que usted. La base de datos del banco inicia una transacción, reduce el monto en su cuenta corriente en $ 100, y luego aumenta el monto en la cuenta corriente de su amigo en $ 100, y luego confirma la transacción. Si alguna parte del proceso falla, la transacción se revierte y agrega los $ 100 a su cuenta. Facebook probablemente también usa transacciones. Cuando haces clic en “Me gusta” en una publicación de un amigo, tiene que registrar el me gusta, pero también tiene que registrar en alguna parte el hecho de que aún no te han notificado. La próxima vez que inicie sesión en Facebook, verá ese número rojo con la cantidad de notificaciones que tiene.
Procesamiento analítico en línea (OLAP):
El procesamiento analítico en línea es compatible con la metodología de arquitectura de base de datos Star Schema . Se llama Star Schema porque cuando crea un diagrama de relación de entidad de una base de datos OLAP, se asemeja a una estrella (o, más a menudo, múltiples estrellas). La arquitectura Star Schema es lo que se ve más comúnmente en Data Warehouses . Hay 2 tipos de tablas en el Star Schema:
- Tablas de hechos: hay 1 tabla de hechos en el centro de cada estrella. La tabla de hechos almacena los datos cuantitativos . La clave primaria de la tabla de hechos es una clave primaria compuesta que consiste en al menos el número mínimo de claves foráneas necesarias para garantizar que cada fila de la tabla de hechos sea única (no todas las claves foráneas para las tablas de dimensiones deben participar en la clave primaria compuesta). Aunque la granularidad de la tabla de hechos puede variar, las tablas de hechos suelen almacenar datos numéricos transaccionales muy granulares (transaccionales en el contexto de los negocios o del mundo real, no OLTP). Los datos en la tabla de hechos son los que respaldan los cálculos analíticos, el cálculo de números. Las tablas de hechos suelen ser más estrechas (menos columnas), pero muy profundas (muchas filas). El crecimiento de las tablas de hechos tiende a ser lineal, con aproximadamente el mismo número de filas agregadas por día. La mayoría de los datos numéricos en las tablas de hechos son datos aditivos , pero pueden ser solo semi-aditivos o no aditivos . A menudo, la dimensión que se usa para agrupar o filtrar los datos determinará si la columna de hechos numéricos es o no aditiva.
- Tablas de dimensiones: puede haber cualquier cantidad de tablas de dimensiones para cada estrella. Las tablas de dimensiones almacenan los datos cualitativos . Cada dimensión tiene una relación de uno a muchos con la tabla de hechos. En un entorno puro de Star Schema, las dimensiones son altamente no normalizadas y pueden consistir en múltiples jerarquías . En un entorno OLTP, estas jerarquías se describen utilizando tablas de búsqueda normalizadas con claves foráneas. Pero en un esquema en estrella, los datos se aplanan en las tablas de dimensiones. Esto da como resultado un gran número de filas que almacenan valores repetidos, como las columnas Ciudad, Estado, País y Código postal que pueden existir en una tabla de dimensiones Clientes. Las dimensiones tienden a ser más anchas (más columnas) y tienen menos filas en comparación con las tablas de hechos. El crecimiento de las tablas de dimensiones tiende a estabilizarse con el tiempo, ya que es más probable que el dominio de los valores en las tablas de dimensiones sea aplicable a las nuevas filas de tablas de hechos. Algunos arquitectos eligen normalizar los datos de dimensión en algún nivel. Esto suele ser un esfuerzo para reducir el espacio consumido por el almacén de datos. La normalización de las dimensiones dará como resultado menos espacio, pero agregará uniones a las consultas analíticas, lo que intensifica el costo de la CPU. Esta es una compensación que los arquitectos y administradores de bases de datos deben considerar. Cuando los datos de dimensión se normalizan a cualquier punto más allá de un nivel de la tabla de hechos, esto se llama un esquema de copo de nieve . La mayoría de los almacenes de datos que se describen como esquemas en estrella en realidad tienen algunos atributos de esquema de copo de nieve. Una razón común para convertir una estrella en un copo de nieve es cuando tienes una relación de muchos a muchos entre las dimensiones que necesitas facilitar. También debo tener en cuenta que varias estrellas pueden usar las mismas dimensiones. En este caso, las dimensiones compartidas se denominan Dimensiones conformadas . El uso de dimensiones conformadas es una práctica recomendada fundamental para garantizar la coherencia de los datos y la facilidad de desarrollo al agregar nuevas estrellas a su almacén de datos.
Los almacenes de datos se rellenan con datos a través de un proceso llamado Extraer, Transformar y Cargar (ETL). Antes de que los datos lleguen a un almacén de datos, a menudo reside en una base de datos OLTP. Debido a las diferentes metodologías de arquitectura, ETL es un aspecto crítico de la implementación del almacén de datos. Por lo general, hay una ventana ETL, donde el almacén de datos no está disponible para consultas y las tablas se cargan con datos. Una vez que se cierra la ventana ETL, el almacén de datos entra en modo de solo lectura. A diferencia de las bases de datos OLTP altamente normalizadas donde las transacciones pequeñas actualizan solo unas pocas filas, la estructura del esquema en estrella es óptima para leer grandes cantidades de filas, crear agregaciones como sumas, recuentos, promedios, máximos y mínimos, y filtrar y agrupar los datos.
Una vez que los datos están disponibles en la estructura de esquema en estrella, puede crear Cubos OLAP (piense en un cubo OLAP como similar a una tabla dinámica en Excel) para analizar los datos con mucha más facilidad que es posible a partir de los datos OLTP. Los cubos OLAP le permiten agregar, filtrar y dividir y cortar los datos de tantas maneras como haya combinaciones de columnas de dimensión. A diferencia de los sistemas OLTP, donde cada transacción es de unos pocos milisegundos, las consultas OLAP pueden durar varios minutos, o incluso varias horas, dependiendo del volumen de datos y la complejidad de la consulta.
Recordar:
Los sistemas OLTP tienen una arquitectura que admite inserciones, actualizaciones y eliminaciones eficientes, generalmente utilizando operaciones de búsqueda de índice como método de acceso a datos. Los sistemas OLTP no son óptimos para operaciones de lectura grandes, donde se realizan escaneos de tablas . Los sistemas OLTP están altamente normalizados , generalmente a la tercera forma normal , y a veces incluso a formas normales más altas. Son difíciles para las consultas analíticas porque están normalizadas, lo que requiere unir muchas tablas, lo que es costoso en términos de costo de CPU.
Los sistemas OLAP utilizan la arquitectura Star / Snowflake Schema para admitir cargas de trabajo analíticas, que se leen principalmente mediante escaneos de tablas . De hecho, algunos almacenes de datos se vuelven de solo lectura fuera de la ventana ETL . El sistema OLAP es altamente no normalizado para facilitar el análisis y reducir el costo que de otro modo se incurriría de las uniones de tabla, lo que ocurriría si las consultas analíticas se ejecutaran contra un sistema OLTP.
