ES2905843T3 - Actualización de los resultados de la consulta de la base de datos en caché - Google Patents

Abstract

Un método para actualizar los resultados de la consulta de la base de datos en caché en un sistema (1) de base de datos distribuido, en el que el sistema (1) de base de datos distribuido comprende una plataforma (2) de caché de datos que mantiene los resultados de la consulta de la base de datos calculados previamente y una plataforma de cálculo (3) para calcular los resultados de la consulta de la base de datos almacenada en caché se basan en datos mantenidos en la plataforma (3) de cálculo, donde la plataforma (2) de caché de datos comprende al menos una interfaz de comunicación para fuentes de comunicación externas, comprendiendo el método: - recibir, por la al menos una interfaz de comunicación, notificaciones con información sobre eventos cuyo punto de tiempo de su ocurrencia no está determinado; - determinar, mediante la plataforma (2) de caché de datos, las probabilidades de que los resultados de la consulta de la base de datos almacenada en caché estén desactualizados, en donde - la determinación depende de un modelo probabilístico y de la ocurrencia de los eventos, - el modelo probabilístico modela las discrepancias entre los resultados de la consulta de la base de datos almacenada en caché que se mantienen en la plataforma (2) de caché de datos y los resultados de la consulta de la base de datos reales supuestos, - los eventos son indeterministas con respecto a la caducidad de los resultados de la consulta de la base de datos en caché y solo tienen una influencia probabilística en las discrepancias entre los resultados de la consulta de la base de datos en caché mantenidos en la plataforma (2) de caché de datos y los resultados de la consulta de la base de datos reales supuestos, - las probabilidades se determinan con base en el modelo probabilístico y se modifican con la ocurrencia de los eventos; - emitir automáticamente, por parte de la plataforma (2) de caché de datos, órdenes de recálculo a la plataforma (3) de cálculo para actualizar los resultados de la consulta de la base de datos almacenados en caché en base a las probabilidades determinadas de que los resultados de la consulta de la base de datos calculados previamente estén desactualizados, en donde almacenados en caché se ordena que se recalculen los resultados de la consulta de la base de datos que tienen una probabilidad de estar desactualizados por encima de un umbral; y - recibir, en la plataforma (2) de caché de datos, los resultados actualizados de la consulta de la base de datos calculados previamente como resultado de las órdenes de recálculo.

Description

DESCRIPCIÓN

Actualización de los resultados de la consulta de la base de datos en caché

Campo de la invención

La presente invención está dirigida al campo de la tecnología de bases de datos. Más específicamente, se refiere a los resultados de las consultas de la base de datos de precálculo y almacenamiento en caché y las estrategias para mantener estos resultados actualizados.

Antecedentes

Un problema común en la tecnología de bases de datos es garantizar tiempos de respuesta cortos a las consultas de bases de datos que requieren el procesamiento de grandes volúmenes de datos. Por ejemplo, dicho procesamiento que consume potencia informática tiene que realizarse en respuesta a las llamadas "consultas abiertas" que contienen solo poca información de entrada (por ejemplo, solo se especifican uno o dos parámetros de una docena de parámetros posibles y/o los rangos del valor especificado de los parámetros son amplios) y, en consecuencia, conducen a un gran número de resultados en general. Las posibilidades de acelerar el procesamiento de datos mediante el aumento del rendimiento del hardware son limitadas. Por lo tanto, se llama la atención sobre la mejora de los mecanismos subyacentes al procesamiento de grandes volúmenes de datos.

Un enfoque general para acortar los tiempos de consulta es calcular previamente las consultas esperadas y mantener los resultados de las consultas correspondientes en un sistema de caché. Entonces, las consultas en realidad no se procesan sobre la base de datos grandes, sino que se dirigen al sistema de caché.

Sin embargo, otro problema que surge junto con tales enfoques de almacenamiento en caché es mantener actualizados los resultados de las consultas calculadas previamente para garantizar que las consultas respondidas por los resultados almacenados en caché reflejen correctamente el estado de la base de datos grande correspondiente. En caso de que los datos subyacentes cambien, los resultados de la consulta en caché quedarán obsoletos y el sistema de caché devolverá resultados incorrectos. Por lo tanto, se necesitan estrategias para mantener actualizado el sistema de caché.

En la técnica anterior se conocen varias estrategias de actualización relativamente simples como, por ejemplo, recalcular todo el dominio de datos con frecuencia, establecer y mantener calendarios de recálculo manualmente y recalcular los datos cuando se vuelven demasiado antiguos.

El documento WO 01/33472 se refiere a un sistema de disponibilidad utilizado en un sistema de planificación de viajes. El sistema incluye una caché que tiene entradas de información de disponibilidad con respecto a los asientos de las aerolíneas. Un gestor de caché gestiona la información de entrada en la caché para mantener la información en la caché correcta, actual, completa o lo más útil posible. En respuesta a una consulta dirigida a la caché, el gestor de caché determina si una respuesta almacenada está obsoleta y, si este es el caso, envía una consulta de disponibilidad a una fuente de información de disponibilidad. Las entradas de caché que se van a modificar se obtienen mediante notificaciones asincrónicas de sistemas externos y se determinan mediante un modelo determinista, predictivo o estadístico.

Similarmente, el documento WO 02/25557 se refiere a un sistema de recuperación de información en el que la información recibida de fuentes de información se almacena en caché para uso futuro, como para futuras solicitudes de clientes. Se pueden generar consultas proactivas para llenar una caché y/o actualizar la información actualmente almacenada en caché. En un sistema de información de aerolíneas, las consultas proactivas se ordenan sobre la base de estadísticas o indicaciones predictivas, como la proximidad de la hora de salida, la antigüedad de los datos almacenados en caché, los asientos restantes en un avión, días festivos o eventos especiales o tipo de equipo. Además, las actualizaciones se reciben mediante notificaciones externas de las aerolíneas, como los mensajes AVS.

Es más, el documento WO 99/22315 describe un mecanismo para actualizar automáticamente los documentos en una caché mediante el uso de un modelo probabilístico basado en estadísticas. Para cada documento, la caché determina una probabilidad Psi(t) de que un objeto almacenado en caché i esté obsoleto en un momento particular t (es decir, el servidor ha cambiado ese objeto) y una probabilidad Pri(h) de que un usuario solicite el objeto i en un momento de solicitud h. La caché actualiza los objetos con el producto más alto Pi = Psi(t) x Pri(h), es decir, la probabilidad de que un objeto desactualizado se devuelva al usuario con la siguiente solicitud. Para mantener estos valores de probabilidad, la caché mantiene y realiza un seguimiento de las estadísticas históricas de los objetos almacenados en la caché, como un intervalo medio estimado entre las actualizaciones del servidor EUI. EUI de un objeto es por ejemplo actualizado cuando el servidor actualiza el propio objeto o el objeto no se actualiza después de que haya transcurrido su tiempo de actualización medio estimado.

Compendio de la invención

Según la invención, un método que comprende las características de la reivindicación 1, una plataforma de caché de datos que comprende las características de la reivindicación 8, un medio de almacenamiento no transitorio legible por ordenador que comprende las características de la reivindicación 9 y un programa informático que comprende las características de la reivindicación 10 son propuestos.

Otros aspectos se exponen en las reivindicaciones dependientes.

Breve descripción de las figuras

La presente invención se describirá con referencia a las figuras adjuntas. Los números de referencia similares generalmente indican elementos idénticos o funcionalmente similares.

La Fig. 1 ilustra una visión general del sistema de base de datos distribuido;

La Fig. 2 muestra una vista más detallada del sistema de base de datos distribuido según una realización;

La Fig. 3 ilustra los componentes de la plataforma de caché según una realización;

La Fig. 4 representa un diagrama de flujo según una realización del método;

La Fig. 5 muestra la disponibilidad de recursos a modo de ejemplo para recalcular según una realización;

La Fig. 6 muestra una representación esquemática de un ordenador de plataforma de caché según una realización.

Descripción general

