Nenhum processamento é melhor do que algum processamento?

Vamos fazer um pequeno experimento mental.

Sim, eu sei, estou pensando. Quem quer fazer isso?

Espere!

Antes que você me ignore e passe para a próxima postagem sobre índices sensuais...

Pelo menos me dê alguns minutos.

Digamos que você tenha um site.

Bem, não é qualquer site...

Isso é um pouco genérico demais.

Digamos que você tenha um site de viagens.

Um lugar onde as pessoas vão para fazer reservas de passagens aéreas.

Acho que todos nós já usamos um desses em algum momento.

Então, os usuários chegam ao seu site e querem ver quais voos estão disponíveis.

Qual é a primeira coisa que eles fazem?

Eles escrevem uma pergunta à mão?

Hoje em dia, não.

Eles provavelmente começam selecionando o local de onde querem sair.

Seu aeroporto local.

E, em seguida, eles provavelmente querem selecionar para onde querem ir.

Portanto, duas opções, ambas em aeroportos.

Você pode fazer com que eles adivinhem quais aeroportos estão por perto.

Normalmente, digito a cidade para onde preciso ir e deixo que o site descubra o aeroporto para o qual preciso voar.

Mas vamos supor que seus usuários já conheçam os aeroportos nos dois extremos da viagem.

Isso facilita nosso pequeno experimento mental.

Portanto, você precisa apresentar ao usuário uma lista de aeroportos para escolher.

Sim, será uma longa lista.

Parece que há muitos aeroportos espalhados por este grande mundo.

Apenas carregando nosso balde de amostras de viagem, temos quase 2 mil.

Cara, são muitos aeroportos!

Alguém fez muitos registros de dados...

Mas o lado bom dos aeroportos é que eles não mudam com tanta frequência.

Quero dizer, sim, estão sendo construídas novas...

E os antigos estão sendo deixados para a ruína...

Mas tudo isso acontece com o tempo.

Geralmente, se um aeroporto é abandonado, é porque um mais novo e mais brilhante foi construído.

E a construção de um novo aeroporto leva muito tempo.

Não é como se eles estivessem jogando-os para cima todos os dias.

Então, de volta à nossa lista de aeroportos...

Longo ou não, você terá que fornecer algum tipo de lista de aeroportos para o usuário escolher.

E se o seu site for muito movimentado, pode haver muitos usuários.

E todos nós queremos que nossos sites sejam movimentados.

Portanto, vamos supor que nosso site não esteja apenas ocupado...

É muito movimentado.

Milhões de usuários todos os dias.

Milhares de usuários a cada minuto.

São muitas as vezes em que você tem de apresentar essa lista de aeroportos!

Então, vamos começar supondo que os documentos do aeroporto no seu bucket do Couchbase estejam estruturados como os do nosso bucket de amostra de viagem.

Ei, ele vem com nosso produto Couchbase Server, então é melhor usá-lo!

Facilita as coisas...

Portanto, basta listar os aeroportos usando uma consulta N1QL simples:

Nos dá isso:

Não vai ser fácil encontrar o que nossos usuários precisam nisso. Talvez se classificarmos de acordo com o código do aeroporto da FAA e depois eliminarmos aqueles em que o código é nulo...

Isso é melhor, mas são mais dados do que precisamos fornecer ao site.

Portanto, vamos reduzir o que estamos retornando para o código FAA, o nome do aeroporto, a cidade e o país:

Ok, agora estamos indo para o que estamos procurando.

Portanto, se consultarmos isso, obteremos, digamos, um tempo de resposta de 50 a 60 ms.

Nada mal.

Mas com milhares de solicitações dessa lista a cada minuto...

Talvez possamos acelerar um pouco as coisas.

Vamos transformá-la em uma consulta coberta adicionando nosso próprio índice que inclui tudo o que precisamos.

E agora executamos novamente a consulta e obtemos um tempo de resposta de cerca de 17,5 ms.

Muito melhor.

Mas é possível fazer ainda melhor do que isso?

