MXPA06009355A - Base de datos paralela ultra - nada compartida. - Google Patents

Abstract

Se describe un sistema de bases de datos paralelas, ultra-nada compartidas que incluye por lo menos un nodo amo y multiples nodos esclavo. Una base de datos consistente en por lo menos una tabla de hechos y multiples tablas de dimension se particiona y distribuye a lo largo de los nodos esclavo del sistema de bases de datos para que las consultas sean procesadas en paralelos sin requerir de la transferencia de datos entre los nodos esclavo. La tabla de hechos y una primera tabla de dimension de la base de datos se particionan a lo largo de los nodos esclavo. Las demas tablas de dimension de la base de datos se duplican en cada uno de los nodos esclavo y por lo menos una de estas otras tablas de dimension se particiona a lo largo de los nodos esclavo.

Description

BASE DE DATOS PARALELA ULTRA-NADA COMPARTIDA Esta solicitud reclama el beneficio ante la solicitud provisional US No. 60/546,428, presentada el 21 de febrero de 2004, la cual se incorpora para referencia en la presente.

Campo de la invención La presente invención se refiere a los sistemas de bases de datos paralelas, y en particular se refiere a un sistema de bases de datos paralelas nada compartidas .

Antecedente de la invención Los sistemas de bases de datos paralelas diseñados utilizando arquitectura nada compartida consisten en múltiples nodos, cada uno con sus propios recursos de procesamiento, memoria y disco. En estos sistemas, las tablas de una base de datos se distribuyen a lo largo de lo nodos del sistema. Las consultas contra la base de datos entonces se corren- en paralelo en múltiples nodos al mismo tiempo. Los sistemas de bases de datos nada compartidas están destinados a proporcionar escalamiento lineal donde al aumentar la cantidad de nodos del sistema se mejora el desempeño y permite manejar series de datos más grandes. Sin embargo, los diseños convencionales no proporcionan un escalamiento lineal por problemas como puede ser el sesgo de la consulta.

El sesgo de la consulta se observa cuando dos consultas diferentes de un nivel de complejidad semejante contra la misma base de datos tardan tiempos muy diferentes para ejecutarse. En los sistemas de bases de datos paralelas, nada compartidas, normales, el sesgo de •la consulta es el resultado de tener que transferir cantidades grandes de datos entre nodos para procesar algunas consultas, mientras que otras consultas son procesadas con poca o ninguna transferencia de datos. Esta transferencia de datos hace más lento el procesamiento de la consulta y crea cuellos de botella en los sistemas tradicionales.

Por ejemplo, en un sistema tradicional que tiene 4 nodos, las tablas de las bases de datos muchas veces se distribuyen igualmente cinco una cuarta parte de cada tabla almacenada en cada nodo. Las consultas comunes a la base de datos pueden ser uña o más "uniones" que barren las tablas de las bases de datos buscando coincidencias entre una primera clave de una tabla y una clave ajena de otra tabla. Para procesar una unión de dos tablas de bases de datos, cada nodo debe transferir su parte de una de las tablas de la base de datos a los demás nodos . Dependiendo de las tablas de base de datos que se estén uniendo y cuantas uniones estén incluidas- en una consulta, esta transferencia de datos pueden necesitar tiempo significativo el cual retarda el procesamiento de la consulta. A medida que las series de datos se hacen más grandes y la cantidad de cesiones, de consulta crece, el sesgo de la consulta reduce cada vez más la eficacia del sistema. De acuerdo con el carácter de este problema, la incorporación de otros nodos en estos sistemas tradicionales no superar este cuello de botella en el procesamiento de las consultas.

Por consiguiente, existe la necesidad de un sistema de bases de datos paralelas, nada compartidas, mejorado que mitigue el sesgo de la consulta. Además, el sistema mejorado debe llevar al mínimo los gastos administrativos necesarios para operar el sistema y debe proporcionar protección segura contra relevos .

Compendio de la invención La presente invención se dirige a las deficiencias antes mencionadas de los sistemas de bases de datos nada compartidas, convencionales, proporcionando un sistema de bases de datos paralelas, ultra nada compartidazas . El sistema de bases de datos paralelas, ultra nada compartidas de la invención particiona y distribuye las tablas de una base de datos a través de múltiples nodos esclavos en una forma que permite que las consultas a la base de datos sean procesadas en paralelo sin requerir mucho que los datos sean transferidos entre los nodos como en la técnica anterior. La base de datos se distribuye de acuerdo con una serie de reglas que se refieren a la estructura de los esquemas de las bases de datos y el tamaño relativo de las tablas. Al reducir significativamente la necesidad de transferir datos entre nodos, la presente invención mejora significativamente el desempeño del sistema reduciendo el tráfico de red y el sesgo de la consulta resultante.

Para una base de datos determinada, la tabla de hechos y una de las tablas de dimensiones se particionan en una clave común y se distribuyen a través de múltiples nodos esclavos. Las tablas de dimensión pequeña en la base de datos se duplican en todos los nodos esclavos del sistema. Las tablas de dimensión restantes se particionan a través de los nodos esclavos y se duplican en todos los nodos esclavos. Esto permite que el sistema de las bases de datos ejecute la mayor, parte de las consultas sin ocasionar significativo tráfico de red entre los nodos esclavos o entre el nodo amo y los nodos esclavos.

De acuerdo con un aspecto de la invención, se proporciona ' un sistema de bases de datos paralelo que incluye un nodo amo y múltiples nodos esclavos. Una base de datos, que incluye una tabla de hechos y múltiples tablas de dimensiones, se distribuye a través de los nodos esclavos del sistema de bases de datos. Para distribuir las tablas de la base de datos, la tabla de hechos y una primera tabla de dimensiones se particiona a través de los nodos esclavos. Las tablas de dimensiones restantes se duplican en cada uno de los nodos esclavos y, si tienen un tamaño mínimo, también se particionan a través de los nodos esclavos.

Preferentemente, la tabla de hechos y la primera tabla de dimensiones se particionan en una clave común. Las tablas de dimensiones restantes se particionan, como una opción, por fila o por columna a través de los nodos esclavos del sistema. Las consultas contra la base de datos se traducen en por lo menos una subsconsulta que puede ser ejecutada por los nodos esclavos del sistema de bases de datos paralelas sin transferir datos entre los nodos esclavos.

De acuerdo con otro aspecto de la invención, el sistema de bases de datos paralela almacena en caché los resultados de la consulta producidos por el sistema de bases de datos. Preferentemente, el nodo amo incluye un caché de consulta para cachetizar los resultados de la consulta producidos por el nodo amo y los nodos esclavo cada uno incluye un caché de consulta para cachetizar los resultados de la subconsulta producidos por los nodos esclavos respectivos.

De acuerdo con otro aspecto de la invención, a cada uno de los nodos esclavos del sistema de bases de datos se asigna uno o más contra partes de relevo. La invención resumida antes proporciona un sistema de bases de datos paralelas eficiente y confiable. Se elimina el sesgo de la consulta del procesamiento de las consultas de la base de datos con lo que se permite escalamiento casi lineal del sistema de bases de datos. Una memoria caché de consulta binivel reduce el procesamiento de consultas repetitivas sin intervenir en cambios a las tablas subyacentes de las consultas. Por último, el uso de contrapartes de relevo entre los nodos esclavo proporciona una solución con una buena relación costo eficacia para proporcionar operación continua en el caso de falla del nodo.

El resumen anterior de la invención ha sido proporcionado de modo que se pueda comprender rápidamente el carácter de la invención. Una comprensión más detallada y completa de las modalidades preferidas de la invención se puede obtener haciendo referencia a la siguiente descripción detallada de la invención y los dibujos asociados.

Breve' descripción de los dibujos La Figura 1 es un diagrama esquemático que representa la arquitectura del Hardware de un sistema de bases de datos paralelas nada compartidas.

La Figura 2 es un diagrama esquemático que representa la arquitectura del software de un sistema de bases de datos paralelas ultra nada compartidas de acuerdo con una modalidad de la invención.

La Figura 3 es un diagrama de flujo que representa un proceso que se utiliza para generar un esquema esclavo.