Antes de pasar a la descripción detallada sobre la base de las figuras, primero se expondrán algunos aspectos más generales con respecto a la Fig. 1.

Para poder manejar consultas de bases de datos o solicitudes de cálculo por lotes que requieren cálculos sobre la base de grandes volúmenes de datos subyacentes, los resultados de consultas de bases de datos correspondientes a las consultas esperadas generalmente se calculan previamente y se almacenan en caché (posteriormente, el término "consulta" se utiliza como término general que incluye cualquier tipo de solicitud de recuperación de información, como consultas transaccionales, solicitudes de cálculos por lotes y otras formas). Los resultados almacenados en caché se almacenan y se devuelven a la entidad que realiza la consulta en respuesta a las consultas que se producen realmente. La Fig. 1 ilustra tal sistema 1 de base de datos en un nivel abstracto. Los datos básicos se mantienen en una plataforma 3 de cálculo que está conectada a una plataforma de caché 2. Esta última emite órdenes de recálculo a la plataforma 3 de cálculo que, a su vez, transmite los resultados correspondientes a la plataforma 2 de caché donde se almacenan los resultados de la consulta calculada previamente.

Este enfoque de almacenamiento en caché de resultados de consultas calculadas previamente conduce al problema general de que los datos del dominio de datos subyacente pueden cambiar con el tiempo y, por lo tanto, los resultados de consultas calculadas previamente almacenados en caché quedan obsoletos. Los resultados de consultas en caché que aún están actualizados, es decir, que coinciden con los equivalentes de cálculo en tiempo real correspondientes (resultados que se calcularían realmente a demanda sin tener disponibles resultados calculados previamente almacenados en caché), se denominan resultados almacenados en caché "precisos" en lo sucesivo. Por lo tanto, cuando la caché representa correctamente el estado actual del dominio de datos que subyace en los resultados de la consulta almacenada en la caché, la caché es, en general, precisa.

En general, para devolver resultados correctos sobre la base de la caché, se desea mantener un alto grado de correlación entre los resultados de las consultas de la base de datos almacenadas en caché que se proporcionan a la entidad que realiza la consulta en respuesta a las consultas de la base de datos y sus equivalentes de cálculo en tiempo real. Al mismo tiempo, sin embargo, es deseable minimizar el consumo de recursos de cálculo causado por los recálculos, es decir, evitar cualquier recálculo innecesario tal como el recálculo de resultados de consultas almacenados en caché aún precisos. Los recursos informáticos son limitados y, por lo general, no hay suficientes recursos informáticos para recalcular todos los resultados de las consultas almacenadas en caché en todo momento. Por lo tanto, es necesario encontrar un equilibrio entre la precisión de la caché y la utilización de la potencia informática disponible.

Los enfoques simples de mantener actualizada una caché de resultados de consultas calculadas previamente tienen varios inconvenientes.

Recalcular todo el dominio de datos con frecuencia, según la cantidad de datos y el recurso informático disponible, por ejemplo una vez al día, podría garantizar un equilibrio razonable entre la precisión de la caché y las respuestas en tiempo real. Sin embargo, este enfoque es difícilmente escalable e ineficiente en términos de consumo de recursos de hardware. En particular, también se recalculan los resultados de la consulta que siguen siendo válidos porque los datos subyacentes correspondientes no han cambiado.

La elaboración de planificación de recálculo para determinar qué resultados de consulta se recalcularán en qué momento manualmente, por parte de un administrador humano, puede resultar eficiente para fines específicos, pero es rígido e inflexible. La planificación debe volver a elaborarse nuevamente cuando cambien los supuestos y las condiciones subyacentes a la planificación. Tampoco puede realizar un seguimiento dinámico de una degradación repentina de la calidad de la caché que podría surgir en caso de cambios masivos en el dominio de datos subyacente. También es difícil diseñar una planificación de este tipo manualmente, por ejemplo debido a la falta de criterios de calidad objetivos, y mantener en términos de costes humanos.

Otro enfoque más es recalcular los datos cuando se vuelven demasiado viejos. Sin embargo, dependiendo de la naturaleza de los datos subyacentes y de los resultados de la consulta que se calcularán previamente, puede ser difícil evaluar buenos umbrales de "antigüedad".

Para hacer que el recálculo sea más eficiente, se deben definir métricas para evaluar cuán "innecesario" es un recálculo. Por ejemplo, no vale la pena volver a lanzar un cálculo previo masivo completo todos los días si menos de la mitad de los resultados de la consulta calculada resultan estar desactualizados. Por otro lado, si se sabe qué clases particulares de resultados de consultas cambian con frecuencia, recalcularlos varias veces al día puede ser beneficioso para la precisión. En consecuencia, se necesita una forma eficaz de evaluar o estimar la precisión de los resultados de la consulta, teniendo en cuenta tanto la ganancia asociada en la precisión como el coste de recalcular.

Según la estrategia de actualización de caché que se presenta en este documento, los recálculos de los resultados de las consultas de la base de datos se deciden en función de las probabilidades de que las consultas de la base de datos almacenadas en caché estén desactualizadas, es decir, que difieran potencialmente de los resultados obtenidos por otro recálculo. Solo se recalculan los resultados de las consultas almacenadas en caché que tienen al menos una cierta probabilidad predeterminada de inexactitud, mientras que otros resultados de consultas almacenados en caché que probablemente aún reflejen con precisión los datos subyacentes, es decir, tienen una menor probabilidad de estar desactualizados, no se recalculan.

La estrategia de actualizar la caché que se presenta aquí se basa, como primer aspecto, en los medios para estimar la precisión de la caché completa de resultados de consultas de bases de datos calculados previamente sobre la base de un modelo predictivo. Como segundo aspecto, también se comprueba si dichas estimaciones se ajustan en general a la realidad, verificando que la estrategia de recálculo basada en modelos sigue siendo válida ante la ocurrencia de eventos reales en tiempo real (y de la vida real) que pueden servir como indicaciones de que, por ejemplo, una parte significativa de los datos subyacentes a las consultas almacenadas en caché se ha modificado y, debido a estos cambios, también las consultas almacenadas en caché correspondientes están desactualizadas.

El modelo predictivo, en el que generalmente se basan las estimaciones de la precisión de la caché, modela las discrepancias entre los resultados de la consulta en caché y los supuestos resultados reales de la consulta de la base de datos, es decir, se aproxima a la precisión o inexactitud de cualquier resultado de la consulta en caché. El modelo modela, por ejemplo, la probable volatilidad de los resultados almacenados en caché a lo largo del tiempo. Las presunciones sobre la volatilidad de los resultados almacenados en caché se concluyen y extrapolan de experiencias pasadas del mundo real sobre el tema del dominio de datos respectivo.

Por ejemplo, los datos subyacentes pueden estar ubicados en el dominio de los viajes aéreos y contener información sobre vuelos como el aeropuerto de salida y destino, la línea aérea, las fechas de salida y regreso, las tarifas, las clases de reserva y similares. Estos datos relacionados con los viajes aéreos se guardan en la plataforma de cálculo y los clientes los consultan para conocer la disponibilidad y los precios de los vuelos aéreos. Calcular precios sobre la base de los datos básicos de vuelo requiere recursos y tiempo. Por lo tanto, los precios reales se calculan previamente y se almacenan en caché en la presente plataforma de caché. En este ejemplo, el modelo probabilístico modela la volatilidad de los precios de los vuelos a lo largo del tiempo. El conocimiento necesario para construir un modelo de este tipo se puede obtener de experiencias del mundo real sobre el comportamiento y la evolución de los precios de los vuelos antes de la fecha de salida. Por ejemplo, podría saberse que los precios de los vuelos permanecen relativamente estables durante el período de tiempo anterior a un mes antes de las respectivas fechas de salida, pero se vuelven más volátiles durante el mes anterior a la fecha de salida. Por lo tanto, el modelo probabilístico indica que los precios almacenados en caché calculados previamente que pertenecen a los vuelos que se realizarán el próximo mes deben recalcularse con más frecuencia que los precios calculados previamente que están asociados con vuelos en un futuro más lejano.