Ou seja, essa lista será solicitada milhares de vezes a cada minuto.

Esses milissegundos vão se acumular.

Então, e se pegássemos os resultados dessa consulta e os salvássemos como um único documento?

Vamos chamá-lo de "airport_list".

Portanto, agora, se executarmos uma consulta selecionando todo o documento com a cláusula "USE KEYS":

Isso nos dá um tempo de resposta em torno de 14,5 ms.

Hmm, economizei mais 3 milissegundos inteiros!

E podemos economizar mais meio milissegundo ou dois se usarmos o acesso de valor-chave e obtivermos o documento por sua ID diretamente do serviço de dados.

Para um documento que precisa ser servido milhares de vezes por minuto.

Milhões de vezes por dia.

Esses milissegundos vão se acumular.

Sim, eu sei. Os aeroportos mudam de tempos em tempos.

Sim, mas eles não mudam com muita frequência.

Sim, esse documento precisará ser substituído de tempos em tempos.

Mas essa é uma operação que não está atendendo a um site de alta atividade.

Portanto, não importa o quão lento (comparativamente) esse processo possa ser.

Além disso, não preciso mais do meu índice de cobertura!

Posso economizar um pouco de espaço em meu servidor de índice!

Uau! Bônus!

Sim, eu sei. Eu me empolgo com algumas coisas estranhas...

OK, esse foi um exercício para reduzir o tempo de resposta em milissegundos. E quanto a uma consulta que demora um pouco mais e faz mais?

Digamos que você administre um call center e seja importante acompanhar a rapidez com que sua equipe atende às chamadas recebidas...

OK, vamos ser um pouco mais específicos.

Digamos que você queira ter um painel que mostre quantas chamadas foram atendidas em cinco segundos, dez segundos e o número total de chamadas recebidas hoje.

Algo como...

Assim, você começa com um índice nas propriedades startTime e callType, limitando-o a documentos do tipo "cdr", e descobre que leva cerca de um segundo para executar essa consulta.

E essa não é a única consulta que você deseja usar para preencher seu painel...

Ugh, isso vai ser tão lento quanto melaço!

OK, então vamos criar um novo índice com todas as propriedades nele, transformando-o em uma consulta coberta, apenas para descobrir que, embora tenha melhorado, ainda leva cerca de 100 milissegundos.

Ei, isso é uma melhoria de 10 vezes! Isso é ótimo, não é?

Só que o seu painel de controle ainda se atualiza como se estivesse funcionando em um ritmo lento.

Melaço fino e aguado, mas ainda assim...

O que podemos fazer para melhorar isso?

E se, em vez de usar essa consulta para alimentar o painel, pegarmos a saída e a usarmos para criar um novo documento apenas com os resultados?

Algo com um nome conhecido, como call_stats_...

E podemos executar essa consulta em um cronômetro, usando um cron job, ou acioná-la usando o serviço Couchbase Eventing.

Somente se acionarmos o serviço Eventing, provavelmente queremos executá-lo com uma consistência de varredura de pelo menos at_plus para incluir a atualização do documento que você está usando para acionar a consulta.

Mas agora, quando recuperamos o documento de resultado, estamos obtendo tempos de resposta na faixa de um dígito de milissegundos, o que representa uma melhoria de 1000 vezes no desempenho!

E agora temos um painel responsivo!

WOO-HOO!!!

Agora estamos falando de velocidade de turbo-booster!

Então, qual é a lição desses dois cenários?

Bem, ao pegar qualquer processamento que precisássemos fazer nos dados e torná-los tarefas em segundo plano, de modo que nossas solicitações de dados interativos não envolvam processamento, tornamos as coisas muito rápidas...

Estamos falando de uma velocidade maior que a de uma bala!

Desculpe-nos, Super-Homem, estamos passando...

Então, esse experimento mental foi realmente tão doloroso?

Agora vamos aos índices sensuais...

Couchbase, capacitando os nerds de dados em todos os lugares...

(Ei, Peter, acho que já tenho nosso novo slogan!)