La Figura 4 es un diagrama que representa un ejemplo de un esquema hospedero .

La Figura 5 es un diagrama de flujo que representa un proceso para ordenar las tablas de un esquema hospedero .

La Figura 6 es un diagrama de flujo que representa un proceso para másica de las tablas de una base de datos al sistema de bases de datos de acuerdo con una modalidad de la invención.

La Figura 7 es un diagrama de flujo que representa un proceso para cargar tablas de bases de datos en nodos esclavo de un sistema de bases de datos.

La Figura 8 es un diagrama de flujo que representa un proceso para la carga másica de los datos previamente clasificados directamente en los nodos esclavos.

La Figura 9 es un diagrama de flujo que representa un proceso efectuado luego de recibir una nueva instrucción desde un sistema hospedero externo.

La Figura 10 es un diagrama de flujo que representa un proceso para el análisis y procesamiento de una instrucción SQL.

La Figura 11 es un diagrama de flujo que representa un proceso para alterar una tabla de base de datos.

La Figura 12 es un diagrama de flujo que representa un proceso para actualizar o insertar datos en las tablas de la base de datos.

La Figura 13 es un diagrama de flujo que representa un proceso de paralelización de la consulta.

La Figura 14 es un diagrama de flujo que representa un proceso para gestionar una consulta en un solo paso .

La Figura 15 es un diagrama de flujo que representa un proceso para sustituir nombres de tabla en una consulta con los nombres de las tablas utilizadas en un esquema esclavo.

La Figura 16 es un diagrama de flujo que representa un proceso realizado en un nodo esclavo para gestionar una consulta.

La Figura 17 es un diagrama de flujo que representa un proceso de consulta en múltiples pasos.

La Figura 18 es un diagrama de flujo que representa un proceso de relevo realizado en el caso de una falla del nodo amo .

La Figura 19 es un diagrama de flujo que representa un proceso de relevo realizado en el caso de una talla de no nodo esclavo.

Descripción detallada de la invención La presente invención es un sistema de bases de datos paralelas, nada compartidas, mejorado, que se conoce como un sistema de bases de datos paralelas, ultra nada compartidas . El sistema de bases de datos paralelas ultra nada compartidas esta configurado en una forma semejante a los sistemas de bases de datos paralelas nada compartidas, tradicionales, utilizando por lo menos un nodo amo y múltiples nodos esclavos . La Figura 1 es un diagrama esquemático que representa la arquitectura del Hardware de una modalidad del sistema de bases de datos paralelas, ultra nada compartidas.

La Figura 1 representa la configuración del sistema de bases de datos 10, el cual incluye el nodo amo 11 y nodos esclavos 12a a 12n. Para simplificar el diagrama, la Figura 1 incluye solo un nodo amo 11. Sin embargo, como se describe con mayor detalle más adelante, otras modalidades de la invención incorporan múltiples nodos amo 11 en el sistema de bases de datos 10. El nodo amo 11 y los nodos esclavos 12a a 12n están interconectados a través de la red 13. Preferentemente, la red 13 es una red redundante que se utiliza para mejorar la confiabilidad del sistema de bases de datos 10. En otra versión, es posible utilizar una red no redundante para aplicaciones no cruciales. La red 13 se implementa utilizando cualquiera de un número de técnicas de disposición de red y protocolos bien conocidos para los expertos en la técnica. Las redes ejemplares pueden ser, pero no se limitan a, TCP/IP sobre Ethernet y MPI (interfaz de paso de mensajes) sobe Infiniband.

Cada nodo del sistema de la bases de datos 10 incluye sus propios recursos de procesamiento, memoria y disco. Específicamente, el nodo amo 11 incluye la unidad de procesamiento central (CPU) 14, memoria de acceso aleatorio (RAM) 15 y el disco 16. Los nodos esclavos 12a a 12n incluyen las CPU 17a a 17n, RAM 18a a 18n y los discos 19a a 19n, respectivamente. Las CPU ejecutan instrucciones de programas de módulos de Software almacenados en los discos respectivos. Las CPU utilizan la RAM como espacio de trabajo o cargar secuencias de instrucciones y almacenar y manipular datos. Si bien cada nodo esta representado como que incluye una sola CPU y un solo disco, un experto en la técnica se dará cuenta que cada nodo puede incluir múltiples CPU y múltiples discos para mejorar el desempeño del sistema. Por ejemplo, una instrumentación de la invención utiliza nodos que tienen procesadores dobles y arreglos de 12 discos duros.

Además de los componentes básicos de Software, como puede ser un sistema operativo y controladores de dispositivos, cada nodo del sistema de bases de datos 10 almacena y ejecuta módulos de Software que se utilizan para implementar la presente invención. La Figura 2 es un diagrama esquemático que representa la arquitectura del Software del sistema de bases de datos 10. El nodo amo lia incluye Software de manejo de flujos 20, Software del caché de consulta 21, Software de análisis del Lenguaje Estructurado de Consulta (SQL) 22, el Software para la generación de esquemas esclavos 23, Software para actualización e inserción 24, Software de paralelización y optimización de consultas 25, Software para la ejecución de consultas en múltiples pasos 26, Software para el análisis de las series de resultados 28, Software para el mantenimiento de la partición de las fechas 29, Software para la carga másica 30, Sistema de Manejo de Bases de Datos (DBMS) 31 y Software para la gestión del sistema 32. En modalidades que utilizan nodos amo, múltiples, cada nodo amo esta configurado con los módulos de Software antes descritos . Cada nodo esclavo incluye un DBMS (los DBMS 33a a 33n) y Software para la gestión de los esclavos 34a a 34n, respectivamente. Por último, el Software de la consola de gestión 35 esta instalado en uno o más nodos amos y se puede acceder a este a través de una terminal conectada al nodo amo o a través de un programa cliente que corra en un sistema de computo independiente del sistema de bases de datos 10.

Los módulos de Software antes mencionados se almacenan en los discos respectivos de los nodos del sistema de bases de datos y se ejecutan a través de las CPU respectivas de estos nodos. En una modalidad preferida, todos los nodos tienen una configuración de Hardware idéntica y pueden funcionar como un nodo amo o un nodo esclavo cargando y ejecutando módulos de Software apropiados en un nodo específico. De acuerdo con una modalidad de la invención, los módulos de Software se implementan utilizando el lenguaje de programación Java. No obstante, un experto en la técnica se dará cuenta que es posible utilizar otros lenguajes de programación para poner en práctica uno o más de los módulos de Software .

Una descripción detallada del funcionamiento de estos módulos de Software se proporciona más adelanté en la descripción de la operación de la invención.

Un mejoramiento significativo de la invención sobre los diseños de las bases de datos paralelas, nada compartidas, tradicionales es una reducción importante en la necesidad de transferir datos entre los nodos para gestionar consultas de las bases de datos como pueden ser las uniones. Este mejoramiento se logra utilizando una serie de reglas para la partición automática y distribución de las tablas de las bases de datos a través de los nodos esclavos del sistema de bases de datos 10. La partición y distribución de las tablas de las bases de datos se realiza de acuerdo con un esquema esclavo generado .

Un sistema hospedero externo envía metadatos que definen un esquema hospedero al sistema de bases de datos 10. El Software de gestión de flujos 20 recibe un flujo que contiene los metadatos y envía los metadatos al DBMS 31. Para generar un esquema esclavo para el esquema hospedero enviado, el DBMS 31 envía los metadatos del esquema hospedero hacia el Software que genera los esquemas esclavos 23. Luego de recibir el esquema hospedero, el Software que genera los esquemas esclavos 23 aplica a la serie de reglas para generar un esquema esclavo. El esquema esclavo define como se particionan y distribuyen las tablas de las bases de datos a través de los nodos esclavos 12a a 12n. La Figura 3 es un diagrama de flujo que representa un proceso que realiza el Software que genera los esquemas esclavos 23 para generar el esquema esclavo de acuerdo con una modalidad de la invención. Los pasos que se muestran en la Figura 3 incorporan la serie de reglas que se utilizan para generar el esquema esclavo.

