stringtranslate.com

Base de datos en tiempo real

La base de datos en tiempo real tiene dos significados. El uso más común del término se refiere a un sistema de base de datos que utiliza tecnologías de transmisión para manejar cargas de trabajo cuyo estado cambia constantemente. [1] Esto difiere de las bases de datos tradicionales que contienen datos persistentes , que en su mayoría no se ven afectados por el tiempo. Cuando se hace referencia a las tecnologías de transmisión por secuencias, el procesamiento en tiempo real significa que una transacción se procesa lo suficientemente rápido como para que el resultado regrese y se actúe de inmediato. [2] Estas bases de datos en tiempo real son útiles para ayudar a las plataformas de redes sociales a eliminar noticias falsas, cámaras de vigilancia en las tiendas que identifican a posibles ladrones por su comportamiento/movimientos, etc.

El segundo significado del término "base de datos en tiempo real" se adhiere a una definición más estricta de tiempo real consistente con informática en tiempo real . Los sistemas de bases de datos en tiempo real funcionan con un sistema operativo en tiempo real para garantizar la validez temporal de los datos mediante el cumplimiento de los plazos de las transacciones de la base de datos e incluyen un mecanismo (como políticas de programación de transacciones) para maximizar el número de transacciones comprometidas con éxito y minimizar el número de transacciones revertidas. Si bien la métrica de rendimiento para la mayoría de los sistemas de bases de datos es el rendimiento o las transacciones por segundo, la métrica de rendimiento de un sistema de base de datos en tiempo real es la proporción de transacciones comprometidas y abortadas. Este ratio indica qué tan efectiva es la política de programación de transacciones, con el objetivo final de cumplir los plazos el 100% del tiempo. Es posible que las bases de datos estrictas en tiempo real, mediante el cumplimiento de plazos, no permitan que las transacciones se retrasen (excedan el plazo). [3]

Descripción general

Las bases de datos en tiempo real son bases de datos tradicionales que utilizan una extensión para brindar potencia adicional para generar respuestas confiables. Utilizan restricciones de tiempo que representan un cierto rango de valores para los cuales los datos son válidos. Este rango se llama validez temporal. Una base de datos convencional no puede funcionar en estas circunstancias porque las inconsistencias entre los objetos del mundo real y los datos que los representan son demasiado graves para realizar modificaciones simples. Un sistema eficaz debe poder manejar consultas urgentes, devolver solo datos temporalmente válidos y admitir la programación de prioridades. Para ingresar los datos en los registros, a menudo un sensor o un dispositivo de entrada monitorea el estado del sistema físico y actualiza la base de datos con nueva información para reflejar el sistema físico con mayor precisión. [4] Al diseñar un sistema de base de datos en tiempo real , se debe considerar cómo representar el tiempo válido y cómo se asocian los hechos con el sistema en tiempo real . Además, considere cómo representar los valores de los atributos en la base de datos para que las transacciones del proceso y la coherencia de los datos no tengan violaciones.

Al diseñar un sistema, es importante considerar qué debe hacer el sistema cuando no se cumplen los plazos. [5] Por ejemplo, un sistema de control de tráfico aéreo monitorea constantemente cientos de aviones y toma decisiones sobre las rutas de vuelo entrantes y determina el orden en el que los aviones deben aterrizar en función de datos como el combustible, la altitud y la velocidad. Si alguna de esta información llega tarde, el resultado podría ser devastador. Para abordar los problemas de datos obsoletos, la marca de tiempo puede respaldar las transacciones al proporcionar referencias de tiempo claras.

Preservar la coherencia de los datos

