Elaborazione AE a distanza
L'AE remoto in ascolto su un punto di connessione AE riceve notifiche dal sistema Netezza che indicano la chiamata di una nuova istanza di una funzione SQL. L'AE remoto crea quindi un nuovo thread, ottiene un thread da un pool o crea un nuovo processo per gestire la chiamata di funzione SQL. Il thread o il processo che gestisce la funzione SQL crea una connessione dati per tale funzione. Quando la richiesta viene completata con successo, è importante che l'AE remoto chiami "done" sulla connessione dati e la chiuda. Se si verifica un errore, è importante che l'AE chiami "errore" sulla connessione dati e poi la chiuda. Lo stesso thread o processo può essere utilizzato per elaborare in serie le chiamate di funzione SQL, quindi è possibile utilizzare un pool di thread o un pool di processi.
Di seguito sono riportati quattro possibili scenari che si possono incontrare durante l'implementazione delle AE.
Scenario 1: La lingua supporta i thread
Utilizzando un linguaggio che supporta i thread, possibilmente Java o C++ con thread POSIX, si esegue un'istanza di AE in stile demone su ogni SPU e una sull'host. Ogni funzione SQL è gestita da un thread preso da un pool, in modo che le richieste siano gestite in modo concorrente. In questo caso, l'indirizzo del punto di connessione AE è costituito solo dal nome della stringa e da nient'altro. L'AE remoto ha un ascoltatore su questo indirizzo.
Scenario 2: La lingua non supporta le filettature
Se si utilizza un linguaggio che non supporta le filettature, che non le supporta bene o in cui le filettature non sono desiderabili, utilizzare lo stesso punto di connessione dello Scenario 1. Per elaborare le funzioni SQL, è necessario eseguire il fork e gestire la funzione SQL nel nuovo processo. In questo caso, il processo di ascolto cerca gli ambienti AE, che sono insiemi di variabili di ambiente AE che descrivono una richiesta di funzione SQL AE. Dopo il fork, l'ambiente AE può essere usato per creare una connessione dati AE.
Scenario 3: Utilizzo di una singola istanza
Le soluzioni per i primi due scenari prevedono che quando si usa il database si utilizzi la stessa singola istanza dell'AE remoto per SPU o host. Se per motivi di sicurezza o altro non si vuole che altri condividano gli AE, è possibile aggiungere l'ID di sessione all'indirizzo dell'AE remoto.
A tal fine, impostare NZAE_REMOTE_NAME_SESSION=1 (o l'opzione register_ae --rsession) durante la registrazione della funzione SQL e specificare l'ID di sessione quando si crea il punto di connessione nell'AE remoto.
Si noti che è ancora necessario utilizzare i thread o creare nuovi processi, poiché vengono ancora ricevute più notifiche simultanee di chiamate a funzioni SQL. Questo accade perché una SPU è composta da più dataslices e le chiamate di funzione simultanee provengono da ogni dataslice.
È necessario avviare l'AE remoto dopo l'avvio della sessione e arrestarlo prima della sua conclusione. (L'avvio e l'arresto degli AE remoti sono trattati in Avvio di un eseguibile analitico remoto) Ogni sessione utilizza la propria istanza del processo AE remoto.
Scenario 4: Fetta di dati nell'indirizzo dell'AE remoto
Esistono due approcci possibili che utilizzano i dataslices nell'indirizzo dell'AE remoto. Il primo consiste nell'avviare un AE per ogni dataslice su ogni SPU. La funzione SQL viene registrata con NZAE_REMOTE_NAME_DATA_SLICE=1 utilizzando (o l'opzione register_ae --rdataslice). Ogni AE remoto può utilizzare una chiamata API per restituire la dataslice per la quale è stato lanciato. Quindi si mette in ascolto su un indirizzo remoto composto dal nome della stringa e dall'ID della dataslice. Se ci sono quattro dataslices su una SPU, ci sono quattro processi AE remoti. Ogni AE remoto immette dati solo per la propria dataslice.
Questo approccio funziona bene per un linguaggio di programmazione come il C++, ma potrebbe non funzionare altrettanto bene se ogni processo AE remoto ha requisiti di risorse molto elevati o è scritto in un linguaggio di programmazione con un ambiente di runtime che richiede molte risorse. In questa situazione, c'è un processo AE pesante per ogni dataslice; collettivamente i processi multipli potrebbero consumare troppe risorse di sistema, soprattutto la memoria.
L'altro approccio è un modo più complesso di utilizzare i dataslices nell'indirizzo AE remoto. Un singolo processo AE remoto può utilizzare più connessioni di notifica contemporaneamente, purché abbiano indirizzi diversi. Nello Scenario 1, è stato utilizzato un ascoltatore di notifiche per l'intero processo con un nome di stringa di indirizzo AE remoto. Per questo scenario, si consideri il caso in cui si esegue una singola query che viene eseguita sulle SPU. Un AE remoto in esecuzione su una SPU riceve più notifiche di chiamate di funzioni SQL, una per ogni dataslice, sulla SPU. Le notifiche sono simultanee, ma vengono elaborate in serie dall'ascoltatore. Nello Scenario 1, ogni notifica è stata ricevuta e assegnata a un thread del pool per servire la funzione SQL. Le connessioni di dati vengono elaborate simultaneamente, ma alcune iniziano prima di altre perché le notifiche vengono elaborate individualmente.
Per efficienza, si vuole un ascoltatore di notifiche per ogni dataslice. Se ci sono quattro dataslices su una SPU, si creano quattro thread, ciascuno in ascolto di un punto di connessione AE specificato con un indirizzo costruito a partire dal nome della stringa remota e dall'ID della dataslice.
La funzione SQL è ancora registrata con NZAE_REMOTE_NAME_DATA_SLICE=1 utilizzando l'opzione register_ae --rdataslice.
{ 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 }Quando un thread in ascolto riceve la notifica di una nuova chiamata di funzione SQL, recupera un thread di notifica dal pool e lo assegna alla richiesta di funzione SQL per la dataslice assegnata.
{ name=MY_REMOTEAE }Non esiste una chiamata diretta all'API per determinare come il singolo processo AE in esecuzione sulla SPU determini quali dataslices ascoltare. Esiste una vista del database chiamata _v_dual_dslice che contiene un record per ogni dataslice dell'intero database. Ad esempio:
SELECT * FROM _v_dual_dslice;
DSID
------
1
4
2
3
…Per utilizzare questa vista, registrare una funzione scalare che si connetta all'AE remoto utilizzando il nome della stringa di indirizzo. Lo scalare accetta un argomento intero e viene chiamato utilizzando come argomento la colonna DSID nella vista _v_dual_dslice. Dopo l'avvio dell'AE remoto, viene richiamata questa funzione scalare. L'AE remoto di ogni SPU riceve una notifica per ogni dataslice. Quando l'AE remoto apre la connessione ai dati, ottiene la slice di dati per quella richiesta e la usa per avviare l'ascoltatore per nome stringa indirizzo, slice di dati su un nuovo thread. La funzione scalare viene elaborata normalmente per restituire un valore e chiudere la connessione dati. Poiché la funzione scalare viene utilizzata per fornire le informazioni sull'AE remoto, il valore di ritorno è irrilevante.
Per riassumere, nello Scenario 1 si è utilizzato un ascoltatore. Nello Scenario 4, primo approccio, è stato utilizzato un processo AE remoto per ogni dataslice, ciascuno con un ascoltatore. Per lo Scenario 4, approccio due, sono stati utilizzati cinque diversi ascoltatori di notifiche in un singolo processo AE remoto.