Detectar Alteração ou Trocar para Ver Fonte? O Vencedor É....

bharold

A resposta é ambas as opções para mim, mas você é o juiz para a sua situação!  Continue lendo para os critérios de decisão...<\/P>

Se você deseja manter um grande serviço de feição hospedado a partir de dados externos, a melhor prática é evitar substituições completas a cada atualização, por duas razões:<\/P>

1. Grandes transações de gravação podem ser frágeis<\/LI>
2. Grandes transações de gravação podem causar tempo significativo de inatividade do serviço<\/LI><\/OL>

   Para evitar ambos os problemas, é preferível implementar uma abordagem CDC<\/A> (captura de dados alterados) e gravar apenas os deltas no serviço de feição alvo.  Este blog descreverá duas maneiras de fazer isso:<\/P>

   1. Gravando deltas diretamente no serviço de feição alvo<\/LI>
   2. Manter uma
   visualização da camada de feição hospedada<\/A> apontando alternadamente para dois serviços
   • Gravar transações delta no serviço não<\/STRONG> atualmente a fonte e então
   trocar<\/A> para que ele seja<\/STRONG> a fonte da visualização<\/LI><\/UL><\/LI><\/OL>Na situação usual onde um delta periódico é uma pequena fração dos dados, uma gravação direta do delta pode levar vários segundos, enquanto para uma troca da fonte da visualização o tempo de inatividade pode ser milissegundos, mas tem o dobro do custo de armazenamento.<\/EM>  Faremos um exemplo prático para que você possa escolher entre as abordagens, mas de qualquer forma você sai ganhando usando CDC!<\/STRONG><\/P>Aqui estão meus dados do assunto, cerca de um milhão de pontos de endereço de rua em Los Angeles<\/A>, Califórnia, mantidos diariamente:<\/P>

   Pontos de Endereço em Los Angeles<\/span><\/span><\/P>A tarefa é calcular e aplicar a transação delta diária (tipicamente algumas centenas de feições) com baixo tempo de inatividade, e enquanto nossos modos candidatos de gravação (direta, troca da fonte da visualização) isolam o tempo de inatividade do serviço do tempo de cálculo do delta, é sempre bom incorporar quaisquer otimizações que puder<\/STRONG>. O site de dados abertos da cidade suporta download CSV, e CSV é um formato performático em ferramentas ETL espaciais, então isso é metade da etapa do cálculo do delta.  A outra metade é ler o estado atual do serviço/visualização da feição.<\/P>Aqui está minha otimização para leitura do serviço de feição, em LAChangeDetection.fmw<\/STRONG> (no download do blog):<\/P>Gravação Direta Após Detecção de Mudança<\/span><\/span><\/P>Enquanto o pacote

   Esri ArcGIS Connector<\/A> fornece um leitor para serviço de feição, na busca por velocidade implementei a leitura do serviço alvo usando múltiplas chamadas concorrentes Query<\/A> via HTTP.  Descobri que o número máximo padrão de registros por chamada (2000<\/STRONG>) em 4 requisições concorrentes<\/STRONG> deu desempenho ótimo, aproximadamente o dobro da taxa do leitor fornecido pelo pacote.  O transformador ChangeDetector<\/A> calcula o delta em segundos assim que tem os dados, então gravar o delta leva 3-4 segundos para um conjunto típico diário de mudanças (se você inspecionar o workspace verá que eu o instrumentei com transformadores Emailer para enviar informações com timestamp).<\/P>

   Para pessoas não satisfeitas com alguns segundos de tempo de inatividade do serviço, implementar troca da fonte da visualização é apenas um pouco mais desafiador, veja LAViewSourceSwap.fmw<\/STRONG> no download do blog:<\/P>Troca da Fonte da Visualização<\/span><\/span><\/P>Você verá lógica no workspace para alternar entre os serviços "A" e "B" para leitura, gravação e troca da fonte.  Por essa razão as mudanças são detectadas um pouco diferente; a mesma URL pública acessando os dados dos endereços como CSV é lida, mas o delta é calculado versus a camada hospedada que não é a fonte atual para a visualização da camada hospedada, e o delta é aplicado nessa camada.
   
   

   Então a camada atualizada deve ser trocada para ser a fonte da visualização da camada hospedada.  Como?<\strong>
   

   A resposta requer algum trabalho investigativo, inspecionando como o ArcGIS lida nativamente com troca da fonte na configuração do item:
   

   <span class=\"lia-inline-image-display-wrapper lia-image-align-inline\" image-alt=\"View Source Swap\" style=\"width: 999px;\"><img src=\"https:\/\\/us.v-cdn.net\\/6038851\\/uploads\\/images\\/141308i85745DF3DFCD561E\\/SwapSource.png\" role=\"button\" title=\"SwapSource.png\" alt=\"View Source Swap\" /><span class=\"lia-inline-image-caption\" onclick=\"event.preventDefault();\">Troca da Fonte da Visualização</span></span>
   

   O que você está vendo acima sou eu fazendo manualmente uma troca da fonte mas com as ferramentas do desenvolvedor do navegador ativas, filtradas para registrar transações POST na visualização detalhada das requisições.
   Enquanto clicava pela troca da fonte pude ver que o sistema usa duas chamadas,

   😉.

   O payload deleteFromDefinition é trivial, mas o payload JSON addToDefinition é enorme. No entanto, como fiz meus serviços com configurações padrão que não pretendo alterar, cortei o JSON para objetos que achei importante manter e claro o ponteiro necessário para a fonte desejada. Aqui está o JSON:
   

   {

   No ambiente produtivo eu poderia editar o JSON para ajustar coisas se desejado, como extensão ou campo exibido, mas provavelmente é melhor investimento acertar seu design da camada antes dos fatos.
   

   Uma coisa chave que aprendi sobre o payload está na linha 15 onde injeto um atributo da feição no JSON em tempo real, sourceServiceName é uma propriedade que indica qual serviço está sendo trocado dentro, não há referência ao ID do item ou URL do serviço.  No meu caso o nome do serviço alterna entre "LosAngelesAddressesA" e "LosAngelesAddressesB" em execuções consecutivas.  Se alguma transação delta não contiver edições então nenhum serviço a troca ocorre.<\/P>

   Então, agora que extraímos o máximo de tempo de inatividade possível de uma atualização do serviço de feição, cabe a você decidir se o delta da transação do período médio é grande o suficiente (milhares de feições?) para justificar o custo extra de armazenamento da troca da fonte da view e o tempo mínimo garantido de inatividade.<\/P>

   Embora eu esteja focando aqui na minimização do tempo de inatividade, não no tempo total de execução do trabalho, se alguém estiver curioso, está levando de 3 a 5 minutos para atualizar o milhão de pontos com os quais estou lidando.  Eu suponho que a variabilidade vem das condições de carga do servidor de onde os dados estão vindo e para onde estão indo.<\/P>

   Agradecimentos:<\/STRONG>  Fui inspirado a escrever este post pelo meu colega da Esri @SashaLockamy<\/a> que primeiro explorou esse fluxo de trabalho, e a quem sou grato, além de algumas obras anteriores em um fluxo de trabalho relacionado onde geodatabases de arquivo são republicados, veja a primeira apresentação aqui<\/A>.<\/P>

bharold

Hello everyone.  If you downloaded the blog attachment with workspace source files before 5:45 am PDT Friday 3rd October then please do so again, I simplified the LAViewSourceSwap.fmw workspace to remove unnecessary parameters which were artifacts of development testing.