O Stream DB V3 permite estabelecer uma conexão com um serviço que suporta o protocolo JDBC (Java Database Connectivity) e executar instruções SQL (Structured Query Language).

Diferentemente do componente DB Connector, o Stream DB foi desenvolvido para realizar execução em lotes, ou seja, cada retorno (linha resultante ou row) da instrução SQL executada é tratada individualmente através de um subpipeline, podendo conter seu próprio fluxo de processamento. Aprenda mais sobre subpipelines clicando aqui.

Dê uma olhada nos parâmetros de configuração do componente:

  • Account: para o componente fazer a autenticação a um serviço JDBC, é necessário usar uma account do tipo BASIC ou KERBEROS (veja o tópico "Autenticação via Kerberos").
  • Database URL: URL (Uniform Resource Locator) para estabelecer conexão ao servidor de banco de dados com suporte ao protocolo JDBC. Este parâmetro aceita Double Braces.
  • SQL Statement: instrução SQL a ser executada.
  • Column Name: caso haja um erro no processamento do subpipeline, o valor associado a coluna definida neste campo será adicionado à mensagem de erro no campo "processedId", conforme a seguir:
{
"timestamp": 1600797662733,
"error": "Error message",
"code": 500,
"processedId": "2"
}

  • Parallel Execution Of Each Iteration: quando ativada, essa opção faz com que cada uma das passagens pelo subpipeline seja feita em paralelo, reduzindo o tempo de execução total. No entanto, não há qualquer garantia de que os itens sejam executados na ordem retornada pelo banco de dados.
  • Blob As File: se ativada, a opção faz com que os campos do tipo blob sejam armazenados no contexto do pipeline como arquivo; do contrário, os campos são armazenados como textos normais (strings) e codificados em base64, conforme a seguir:
// "Blob As File" true
{
"id": 12,
"blob": "d3X8YK.file",
}

// "Blob As File" false
{
"id": 12,
"blob": "iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAeSURBVDhPY1Da6EMSYiBJNVDxqAZiQmw0lAZHKAEAaskfEED3lr0AAAAASUVORK5CYII="
}

  • Fail On Error: se a opção estiver ativada, a execução do pipeline com erro será interrompida; do contrário, a execução do pipeline continua, mas o resultado vai mostrar um valor "false" para a propriedade success.
  • Custom Connection Properties: propriedades de conexão específicas definidas pelo usuário.
  • Keep Connections: se ativada, a opção vai manter as conexões com a base de dados por no máximo 30 minutos; do contrário, será por apenas 5 minutos.
  • Advanced: configurações avançadas.
  • Output Column From Label: para alguns bancos de dados, é importante manter esta opção ativada caso o seu SELECT esteja utilizando algum alias, pois dessa maneira garante-se que o nome da coluna será exibido da mesma forma que o alias configurado.
  • Connection Test Query: instrução SQL a ser executada antes que cada conexão seja estabelecida (i.e. select 1 from dual) - esse parâmetro é opcional e deve ser aplicado apenas a bancos de dados que não possuem informações confiáveis sobre o status da conexão.

Tecnologia

Autenticação via Kerberos

Para realizar autenticação a um banco de dados via Kerberos é necessário:

  • informar uma conta (account) do tipo KERBEROS
  • configurar um Kerberos principal
  • configurar uma keytab (que deve ser a base64 do próprio arquivo keytab gerado)

Fluxo de Mensagens

Estrutura de mensagem disponível no subpipeline onProcess

Uma vez que a instrução SQL é executada, o subpipeline será disparado recebendo o resultado da execução por meio de uma mensagem na seguinte estrutura:

{
"coluna1": "dado1",
"coluna2": "dado2",
"coluna3": "dado3"
}

Erro

{
"code": error_code,
"error": mensagem de erro,
"processId": the_id_column_value
}

Saída

Após a execução do componente, é retornada uma mensagem na seguinte estrutura:

{
"total": 0,
"success": 0,
"failed": 0
}

  • total: número total de linhas processadas
  • success: número total de linhas processadas com sucesso
  • failed: número total de linhas cujo processamento falhou

IMPORTANTE: para detectar se uma linha foi processada corretamente, cada subpipeline onProcess deve responder com { "success": true } a cada elemento processado.

O Stream DB V3 realiza processamento em lote. Para entender melhor o conceito, clique aqui.

Pool de conexão

Por padrão, utilizamos um pool com tamanho baseado nas configurações do pipeline implantado. Caso seja um pipeline SMALL, então o tamanho do pool será de 10; para o MEDIUM será de 20 e para o LARGE de 40.

É possível gerenciar o tamanho do pool na hora da implantação também. Para isso, será necessário habilitar a propriedade "Pool Size By Actual Consumers" no componente. Com isso, será utilizado o que for configurado manualmente na tela de implantação.

No exemplo da figura abaixo, foi configurado um pipeline SMALL com 5 consumers. Se você quiser que o pool dos componentes de banco de dados (DB V2 e Stream DB V3) utilize esse tamanho, é necessário habilitar a propriedade “Pool Size By Actual Consumers” em todos os componentes existentes.

Tenha atenção redobrada ao configurar o tamanho do pool manualmente para que não ocorra nenhum deadlock em chamadas concorrentes ao mesmo banco.

O nosso pool é compartilhado entre os componentes de banco de dados que acessam o mesmo banco de dados dentro do pipeline. Caso seja necessário um pool exclusivo para um determinado componente, habilite a propriedade “Exclusive Pool”.

Encontrou sua resposta?