En el paso 300, el Software que genera los esquemas esclavos 23 recibe un esquema hospedero proporcionado por un sistema hospedero externo conectado al sistema de la bases de datos 10. Los esquemas hospederos posibles incluyen, pero no se limitan a, esquemas de estrella, esquemas de copos de nieve y esquemas normalizados. La Figura 4 es un ejemplo de un esquema de copo de nieve utilizado como una referencia normal para los sistemas de bases de datos creados por el Transaction Processing Council (consejo de procesamiento de transacciones) . Este esquema incluye una tabla de hechos (LINEITEM) y múltiples tablas de dimensiones (ORDERS, CUSTOMER, PART, PARTSUPP, SUPPLIER, NATION y REGIÓN) . Una tabla de hechos se define como una tabla que no tiene relaciones padre- hijo con otras tablas de las cuales es el precursor. Una tabla de dimensiones se define como aquella que tiene una relación padre-hijo con otras tablas de las que es el precursor. Si bien el esquema representado en la Figura 4 incluye solo una tabla de hechos, se entiende que los esquemas de las bases de datos pueden incluir múltiples tablas de hechos .

En el paso S301, las tablas del esquema hospedero se orden en preparació -para generar los esquemas esclavos. La Figura 5 es un diagrama de flujo que representa un proceso para ordenar las tablas de los esquemas hospederos. En el paso S500, todas las tablas de hechos dentro del esquema hospedero están identificadas. Para cada una de las tablas de hechos identificadas, las relaciones de las tablas definidas en los esquemas hospederos son seguidas hacia afuera de la tabla de hechos para identificar una primera tabla de dimensiones en el paso S501 y ordenar las demás tablas de dimensiones relacionadas en el paso S502. Las tablas de dimensiones están ordenadas con base en sus posiciones' y relaciones con respecto a la tabla de hechos. En relación con el esquema hospedero representado en la Figura 4, la tabla LIN?ITEM esta identificada como la única tabla de hechos del esquema hospedero. Trabajando hacia afuera de la tabla LINEITEM, las tablas ORDERS, PART, PARTSUPP y SUPPLIER están identificadas como tablas que tienen relación directa con la tabla LINEITEM. Este primer escalón de tablas esta ordenado con base en un criterio especificado, como el tamaño. La primera tabla ordenada en este primer escalón, la tabla ORDER por ejemplo, se identifica como una primera tabla de dimensión. Mediante el uso de las relaciones entre tablas y los criterios de ordenación especificados, se ' orden el resto de las tablas de dimensión.

Para procesar eficientemente las consultas utilizando un sistema de las bases de datos paralelas, las tablas más grandes y accesadas con mayor frecuencia deben ser distribuidas tan uniforme y eficientemente a lo largo de los nodos esclavos como sea posible. En este sentido, la presente invención adopta un enfoque semejante al que se utiliza en los sistemas de bases de datos nada compartidas, convencionales. Específicamente, la presente invención refunde particiones de la tabla de hechos y la primera tabla de dimensión utilizando una clave común. Mediante la partición de refundición estas tablas utilizan una clave común, se mapea un determinado valor clave para un nodo específico y se pueden procesar las consultas que se unen a las dos tablas sin transferir datos Entre nodos esclavos. En el paso S302 de la Figura 3, se marca una clave de refundición en cada par tabla de hechos y primera tabla de dimensión. En relación otra vez con los esquemas hospederos representados en la Figura 4, se marca ORDERKEY como la clave de refundición puesto que es la clave primaria en la tabla ORDERS (primera tabla de dimensión) y .una clave ajena en la tabla LINEITEM (tabla de hechos) .

Una vez que las tablas de la base de datos han sido ordenadas y marcadas las claves de refundición, el proceso de generación de esquemas de esclavos esta listo para generar un esquema esclavo. Se examina cada tabla del esquema hospedero y se genera una o más tablas correspondientes en los esquemas esclavos . Primero en el paso S303 se determina si en la tabla actual es una tabla de hechos o una primera tabla de dimensión. Cada tabla de hechos y la primera tabla de dimensión se particionan horizontalmente y se distribuye a lo largo de los nodos esclavo. De este modo, cada nodo esclavo es responsable de una porción horizontalmente particionada de cada tabla de hechos y cada primera tabla de dimensión del esquema hospedero.

En una base de datos común, las tablas muchas veces contienen una cantidad importante de texto. Este texto normalmente se encuentra dentro de un campo de comentarios de la tabla. Una característica opcional de 5. la invención es la partición vertical de las tablas para quitar estos grandes campos de comentarios y colocarlos en una tabla independiente dentro del esquema esclavo. Al garantizar que las filas dentro de dos tablas se mantengan exactamente en el mismo orden, el campo o los campos de comentarios para una fila específica se pueden encontrar utilizando el identificador de la fila. La opción de la partición vertical es establece como una regla predeterminada o se establece utilizando entradas desde un administrador del sistema. En el paso S304 se determina si las tablas se van a particionar en el sentido vertical. Si no se establece la partición vertical, se genera una tabla particionada en el sentido horizontal en los esquemas esclavos en el paso S305. Si se determina partición vertical, se genera una serie de tablas en partición vertical en los esquemas esclavos en el paso S306. Estas tablas verticalmente particionadas son particiones verticales de una tabla horizontalmente particionada, y como una serie son equivalentes a una tabla horizontalmente particionada generada en el paso S305.

De acuerdo con una modalidad preferida de la invención, en cada nodo esclavo se almacena una copia completa de cada tabla además de las tablas de hechos y la primera tabla de dimensiones. En el paso S307, si la tabla que se esta examinando no es una tabla de hechos o una primera tabla de dimensión, en el esquema esclavo se genera una tabla completa. Al colocar una copia completa de cada una de estas tablas de dimensiones externas en cada nodo esclavo, las consultas, como puede ser las uniones entre las tablas de dimensiones externas y la tabla de hechos o la primera tabla de .dimensión se ejecutan en paralelo sin necesitar la transferencia de los datos de la tabla entre los nodos esclavos.

Además de una copia completa de cada una de las tablas de dimensiones externas, una modalidad preferida de la invención, como una opción, particiona y distribuye las tablas de dimensiones externas a lo largo de los nodos esclavos. Al incluir una copia completa de las tablas de dimensiones externas y las particiones de las tablas de dimensiones externas en los nodos esclavos, las consultas pueden ser optimizadas para referirlas a las tablas en los nodos esclavos que producirán el mejor desempeño del sistema. Sin embargo, algunas tablas de bases de datos no producen suficiente ganancia de desempeño para' justificar el procesamiento adicional y el espacio de almacenamiento. Por ejemplo, podrían no proporcionar beneficios significativos en el desempeñó para la partición y distribuir tablas de bases de datos relativamente pequeñas a través de los nodos esclavos. Por consiguiente, este aspecto de la invención es una opción que se establece como una regla predeterminada o mediante una entrada desde un administrador del sistema para no particionar algunas tablas de dimensiones externas, como pueden ser aquellas que están por debajo de un tamaño especificado.

En el paso S308 se determina si la tabla actual va a ser particionada o no. Si no se establece la opción de partición, o si la tabla satisface los criterios de partición, el paso S309 determina si se ha establecido partición vertical de las tablas . Si no ha sido establecida la partición vertical, se genera una tabla horizontalmente particionada en los esquemas esclavos del paso S310. Si se ha establecido la partición vertical, se genera una serie de tablas verticalmente particionadas en el esquema del paso S311. Estas tablas verticalmente particionadas son particiones verticales de una tabla horizontalmente particionada, y como conjunto son equivalentes a una tabla horizontalmente particionada generada en el paso S310.

Una vez que todas las tablas del esquema hospedero han sido examinadas y se han creado las tablas apropiadas en el esquema esclavo, el esquema esclavo generado se almacena en el DBMS31 y se envía a cada uno de los nodos esclavos en el paso S312. El esquema esclavo se utiliza en los nodos amo y los nodos esclavos para cargar y particionar las tablas de una base de datos en el sistema de bases de datos .