Aunque el sistema de base de datos en tiempo real puede parecer un sistema simple, surgen problemas durante la sobrecarga cuando dos o más transacciones de la base de datos requieren acceso a la misma parte de la base de datos. Una transacción suele ser el resultado de la ejecución de un programa que accede o cambia el contenido de una base de datos. [6] Una transacción es diferente de una secuencia porque una secuencia solo permite operaciones de solo lectura y las transacciones pueden realizar operaciones de lectura y escritura. Esto significa que en una secuencia, varios usuarios pueden leer el mismo dato, pero no pueden modificarlo ambos. [4] Una base de datos debe permitir que solo se opere una transacción a la vez para preservar la coherencia de los datos . Por ejemplo, si dos estudiantes exigen ocupar el lugar restante para una sección de una clase y presionan enviar al mismo tiempo, solo un estudiante debería poder registrarse. [4]

Las bases de datos en tiempo real pueden procesar estas solicitudes utilizando algoritmos de programación para el control de la concurrencia , priorizando de alguna manera las solicitudes de ambos estudiantes. A lo largo de este artículo, asumimos que el sistema tiene un único procesador, una base de datos basada en disco y un grupo de memoria principal. [7]

En las bases de datos en tiempo real, se forman plazos y diferentes tipos de sistemas responden a los datos que no cumplen con su plazo de diferentes maneras. En un sistema en tiempo real, cada transacción utiliza una marca de tiempo para programar las transacciones. [4] Una unidad de mapeo de prioridades asigna un nivel de importancia a cada transacción a su llegada al sistema de base de datos que depende de cómo el sistema ve los tiempos y otras prioridades. El método de marca de tiempo se basa en la hora de llegada al sistema. Los investigadores indican que, para la mayoría de los estudios, las transacciones son esporádicas con tiempos de llegada impredecibles. Por ejemplo, el sistema otorga una fecha límite de solicitud anterior a una prioridad más alta y una fecha límite posterior a una prioridad más baja. [7] A continuación se muestra una comparación de diferentes algoritmos de programación.

Fecha límite más temprana
PT = DT : el valor de una transacción no es importante. Un ejemplo es un grupo de personas que llaman para pedir un producto.
Valor más alto
PT = 1/VT : la fecha límite no es importante. Algunas transacciones deberían llegar a la CPU en función de su importancia, no de su equidad. Este es un ejemplo de menor holgura que puede esperar la menor cantidad de tiempo. Si las centralitas telefónicas estuvieran sobrecargadas, las personas que llamen al 911 deberían tener prioridad. [8]
Plazo inflado de valor
PT = DT/VT : da igual peso a la fecha límite y a los valores según la programación. Un ejemplo es registrarse para clases donde el estudiante selecciona un bloque de clases que desea tomar y presiona enviar. En este escenario, las prioridades más altas suelen tener prioridad. Un sistema de registro escolar probablemente utilice esta técnica cuando el servidor recibe dos transacciones de registro. Si un estudiante tenía 22 créditos y el otro 100 créditos, la persona con 100 créditos tendría prioridad (programación basada en valores).

Limitaciones de tiempo y plazos

Un sistema que percibe correctamente las limitaciones de serialización y tiempo asociadas con transacciones con plazos flexibles o firmes, aprovecha la coherencia absoluta . [9] Otra forma de asegurarse de que los datos sean absolutos es utilizar restricciones relativas. Las restricciones relativas garantizan que las transacciones ingresen al sistema al mismo tiempo que el resto del grupo al que está asociada la transacción de datos. El uso de mecanismos de restricciones absolutas y relativas garantiza en gran medida la precisión de los datos.

Una forma adicional de abordar la resolución de conflictos en un sistema de base de datos en tiempo real además de los plazos es un método de política de espera. Este proceso ayuda a garantizar la información más reciente en sistemas en los que el tiempo es crítico. La política evita conflictos al pedir a todos los bloques que no lo solicitan que esperen hasta que se procese el bloque de datos más esencial. [4] Si bien los estudios en laboratorios han encontrado que las políticas basadas en fechas límite de datos no mejoran el rendimiento significativamente, la política de espera forzada puede mejorar el rendimiento en un 50 por ciento. [10] La política de espera forzada puede implicar esperar a que se procesen transacciones de mayor prioridad para evitar un punto muerto. Otro ejemplo de cuándo se pueden retrasar los datos es cuando un bloque de datos está a punto de caducar. La política de espera forzada retrasa el procesamiento hasta que los datos se actualizan utilizando nuevos datos de entrada. El último método ayuda a aumentar la precisión del sistema y puede reducir la cantidad de procesos necesarios que se cancelan. Generalmente, confiar en políticas de espera no es óptimo. [11]