Además de modelar la precisión de la caché mediante el modelo probabilístico, se evita una caída severa de la precisión de la caché al ser reactiva a los eventos en tiempo real. Las decisiones de recálculo se refinan en la recepción de eventos predeterminados en tiempo real que pueden tener un impacto en la corrección de los resultados de la consulta en caché. Los eventos en tiempo real son asincrónicos, es decir, el punto de tiempo de su ocurrencia no está predeterminado, pueden ocurrir en cualquier momento. Para poder recibir y procesar eventos entrantes en tiempo real, la plataforma 2 de datos de caché está equipada con interfaces externas a fuentes de comunicación que notifican a la plataforma de datos de caché según la información relevante.

Dichos eventos en tiempo real pueden pertenecer a situaciones particulares que no se consideran en el modelo predictivo. Por ejemplo, una parte de los precios almacenados en caché pueden verse afectados por una promoción, mientras que otros precios pueden volverse más volátiles en una época particular del año (como temporadas festivas, Navidad, etc.). También situaciones "excepcionales" como una feria comercial, un evento deportivo o similares, eventos aleatorios como huelgas o desastres naturales podrían cambiar las presunciones que subyacen a las causalidades del modelo "normal". Estas influencias particulares se pueden considerar al determinar las probabilidades de que los resultados de las consultas en caché estén desactualizados en respuesta a los respectivos eventos en tiempo real que representan tales situaciones excepcionales. Alternativamente, el impacto de eventos programados como ferias comerciales, temporadas de vacaciones, eventos deportivos y similares se puede introducir en el modelo probabilístico con tiempo suficiente antes de la fecha del evento.

Es importante tener en cuenta que la estrategia de actualización que se presenta aquí es capaz de tener en cuenta eventos "inciertos", es decir, eventos que no invalidan con certeza uno o más resultados de consultas en caché calculados previamente, sino que solo indican que la probabilidad de que los resultados de la consulta de la base de datos en caché están desactualizados podría aumentar. En otras palabras, estos eventos son indeterministas con respecto a la precisión de los resultados de la consulta en caché y solo tienen una influencia probabilística en las discrepancias entre los resultados de la consulta en caché mantenidos en la plataforma 2 de caché y los supuestos resultados reales de la consulta de la base de datos resultantes de un cálculo hipotético. Esto es diferente de las propuestas descritas en los documentos WO 01/33472 y WO 02/25557 en donde los mensajes AVS, por ejemplo, indican que un vuelo particular ha sido cancelado. En consecuencia, al recibir tal mensaje AVS, se sabe con certeza que los respectivos asientos del avión ya no están disponibles.

Por ejemplo, en referencia al escenario de almacenamiento de datos relacionados con viajes como se mencionó anteriormente, un evento en tiempo real que solo tenga un impacto potencial en la precisión de los resultados de la consulta en caché podría ser una actualización de tarifa. Una tarifa es un conjunto de datos que incluye parámetros como la ciudad de salida y de destino, la clase de reserva, el tipo de vuelo (de ida o de ida y vuelta), la cantidad de dinero y las reglas que definen las restricciones que se deben cumplir para que la tarifa se aplique realmente. Por lo tanto, las tarifas representan los datos básicos para el cálculo del precio de un vuelo en particular. Si la aerolínea actualiza las tarifas para un par de ciudades origen-destino específico, puede aumentar la probabilidad de que un precio de vuelo calculado previamente y almacenado en caché con respecto a este par de ciudades ya no sea correcto. Sin embargo, desde la perspectiva de la plataforma 2 de caché de datos, esto no es seguro porque la plataforma 2 de caché de datos desconoce la tarifa que realmente aplicó la plataforma 3 de cálculo previo al calcular previamente el precio almacenado en caché. Es posible que la tarifa aplicada para el cálculo previo anterior no haya cambiado y los cambios de tarifa indicados por el evento de cambio de tarifa no cambien el hecho de que la tarifa pertinente anterior aún se aplica y, por lo tanto, el precio calculado anteriormente sigue siendo válido. O bien, la tarifa aplicada anteriormente en realidad se cambia, pero, debido al cambio, ahora se aplica otra tarifa para el cálculo del precio del vuelo en cuestión que, al final, tiene el efecto de que el precio almacenado en caché sigue siendo válido.

Por lo tanto, en la observación de tales eventos en tiempo real, la plataforma 2 de caché de datos solo puede adivinar con una probabilidad indeterminista que ciertos resultados de consultas en caché ahora están desactualizados y sería ventajoso recalcularlos para mantener la caché precisa. Sin embargo, esto no es un hecho cierto y bien puede ser que los respectivos resultados de la consulta en caché, aunque su probabilidad de estar desactualizados ha aumentado, en realidad siguen siendo precisos.

La determinación de las probabilidades de que los resultados de la consulta de la base de datos en caché estén desactualizados se realiza en dos pasos lógicos: generalmente, en el primer nivel lógico, las probabilidades se identifican mediante el uso del modelo predictivo probabilístico. Posteriormente, en el segundo nivel lógico, estas probabilidades determinadas pueden modificarse en respuesta a eventos entrantes en tiempo real.

Basándose en las probabilidades determinadas de esta manera, la plataforma 2 de caché de datos genera y emite automáticamente órdenes de recálculo a la plataforma 3 de recálculo a través de una interfaz de red apropiada entre las dos entidades (cf. Fig. 1). Generalmente, las órdenes de recálculo se generan con respecto a los resultados de consultas en caché que tienen una mayor probabilidad de estar desactualizados que otros resultados de consultas en caché que tienen una menor probabilidad de estar desactualizados. Esta regla general puede implementarse mediante el uso de valores de umbral de las probabilidades: los resultados de consultas en caché con una probabilidad determinada de estar desactualizados por encima de dicho valor de umbral deben recalcularse. En consecuencia, se envían las respectivas órdenes de recálculo. Los resultados de la consulta en caché con una probabilidad determinada de estar desactualizados en o por debajo de dicho valor de umbral, se consideran probablemente aún precisos y, en consecuencia, no es necesario recalcularlos. En consecuencia, no se emiten órdenes de recálculo con respecto a estos resultados de consulta almacenados en caché.

La plataforma 2 de caché de datos tiene en cuenta las capacidades de cálculo disponibles en momentos particulares antes de enviar las órdenes de recálculo. Para ser capaz de considerar los recursos disponibles, la plataforma 2 de caché de datos necesita tener conocimiento sobre el grado y/o el programa de utilización de la capacidad de la plataforma 3 de cálculo y los recursos de cálculo libres, respectivamente. La información relevante se completa a través del enlace de comunicación entre las dos plataformas.

En respuesta a recibir una orden de recálculo, la plataforma 3 de recálculo vuelve a calcular los resultados de la consulta respectiva y los devuelve a la plataforma 2 de caché de datos donde se almacenan y se repite el seguimiento y determinación de las probabilidades.

Es preferible considerar la relación entre el modelo probabilístico y los eventos en tiempo real que ocurren antes de decidir si una decisión de recálculo debe modificarse o anularse en respuesta a un evento en tiempo real en particular. Básicamente, los eventos en tiempo real deben analizarse si ya están presentes en el modelo probabilístico y en qué medida. Para tales eventos que están suficientemente representados en el modelo, no son necesarias enmiendas ya que su ocurrencia ya se ha tenido en cuenta al determinar las probabilidades de los resultados de la consulta de la base de datos almacenada en caché respectiva sobre la base del modelo probabilístico. Si, por otro lado, el modelo probabilístico no predice en absoluto un evento en tiempo real, es decir, no está presente en el modelo, se lo tiene en cuenta inmediatamente y las probabilidades y las órdenes de recálculo con respecto a la base de datos almacenada en caché respectiva los resultados de la consulta se modifican lo antes posible.

Opcionalmente, los eventos que ocurren en tiempo real que están presentes en el modelo probabilístico hasta cierto punto se acumulan para evaluar las tendencias. Si una acumulación de eventos emergentes en tiempo real generalmente modelados por el modelo probabilístico indica un estallido cuyo alcance está más allá de lo considerado por el modelo, las probabilidades se modifican y, si corresponde, las órdenes de recálculo se anulan en consecuencia.

