Procesamiento remoto de EA

El AE remoto que escucha en un punto de conexión AE recibe notificaciones del sistema Netezza de que se está llamando a una nueva instancia de una función SQL. El AE remoto entonces crea un nuevo hilo, obtiene un hilo de un pool, o bifurca un nuevo proceso para manejar la llamada a la función SQL. El hilo o proceso que maneja la función SQL crea una conexión de datos para esa función. Cuando la solicitud se completa con éxito, es importante que el AE remoto llame "hecho" a la conexión de datos y la cierre. Si se produce un error, es importante que el AE llame a "error" en la conexión de datos y luego la cierre. El mismo hilo o proceso puede utilizarse para procesar en serie llamadas a funciones SQL, por lo que es posible utilizar un pool de hilos o un pool de procesos.

A continuación se exponen cuatro posibles situaciones que pueden darse al aplicar las EA.

Escenario 1: La lengua ayuda a los hilos

Utilizando un lenguaje que soporte hilos, posiblemente Java o C++ con hilos POSIX, se ejecuta una instancia del AE al estilo daemon en cada SPU y otra en el host. Cada función SQL se gestiona en un hilo tomado de un pool, de forma que las peticiones se gestionan de forma concurrente. En este caso, la dirección del punto de conexión AE sólo consta del nombre de la cadena y nada más. El AE remoto tiene un oyente en esta dirección.

Escenario 2: El lenguaje no soporta hilos

Si utiliza un lenguaje que no admite hilos, que no los admite bien o en el que los hilos no son deseables, utilice el mismo punto de conexión que en el Escenario 1. Para procesar funciones SQL, debe bifurcar y manejar la función SQL en el nuevo proceso. En este caso, el proceso de escucha escucha los entornos AE, que son conjuntos de variables de entorno AE que describen una solicitud de función SQL AE. Tras la bifurcación, el entorno AE puede utilizarse para crear una conexión de datos AE.

Escenario 3: Uso de una única instancia

Las soluciones para los dos primeros escenarios dictan que cuando se utiliza la base de datos se utiliza la misma instancia única del AE remoto por SPU o host. Si por seguridad u otras razones no quieres que otros compartan EAs, puedes añadir ID de sesión a la dirección del EA remoto.

Para ello, establezca NZAE_REMOTE_NAME_SESSION=1 (o la opción register_ae --rsession) al registrar la función SQL, y especifique el ID de sesión al crear el punto de conexión en el AE remoto.

Tenga en cuenta que debe seguir utilizando hilos o bifurcar nuevos procesos porque se siguen recibiendo múltiples notificaciones simultáneas de llamadas a funciones SQL. Esto ocurre porque una EPD consta de varios dataslices, y las llamadas a funciones simultáneas proceden de cada dataslice.

Debe iniciar el EA remoto después de que se inicie la sesión y detener el EA remoto antes de que finalice. (El lanzamiento y detención de EAs remotos se trata en Lanzamiento de un ejecutable analítico remoto) Cada sesión utiliza su propia instancia del proceso AE remoto.

Escenario 4: Rebanada de datos en la dirección AE remota

Hay dos enfoques posibles que utilizan dataslices en la dirección AE remota. La primera es lanzar un AE por dataslice en cada SPU. La función SQL se registra con NZAE_REMOTE_NAME_DATA_SLICE=1 utilizando (o la opción register_ae --rdataslice). Cada AE remoto puede utilizar una llamada a la API para devolver el dataslice para el que fue lanzado. A continuación, escucha en una dirección remota formada por el nombre de la cadena y el ID del dataslice. Si hay cuatro dataslices en una SPU, entonces hay cuatro procesos remotos AE. Cada AE remoto introduce datos sólo para su dataslice.