Es necesario discutir la formación de plazos. Los plazos son las limitaciones para los datos que pronto serán reemplazados a los que tendrá acceso la transacción. Los plazos pueden ser observadores o predictivos. [11] En un sistema de plazos estricto, se examinan todas las transacciones inconclusas y el procesador determina si alguna ha cumplido su plazo. [4] Los problemas surgen en este método debido a las variaciones causadas por las variaciones del tiempo de búsqueda, la gestión del búfer y los fallos de página . [12] Una forma más estable de organizar los plazos es el método predictivo. Crea un cronograma candidato y determina si una transacción no cumpliría con la fecha límite según el cronograma. [4]

El tipo de respuesta a un plazo incumplido depende de si el plazo es estricto, flexible o firme. Los plazos estrictos requieren que cada paquete de datos llegue a su destino antes de que expire y, de lo contrario, el proceso podría perderse, provocando un posible problema. Problemas como estos no son muy comunes porque se requiere la omnipotencia del sistema antes de asignar plazos para determinar el peor de los casos. Esto es muy difícil de hacer y si algo inesperado le sucede al sistema, como un pequeño fallo de hardware, podría alterar los datos. Para plazos flexibles o firmes, el incumplimiento de un plazo puede provocar un desempeño degradado, pero no una catástrofe. [7] Un plazo flexible cumple con tantos plazos como sea posible. Sin embargo, no existe ninguna garantía de que el sistema pueda cumplir todos los plazos. Si una transacción no cumple con su fecha límite, el sistema tiene más flexibilidad y la transacción puede aumentar en importancia. A continuación se muestra una descripción de estas respuestas:

Fecha limite inflexible
Si el incumplimiento de los plazos crea problemas, lo mejor es fijar un plazo estricto. Es periódico, lo que significa que ingresa a la base de datos siguiendo un patrón rítmico regular. Un ejemplo son los datos recopilados por un sensor. Estos se utilizan a menudo en sistemas críticos para la vida. [13]
Plazo firme
Los plazos firmes parecen ser similares a los plazos estrictos, pero se diferencian de los plazos estrictos porque los plazos firmes miden la importancia de completar la transacción en algún momento después de que llega la transacción. A veces, completar una transacción después de que haya expirado el plazo puede ser perjudicial o no útil, y tanto los plazos firmes como los estrictos tienen esto en cuenta. Un ejemplo de fecha límite firme es un sistema de piloto automático. [8]
Plazo flexible
Si es deseable cumplir con las limitaciones de tiempo pero el incumplimiento de los plazos no causa daños graves, lo mejor puede ser un plazo flexible. Opera en un horario aperiódico o irregular. De hecho, se desconoce la llegada de cada tiempo para cada tarea. Un ejemplo es la centralita de un operador telefónico. [13]

Los procesos de fecha límite estricta cancelan las transacciones que han superado la fecha límite, lo que mejora el sistema al eliminar el desorden que debe procesarse. Los procesos pueden borrar no sólo las transacciones con plazos vencidos sino también las transacciones con plazos más largos, asumiendo que una vez que lleguen al procesador quedarían obsoletas. Esto significa que otras transacciones deberían tener mayor prioridad. Además, un sistema puede eliminar las transacciones menos críticas. Cuando estaba preseleccionando clases durante un período de mucho tráfico, un campo en la base de datos puede estar tan ocupado con solicitudes de registro que no estuvo disponible por un tiempo y el resultado de mi transacción fue una visualización de la consulta SQL enviada y un mensaje. Dicho esto, los datos no están disponibles actualmente. Este error es causado por el verificador, un mecanismo que verifica el estado de las reglas y la regla que ocurrió antes. [14]