Opcionalmente, los eventos también se acumulan y analizan en grupos con el fin de filtrar los eventos que podrían desactualizar muy pocos resultados de consultas almacenados en caché y/o podrían considerarse irrelevantes. También por este motivo, los eventos se registran, recopilan a lo largo del tiempo y se gestionan de forma agregada. De esta forma, se evita generar demasiadas órdenes de recálculo en respuesta a eventos de bajo impacto y, por tanto, se evita un aumento desproporcionado de los costes de los recursos de cálculo.

En resumen, tener en cuenta los eventos en tiempo real que pueden influir en la precisión de los resultados de la consulta de la base de datos almacenada en caché al menos por encima de un grado predeterminado proporciona una alta reactividad a la degradación de la caché.

La presente estrategia de actualización de caché se puede utilizar, por ejemplo, junto con la Plataforma de Cálculo Masivo (MCP) de Amadeus, que está sujeta al documento EP 2521074. Empleando la plataforma actual de caché de datos en coexistencia con la MCP, se encuentra disponible un subsistema mejorado para desencadenar el recálculo de la MCP. Los resultados de las consultas de la base de datos, como las recomendaciones de viaje generadas por la MCP, se duplican y almacenan en la plataforma de caché de datos para su posterior análisis. Las decisiones de recálculo se toman sobre la base de un modelo probabilístico que, a su vez, puede estar compuesto sobre la base de datos estadísticos tomados de otros servicios de Amadeus. Además, se tienen en cuenta eventos en tiempo real como cambios en las tarifas de los vuelos, cambios en la disponibilidad de los asientos del avión, invalidaciones de clases de reserva, solicitudes de billetes de vuelos de clientes, eventos de retroalimentación de calidad del usuario, cancelaciones de vuelos y/o similares.

Una aplicación ejemplar para el presente enfoque de actualización de caché es la compra anticipada. Antes de reservar un viaje, los usuarios finales de la industria de viajes normalmente desean informarse sobre los vuelos disponibles, incluidos los precios actuales de los vuelos, sin ningún compromiso de reservar el vuelo. Muy a menudo, estas solicitudes no vinculantes de información previa a la reserva toman la forma de consultas abiertas y amplias de bases de datos que requerirían una enorme cantidad de recursos informáticos si se calcularan solo en el momento de la consulta. Además, los clientes esperan que la información solicitada se entregue de forma prácticamente instantánea en respuesta a sus consultas. Por lo tanto, los resultados de las consultas previas a la compra, como las recomendaciones de viajes aéreos con precios, generalmente se calculan previamente y se almacenan en caché. En consecuencia, la compra anticipada de la industria de viajes constituye una aplicación adecuada para la estrategia de actualización de caché propuesta en este documento.

Descripción detallada

Volviendo ahora a la descripción más detallada, la Fig. 2 muestra una visión general del sistema 1 de base de datos distribuido según una realización ejemplar. Las realizaciones descritas posteriormente se refieren a bases de datos en la industria de viajes. Específicamente, se presenta una realización en la que la plataforma 3 de cálculo mantiene datos sobre ofertas de viajes aéreos y la plataforma 2 de datos de caché almacena precios relacionados con estas ofertas de viajes aéreos que la plataforma 3 de cálculo calcula sobre la base de reglas de cálculo, en particular tarifas de vuelos y sus reglas de cálculo asociadas. Sin embargo, debe señalarse que estas realizaciones son ejemplos únicamente con el fin de ilustrar la presente estrategia de actualización de caché con más detalle. La estrategia de actualización de caché presentada en este documento se puede aplicar a cualquier tipo de datos y resultados de consultas de bases de datos independientemente de la estructura y/o la semántica de los datos y los resultados almacenados en caché.

Como se describió anteriormente, las entidades principales del sistema 1 de base de datos distribuido son la plataforma 2 de caché de datos (en lo sucesivo denominada brevemente DCP) y la plataforma 3 de cálculo. En el ejemplo de la Fig. 2, la plataforma 3 de cálculo es una Plataforma de Cálculo Masivo (MCP) como se describe en el documento EP 2521074. La DCP 2 y la MCP 3 están acopladas a través de al menos un enlace de comunicación que se utiliza para transmitir órdenes de recálculo desde la DCP 2 a la MCP 3 y, en respuesta, recomendaciones de viaje con precio calculado previamente (en lo sucesivo, también denominadas brevemente como "precios") de la MCP 3 a la DCP 2.

La DCP 2 está equipada con interfaces de comunicación adicionales para incorporar datos que utiliza para la determinación de las probabilidades de precisión de los precios almacenados en caché. Estas interfaces incluyen, por ejemplo, enlaces de comunicación para incorporar datos estadísticos que forman la base del modelo probabilístico y para recibir eventos asincrónicos en tiempo real, como cambios de tarifas y anuncios de disponibilidad de vuelos que realizan las aerolíneas o campañas de promoción de clientes.

Además, el sistema 1 de base de datos distribuido puede comprender plataformas 4 de aplicación que organizan y mantienen datos que pueden ser consultados por usuarios finales o clientes externos, como agencias de viajes. Las plataformas 4 de aplicación son llenadas y actualizadas por la MCP 3 a través de los respectivos enlaces de comunicación entre la MCP 3 y las plataformas 4 de aplicación. Este llenado y actualización se activa mediante las órdenes de recálculo emitidas por la DCP 2.

Como se describe en general más arriba y más específicamente a continuación, en respuesta a las órdenes de recálculo recibidas de la DCP 2, la MCP 3 recalcula los precios de las recomendaciones de viaje y los devuelve a la DCP 2. Sin embargo, al mismo tiempo, la MCP 3 también reenvía las recomendaciones de viaje con precio recalculado a las plataformas 4 de aplicación y que también las almacenan (como se indica mediante "integración de recomendación de viaje" en la Fig. 2). En consecuencia, las plataformas 4 de aplicación también almacenan en caché las recomendaciones de viaje con precio calculado previamente que son consultadas por los usuarios, sobre la base de la estrategia de actualización de caché implementada por la DCP 2. Por lo tanto, la presente estrategia de actualización de caché se aprovecha para aplicaciones que brindan beneficios a usuarios, por ejemplo en forma de respuestas instantáneas a consultas abiertas. En tal disposición, la plataforma 2 de caché de datos actúa como una plataforma de control dispuesta para controlar y activar las actualizaciones de las cachés de las plataformas 4 de aplicación. Por lo tanto, los resultados de la consulta de la base de datos en caché almacenados en la plataforma 2 de caché de datos no son accedidos ni consultados por ningún usuario o cliente, sino que simplemente forman la base de datos de control sobre la que se realiza la estrategia de actualización de caché. Sin embargo, en otras disposiciones, la plataforma 2 de caché de datos también puede ser consultada directamente por usuarios o clientes, o, en otras palabras, la presente estrategia de actualización de caché puede implementarse directamente en una o varias plataformas 4 de aplicación en lugar de una entidad de control separada.

Las plataformas 4 de aplicaciones comprenden, por ejemplo, una plataforma de aplicación de compra anticipada, unas plataformas de aplicación de análisis de tarifas y otras plataformas. La plataforma de aplicación de compra anticipada es consultada por usuarios finales que desean información sobre disponibilidad de vuelos y precios. Por ejemplo, un usuario final podría dirigir una consulta a la aplicación de compra anticipada para obtener una visión general de los precios de las ofertas de viaje durante la temporada de vacaciones con salida de Niza por debajo de los 500 euros. Debido a las recomendaciones de viajes con precios calculados previamente almacenados en caché en la aplicación de compra anticipada que se actualizan según la presente estrategia de actualización de caché, no es necesario calcular los precios de los vuelos respectivos en el momento de la consulta. Más bien, una lista de ofertas de viajes que cumplen con estas restricciones bastante no especificadas se puede devolver muy rápidamente sobre la base de las recomendaciones de viajes con precios almacenadas en la plataforma de aplicación de compra anticipada. El usuario puede entonces seleccionar un viaje de la lista devuelta que más le convenga y luego puede emitir una nueva solicitud para reservar realmente este viaje. A continuación, la segunda solicitud es procesada por un motor de reservas (no mostrado) que calcula el precio actual y real y sugiere una oferta vinculante al usuario.