Los datos para una base de datos particular se cargan en forma masiva en el sistema de bases de datos de la invención a través de uno de los nodos amo o, de otro modo, un nodo de carga másica dedicado. La Figura 6 es un diagrama de flujo que representa el proceso para la carga másica de datos en el sistema de bases de datos. Para cargar cada tabla, el proceso implica la preparación de los esclavos para recibir datos determinando candados apropiados en las tablas pertinentes en el paso S601 y enviar los datos para cada tabla a todos los nodos esclavos en el paso S602. Preferentemente, los datos se envían a los nodos esclavos a' través de un servicio de multidifusión proporcionado por la red entre nodos.

En el paso S603 la tabla recibida por los nodos esclavos se particiona de acuerdo con el esquema esclavo.

La Figura 7 es un diagrama de flujo que representa el proceso de cargar y particionar una tabla en un nodo esclavo. Para cargar y particionar la tabla en un nodo específico, • el Software de gestión de esclavos 34 examina cada fila de la tabla. En el paso S700 se determina si la tabla va a ser cargada completa, en cuyo caso cada fila es cargada en la tabla apropiada en el paso S701. En el paso S702 se determina si la tabla se mantiene en forma particionada. Si es así, cada fila es examinada en el paso S703 para determinar si la fila esta incluida en las tablas particionadas del nodo esclavo específico. Observe que cada nodo esclavo es responsable de una porción única de filas de la tabla particionada. La partición de la tabla se realiza utilizando cualquiera de los diferentes algoritmos conocidos para dividir y distribuir las filas de la tabla. Preferentemente, las tablas se particionan de igual forma a lo largo de los nodos esclavos. Con base en el algoritmo utilizado para particionar las filas de la tabla, se determina si el nodo esclavo particular es responsable de la fila que se examina .

Una característica opcional de la presente invención es el uso de la partición de fechas para particionar y distribuir los datos. Con la partición de fechas, las tablas de una base de datos se particionan y distribuyen de acuerdo con las fechas pertinentes dentro de los datos. Las fechas pueden ser establecidas utilizando reglas definidas o pueden ser controladas por la entrada del administrador del sistema. Por ejemplo, los datos para años, trimestres o meses específicos pueden ser almacenados en diferentes nodos esclavos. Estas tablas particionadas por fechas se almacenan y utilizan para procesar consultas a bases de datos que respondan a fechas. Las tablas particionadas por fechas regularmente se mantienen para eliminar datos que no entran dentro de los intervalos de fechas pertinentes. Preferentemente, las tablas particionadas por fechas se almacenan en nodos esclavos dedicados para particionar fechas. Sin embargo, las tablas particionadas por fechas también se pueden almacenar en los nodos esclavos normales junto con las demás tablas particionadas y no particionadas.

En el paso S704 se determina si el nodo esclavo particular es un nodo esclavo particionado por fechas y, si es así en el paso S705 si la fila que se esta examinando entra dentro del intervalo de fechas almacenado por el nodo esclavo. Si el nodo esclavo es un nodo esclavo particionado por fechas y la fila entra dentro del intervalo de fechas pertinente, se determina en el paso S706 si la fila esta particionada verticalmente con base en el esquema esclavo. Para filas particionadas verticalmente, la fila se escribe en la serie apropiada de tablas verticalmente particionadas en el paso S707. Si la fila no esta particionada verticalmente, la fila se escribe en la tabla horizontalmente particionada, apropiada, en el paso S708.

Una característica opcional de la invención es el uso de otro nivel de partición de tablas dentro de los nodos esclavos, utilizando cualquiera de los diferentes algoritmos de partición conocidos. Por ejemplo, las tablas pueden ser particionadas por valor de refundición o intervalo de fechas .

El sistema de bases de datos de la invención también esta diseñado para proporcionar protección de relevo. Para poner en práctica esta protección, los nodos esclavos tienen asignados contra partes de relevo. Además de sus propias tablas particionadas, cada nodo esclavo almacena las tablas particionadas de su contra parte relevo y utilizará el mismo algoritmo para actualizar las tablas pertinentes, como se describe en la presente. Mediante el uso de este sistema de relevo se proporciona un elevo nivel de confiabilidad sin utilizar arreglos de discos en espejo o basados en paridad en cada nodo. Esto reduce costos de instrumentación puesto que es posible utilizar sistemas de discos RAID de nivel 0 para obtener mayor eficacia sin mayores costos asociados con el mayor nivel de los sistemas RAID.

Si la fila que se esta examinando no entra dentro del intervalo de fechas de las tablas particionadas por fechas en los nodos esclavos, o si los nodos esclavos no almacenan tablas particionadas por fechas, se determina en el paso S70-9 si fila esta verticalmente particionada en el nodo esclavo. Si la fila esta verticalmente particionada, esto se escribe en la serie apropiada de tablas verticalmente particionadas en el paso S710.

En el paso S711 se determina si la fila es parte de una tabla horizontalmente particionada en el nodo esclavo. Si la fila es parte de una tabla horizontalmente particionada, la fila se escribe en esa tabla en el paso S712.

Una vez que todas las filas de una tabla específica han sido adicionadas a la base de datos, el índice de las diferentes tablas físicas afectadas se actualiza en el paso S713.

Otra característica mejorada del desempeño de la presente invención es el uso de una memoria caché de consulta y una memoria caché de tablas temporal . Una memoria caché de consulta es almacenada y se mantiene en el DBMS31 en cada uno de los nodos amo y en el DBMS33 en cada nodo esclavo . La memoria caché de consulta almacenad resultados de consulta para gestiones de consultas en el nodo particular. Una memoria caché de tablas temporal se almacena y mantiene en el DBMS31 en cada nodo amo para almacenar tablas temporales generadas por el nodo amo mientras se ejecutan consultas de múltiples pasos. Cuando las tablas son cargadas en el sistema de bases de datos, las memorias caché de consulta y caché de tablas temporal que contienen resultados generados basados en las versiones anteriores de las tablas se deben borrar. Por consiguiente, en el paso S604 se vacían las memorias caché de consulta y de tablas temporal pertinentes. Una descripción más detallada del funcionamiento de estas memorias caché se proporciona más adelante.

Los diferentes procesos antes descritos utilizan carga masiva de tablas en el sistema de datos para clasificar y particionar las tablas. Un proceso opcional para cargar datos en el sistema de bases de datos es clasificar previamente los datos utilizando un sistema hospedero externo que tenga acceso a los esquemas esclavos generados y cualquier parámetro del sistema que afecte la distribución de los datos. Los datos previamente clasificados pueden derivar los nodos amo y ser cargados directamente en los nodos esclavo . La Figura 8 es un diagrama de flujo que representa un proceso para la carga masiva de los datos previamente clasificados.

Como se muestra en la Figura 8 , cada tabla y cada partición de los datos previamente clasificados se examina y carga en los nodos esclavos .apropiados . Para cada tabla que se almacena completa en los nodos esclavos, todos los nodos esclavos se preparan para la carga masiva de la tabla en el paso S800 y todo el contenido de la tabla se envía a todos los nodos esclavos en el paso S801. Para cada partición de los datos almacenados, la serie relevo asignada de nodos esclavos se prepara para carga la partición en el paso S802 y se envía la partición a la serie de relevos en el paso S803. Por último, en el paso S804 se vacían las memoria caché de consulta y caché de tablas temporal apropiadas.

De acuerdo con una modalidad de la invención, los sistemas hospederos externos se comunican con el sistema de bases de datos utilizando instrucciones SQL. Las instrucciones SQL generalmente se separan en flujos "por el sistema hospedero, con cada flujo correspondiente a un usuario o aplicación particular. El uso de flujos para organizar instrucciones SQL garantiza que las instrucciones sean ejecutadas por el sistema de bases de datos en el orden correcto. Los flujos de las instrucciones SQL recibidas por el sistema de bases de datos se manejan por el Software de gestión de flujos 20 en cada nodo amo. La Figura 9 es un diagrama de flujo que representa el procesamiento realizado por el Software de gestión de flujos 20 al recibir una nueva instrucción desde un sistema hospedero externo.