Este enfoque funciona bien para un lenguaje de programación como C++, sin embargo, puede que no funcione tan bien si cada proceso remoto AE tiene requisitos de recursos muy grandes o está escrito en un lenguaje de programación con un entorno de tiempo de ejecución intensivo en recursos. En esta situación, hay un proceso AE pesado por dataslice; colectivamente, los múltiples procesos pueden estar consumiendo demasiados recursos del sistema, especialmente memoria.

El otro enfoque es una forma más compleja de utilizar dataslices en la dirección AE remota. Un único proceso AE remoto puede utilizar varias conexiones de notificación simultáneamente, siempre que tengan direcciones diferentes. En el Escenario 1, se utilizó un oyente de notificaciones para todo el proceso con un nombre de cadena de direcciones AE remotas. Para ese escenario, considere el caso en el que ejecuta una única consulta que se ejecuta en las SPU. Un AE remoto que se ejecuta en una SPU recibe múltiples notificaciones de llamadas a funciones SQL, una de cada dataslice, en la SPU. Las notificaciones son simultáneas, pero el receptor las procesa en serie. En el Escenario 1, cada notificación era recibida y asignada a un hilo en el pool para dar servicio a la función SQL. Las conexiones de datos se procesan simultáneamente, pero algunas empiezan antes que otras porque las notificaciones se procesan individualmente.

En aras de la eficacia, es conveniente tener un receptor de notificaciones por dataslice. Si hay cuatro dataslices en una SPU, se crean cuatro hilos, cada uno escuchando un punto de conexión AE especificado con una dirección construida a partir del nombre de la cadena remota y el ID del dataslice.

La función SQL sigue registrada con NZAE_REMOTE_NAME_DATA_SLICE=1 utilizando la opción register_ae --rdataslice.

Supongamos que el nombre remoto es "MY_REMOTEAE" y que los dataslices de una SPU determinada son 17, 18, 19 y 20. En el proceso AE, los cuatro hilos de notificación están a la escucha en las direcciones de los puntos de conexión AE:

{ name=MY_REMOTEAE, data slice id=17 }
{ name=MY_REMOTEAE, data slice id=18 }
{ name=MY_REMOTEAE, data slice id=19 }
{ name=MY_REMOTEAE, data slice id=20 }

Cuando un hilo de escucha recibe una notificación de una nueva llamada a una función SQL, recupera un hilo de notificación del pool y lo asigna a esa petición de función SQL para el dataslice asignado.

Por último, desea que un oyente gestione los comandos de control de trabajos de AE. El control de trabajos permite enviar comandos ping y de parada a un AE remoto en ejecución. El punto de conexión es:

{ name=MY_REMOTEAE }

No existe una llamada directa a la API para determinar cómo el proceso AE único que se ejecuta en la SPU determina qué dataslices debe escuchar. Existe una vista de base de datos llamada _v_dual_dslice que contiene un registro para cada dataslice de toda la base de datos. Por ejemplo:

SELECT * FROM _v_dual_dslice;
DSID 
------
1
4
2
3
…

Para utilizar esta vista, registre una función escalar que se conecte al AE remoto utilizando el nombre de la cadena de direcciones. El escalar toma un argumento entero y se llama usando la columna DSID en la vista _v_dual_dslice como argumento. Después de lanzar el AE remoto, se llama a esta función escalar. El AE remoto de cada SPU recibe una notificación por cada dataslice. Cuando el AE remoto abre la conexión de datos, obtiene el dataslice para esa petición y utiliza ese slice para iniciar el listener para address string name, dataslice en un nuevo thread. La función escalar se procesa normalmente para devolver un valor y cerrar la conexión de datos. Dado que la función escalar se utiliza para proporcionar la información AE remota, el valor de retorno es irrelevante.

Para resumir, en el Escenario 1, usted utilizó un oyente. En el Escenario 4, enfoque uno, se utilizó un proceso AE remoto por dataslice, cada uno con un listener. Para el Escenario 4, enfoque dos, usted utilizó cinco escuchadores de notificación diferentes en un único proceso AE remoto.