Ahora, con una mirada más cercana a la estructura de la plataforma 2 de caché de datos que se muestra en la Fig. 3, la plataforma 2 de caché de datos se compone de tres módulos:

- El gestor 5 de entrada es responsable de recibir entradas como resultados de consultas de bases de datos calculadas previamente de la MCP 3, eventos asíncronos en tiempo real y otra información como datos estadísticos para alimentar y actualizar el modelo probabilístico.

- El analizador 6 utiliza el modelo probabilístico sobre la base del cual está dispuesto para determinar los resultados candidatos de consulta almacenados en caché que se van a actualizar.

- Finalmente, el consolidador 7 modifica las probabilidades determinadas por el analizador 6 y, cuando es necesario, también el modelo probabilístico sobre la base de eventos observados en tiempo real (este último no se muestra en la Fig. 3).

Además, la DCP 2 incluye una base de datos 8 interna que mantiene los datos de recomendaciones de viajes con precios almacenados en caché. Esta representación solo conserva atributos de la información de precios que son relevantes para evaluar las probabilidades desactualizadas y decidir sobre la decisión de recalcular, como, por ejemplo: par de ciudades, fecha de salida, duración de la estadía y fecha del último cálculo, todos los cuales son salidas de cálculos devueltos por la MCP 3.

Otros datos utilizados por la MCP 3 para realizar sus cálculos, como las tarifas, no se reflejan en la DCP 2, ya que no son necesarios para realizar la estrategia de actualización de caché. Sin embargo, por otro lado, la DCP 2 enriquece sus datos con atributos de metadatos (que no forman parte de los conjuntos de datos devueltos por la MCP 3), como una supuesta precisión inicial (posibilidades de que un precio recién calculado por la MCP 3 difiere del cálculo para la reserva), la volatilidad (indicación de la probabilidad de que un precio difiera del cálculo para la reserva desde su último cálculo) y la popularidad (con qué frecuencia se busca y se reserva el vuelo). Los datos necesarios para establecer estos atributos se guardan en bases de datos externas, como una base de datos 10 de volatilidad, una base de datos 11 de precisión inicial y servidores 9 de estadísticas. Los atributos de metadatos representan el modelo probabilístico sobre la base del cual el analizador 6 determina las probabilidades de si los precios almacenados en caché pueden estar desactualizados (como se explicará con más detalle a continuación).

El gestor 5 de entrada está dispuesto para convertir e integrar todas las fuentes heterogéneas de información en la base de datos 8 de representación local de los precios devueltos por la MCP 3. Registra eventos y acciones que potencialmente impactan en los precios modelados. Estos eventos incluyen promociones de clientes y comentarios sobre discrepancias de clientes. Además, los eventos de disponibilidad de vuelos, como cancelaciones de vuelos, no solo invalidan las recomendaciones de viaje almacenadas en caché que se basan directamente en el vuelo cancelado, sino que también pueden influir en los datos almacenados en caché paralelos, como vuelos del mismo par de ciudades que están programados al mismo tiempo que el vuelo cancelado. Estos eventos en tiempo real se envían luego al consolidador 7 que los procesa adicionalmente para modificar las probabilidades obsoletas y las decisiones de recálculo.

Debido a la cantidad de información involucrada en el almacenamiento en caché de las recomendaciones de viaje con precio, es beneficioso emplear técnicas de codificación. De esta manera, los datos con precio almacenados en caché en la DCP 2 se asignan globalmente al dominio de datos subyacente guardado en la MCP 3, al tiempo que se reducen significativamente los costes de los recursos de almacenamiento. La codificación probabilística se implementa, por ejemplo, mediante el uso de filtros Bloom. El efecto de dicha codificación es doble. Primero, los filtros Bloom son conservadores. Permiten realizar un seguimiento positivo al menos y, en cualquier caso, de aquellos precios que probablemente se vean afectados, por ejemplo por un evento en tiempo real que indica cambios en las tarifas, pero no están equivocados al contrario, los precios que se consideran no afectados en realidad no lo están. Por lo tanto, no hay riesgo de no reconocer los precios potencialmente influenciados por un evento de cambio de tarifas de este tipo. En segundo lugar, la cantidad de indicaciones de falsos positivos depende estrictamente del tamaño asignado del filtro Bloom, por lo que se puede limitar su aparición según sea necesario.

El segundo módulo, el analizador 6, realiza el primer nivel general de determinación de las probabilidades de que las recomendaciones de viajes con precios almacenados en caché estén desactualizadas en función del modelo de degradación probabilística de la precisión de los precios calculados previamente guardados en la DCP 2. Examina y evalúa los metadatos agregados a los precios por el gestor 5 de entrada, como se explicó anteriormente. El modelo probabilístico representado por estos metadatos incluye métricas relativas a la volatilidad de los precios incluidas en la base de datos 10 de volatilidad, la precisión inicial de los precios incorporada a partir de la base de datos 11 de precisión inicial y la popularidad de las recomendaciones de vuelo devueltas por los informes de popularidad de los servidores 9 de estadísticas. Envía información de probabilidad y prioridad con respecto a los precios almacenados en caché al consolidador 7, es decir, indicaciones de qué precios deben recalcularse con prioridad basándose únicamente en la información probabilística estática (es decir, sin considerar ningún evento).

Hay varias formas de utilizar la información del modelo probabilístico para priorizar y decidir qué precios recalcular a continuación. El analizador 6 es configurable para aplicar esa estrategia o una combinación de estrategias dependiendo de la situación (por ejemplo, según un acuerdo con el cliente que posee los datos de viaje subyacentes en la MCP 3, dependiendo de la cantidad de datos, dependiendo de los recursos informáticos disponibles, dependiendo de la objeción de qué manera se debe optimizar la caché). Se pueden aplicar las siguientes estrategias:

• Precisión de los precios: tiene como objetivo maximizar la precisión global del dominio de la fecha.

Presumiblemente, los precios inexactos se recalculan primero.

• Precisión de los precios, ponderada con la popularidad: entre los precios que probablemente sean inexactos, los precios más populares se recalcularán con mayor prioridad que los precios menos populares.

• Precisión de los precios, ponderados por la popularidad y por su antigüedad: Al igual que la estrategia anterior, pero teniendo en cuenta también la hora del último recálculo. Esta estrategia evita la falta de recálculo causada por precios muy volátiles, en particular en el contexto en el que los recursos de recálculo son limitados en comparación con la cantidad de precios que generalmente se deben recalcular.

• Modular los pares de ciudades populares en función de su ubicación geográfica y de la hora de recálculo: esta estrategia también tiene en cuenta las estadísticas sobre qué vuelos de pares de ciudades se consultan con más frecuencia en determinados momentos del día. Como efecto, se evitan los recálculos frecuentes en aquellos momentos en los que rara vez se accede a los vuelos de un par de ciudades específico (porque los datos almacenados en caché inexactos no dañan siempre que las consultas respectivas realmente no ocurran).

Como efecto secundario, el analizador 6 actualiza la base de datos 10 del modelo de volatilidad en función de los valores de los precios recientemente recalculados recibidos de la MCP 3 e incorporados a la DCP 2. Como el analizador puede rastrear la volatilidad real de los precios almacenados en caché en función de la repetición recálculos, puede retroalimentar esta información estadística a la base de datos del modelo de volatilidad 10. Para actualizar el modelo de volatilidad, el analizador 6 cuenta el número de diferencias entre los resultados de precios recién calculados y los valores de precios recibidos previamente. A partir de estas diferencias actualiza los parámetros de volatilidad para las respectivas partes de los precios analizados.