Como ya se describió. El sistema de bases de datos de la presente invención incluye uno o más nodos amos.

Las instrucciones SQL enviadas por el sistema hospedero externo son recibidas por cada uno de los nodos amos y procesadas en la forma que se describe en la Figura 9.

Específicamente, para cada flujo de nodo amos, el Software de gestión 20 determina en el paso S901 si la instrucción recibida es el comienzo de un nuevo flujo o parte de un flujo existente que ya esta siendo procesado por el sistema de bases de datos . Si la instrucción es el comienzo de un nuevo flujo, el Software de gestión de flujos 20 determina en el paso S902 si el flujo debe ser controlado por ese nodo amo particular. Cada flujo es controlado por un nodo amo en el sistema de bases de datos. El Software de gestión de flujos 20 en cada no amo se comunica con otros nodos amos para determinar cual, de los nodos amos controlará un flujo que ingrese. El control de flujos se determina utilizando cualquiera de los diferentes algoritmos equilibradores de carga, conocidos. Si se determina en el paso S902 que el nodo amo correspondiente va a controlar el flujo, el Software de gestión de flujo 20 notifica a los demás nodos amo que esta controlando el flujo en el paso S903.

Puesto que cada instrucción es recibida por los nodos amo, el Software de la memoria caché de consulta 21 en cada nodo amo compara la instrucción contra la memoria caché de consulta del nodo amo en el paso S904. Como ya se menciono, cada nodo amo almacena los resultados de las consultas anteriores en una memoria caché de consulta. En el paso S904, la instrucción es comparada contra la memoria caché de consulta para determinar si se ha procesado anteriormente una instrucción idéntica en el nodo amo con cambios intervinentes a las tablas subyacentes. Si se ha procesado anteriormente una instrucción idéntica, el resultado correspondiente establece para esa instrucción que sea recuperada de la memoria caché de consulta y enviada a cualquier sistema hospedero externo o el nodo amo que controle el flujo de consultas en el paso S905 y el procesamiento de la instrucción mediante el nodo amo termina. Si la instrucción no se encuentra en la memoria caché de consulta, en el paso S906 se determina si la instrucción recibida es parte de un flujo controlado por el nodo amo asociado. Si el nodo amo controla el flujo particular, la instrucción es procesada por el Software de análisis SQL 22 en el paso S907. SI la instrucción no es parte de un flujo controlado por el nodo amo asociado, el procesamiento de la instrucción por el nodo amo termina y el Software de gestión de flujos 20 espera la siguiente instrucción que será recibida.

La Figura 10 es un diagrama de flujo que representa un proceso realizado por el Software de análisis SQL 22 para preparar instrucciones para otro procesamiento. Para preparar cada instrucción para procesamiento posterior, en el paso SlOOl se asignan testigos a la instrucción, y se analizan los testigos en el paso S1002. Por último, en el paso S1003 se llama a la subrutina pertinente para procesar instrucciones analizadas. Las subrutinas posibles pueden ser, pero no se limitan a, alterar la tabla, actualizar o insertar datos y la paralelización de la consulta.

La Figura 11 es un diagrama de flujo que representa un proceso realizado por una s'ubrutina de alteración de tabla llamada por el Software de análisis SQL 22 para alterar una tabla de la base de datos . La alteración de -las tablas de la base de datos se realiza principalmente por el Software que genera esquemas esclavos 23. El proceso comienza cuando se determina, en el paso S1100, si la tabla que va a ser alterada es una tabla de hechos o una primera tabla de dimensión. Si la tabla es una tabla de hechos o una primera tabla de dimensión, se determina en el paso S1101 si la tabla que esta siendo alterada esta particionada verticalmente. Si la tabla no esta particionada verticalmente, las alteraciones a la tabla se hacen en la tabla horizontalmente particionada, correspondiente, en los metadatos almacenados en el DBMS 31 del nodo amo o en cada uno de los nodos esclavos en el paso S1102. Si la tabla que se esta alterando esta verticalmente particionada, la serie correspondiente de tablas verticalmente particionadas se altera en los metadatados almacenados en el DBMS31 del nodo amo y en cada uno de los nodos esclavos en el paso S1103.

Si la tabla que se va a alterar no es una tabla de hechos o una primera tabla de dimensión, la tabla correspondiente se altera en los metadatos almacenados en DBMS31 del nodo amo y en cada uno de los nodos esclavos en el paso S1104. En el paso S1105 se determina si la tabla que se va a alterar esta particionada en los nodos esclavos. Si la tabla esta particionada, se determina en el paso S1106 si la tabla esta verticalmente particionada. Si la tabla no esta particionada verticalmente, los metadatos y el contenido real de la tabla horizontalmente particionada correspondiente se altera en el paso S1107. Si la tabla esta verticalmente particionada, los metadatos y el contenido real de la tabla para la serie correspondiente de tablas verticalmente particionadas se altera en el paso S1108. Por último, en el paso S1109, se vacían las entradas de las memoria caché de consulta y las entradas de la memoria caché de tablas temporal que dependen de la tabla alterada.

La Figura 12 es un diagrama de flujo que representa un proceso realizado por una subrutina de actualización e inserción llamada por el Software de análisis SQL22 para actualizar o insertar datos en la base de datos. Para cada fila que este actualizando o insertando, se determina en el paso S1200 si la fila es parte de una tabla que se mantuvo solo en forma particionada en los nodos esclavos, como puede ser una tabla de hechos o una primera tabla de dimensión. Si la fila es parte de una tabla, que no se mantuvo solamente en forma particionada, la fila es escrita a cada uno de los nodos esclavo en el sistema en el paso S1201. La fila es parte de una tabla que se mantuvo solamente en forma particionada, la fila es particionada de acuerdo con la clave de refundición apropiada y como una opción la fecha pertinente en el paso S1202 y se escribe a las tablas particionadas en el nodos esclavo pertinentes en el paso S1203. En el paso S1204 se actualizan los índices de todas las tablas cambiandas en la base de datos. Por último, en el paso 51205 se vacían todas las entradas de la memoria caché de consulta y de la memoria caché de tablas temporal que dependen de la tabla en la que se actualizaron o insertaron los datos.

Las instrucciones de consulta se procesan y optimizan por el Software de paralelización de consultas 25. La Figura 13 es un diagrama de flujo que representa un proceso de paralelización de consultas. En el paso 51301 se determina si la consulta busca un intervalo de fechas específico cubierto por alguna de las particiones de fechas establecidas en el sistema de bases de datos. Si la consulta busca un intervalo de fechas cubierto por una partición de fechas, el grupo de nodos esclavo utilizados para este intervalo de fechas particular es designado, en el paso S1302 para que sea utilizado para el procesamiento de la consulta. Si la consulta no busca un intervalo de fechas particular, o si el intervalo de fechas no corresponde con ninguna de las particiones de fechas establecidas, en el paso S1303 se designa a los nodos esclavos que serán utilizados para procesar la consulta. Los pasos S1304, S1305 y S1306 determinan como ejecutar la consulta en los nodos esclavos con base en la estructura de la consulta y el uso de las técnicas bien conocidas para los expertos en la técnica. En el paso S1304,' las subconsultas que deben ser gestionadas independientemente se dividen en dos consultas independientes. La subconsulta se ejecuta primero, con los resultados intermedios reunidos en el nodo amo y luego regresados a los nodos esclavos para otro procesamiento junto con el resto de la consulta. En el paso S1305, las uniones externas se dividen en consultas múltiples que se ejecutan de común acuerdo con los nodos esclavos y los nodos amo para satisfacer la consulta. Por último, en el paso S1306 el optimizador de consultas evalúa el consto de las estrategias de ejecución en múltiples pasos y en un solo paso y elige la opción de costo más bajo, otra vez utilizando las técnicas bien conocidas para los expertos en la materia. Entonces la consulta va hacia el paso S1307 para las consultas de un paso o el paso S1308 para consultas de múltiples pasos, después de lo cual la serie de resultados es regresada al hospedero en el paso S1309.