El objetivo de programar períodos y plazos es actualizar las transacciones que se garantiza que se completarán antes de su fecha límite de tal manera que la carga de trabajo sea mínima. Con grandes bases de datos en tiempo real, las funciones de almacenamiento en búfer pueden ayudar a mejorar enormemente el rendimiento. Un búfer es parte de la base de datos que se almacena en la memoria principal para reducir el tiempo de respuesta de las transacciones. Para reducir las transacciones de entrada y salida del disco, se debe asignar una cierta cantidad de buffers. [15] A veces, las multiversiones se almacenan en buffers cuando el bloque de datos que necesita la transacción está actualmente en uso. Posteriormente, la base de datos tiene los datos adjuntos. Diferentes estrategias asignan búferes y deben equilibrar entre tomar una cantidad excesiva de memoria y tener todo lo que se debe buscar en un búfer. El objetivo es eliminar el tiempo de búsqueda y distribuir los recursos entre marcos de búfer para acceder a los datos rápidamente. Un administrador de búfer es capaz de asignar más memoria, si es necesario, para mejorar el tiempo de respuesta. El administrador del buffer puede incluso determinar si una transacción que tiene debe avanzar. El almacenamiento en búfer puede mejorar la velocidad en sistemas en tiempo real. [15]

Futuros sistemas de bases de datos

Las bases de datos tradicionales son persistentes pero incapaces de manejar datos dinámicos que cambian constantemente. Por tanto, se necesita otro sistema. Las bases de datos en tiempo real pueden modificarse para mejorar la precisión y la eficiencia y evitar conflictos, proporcionando fechas límite y períodos de espera para asegurar la coherencia temporal. Los sistemas de bases de datos en tiempo real ofrecen una forma de monitorear un sistema físico y representarlo en flujos de datos en una base de datos. Un flujo de datos, como la memoria, se desvanece con el tiempo. Para garantizar que se registre la información más actualizada y precisa, existen varias formas de verificar las transacciones para asegurarse de que se ejecuten en el orden correcto. Una casa de subastas en línea es un ejemplo de una base de datos que cambia rápidamente.

Ahora los sistemas de bases de datos son más rápidos que en el pasado. En el futuro, podemos esperar sistemas de bases de datos aún más rápidos. Aunque ahora tenemos sistemas más rápidos, un esfuerzo por reducir los errores y las tardanzas seguirá siendo beneficioso. La capacidad de procesar los resultados de manera oportuna y predecible siempre será más importante que el procesamiento rápido. El procesamiento rápido que se aplica mal no es útil para los sistemas de bases de datos en tiempo real. Las transacciones que se ejecutan más rápido a veces se bloquean de tal manera que es necesario cancelarlas y reiniciarlas. De hecho, un procesamiento más rápido perjudica algunas aplicaciones en tiempo real porque una mayor velocidad genera más complejidad y más posibilidades de que surjan problemas causados ​​por una variación de velocidad. Un procesamiento más rápido hace que sea más difícil determinar qué plazos se han cumplido con éxito. Dado que los futuros sistemas de bases de datos funcionarán incluso más rápido que nunca, es necesario realizar más estudios para que podamos seguir teniendo sistemas eficientes. [dieciséis]

La cantidad de investigaciones que estudien los sistemas de bases de datos en tiempo real aumentará debido a aplicaciones comerciales como las casas de subastas basadas en la web como eBay . Cada vez más países en desarrollo están ampliando sus sistemas telefónicos y el número de personas con teléfonos móviles en Estados Unidos y en otros lugares del mundo sigue creciendo. También es probable que estimule la investigación en tiempo real el aumento exponencial de la velocidad del microprocesador. Esto también permite nuevas tecnologías como las videoconferencias web y las conversaciones de mensajería instantánea con sonido y vídeo de alta resolución, que dependen de sistemas de bases de datos en tiempo real. Los estudios de consistencia temporal dan como resultado nuevos protocolos y restricciones de tiempo con el objetivo de manejar transacciones en tiempo real de manera más efectiva. [7]

