Fala Radizeiros e Radizeiras, tudo bem com vocês?
Por quanto tempo você tem utilizado um banco de dados relacional?
Você já teve algumas dificuldades na sua utilização, e na performance dos seus bancos de dados relacionais?
Creio que em algum momento no decorrer do uso dos bancos de dados relacionais, você possa ter se deparado com algum problema.
E quando não detemos um conhecimento considerável em relação aos bancos de dados, realmente isso se torna custoso.
E por muitas vezes seus clientes podem ter questionado sobre a demora na geração de um relatório, o arquivo SPED, dentre outros.
E em termos de buscas, e até mesmo escalabilidade, atualmente os bancos relacionais não tem nos atendido muito bem.
E com a gama de dados que existem, isso é impossível de ser escalável.
É neste momento que entram bancos de dados NoSQL, e dentre outros, orientados a documentos.
E como estamos falando do elastic, temos grande evolução na sua usabilidade.
Eu possuo um banco de dados relacional com uma quantidade considerável de registros em uma tabela.
E já fiz um ETL desses dados para dentro do elastic, ou seja, eu fiz um processo de transformação dos dados.
Peguei as notas que estão no banco de dados relacional, onde eu fiz um SQL juntando as notas e os itens, para criar um documento JSON, para ser persistido no elastic.
Dentro do elastic eu possuo um documento, dentro de source, onde eu tenho todos os principais dados de uma nota, e dentro desta nota ela possui um array de json, que seria os itens.
Cada documento json desse tem os dados principais da nota, e cada item da nota, com os dados que eu julguei serem relevantes.
Num total de 366825 notas.
Se observarmos dentro do elast, nos seus registros, a quantidade de notas.
Todas as notas foram importadas para dentro desse documento chamado passaporte.
Tudo para que possam fazer algumas consultas.
Vamos ao banco de dados relacional, onde irei executar um SQL, que irá me retornar a quantidade de registros da tabela item da nota, onde a descrição do produto contém a palavra filtro.
SELECT
COUNT(*)
FROM
ITENS_NOTA
WHERE
UPPER(DESCRICAO) LIKE UPPER('%%FILTRO%%')
Essa busca será feita naqueles mais de um milhão de registros mostrados anteriormente para você.
Esse total para nós é irrelevante, como nós fizemos um ETL, o total irá dar diferente lá no elastic.
Essa diferença irá ocorrer porque juntamos todas as notas, e seus respectivos itens num documento só.
Mas o importante é o seguinte, para executar esse SQL, o banco de dados relacional demorou 5 segundos.
Então vamos fazer essa mesma consulta no elastic.
Nessa nossa query no elastic, estamos realizando uma busca, como os itens estão dentro de um array, para fazer uma busca basta colocar ITENS.DESCRICAO_PRODUTO.
Dessa forma ele irá buscar dentro desse array de itens, no campo descrição do produto, que contém a palavra filtro.
Observe que no elasti ele demorou 69 milisegundo.
Ele trouxe todas as notas, que contenham a palavra filtro dentro do campo de descrição.
Observe que saímos de 5s para fazer uma busca dessa com o like, para 69 milisegundos.
Muito show não é verdade?
O Firebird tem uma coisa muito legal, ele vai melhorando conforme você usa, mas ele melhora a performance.
Cada vez que você vier fazer esse select, ele guarda no cache para utilizar essas buscar.
A tendência é que a cada vez que realizarmos essas buscas ele melhore seu desempenho.
Mesmo assim não chega perto do tempo de resposta do elastic.
Agora iremos aumentar um nível de consulta.
SELECT
COUNT(*)
FROM
ITENS_NOTA
WHERE
UPPER(DESCRICAO_PRODUTO) LIKE UPPER('%%FILTRO%%')
OR UPPER(DESCRICAO_PRODUTO) LIKE UPPER('%%ANEL%%')
Observe que eu quero que ele traga todos os produtos que contenha filtro na sua descrição, ou que contenha anel na sua descrição.
Observe que ele teve uma demora de 8 segundos para me retornar o resultado, de uma pesquisa com mais de um milhão de registros.
Agora para que possamos ver o desempenho do uso no elastic iremos executar esse comando json para que ele possa realizar a mesma pesquisa que fizemos no banco de dados relacional.
Observe que adicionamos algumas palavras, que são particularidades do elastic, mas não iremos entrar nisso nesse momento.
A palavra must é basicamente a mesma coisa que o or da query do banco de dados relacional.
Nesse caso estamos fazendo uma busca que me retorne uma condição verdadeira, onde a descrição do produto tenha filtro ou que tenha anel.
Viu como é muito mais rápido?
De 8 segundos, temos a mesma pesquisa, sendo que no elastic, um tempo de resposta de 77 milissegundos.
Olha como é a performance do elastic, é impressionante.
É muito mais rápido você trabalhar com elastic do que com um banco de dados relacional para fazer esse processo de busca dentro de sua aplicação.
Principalmente as rotinas de BI.
Para que hoje você tenha um tempo de resposta nas suas aplicações, e seus clientes tenham maior assertividade, é importante o uso do elastic.
E caso você tenha interesse de conhecer mais sobre Elasticsearch no Delphi acesse o nosso portal do CLUBE DE PROGRAMADORES EM DELPHI, onde você não terá só conteúdos relacionados ao Elasticsearch, mas uma quantidade enorme de conteúdos que poderá lhe ajudar muito no seu dia a dia, é uma verdadeira NETFLIX para os programadores Delphi.
CLIQUE AQUI E SAIBA MAIS SOBRE O CLUBE DOS PROGRAMADORES DELPHI