La Figura 14 es un diagrama de flujo que representa un proceso para gestionar una consulta de un solo paso. Las consultas son recibidas desde el sistema hospedero externo que se refiere a las tablas utilizando los nombres de las tablas del esquema hospedero. Para procesar las consultas en paralelo utilizando los nodos esclavo, los nombres de las tablas deben ser sustituidos con nombres de tablas correspondientes desde el esquema esclavo. En una modalidad alternativa, los nombres de las tablas utilizados en el esquema hospedero podrían utilizarse en el esquema esclavo generado para que las consultas de un paso se puedan enviar directamente a los nodos esclavo. En el paso S1401 los nombres de las tablas que se mencionan en la consulta son sustituidos con los nombres de tablas correspondientes del esquema esclavo. La Figura 15 es un diagrama de flujo que representa un proceso que se utiliza para sustituir los nombres de las tablas contenidos en la consulta.

En el paso S1500, las uniones y/o tablas procedentes de la consulta son reordenados trabajando hacia afuera de la tabla de hechos. La consulta ordenada es examinada en el paso S1501 para determinar si hay alguna unión que se vaya a gestionar en la consulta. Si la consulta no contiene una' unión, en el paso S1502 se determina si la tabla utilizada en la consulta se mantuvo solamente en forma particionada en los nodos esclavos. Si la tabla se mantuvo completa en los nodos esclavos, el nombre de la tabla no se sustituye y termina el procesamiento. Si la tabla se mantuvo solamente en forma particionada, en el paso S1503 se determina si la tabla esta verticalmente particionada en el esquema esclavo. Si la tabla no esta verticalmente particionada, el nombre de la tabla es sustituido con el nombre de la tabla horizontalmente particionada, correspondiente, en el paso S1504. En otra versión, si la tabla esta verticalmente particionada en el esquema esclavo, se determina en el paso S1505 si la consulta utiliza alguna de las columnas, como grandes campos de comentarios, que fueron removidos por la partición vertical. Si en la consulta no se utilizan las columnas eliminadas, el nombre de la tabla es sustituido con el nombre de la tabla verticalmente particionada, correspondiente en el paso S1506. Si en la consulta se utiliza alguna de las columnas removidas, el nombre de la tabla es sustituido con el nombre de la tabla verticalmente particionada, correspondiente, y se modifica la consulta para obtener la fila correspondiente de la tabla que contiene las columnas removidas en el paso S1507. Esto se logra a través de un identificador de filas que utilice técnicas bien conocidas para los expertos en la materia.

Si en el paso S1501 se determina que la consulta incluye uniones , cada unión es examinada en su momento . Para cada tabla en la unión actual, en el paso S1508 se determina si la tabla es una tabla de hechos o una primera tabla de dimensión. Si la tabla es una tabla de hechos o una primera tabla de dimensión, en el paso S1509 se determina si la tabla esta verticalmente particionada en el esquema esclavo. Si la tabla no esta verticalmente particionada, el nombre de la tabla se sustituye con el nombre de la tabla horizontalmente particionada, correspondiente, en el paso S1510. Si la tabla esta verticalmente particionada, se determina si la consulta utiliza alguna de las columnas removidas en la partición vertical en el paso S1511. Si en la consulta no se utilizan las columnas removidas, el nombre de la tabla es sustituido con el nombre de la tabla verticalmente particionada, correspondiente, en el paso S1512. En otra versión, si en la consulta se utiliza algunas de las columnas removidas, el nombre de la tabla se sustituye con la tabla verticalmente particionada, correspondiente, y se modifica la consulta para obtener la fila correspondiente de la tabla que contiene las columnas removidas en el paso S1513. Esto se logra a través de un identificador de filas que utilice las técnicas bien conocidas para los expertos en la materia.

Si en el paso S1508 se determina que la tabla no es una tabla de hechos o una primera tabla de dimensión, en el paso S1514 se determina si alguno de los nombres de las tablas utilizados en la consulta que han sido examinadas han sido sustituidos con el nombre de la tabla horizontalmente particionada, correspondiente. Si ninguno de los nombres de las tablas horizontalmente particionadas han sido incluidos en la consulta, el proceso continúa al paso S1509. Los pasos S1509 al paso S1513 entonces se repiten en la forma antes descrita. Si se ha sustituido un nombre de tabla con el de una tabla horizontalmente particionada, en el paso S1515 se determina si la tabla tiene la misma clave de partición que la tabla horizontalmente particionada ya utilizada. Si la tabla tiene la misma clave de partición, la unión se lleva a cabo entre particiones co-localizadas de las tablas y el proceso continúa a los pasos S1509 a S1513, los cuales se realizan en la forma antes descrita. Si la tabla no tiene la misma clave de partición, no se sustituye el nombre de la tabla y finaliza el proceso.

Regresando a la Figura 14, una vez que los nombres de las tablas han sido sustituidos en el paso S1401, en el paso S1402 se optimiza la consulta para la base de datos particular que se este utilizando en los nodos esclavos utilizando las técnicas bien conocidas para los expertos en la materia. Por ejemplo, los parámetros para el costo de los ciclos de la CPU en relación co los ciclos de E/A- se pueden cambiar para que la consulta se ejecute con mayor eficiencia. La consulta optimizada entonces es enviada a los nodos esclavos en el paso S1403. En el caso de que falle un nodo esclavo, la consulta se envía a las contrapartes relevo apropiadas del nodo esclavo que fallo, además de los demás nodos esclavos del sistema, como se describe con mayor detalle más adelante. El Software de gestión de esclavos 34 en cada nodo esclavo recibe y procesa la consulta procedente del nodo amo responsable. La Figura 16 es un diagrama de flujo que representa los pasos del proceso realizados por el Software de gestión de esclavos cuando se recibe una nueva consulta. Observe que algunos casos la consulta puede ser ejecutada directamente por el DBMS en los nodos esclavos sin intervención del Software de gestión de esclavos .

Luego de recibir una nueva consulta desde un nodo amo, el Software de gestión de esclavos 34 determina, en el paso S1600, si la consulta debe ser traducida para el DBMS que se esta utilizando el nodo esclavo. El diseño del sistema de la invención no necesita un DBMS patentado para utilizarlo en el nivel de esclavo del sistema. Esta propiedad reduce los costos y tiempo de implementación del sistema puesto que en los nodos esclavo es posible utilizar un DBMS comercial. Si se necesita traducción, la consulta se traduce para el DBMS específico en el paso S1601. En el paso S1602 se determina si es necesario hacer alguna optimización para gestionar la consulta en el DBMS específico. Si se necesita optimización, la consulta se optimiza en el paso S1603.

Igual que el proceso realizado en el nivel amo, nuevas consultas son revisadas contra una memoria caché de consulta para ver si la consulta ha sido previamente gestionada contra la base de datos sin cambios intervinentes a las tablas mencionadas en la consulta. El Software para gestión de esclavos 34 mantiene una memoria caché de consulta para las tablas relevo y las tablas locales asignadas a ese nodo esclavo específico. Algunos productos de DBMS incluyen un caché de consulta de su propiedad. Si el DBMS que se ejecuta en el nodo esclavo mantiene una memoria caché de consulta, el Software de gestión de esclavos 34 no necesita comprobar o mantener su propio caché de consulta . Junto con el caché de consulta que se mantiene en el nivel amo, la invención proporciona un caché de consulta binivel que mejora la eficacia del sistema evitando repetición innecesaria del procesamiento de consultas.

En el paso S1604, la consulta recibida se compara contra el caché de consulta. Si la consulta se encuentra en el caché de consulta, la serie de resultados se recupera del caché de consulta en el paso S1605. Si la consulta no se encuentra en la memoria caché de consulta, la consulta es enviada al DBMS en el paso 1606 para su ejecución.

Una vez que la serie de resultados ha sido obtenida, el Software de manejo de esclavos 34 determina en el paso S1607 si la serie o series de resultados requieren procesamiento posterior antes de regresar la serie o series de resultados al nodo amo. Si se necesita procesamiento posterior, este se realiza en el paso S1608. Por último, la serie o series de resultados se regresan al nodo amo que origino la consulta en el paso S1609.