Asimismo, el analizador 6 puede actualizar la base de datos 11 de precisión inicial de la misma manera. También puede solicitar otros informes de popularidad, por ejemplo, si los precios de los nuevos pares de ciudades se han integrado en la DCP 2 por primera vez.

En caso de que no existan datos históricos y estadísticos, respectivamente, de volatilidad, precisión o popularidad de precios, el analizador 6 realiza su procesamiento con parámetros por defecto para ser lo más conservador posible.

Volviendo ahora al tercer módulo, el consolidador 7 realiza el segundo nivel de determinación de probabilidad teniendo en cuenta los eventos entrantes en tiempo real. Además, es la entidad que genera las órdenes de recálculo y las emite a la MCP 3. Toma las salidas del analizador 6 como base para su decisión. Estos proporcionan una primera estimación de las prioridades de recálculo para todos los precios del dominio de datos. Luego, superpone toda la información recopilada de las diversas fuentes de eventos en tiempo real para modificar las prioridades de recálculo. Esto da como resultado prioridades de recálculo mejoradas.

Opcionalmente, puede considerar cualquier acuerdo de nivel de servicio al cliente como, por ejemplo, "garantizar que todos los precios se recalcularán al menos una vez por semana", y modificar las prioridades en consecuencia. Selecciona aquellas entradas en la representación 8 de datos de precios internos con las prioridades más altas primero y las marca para recalcular. Como el consolidador preferiblemente tiene conocimiento de los recursos de cálculo disponibles en la MCP 3, puede asignar tantos precios almacenados en caché como pueda recalcular la MCP 3 en un intervalo de tiempo particular. Luego envía la orden de recálculo resultante a la MCP 3.

La información de eventos en tiempo real es un medio para mejorar la precisión de los datos almacenados en caché sobre un modelo estadístico estricto. Se pueden usar para rastrear lo que realmente está sucediendo en lugar de solo lo que se esperaba. Es un medio para controlar las predicciones del modelo estadístico y modificarlas cuando se demuestra que las predicciones son incorrectas o inadecuadas. Se pueden contemplar varias clases de eventos en tiempo real con respecto a la presente realización:

Los eventos de los actores generalmente ocurren de forma selectiva (es decir, de vez en cuando), pero pueden tener una influencia drástica en las decisiones de recálculo. El cliente externo puede proporcionar comentarios sobre las discrepancias entre la caché y las compras que está experimentando en su propia plataforma. Esta retroalimentación se puede utilizar para modificar la precisión predicha por el modelo estadístico y, por lo tanto, obligar a realizar recálculos antes cuando sea necesario. Cuando un proveedor de datos almacenados en la MCP 3 (por ejemplo, un proveedor de viajes que ofrece viajes) realiza una campaña de promoción de vuelos en ciertos pares de ciudades, se puede suponer que estos precios son más volátiles y se desactualizan con más frecuencia. Por lo tanto, es posible que sea necesario aumentar la frecuencia de recálculo de estos precios durante la campaña de promoción. Como otro ejemplo, puede ser necesaria una operación de mantenimiento para la MCP 3 de vez en cuando o pueden experimentarse problemas operativos dentro del sistema 1. En tales casos, se puede ordenar a la DCP 2 que genere menos o ninguna orden de recálculo hasta que se realiza el mantenimiento y se recupera el problema, respectivamente.

Los eventos de disponibilidad indican un estado en tiempo real sobre la precisión de los vuelos almacenados en caché. Dependiendo de la declaración del evento, se puede saber con certeza que un precio específico del dominio de datos subyacente en la MCP 3 ha cambiado y, por lo tanto, el precio almacenado en caché por la DCP 2 se ha vuelto inválido. No obstante, también pueden verse afectados otros precios, cuyo efecto es incierto y, por tanto, puede aumentar la probabilidad de que estos precios estén desactualizados. Por ejemplo, un evento de "clase cerrada" indica que una clase de reserva en particular se ha llenado para un vuelo en particular. Los asientos en este vuelo y clase ya no se pueden reservar y, por lo tanto, los precios respectivos almacenados en caché por la DCP 2 se han vuelto inválidos con certeza. Sin embargo, esto podría considerarse como una indicación de que otras clases del mismo vuelo y/o asientos en la misma clase en otros vuelos que salen poco antes o después de este vuelo pueden volverse más volátiles. Por lo tanto, sus probabilidades de quedar obsoletos podrían aumentar y recalcular estos precios podría ser beneficioso. Como otro ejemplo, se experimenta que las aerolíneas de bajo costo fijan el precio de sus asientos en función de la ocupación del vuelo. Tras las notificaciones de cambios de ocupación, los respectivos precios almacenados en caché se pueden recalcular rápidamente y, por lo tanto, se mejora/recupera la precisión de la caché.

Las implicaciones de los eventos de cambio de tarifas son difíciles de estimar. En pocas palabras, las tarifas contienen información y lógica, como reglas que se utilizan para calcular el precio de un vuelo en particular. Así, a la hora de calcular el precio real de un determinado vuelo, se accede a un conjunto de tarifas, se decide qué tarifa es la relevante y la que realmente se va a aplicar y, finalmente, se calcula el precio. Por lo tanto, existe una relación "vuelo ^ tarifa o tarifas" (que, sin embargo, también puede cambiar con el tiempo, ya que pueden cambiar las restricciones de la tarifa que se aplica a un vuelo en particular). Sin embargo, las relaciones en la otra dirección "tarifa ^ vuelo o vuelos" generalmente no se rastrean, es decir, no está claro qué tarifa se aplica a qué vuelos. Además, un cambio en una tarifa afecta potencialmente a una gran cantidad de precios calculados a partir del dominio de datos subyacente.

Para determinar el impacto de los eventos de tarifas, la comunicación entre la MCP 3 y la DCP 2 se puede utilizar para proporcionar a la DCP 2 una correspondencia de las tarifas aplicadas por la MCP 3 para calcular los precios. Cuando se calculan los precios en respuesta a las órdenes de recálculo, la MCP 3 registra todas las tarifas a las que se accede para calcular los precios solicitados. Luego, esta información se almacena globalmente en una correspondencia de tarifas ^ vuelos y se mantiene durante cada cálculo por parte de la MCP 3. En el momento en que se recibe un evento de cambio de tarifas, el gestor 5 de entrada busca en esta correspondencia global para determinar los vuelos afectados por los eventos de cambio de tarifas y los marca como "actualizados". Tenga en cuenta que un cambio de tarifa no implica necesariamente un cambio de precio para una recomendación de viaje, como se explicó brevemente anteriormente.

El consolidador 7 primero evalúa la influencia potencial del evento en tiempo real sobre los precios almacenados en caché en lugar de iniciar un recálculo de las recomendaciones de viaje almacenadas en caché sin haber considerado la relación del evento con el modelo probabilístico básico. Dichos eventos se analizan primero con respecto a su representación en el modelo probabilístico. Para eventos que no son predecibles y, por lo tanto, no están incluidos en el modelo probabilístico como, por ejemplo, campañas de promoción o eventos de mantenimiento, los eventos se procesan lo antes posible. Sin embargo, los eventos que están representados en el modelo probabilístico al menos hasta cierto punto, como tarifas o cambios de disponibilidad, se acumulan y su apariencia se compara con las predicciones del modelo probabilístico. Cuando los picos de eventos no coinciden con el modelo localmente, es decir, una ráfaga de eventos está significativamente fuera de la estadística subyacente al modelo probabilístico, los precios afectados se marcan como potencialmente obsoletos para recalcularlos lo antes posible. De esta manera, se filtra el "ruido" provocado por eventos ya presentes en el modelo probabilístico y por lo tanto ya considerados por las determinaciones realizadas por el analizador 6 con anterioridad.

Opcionalmente, con fines de optimización, el consolidador 7 trabaja en una vista de cuadrícula de la representación 8 de datos internos, es decir, considera grupos de precios adyacentes juntos durante su algoritmo en lugar de trabajar en el conjunto de precios de manera aislada. En este enfoque, los conjuntos de datos de precios adyacentes se ven como un solo conjunto de datos con valores de propiedades agregados. Trabajar en conjuntos de datos agregados limita la generación de órdenes de recálculo dispersas y, por lo tanto, aumenta las oportunidades de mutualización y optimización en la MCP 3. Esto reduce los costes de cálculo.

