Processamento remoto de AE
O AE remoto que escuta em um ponto de conexão AE recebe notificações do sistema Netezza de que uma nova instância de uma função SQL está sendo chamada. Em seguida, o AE remoto cria um novo thread, obtém um thread de um pool ou bifurca um novo processo para lidar com a chamada de função SQL. O thread ou processo que manipula a função SQL cria uma conexão de dados para essa função. Quando a solicitação for concluída com êxito, é importante que o AE remoto chame "done" na conexão de dados e a feche. Se ocorrer um erro, é importante que o AE chame "erro" na conexão de dados e, em seguida, feche-a. O mesmo thread ou processo pode ser usado para processar em série as chamadas de função SQL, portanto, é possível usar um pool de threads ou um pool de processos.
Abaixo estão quatro cenários possíveis que podem ser encontrados na implementação de AEs.
Cenário 1: idioma oferece suporte a threads
Usando uma linguagem que ofereça suporte a threads, possivelmente Java ou C++ com threads POSIX, você executa uma instância do estilo daemon do AE em cada SPU e uma no host. Cada função SQL é tratada em um thread retirado de um pool, de modo que as solicitações sejam tratadas simultaneamente. Nesse caso, o endereço do ponto de conexão AE consiste apenas no nome da cadeia de caracteres e nada mais. O AE remoto tem um ouvinte nesse endereço.
Cenário 2: a linguagem não é compatível com threads
Usando uma linguagem que não ofereça suporte a threads, que não ofereça um bom suporte a elas ou em que as threads não sejam desejáveis, use o mesmo ponto de conexão do Cenário 1. Para processar funções SQL, você deve bifurcar e manipular a função SQL no novo processo. Nesse caso, o processo de escuta escuta os ambientes AE, que são conjuntos de variáveis de ambiente AE que descrevem uma solicitação de função SQL AE. Após a bifurcação, o ambiente AE pode ser usado para criar uma conexão de dados AE.
Cenário 3: uso de uma única instância
As soluções para os dois primeiros cenários determinam que, ao usar o banco de dados, você use a mesma instância única do AE remoto por SPU ou host. Se, por motivos de segurança ou outros, você não quiser que outras pessoas compartilhem AEs, poderá adicionar o ID da sessão ao endereço do AE remoto.
Para isso, defina NZAE_REMOTE_NAME_SESSION=1 (ou a opção register_ae --rsession) ao registrar a função SQL e especifique a ID da sessão ao criar o ponto de conexão no AE remoto.
Observe que você ainda deve usar threads ou bifurcar novos processos porque várias notificações simultâneas de chamadas de função SQL ainda são recebidas. Isso ocorre porque uma SPU consiste em vários cortes de dados, e as chamadas de função simultâneas vêm de cada corte de dados.
Você deve iniciar o AE remoto após o início da sessão e interromper o AE remoto antes do término. (O lançamento e a interrupção de AEs remotos são abordados em Lançamento de um executável analítico remoto) Cada sessão usa sua própria instância do processo AE remoto.
Cenário 4: Fatia de dados no endereço AE remoto
Há duas abordagens possíveis que usam os conjuntos de dados no endereço AE remoto. A primeira é iniciar um AE por corte de dados em cada SPU. A função SQL é registrada com NZAE_REMOTE_NAME_DATA_SLICE=1 usando (ou a opção register_ae --rdataslice). Cada AE remoto pode usar uma chamada de API para retornar a fatia de dados para a qual foi iniciado. Em seguida, ele escuta em um endereço remoto que consiste no nome da cadeia de caracteres e no ID do dataslice. Se houver quatro dataslices em uma SPU, haverá quatro processos AE remotos. Cada AE remoto insere dados apenas para sua fatia de dados.
Essa abordagem funciona bem para uma linguagem de programação como C++, mas pode não funcionar tão bem se cada processo de AE remoto tiver requisitos de recursos muito grandes ou for escrito em uma linguagem de programação com um ambiente de tempo de execução que consome muitos recursos. Nessa situação, há um processo AE pesado por fatia de dados; coletivamente, os vários processos podem estar consumindo muitos recursos do sistema, especialmente memória.
A outra abordagem é uma maneira mais complexa de usar os conjuntos de dados no endereço AE remoto. Um único processo AE remoto pode usar várias conexões de notificação simultaneamente, desde que tenham endereços diferentes. No Cenário 1, um ouvinte de notificação foi usado para todo o processo com um nome de cadeia de caracteres de endereço AE remoto. Para esse cenário, considere o caso em que você executa uma única consulta que é executada nas SPUs. Um AE remoto em execução em uma SPU recebe várias notificações de chamada de função SQL, uma de cada fatia de dados, na SPU. As notificações são simultâneas, mas são processadas em série pelo ouvinte. No Cenário 1, cada notificação foi recebida e atribuída a um thread no pool para atender à função SQL. As conexões de dados são processadas simultaneamente, mas algumas começam antes das outras porque as notificações são processadas individualmente.
Para maior eficiência, você deseja um ouvinte de notificação por fatia de dados. Se houver quatro dataslices em uma SPU, você criará quatro threads, cada um ouvindo um ponto de conexão AE especificado com um endereço criado a partir do nome da string remota e do ID do dataslice.
A função SQL ainda é registrada com NZAE_REMOTE_NAME_DATA_SLICE=1 usando a opção 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 um thread de escuta recebe uma notificação de uma nova chamada de função SQL, ele recupera um thread de notificação do pool e o atribui a essa solicitação de função SQL para o dataslice atribuído.
{ name=MY_REMOTEAE }Não há nenhuma chamada direta à API para determinar como o processo AE único em execução na SPU determina quais dataslices devem ser ouvidos. Há uma visualização de banco de dados chamada _v_dual_dslice que contém um registro para cada dataslice de todo o banco de dados. Por exemplo:
SELECT * FROM _v_dual_dslice;
DSID
------
1
4
2
3
…Para usar essa visualização, registre uma função escalar que se conecte ao AE remoto usando o nome da cadeia de endereços. O escalar recebe um argumento inteiro e é chamado usando a coluna DSID na exibição _v_dual_dslice como um argumento. Depois que o AE remoto é iniciado, essa função escalar é chamada. O AE remoto em cada SPU recebe uma notificação para cada fatia de dados. Quando o AE remoto abre a conexão de dados, ele obtém o dataslice para essa solicitação e usa esse slice para iniciar o ouvinte para o nome da string de endereço, dataslice em um novo thread. A função escalar é processada normalmente para retornar um valor e fechar a conexão de dados. Como a função escalar está sendo usada para fornecer as informações do AE remoto, o valor de retorno é irrelevante.
Para resumir, no Cenário 1, você usou um ouvinte. No Cenário 4, abordagem 1, você usou um processo AE remoto por fatia de dados, cada um com um ouvinte. No Cenário 4, abordagem dois, você usou cinco ouvintes de notificação diferentes em um único processo AE remoto.