Regresando otra vez a la Figura 14, el Software de análisis de la serie de resultados 28 en el nodo amo recibe las series de resultados de cada uno de los nodos esclavos utilizados para procesar la consulta. En el paso S1404, el Software de análisis de la serie de resultados 28 realiza procesamiento posterior en las series de resultados recibidas. El procesamiento posterior puede ser, pero no se " limita' a, combinar las series de resultados en una sola serie de resultados, organizar la resultados dentro de la serie de resultados y dar forma a las serie de resultados en un formato que sea compatible con el sistema hospedero externo que somete la consulta.

La Figura 17 es un diagrama de flujo que representa un proceso de consulta de múltiples pasos de acuerdo con una modalidad de la invención. En el paso S1701, la consulta se divide en dos o más consultas esclavo. La división de estas consultas en consultas esclavo múltiples ser ejecutada en serie sobre los nodos esclavo elimina la necesidad de transferir datos entre nodos esclavos para procesar la consulta original y mejora la eficiencia del sistema gestionando estas consultas.

Las consultas de múltiples pasos dependen del uso de tablas temporales en el nodo amo que ejecuta la consulta. Estas tablas temporales almacenan series de resultados intermedios generados ejecutando las consultas esclavo individuales. Las tablas temporales se utilizan para acumular las series de resultados de cada consulta esclavo. En otra versión, las tablas temporales pueden ser enviadas a los nodos esclavo para ejecutar consultas esclavo subsecuentes que unan una tabla temporal con una tabla local en los nodos esclavo.

Al igual que las memorias caché de consulta utilizadas en los nodos amo y esclavo del sistema de bases de datos, cada nodo amo mantiene una memoria caché de tablas temporal almacenando copias de tablas temporales creadas para ejecutar consultas esclavo por este nodo amo en el DBMS de este nodo amo. Cuando se ejecuta una consulta esclavo, la consulta esclavo es verificada contra el caché de tablas temporal en el paso S1702 para determinar si la consulta esclavo particular ha sido ejecutada sin cambios intermitentes para las tablas 'subyacentes en las que depende la tabla temporal.

Si no hay una coincidencia en el caché de la tabla temporal, una tabla temporal para la consulta esclavo se crea en el paso S1703. ' La consulta esclavo entonces se ejecuta y los resultados se procesan en los pasos S17034 a S1707. Las acciones realizadas en estos pasos corresponden con las realizadas en los pasos S1401 a S1404 de la Figura 14, y por tanto, no serán descritas otra vez.

Una vez que se ha procesado la consulta esclavo, o si se encontró una coincidencia para la consulta esclavo en el caché de tablas temporales, el nodo amo determina, en el paso S1708, si queda alguna consulta esclavo. Si hay otras consultas esclavo que se han de ejecutar, esto se determina en el paso S1709 si las siguientes consultas esclavo requieren de una tabla temporal para el procesamiento. Si se requiere una tabla temporal en los esclavos, la tabla temporal es enviada a los nodos esclavo en el paso S1710 y el procesamiento regresa al paso S1702. Si no se necesita una tabla temporal, el procesamiento simplemente regresa al paso S1702 para la siguiente consulta esclavo.

Como se muestra en la Figura 13 , una vez que la consulta recibida desde el sistema hospedero externo ha sido ejecutada y procesada, sea como una consulta de un solo paso o una consulta de múltiples pasos, la serie de resultados final es regresada al sistema hospedero externo en el paso S1309.

Cada nodo amo en el sistema de bases de datos de la presente invención forma la interfaz con el Software de gestión del sistema 32 para monitorizar el estado de los demás nodos en el sistema de bases de datos. Los ejemplos del Software de gestión del sistema incluyen IPMI (Interfaz de Manejo de Plataformas Inteligentes) y el System Manager de Intel .

Luego de la recepción de la notificación de la falla de un nodo amo, el Software de gestión de flujos 20 envía un mensaje del estado del sistema a la consola de gestión 35 indicando la falla de unión nodo amo. La consola de gestión 35 es utilizada por el administrador del sistema para rastrear el estado del sistema de bases de datos y para identificar los nodos que falla y que deben ser reparados o sustituidos para mantener el funcionamiento del sistema. Una vez que la consola de gestión 35 es notificada de la falla del nodo amo, el Software de gestión de flujos 20 ejecuta un proceso de relevo del nodo amo.

La Figura 18 es un diagrama de flujo que representa el proceso de relevo realizado por el Software de gestión de flujo 20 en el caso de la falla de un nodo amo en el sistema de bases de datos. El proceso que representa la Figura 18 se realiza para cada uno de los flujos que manejan los nodos amo con falla. En el paso S1800, el nodo amo determina si este es responsable del flujo específico del nodo amo que fallo. De acuerdo con una modalidad de la invención, esta determinación se hace entre los nodos amo operativos del sistema de bases de datos utilizando el mismo método de equilibrio de carga que se utiliza para manejar nuevos flujos recibidos por el sistema de bases de datos .

Sin embargo, para hacer estas determinaciones es posible utilizar otros métodos conocidos en la técnica. Su el nodo amo determina que es responsable del flujo específico, el nodo amo notifica a los demás nodos amo en el paso S1801 que esta controlando el flujo.

Una vez que un nodo amo ha tomado control sobre un flujo, cada una de las instrucciones incompletas de ese flujo son tomadas por el nodo amo. En el paso S1802 se hace retroceder la instrucción incompleta utilizando técnicas de gestión de transacciones bien conocidas. La instrucción entonces se vuelve a correr en el paso S1803. De este modo, cada flujo controlado por el nodo amo con falla es tomada por un nodo amo operativo para mantener el funcionamiento del sistema de bases de datos, una vez que el nodo amo que fallo ha sido reestablecido o sustituido, este esta disponible para nuevos flujos recibidos por el sistema de bases de datos.

Además de la monitorización de los demás nodos amo en el sistema de bases de datos, el Software de gestión del sistema 32 también monitoriza cada uno de los nodos esclavo en el sistema. La Figura 19 es un diagrama de flujo que representa un proceso ejecutado tras la falla de un nodo esclavo en el sistema de bases de datos. En el caso de una falla de un nodo esclavo, el Software de gestión de flujos 20 es notificado de la falla en el paso S1900. El Software de gestión de flujos 20 entonces notifica al administrador del sistema de la falla del nodo a través de la consola de gestión 35. Para cada transacción incompleta que involucre el nodo esclavo que fallo, el Software de gestión de flujos 20 hace retroceder la transacción incompleta en el paso S1901 y vuelve a ejecutar la transacción en el ,rpaso S1902 utilizando el compañero o compañeros relevo correspondientes en lugar del nodo esclavo que fallo.

Durante el tiempo en el que el nodo esclavo que fallo esta siendo restablecido o sustituido, los nodos amo ejecutan consultas en los nodos esclavo operativos regulares y en los nodos esclavo compañeros relevo pertinentes . Por consiguiente, se mantiene la operación del sistema de bases de datos a pesar de la falla de un nodo esclavo. Una vez que el nodo esclavo ha sido reestablecido o sustituido, los nodos amo regresan a la ejecución de consultas normal .

Modalidades alternativas de la invención incluyen el uso de una configuración jerárquica de los nodos amo para manejar una cantidad grande de nodos esclavo. En esta configuración, el procesamiento realizado por los nodos amo se rompe en múltiples capas para mejorar el desempeño. Además, algo del procesamiento realizado a nivel de los nodos esclavo podría ser trasladado a un nivel de los nodos amo. Otras modalidades consisten en el uso de un sistema de almacenamiento compartido para los nodos esclavo del sistema de bases de datos en lugar del almacenamiento unido directo antes descrito .

Los datos relevo se podrían almacenar en un almacenamiento compartido y con ello permitir a cualquier nodo esclavo disponible realizar tareas de relevo para un nodo que falle.