La Fig. 4 resume la descripción detallada anterior y ofrece una descripción general del método de actualización de caché presentado en este documento.

El proceso de mantener actualizada la caché de resultados de consulta de base de datos calculados previamente comienza con la determinación 14 de las probabilidades de inexactitud de los resultados de consulta almacenados en caché. Esta determinación se compone de dos actividades que se ubican en dos niveles lógicos: En primer lugar y en general, se emplea un modelo predictivo basado en datos estadísticos y probabilísticos para estimar la probabilidad de que un resultado de consulta en caché particular no se corresponda con el resultado de la consulta (hipotéticamente) recalculado. En segundo lugar, y más específicamente, se tienen en cuenta los eventos en tiempo real que potencialmente impactan y aumentan, respectivamente, la probabilidad de que los resultados de las consultas en caché estén desactualizados. Estos eventos en tiempo real se caracterizan por el hecho de que, en general, no indican con certeza una inexactitud de los resultados de consultas en caché particulares, sino que son indeterministas a este respecto. Por lo tanto, en su ocurrencia, solo se pueden sacar conclusiones probabilísticas sobre la probabilidad de exactitud e inexactitud, respectivamente.

Sobre la base de las probabilidades determinadas de que los resultados de la consulta de la base de datos en caché estén desactualizados, la DCP 2 emite automáticamente 15 las órdenes de recálculo de la base de datos. Estas órdenes son recibidas por la MCP 3, que luego vuelve a calcular los resultados respectivos y los devuelve 16 a la DCP 2. A su vez, la DCP 2 recibe los resultados y los almacena 17 en una representación 8 local. Esto concluye un ciclo de actualización y el próximo ciclo reitera con la determinación 14 de probabilidad.

A continuación, se describe un ejemplo particular con respecto a la temporización del procedimiento de la presente estrategia de actualización de caché con respecto a la Fig. 5. En este ejemplo, la DCP 2 está configurada para generar órdenes de recálculo cada 20 minutos, es decir, una ronda o el ciclo de determinación de probabilidades de si los datos almacenados en caché están desactualizados y la generación y emisión de órdenes de recálculo lleva 20 minutos. Los recursos en la MCP 3 se conocen a priori durante todo un día y la DCP 2 conoce los recursos de cálculo disponibles en la MCP 3 y, por lo tanto, puede sincronizar la cantidad de recálculos con los recursos disponibles de la MCP 3.

Al comienzo de un ciclo de recálculo, la DCP 2 analiza la precisión actual de los resultados de la consulta de la base de datos almacenada en caché, es decir, las recomendaciones de viajes con precios almacenadas en la base de datos 8 interna. La ronda producirá un conjunto de órdenes de recálculo que serán procesadas por la MCP 3 al final de la ronda de 20 minutos. Mientras tanto, en el lado de la MCP 3, se calculan las órdenes del último ciclo y se generan y transmiten nuevas recomendaciones de precios a la DCP, donde se almacenan y están disponibles para el análisis y la actualización de la información recurrente en el próximo ciclo.

La Fig. 5 muestra que la MCP tiene recursos disponibles significativos en el intervalo de tiempo entre las 04:00 y las 05:00 a.m., por lo que se pueden realizar muchos recálculos en esta hora. Posteriormente, sin embargo, no hay recursos disponibles hasta las 9:00 a.m., por lo que no es posible recalcular en ese momento. Más tarde durante el día, de 09:00 a.m. a 7:00 p.m., algunos recursos están disponibles en la MCP 3.

Durante el ciclo que comienza a las 04:20 a.m., el analizador 6 analiza la precisión de la caché, mientras que el consolidador 7 genera órdenes de recálculo en consecuencia. Esas órdenes serán implementadas por MCP 3 a las 04:40 am. El analizador 6 enfoca la recomendación de precio de MCP que recibió al comienzo de la ronda. Cuenta las diferencias entre los precios recibidos y los precios anteriores cuyo valor ha sido almacenado en un repositorio interno. En base a las diferencias, modifica la fuente de información recurrente "volatilidad". El gestor 5 de entrada guarda los precios de la MCP recibidos para una inspección adicional.

En el ciclo de 4:40 a 5:00 a.m., la MCP 3 procesa las órdenes de recálculo recibidas de la DCP 2 durante el intervalo de 04:20 a 4:40 a.m. La DCP 2 es consciente de que no puede generar ninguna orden de recálculo para el intervalo de tiempo por venir (05:00 a.m.) y sus sucesores hasta las 09:00 a.m. Sin embargo, todavía analiza el modelo de datos continuamente para actualizar la precisión actual de todas las recomendaciones de viaje con precios de caché. Hará lo mismo para cada ciclo futuro hasta las 08:40 a.m.

A las 08:40 a. m., el analizador 6 determina que la precisión de la caché disminuyó durante las cuatro horas anteriores sin ningún recálculo. Genera órdenes de recálculo en consecuencia durante los siguientes ciclos, pero solo en menor medida debido a la cantidad limitada de recursos disponibles en la MCP 3 de 09:00 a.m. a 7:00 p m. Luego, a las 09:00 a.m., la MCP 3 comienza a procesar las nuevas órdenes de recálculo que recibió en el intervalo anterior (es decir, de 08:40 a 09:00 a.m.) y se detendrá después del final de la ronda que dura de 6:40 a. 7:00 p.m.

Después de eso, no hay más recursos disponibles en la MCP 3 durante la noche. Por lo tanto, la DCP 2 no generará más órdenes de recálculo, sino que continuará analizando la precisión de la caché sobre la base del modelo probabilístico y posiblemente de los eventos entrantes en tiempo real.

Finalmente, la Fig. 6 es una representación esquemática de un sistema informático que proporciona la funcionalidad de la plataforma 2 de caché de la Fig. 2. Dentro de la plataforma 2 de caché, se puede ejecutar un conjunto de instrucciones para hacer que el sistema informático realice cualquiera de las metodologías discutidas en este documento. La plataforma 2 de caché incluye un procesador 101, una memoria 102 principal y un dispositivo 103 de interfaz de red, que se comunican entre sí a través de un bus 104. Opcionalmente, puede incluir además una memoria 105 estática y una unidad 106 de disco duro. Un elemento 107 de presentación de video, un dispositivo 108 de entrada alfanumérico y un dispositivo 109 de control del cursor pueden formar una interfaz de usuario del navegador de la lista de distribución. El dispositivo 103 de interfaz de red conecta la plataforma 2 de caché de datos a la plataforma 3 de cálculo, las fuentes de datos estadísticos necesarios para completar el modelo predictivo, como los servidores 9 de estadísticas, la base de datos 10 de volatilidad y la base de datos 11 de precisión inicial, las fuentes de eventos en tiempo real, Internet y/o cualquier otra red. Un conjunto de instrucciones (es decir, software) 110 que incorpora cualquiera de las metodologías descritas anteriormente, o todas ellas, reside completamente, o al menos parcialmente, en o sobre un medio legible por máquina, por ejemplo la memoria 102 principal y/o el procesador 101. Un medio legible por máquina en el que reside el software 110 también puede ser un soporte 111 de datos no volátil (por ejemplo, un disco duro magnético no extraíble o un disco extraíble óptico o magnético) que es parte de la unidad 106 de disco duro. El software 110 puede además transmitirse o recibirse como una señal 112 propagada a través de Internet a través del dispositivo 103 de interfaz de red.

La presente estrategia de actualización de caché proporciona un medio para generar automáticamente decisiones de recálculo de caché. Determina qué resultados de consultas almacenados en caché deben recalcularse y controla el recálculo también en el tiempo teniendo en cuenta los recursos de cálculo disponibles en la plataforma de cálculo. Por lo tanto, en general, la precisión de los resultados de la consulta en caché se estima en el modelo probabilístico que modela la actualización y la desactualización, respectivamente, a lo largo del tiempo. Estos análisis obsoletos permiten procesar varios miles de millones de conjuntos de datos por hora que subyacen al recálculo de los resultados de las consultas de la base de datos en caché.