Referencias

  1. ^ Buchmann, A. "Sistemas de bases de datos en tiempo real". Enciclopedia de tecnologías y aplicaciones de bases de datos. Ed. Laura C. Rivero, Jorge H. Doorn y Viviana E. Ferraggine. Grupo de ideas, 2005.
  2. ^ Carpron, HL, JA Johnson. Computadoras: herramientas para la era de la información. Prentice Hall, 1998. 5ª ed.
  3. ^ "¿Qué es y qué no es un sistema de base de datos en tiempo real?". db-engines.com . Consultado el 17 de marzo de 2023 .
  4. ^ abcdefg Abbot, Robert K. y Héctor García-Molina . (1992). "Programación de transacciones en tiempo real: una evaluación del desempeño" (PDF) . Transacciones ACM en sistemas de bases de datos . Universidad de Stanford y Digital Equipment Corp. ACM. 17 (3): 513–560. doi :10.1145/132271.132276. S2CID  28960 . Consultado el 13 de diciembre de 2006 .{{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )
  5. ^ "Los sistemas de bases de datos en tiempo real no son realmente en tiempo real. A menos que lo sean". www.electronicdesign.com . Consultado el 21 de enero de 2023 .
  6. ^ Singhal, Mukesh. Enfoques para el diseño de sistemas de bases de datos en tiempo real, Registro SIGMOD, volumen 17, no. 1 de marzo de 1988
  7. ^ abcd Haritsa, J., J. Stankovic y M Xiong. "Un protocolo de control de concurrencia consciente del estado para bases de datos replicadas en tiempo real". Universidad de Virginia. Simposio de aplicaciones en tiempo real IEEE . Consultado el 13 de diciembre de 2006 . {{cite journal}}: Citar diario requiere |journal=( ayuda )Mantenimiento CS1: varios nombres: lista de autores ( enlace )
  8. ^ ab (Snodgrass)
  9. ^ Lee, Juhnyoung (1994). "Algoritmos de control de concurrencia para sistemas de bases de datos en tiempo real". Disentimiento. Univ. de Virginia . Consultado el 13 de diciembre de 2006 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  10. ^ (Porkka)
  11. ^ ab Kang, K D., S Son y J Stankovic. Especificación y gestión de la calidad de los servicios de datos en tiempo real. Universidad de Virginia. IEEE TKDE, 2004.
  12. ^ Kao y García-Molina 1994, págs. 261–282.
  13. ^ ab Stankovic, John A., Marco Spuri, Krithi Ramamritham y Giorgio C. Buttazzo. Programación de plazos para sistemas en tiempo real: EDF y algoritmos relacionados. Springer, 1998.
  14. ^ (Ramamritham)
  15. ^ ab (O'Neil)
  16. ^ Lam, Kam-Yiu y Tei-Wei Kuo. Sistemas de bases de datos en tiempo real: arquitectura y técnicas. Springer, 2001.

Otras lecturas

  • Ozsoyoglu, Gultekin y Richard T. Snodgrass. Bases de datos temporales y en tiempo real: una encuesta. Ingeniería de datos y conocimiento, 1995. 13 de diciembre de 2006.
  • Kao, Ben; García-Molina, Héctor (1994). "Una descripción general de los sistemas de bases de datos en tiempo real". Computación en tiempo real. Berlín, Heidelberg: Springer Berlín Heidelberg. doi :10.1007/978-3-642-88049-0_13. ISBN 978-3-642-88051-3. ISSN  0258-1248.
  • Lindstrom, enero. Sistemas de bases de datos en tiempo real. Sólido, 2008. 25 de marzo de 2008
  • Sivasankaran, Rajendran M., John A. Stankovic, Don Towsley , Bhaskar Purimetla y Krithi Ramamaritham. Asignación de Prioridades en Bases de Datos Activas en Tiempo Real. Universidad de Massachusetts. Amaherst, Nueva York, 1996. 13 de diciembre de 2006.
  • Stonebraker, Michael y cols. HStore: un sistema de procesamiento de transacciones de memoria principal distribuida de alto rendimiento, 2008.