El sistema de bases de datos paralelas, ultra-nada compartidas descrito en lo anterior proporciona ventajas importantes sobre el sistema de bases de datos paralelas, nada compartidas, convencional. La primera y más importante, el sistema de bases de datos de la presente invención evita sesgo de consultas y los efectos perjudiciales que este tiene sobre el desempeño de las bases de datos. Segunda, la partición y distribución de una base de datos a través de los nodos esclavo del sistema de bases de datos se realiza en forma automática. Esto aumenta la eficacia del sistema sin adicionar complejidad a la administración del sistema. Tercera,_ la memoria caché binivel utilizada para los resultados de las consultas caché evita repetición innecesaria del procesamiento de la misma consulta muchas veces. Por último, el proceso de relevo del sistema de bases de datos mantiene la operación del sistema en el caso de falla de los nodos .

La descripción anterior esta destinada a ilustrar modalidades preferidas de la presente invención. Sin embargo, los ejemplos establecidos en lo anterior no están destinados a limitar el alcance de la invención, la cual debe ser interpretada a partir de las reivindicaciones establecidas más adelante. Debe entenderse que es posible hacer diversas modificaciones a los ejemplos ilustrados sin apartarse del espíritu y alcance de la invención.

Claims (29)

REIVINDICACIONES

1. Un sistema de bases de datos paralelas que consiste en: un nodo amo; una pluralidad de nodos esclavo; medios para distribuir una base de datos a través de la pluralidad de nodos amo, la base de datos contiene una tabla de hechos y una pluralidad de tablas de dimensión; en donde la tabla de hechos y la primera tabla de dimensión se particionan a través de la pluralidad de nodos esclavos; en donde todas las demás tablas de dimensión de la base de datos se duplican en cada uno de la pluralidad de nodos esclavo, y en donde hasta una pluralidad de las demás tablas de dimensión que tienen un tamaño mínimo también se particionan a lo largo de la pluralidad de nodos esclavo.

2. El sistema de bases de datos paralelas de conformidad con la reivindicación 1, caracterizado porque hasta una pluralidad de las demás tablas de dimensión se particionan por fila.

3. El sistema de bases de datos paralelas de conformidad con la reivindicación 1, caracterizado porque hasta una pluralidad de las demás tablas de dimensión se particionan por columna.

4. El sistema de bases de datos paralelas de conformidad con la reivindicación 1, caracterizado porque hasta una pluralidad de las demás tablas de dimensión se particionan por fila y por columna.

5. El sistema de bases de datos paralelas de conformidad con la reivindicación 1, caracterizado porque la tabla de hechos y la primera tabla de dimensión se particionan por fila.

6. El sistema de bases de datos paralelas de conformidad con la reivindicación 5, caracterizado porque la tabla de hechos y la primera tabla de dimensión se particionan por refundición en una clave común.

7. El sistema de bases de datos paralelas de conformidad con la reivindicación 5, caracterizado porque la tabla de hechos y la primera tabla de dimensión se particionan por columna.

8. El sistema de bases de datos paralelas de conformidad con la reivindicación 1, caracterizado porque las tablas de bases de datos se particionan por fecha a lo largo de una • pluralidad de la pluralidad de nodos esclavos.

9. El sistema de bases de datos paralelas de conformidad con la reivindicación 1, caracterizado porque los medios de partición particionan y distribuyen automáticamente las tablas de las bases de datos a través de la pluralidad de nodos esclavo.

10. El sistema de bases de datos paralelas de conformidad con la reivindicación 1, además comprende medios para traducir una consulta contra la base de datos -en por lo menos una subconsulta que se pueda ejecutar por el sistema de bases de datos paralelas sin transferir datos entre los nodos esclavo.

11. El sistema de bases de datos paralelas de conformidad con la reivindicación 10, además comprende medios para almacenar en la memoria caché los resultados de la consulta producidos por el sistema de base de datos paralelas .

12. El sistema de bases de datos paralelas de conformidad con la reivindicación 11, caracterizado porque el nodo maestro incluye medios para guardar en memoria caché los resultados de la consulta producidos por el nodo amo .

13. El sistema de bases de datos paralelas de conformidad con la reivindicación 12, caracterizado porque cada uno de la pluralidad de nodos esclavo incluye medios para guardar en memoria caché resultados de subconsultas producidos por el nodo esclavo respectivo.

14. El sistema de bases de datos paralelas de conformidad con la reivindicación 1, caracterizado porque en cada uno de la pluralidad de los nodos esclavo, una copia de la serie de datos almacenada en el nodo esclavo respectivo es almacenada en otro de la pluralidad de nodos esclavo asignados como un compañero relevo para el nodo esclavo respectivo.

15. El sistema de bases de datos paralelas de conformidad con la reivindicación 14, caracterizado porque las subconsultas que se van a ejecutar por un nodo esclavo que falla se ejecutan por el compañero relevo del nodo esclavo que falla.

16. Un método para gestionar una base de datos dentro de un sistema de bases de datos paralelas, el sistema contiene una tabla de hechos y una pluralidad de tablas de dimensión, el método comprende los pasos de: identificar una tabla de hechos y una primera tabla de dimensión dentro de la base de datos; particionar la tabla de hechos y la primera tabla de dimensión a través de una pluralidad de nodos esclavo; duplicar cada una de las demás tablas de dimensión en cada uno de la pluralidad de nodos- esclavo; y particionar hasta una pluralidad de las demás tablas de dimensión que tenga un tamaño mínimo a través de la pluralidad de nodos esclavo.

17. El método de conformidad con la reivindicación 16, caracterizado porque hasta una pluralidad de las demás tablas de dimensión se particionan por fila.

18. El método de conformidad con la reivindicación 16, caracterizado porque hasta una pluralidad de las demás tablas de dimensión se particiona por columna.

19. El método de conformidad con la reivindicación 16, caracterizado porqué hasta una pluralidad de las demás tablas de dimensión se particiona por fila y por columna

20. El método de conformidad con la reivindicación 16, caracterizado porque la tabla de hecho y la primera tabla de dimensión se particionan por fila.

21. El método de conformidad con la reivindicación 16, caracterizado porque la tabla de hecho y la primera tabla i de dimensión se particionan por refundición en una clave común.

22. El método de conformidad con la reivindicación 20, caracterizado porque la tabla de hechos y la primera tabla de dimensión también se particionan por columna .

23. El método de conformidad con la reivindicación 16, además comprende la partición de las tablas de las bases de datos por fecha a través de una pluralidad de nodos esclavo .

24. El método de conformidad con la reivindicación 16, además consiste en traducir una consulta contra la base de datos en por lo menos una subconsulta que pueda ser ejecutada por el sistema de bases de datos paralelas sin transferir datos entre los nodos esclavo.

25. El método de conformidad con la reivindicación 24, además consiste en cachetizar los resultados de la consulta en un nodo amo.

26.- El método de conformidad con la reivindicación 25. además consiste en cachetizar los resultados de por lo menos una subconsulta en los nodos esclavo respectivos.

27. El método de conformidad con la reivindicación 16, además comprende almacenar una copia de la serie de datos de un nodo esclavo en un compañero relevo asignado al nodo esclavo.

28. El método de conformidad con la reivindicación 27, además comprende ejecutar subconsultas que van a ser ejecutadas por un nodo esclavo con falla en el compañero relevo del nodo esclavo .

29. Los pasos de un proceso que pueden se ejecutados en computadora, almacenados en un medio de memoria legible por computadora, los pasos del proceso para realizar el método descrito en cualquiera de las reivindicaciones 16 a 28. RESUMEN DE LA INVENCIÓN Se describe un sistema de bases de datos paralelas, ultra-nada compartidas que incluye por lo menos un nodo amo y múltiples nodos esclavo. Una base de datos consistente en por lo menos una tabla de hechos y múltiples tablas de dimensión se particiona y distribuye a lo largo de los nodos esclavo del sistema de bases de datos para que las consultas sean procesadas en paralelo sin requerir de la transferencia de los datos entre los nodos esclavo. La tabla de hechos y una primera tabla de dimensión de la base de datos se particionan a lo largo de los nodos esclavo. Las demás tablas de dimensión de la base de datos se duplican en cada uno de los nodos esclavo y por lo menos una de estas otras tablas de dimensión se particiona a lo largo de los nodos esclavo.