Claims (10)

REIVINDICACIONES

1. Un método para actualizar los resultados de la consulta de la base de datos en caché en un sistema (1) de base de datos distribuido, en el que el sistema (1) de base de datos distribuido comprende una plataforma (2) de caché de datos que mantiene los resultados de la consulta de la base de datos calculados previamente y una plataforma de cálculo (3) para calcular los resultados de la consulta de la base de datos almacenada en caché se basan en datos mantenidos en la plataforma (3) de cálculo, donde la plataforma (2) de caché de datos comprende al menos una interfaz de comunicación para fuentes de comunicación externas, comprendiendo el método:

- recibir, por la al menos una interfaz de comunicación, notificaciones con información sobre eventos cuyo punto de tiempo de su ocurrencia no está determinado;

- determinar, mediante la plataforma (2) de caché de datos, las probabilidades de que los resultados de la consulta de la base de datos almacenada en caché estén desactualizados, en donde

- la determinación depende de un modelo probabilístico y de la ocurrencia de los eventos,

- el modelo probabilístico modela las discrepancias entre los resultados de la consulta de la base de datos almacenada en caché que se mantienen en la plataforma (2) de caché de datos y los resultados de la consulta de la base de datos reales supuestos,

- los eventos son indeterministas con respecto a la caducidad de los resultados de la consulta de la base de datos en caché y solo tienen una influencia probabilística en las discrepancias entre los resultados de la consulta de la base de datos en caché mantenidos en la plataforma (2) de caché de datos y los resultados de la consulta de la base de datos reales supuestos,

- las probabilidades se determinan con base en el modelo probabilístico y se modifican con la ocurrencia de los eventos;

- emitir automáticamente, por parte de la plataforma (2) de caché de datos, órdenes de recálculo a la plataforma (3) de cálculo para actualizar los resultados de la consulta de la base de datos almacenados en caché en base a las probabilidades determinadas de que los resultados de la consulta de la base de datos calculados previamente estén desactualizados, en donde almacenados en caché se ordena que se recalculen los resultados de la consulta de la base de datos que tienen una probabilidad de estar desactualizados por encima de un umbral; y

- recibir, en la plataforma (2) de caché de datos, los resultados actualizados de la consulta de la base de datos calculados previamente como resultado de las órdenes de recálculo.

2. Método según la reivindicación 1, en el que el modelo probabilístico modela una volatilidad de los datos mantenidos en la plataforma (3) de cálculo en base a datos históricos estadísticos.

3. Método según cualquiera de las reivindicaciones anteriores, en el que la plataforma de caché de datos (2), al determinar las probabilidades de que los resultados de la consulta de la base de datos en caché estén desactualizados y emitir el recálculo, considera rejillas de los resultados de la consulta de la base de datos en caché correspondientes a grupos de adyacentes. Conjuntos de datos mantenidos en la plataforma (3) de cálculo.

4. Método según cualquiera de las reivindicaciones anteriores, en el que la plataforma (2) de caché de datos emite las órdenes de recálculo en función de la cantidad de recursos de cálculo disponibles en la plataforma (3) de cálculo.

5. Método según cualquiera de las reivindicaciones anteriores, en el que el sistema (1) de base de datos distribuido es un sistema de reserva de viajes, en el que la plataforma (3) de cálculo mantiene información sobre disponibilidad de viajes y tarifas y la plataforma (2) de caché de datos mantiene recomendaciones de viajes con precios calculados a partir de la información de disponibilidad de viajes y las tarifas.

6. Método según la reivindicación 5, en el que los eventos comprenden cambios de tarifa de vuelo, cambios de disponibilidad de asientos de avión, solicitudes de billetes de avión de clientes y/o cancelaciones de vuelos.

7. Método según cualquiera de las reivindicaciones anteriores, en el que el sistema (1) de base de datos distribuido comprende al menos una plataforma (4) de aplicaciones conectada a la plataforma (3) de cálculo, manteniendo y organizando la al menos una plataforma (4) de aplicaciones resultados de consulta de base de datos calculados, los resultados de consulta de base de datos almacenados en al menos una plataforma (4) de aplicación son llenados y/o actualizados por la plataforma (3) de cálculo como resultado de las órdenes de recálculo emitidas por la plataforma (2) de caché de datos.

8. Plataforma (2) de caché de datos que mantiene resultados de consulta de base de datos calculados previamente calculados por una plataforma (3) de cálculo en base a datos mantenidos en la plataforma (3) de cálculo, donde la plataforma (2) de caché de datos comprende al menos una interfaz de comunicación para fuentes de comunicación externa, la plataforma (2) de caché de datos configurada para:

- recibir, por al menos una interfaz de comunicación, notificaciones con información sobre eventos cuyo punto de tiempo de su ocurrencia no está determinado;

- determinar las probabilidades de que los resultados de la consulta de la base de datos en caché estén desactualizados,

- donde la determinación depende de un modelo probabilístico y de la ocurrencia de los eventos,

- donde el modelo probabilístico modela las discrepancias entre los resultados de la consulta de la base de datos almacenada en caché que se mantienen en la plataforma (2) de caché de datos y los resultados reales supuestos de la consulta de la base de datos,

- donde los eventos son indeterministas con respecto a la caducidad de los resultados de la consulta de la base de datos almacenada en caché y solo tienen una influencia probabilística en las discrepancias entre los resultados de la consulta de la base de datos almacenada en caché mantenidos en la plataforma (2) de caché de datos y los resultados de la consulta de la base de datos reales supuestos,

- donde las probabilidades se determinan en base al modelo probabilístico y se modifican con la ocurrencia de los eventos;

- emitir automáticamente órdenes de recálculo a la plataforma (3) de cálculo para actualizar los resultados de la consulta de la base de datos almacenada en caché sobre la base de las probabilidades determinadas de que los resultados de la consulta de la base de datos calculados previamente estén desactualizados, donde los resultados de la consulta de la base de datos almacenada en caché que tienen una probabilidad de estar desactualizados por encima de un umbral se ordenan para ser recalculados; y

- recibir los resultados de consulta de base de datos calculados previamente actualizados como resultados de las órdenes de recálculo.

9. Medio de almacenamiento legible por ordenador no transitorio que tiene instrucciones de programas informáticos almacenadas en él, que cuando se ejecuta en un sistema informático hace que el sistema informático:

- determine las probabilidades de que los resultados de la consulta de la base de datos en caché estén desactualizados,

- donde la determinación depende de un modelo probabilístico y de la ocurrencia de eventos cuyo momento de ocurrencia no está determinado,

- donde el modelo probabilístico modela las discrepancias entre los resultados de la consulta de la base de datos almacenados en caché mantenidos en el sistema informático y los resultados reales supuestos de la consulta de la base de datos,

- donde los eventos son indeterministas con respecto a la caducidad de los resultados de la consulta de la base de datos en caché y solo tienen una influencia probabilística en las discrepancias entre los resultados de la consulta de la base de datos en caché mantenidos en el sistema informático y los supuestos resultados reales de la consulta de la base de datos,

- donde las probabilidades se determinan en base al modelo probabilístico y se modifican con la ocurrencia de los eventos;

- emita automáticamente órdenes de recálculo para actualizar los resultados de la consulta de la base de datos en caché sobre la base de las probabilidades determinadas de que los resultados de la consulta de la base de datos calculados previamente estén desactualizados, donde los resultados de la consulta de la base de datos en caché que tienen una probabilidad de estar desactualizados por encima de un umbral se ordenan para ser recalculados; y

- reciba los resultados de consulta de base de datos calculados previamente actualizados como resultados de las órdenes de recálculo.

10. Programa informático para dar instrucciones a un ordenador para que realice el método de cualquiera de las reivindicaciones 1 a 7.