Site com dicas e tutoriais de Banco de dados e outras tecnologias interligadas

Arquivos mensais: agosto 2018

X-Pack: Ativando a autenticação básica no ElasticSearch e Kibana

Postado em por Publicado em BigData, Devops, ElasticSearch, NOSQL Deixe um comentário

Antes de rolarem as reclamações, algumas considerações sobre esse artigo:

  • O modelo de configuração usado aqui não funciona na versão 6.3.2, por isso fiz esse tutorial na versão 6.2.4, portanto, se você fez os tutoriais anteriores, só reconstrua na versão 6.2.4. 
  • O X-Pack e todos os seus módulos, inclusive segurança, são pagos, para rodar esse tutorial temos um trial de 1 mês, mas o X-Pack basicamente está incluso em um contrato de suporte que pode ser Gold ou Platinum, depende de suas necessidades.

X-Pack Overview:

O X-pack é um conjunto de plugins providos pela Elastic que contemplam os seguintes serviços:

  • Segurança – Todo o esquema de autenticação e politicas de segurança estão contidas nesse pacote, como TSL, Filtros por IP ACL e outras.
  • Alertas – Todo o tipo de alertas ou tresholds podem ser encontrados nesse plugin, alertando desde acessos indevidos aos alertas de utilização.
  • Graph – Faz um contexto muito parecido com o Node4J que alem de ser um database gráfico, faz ligações prováveis entre os dados.
  • Reporting – Traz a possibilidade de gerarmos relatórios sobre qualquer tipo de coisa no ElasticSearch.
  • Machine Learning – O Kibana mostra na tela inicial opções de Machine Learning.

Diferenças das versões:

Principais diferenças entre as versões do X-Pack novo (6.3.2):

  • O X-Pack já vem junto com a instalação, não é necessário instalar o Plugin.
  • O Modulo security fica disabled (na realidade nem vai ter entrada no elasticsearch.yaml), sendo assim seria necessário configurá-lo
  • O comando de definição de senhas padrões não é feito via /elasticsearch/bin/x-pack/setup-passwords e sim via /elasticsearch/bin/elastic-search/setup-passwords
  • Mesmo que você suba o X-Pack nessa versão o trial não estará habilitado, vai constar como que não existe x-pack.

Sendo assim, nesse tutorial, para fins didáticos, vamos usar a versão 6.2.4 e caso você tenha duvida de como baixar, segue o vídeo abaixo:

Instalando o X-Pack:

Vamos fazer a instalação do X-Pack nos 2 serviços nossos, no ElasticSearch e o no Kibana, vamos começar pelo ElasticSearch:

O X-Pack é uma feature paga do ElasticSearch, adquirindo o suporte Gold ou Platinum, você pode fazer uso da ferramenta, houveram algumas alterações quanto ao uso do Trial, eu fiz minha instalação padrão na versão 6.3.2 e alguns comandos que rodei nesse tutorial foram descontinuados e substituídos, voltei para a versão 6.2.4, o protocolo de instalação segue o mesmo, sugiro que você refaça a instalação para esse tutorial.

Instalando o X-Pack no ElasticSearch:

Dentro do diretorio bin, do ElasticSearch, temos o executável do ES, mas tambem temos um outro chamado elasticsearch-plugin (no meu caso que é Linux), caso você esteja usando windows use o .bat

/elasticsearch/bin/elasticsearch-plugin install x-pack

Concorde com as opções de y/n e siga a instalação.

Conforme dito anteriormente, caso você esteja usando a versão 6.3.2 (mais recente no momento), vai rolar uma mensagem assim:

[email protected]  /elasticsearch/bin  /elasticsearch/bin/elasticsearch-plugin install x-pack
ERROR: this distribution of Elasticsearch contains X-Pack by default

Alterando as senhas padrão:

Como ativamos o X-Pack, vamos agora alterar as senhas, lembrando que estamos usando a versão 6.2.4 vamos usar o seguinte comando:

/elasticsearch/bin/x-pack/setup-passwords interactive

Concordamos dando yes e vamos definir as senhas dos seguintes users:

  • elastic
  • kibana
  • logstash_system

Eu atribui para que ficasse mais simples a senha “elastic”
OBS: Como esses users estão armazenados em indexes padrão do ElasticSearch as senhas ficam armazenadas neles, vamos supor que posteriormente adicionemos um novo node no cluster, por sua vez, os indices serão replicados e essas senhas vão para os novos nodes tambem.

Instalando o X-Pack no Kibana:

Assim como o ElasticSearch vou baixar uma versão anterior do Kibana para que eu possa realizar a configuração do Plugin X-Pack, no meu caso usarei a versão 6.2.4 também do Kibana, a instalação segue a mesma dos tutoriais anteriores.

Rodamos então após instalado o comando abaixo:

/kibana/bin/kibana-plugin install x-pack

OBS: Lembrando que se estiver usando a versão 6.3.2 (mais recente) vai tomar a mensagem abaixo, recomendo usar essa versão do tutorial.

/kibana/bin/kibana-plugin install x-pack
Plugin installation was unsuccessful due to error "Kibana now contains X-Pack by default, there is no longer any need to install it as it is already present."

Falta um passo na configuração ainda para startarmos o Kibana, precisamos ir no /kibana/config/kibana.yml e configurar o user e senha do elasticsearch lá, pois nossa senha do Kibana está em um indice la dentro certo? Então fazemo a busca por 2 parâmetros e alteramos (tiramos os comentários do inicio da linha inclusive):

  • elasticsearch.username: “elastic”
  • elasticsearch.password: “elastic”

Feito isso basta iniciar o Kibana e posteriormente acessá-lo via navegador:

Iniciando o Kibana:

/kibana/bin/kibana

Acessando via Navegador (note que já vai pedir autenticação)

http://localhost:5601

Logue com a senha que configuramos:

  • User: Kibana
  • Senha: Elastic

OBS: Note que depois de autenticado, comparando com a nossa ultima configuração sem o X-Pack ativo, não tínhamos na lateral esquerda da tela inicial os campos:

  • Machine Learning
  • Graph

Que são módulos que vem junto com o X-Pack!

Bom nesse tutorial é isso, nos próximos explico como criar Roles, usuários e limitar acessos tanto do Cluster como dos Index, documentos e campos.

Até o pŕóximo.

Anselmo Borges

Brincando com o ElasticSearch (Lab)

Postado em por Publicado em BigData, Devops, ElasticSearch, Linux, NOSQL Deixe um comentário
Lab de ELK – Fazendo ingestão de dados via Logstash

Finalmente o último artigo da série, nesse vamos fazer os esperados Dashboards do Kibana e fazer a ingestão de dados via Logstash. 

Com o Logstash na parada temos o chamado ELK, combo de ferramentas da Elastic que são compostos por ElasticSearch + Logstash + Kibana. Fiz a divisão desse Lab em 3 vídeos:

  • Vídeo 1: Instalação do Logstash + Download dos datasets + Arquivo de configuração do Logstash 
  • Vídeo 2: Ingestão de dados via logstash e acompanhamento via Dev Tools.
  • Vídeo 3: Criação de Dashboards no Kibana

Instalação do Logstash:

O Logstash ferramenta da própria Elastic que faz uma camada entre a aplicação e o ElasticSearch, essas aplicações geram logs e o Logstash faz a ingestão de dados dentro da ferramenta de pesquisa que é o ElasticSearch e esses dados podem ser colhidos em tempo real. Vamos fazer a instalação do Logstash, a mesma para esses testes, se baseiam nos mesmos modelos do ElasticSearch e Kibana.

Download Logstash:

Vamos entrar no site do Logstash e fazer o download do arquivo tar.

https://www.elastic.co/downloads/logstash
Download Logstash
No meu caso como tenho um Ubuntu estou baixando um tar.gz

Se você estiver usando um Linux, pode rodar o comando abaixo também:

wget https://artifacts.elastic.co/downloads/logstash/logstash-6.3.2.tar.gz

Descompactamos o arquivo abaixo e renomeamos pra logstash, no meu caso movimentei pro / e dei privilégios pro meu usuário como você pode ver no vídeo, faça como achar melhor.

tar zfxv logstash-6.3.2.tar.gz
mv logstash-6.3.2 logstash

Diferente dos outros serviços precisamos de um logstash.config para startarmos o serviço, alias para cada serviço no ar, como faremos um lab com alguns dados já deixei o arquivo pronto no git para download.

wget https://github.com/AnselmoDBA/elasticsearch/blob/master/logstash-cars.config

O conteúdo desse arquivo é dividido em 3 partes básicas:

  • input: Onde coloco de onde o Logstash vai ler o arquivo, no caso do exemplo apontei pro local onde disponibilizei o arquivo csv.
  • filter: Onde especifico o tipo de arquivo de estou usando, no caso do exemplo csv, mas poderia ser um xml, json, syslog, log do apache, o lance é ter algum tipo de separador, os tipos de arquivos suportados estão na documentação do Logstash. Nesse arquivo coloco também as colunas e o tipo de separador, no nosso caso a “,”, podemos realizar o mapping, pois por padrão ele importa tudo como text, mas podemos forçar a importação de alguns campos como integer ou float como faremos no LAB.
  • output: Pra onde vou jogar os meus arquivos, no nosso caso pra um ElasticSearch e localhost, pois subimos na nossa maquina. Também configuramos o nome do index que vamos criar lá e o type.

Segue o mesmo abaixo:

file {

path => "/home/anselmoborges/data/cars.csv"
start_position => "beginning"
sincedb_path => "/dev/null"

}

}

filter {
csv {
separator => ","

columns => ['maker', 'model', 'mileage', 'manufacture_year', 'engine_displacement', 'engine_power', 'body_type', 'color_slug', 'stk_year', 'transmission', 'door_count', 'seat_count', 'fuel_type', 'date_created', 'date_last_seen', 'price_eur'] 

}

mutate {convert => ["mileage", "integer"]}
mutate {convert => ["price_eur", "integer"]}
mutate {convert => ["engine_power", "integer"]}
mutate {convert => ["door_count", "integer"]}
mutate {convert => ["seat_count", "integer"]}

}
output {
	elasticsearch {
		hosts => "localhost"
		index => "cars"
		document_type => "sold_cars"
	}
	stdout {}

}

Sendo assim já temos nosso arquivo de configuração mas não temos nosso “cars.csv”.

Baixando o Dataset:

Vamos fazer o download do nosso dataset, conheci no curso um site chamado Kaggle.com que possui uma longa lista de datasets que podem ser usados para vários exemplos tanto para ElasticSearch como em outros bancos. Para nosso exemplo vamos baixar esse aqui.

https://www.kaggle.com/mirosval/personal-cars-classifieds
Baixe o Dataset cars no link acima

Depois do download feito, recomendo que seja disposto em um diretório chamado data no home de seu usuário renomeado para cars.csv, o arquivo de configuração também.

Segue abaixo o vídeo dessa primeira etapa:

Instalando o Logstash, baixando o arquivo de configuração e o dataset

Fazendo a ingestão dos dados no ElasticSearch

Bom, temos o Logstash, o arquivo de configuração e o Dataset, vamos iniciar a ingestão dos dados. Para iniciarmos o processo rodamos o comando abaixo:

/logstash/bin/logstash -f /caminho/do/arquivo/de/configuracao/logstash_cars.config

Demora um pouquinho para iniciar, mas quando começar a gerar logs na tela você vai acompanhando até iniciar a ingestão dos dados, quando iniciar, você pode acompanhar fazendo um count no index cars, com o comando abaixo no Dev tools do Kibana:

get cars/_count

Vai dando play e você vai ver o numero crescendo.

Segue o vídeo dessa segunda parte:

Fazendo a ingestão dos dados via Logstash

Gerando Gráficos e criando um Dashboard com atualização em tempo real.

Bom agora chegamos na parte que o chefe gosta de ver, gráficos! Já vamos notar que conforme a ingestão ocorre os gráficos vão sendo atualizados em tempo real e isso é muito legal. 

Tem uma parte que não foi passada nos vídeos e vou ter que passar aqui via print, quando criamos o index no ElasticSearch, temos meio que configurá-lo no Kibana também, sem isso não conseguimos enxerga-lo na criação dos Dashboards, o procedimento segue abaixo com o index “cadastro” que criei para esse exemplo (faça o mesmo com o “cars” rs).

Clique em Management > Kibana > Index Pattens

Na tela principal clique em Management

Lá em cima clique em “Create Index Pattern”.

Criando index

Adicionei “cadastro” mas no seu caso adicione “cars” e clique em Next.

Encontre seu index e clique em next step

Não vamos criar nada avançado então só clicamos em “create”.

Feito isso, seu index está ativado no Kibana para configuração dos Dashboards:

Bom, feito isso basta configurarmos nossos Dashboards, fiz alguns no vídeo abaixo, tendo uma primeira noção de como cria-los, use sua criatividade e manda bala.

Criando Dashboards no Kibana

Bom por enquanto é isso, explore bem essa ferramenta pois ela me surpreendeu bastante, trazendo um nível bem considerável de opções pro dia a dia.

Espero que tenha ajudado, foi de coração, rs!

Anselmo Borges

Brincando com o ElasticSearch (Parte 6: Aggregations)

Postado em por Publicado em BigData, Devops, Dicas, Dicas Linux, ElasticSearch, Linux, NOSQL Deixe um comentário
Comparando com SQL: Group by, Order by, Max, Min, AVG é nesse artigo! rs

Tá acabando cara, calma, não é só você que não vê a hora disso acabar, rs. N Tem esse e mais um artigo que vai explicar como usar isso junto com o Logstash, vai ser bem legal cara! Confie! Você vai ganhar dinheiro com isso, rs!

Só te animando achei esses exemplos os mais divertidos e fáceis de fazer, tem uma comparação bem real com SQL então você DBA enferrujado que nem eu vai tirar de letra! Só que vamos começar com uma dica, como realizar um processo de BULK no ElasticSearch.

Processo de BULK:

Esse é um processo importante do ElasticSearch que devemos aprender caso queiram realizar a criação de um índice inserindo um grande volume de dados de uma única vez. Nesse exemplo vamos criar o index “vehicles”, segue o link abaixo para download desse bulk no git:

wget https://github.com/AnselmoDBA/elasticsearch/blob/master/vehicles.dsl

Note que no início desse arquivo a linha POST tem o parâmetro _bulk, que não tínhamos visto antes:

POST /vehicles/cars/_bulk

Em conjunto com esse parâmetro fazemos a inserção linha a linha dos dados que estamos cadastrando no index em um único comando, sendo assim, as linhas ficam da seguinte forma:

{ "index": {}}
{ "price" : 10000, "color" : "white", "make" : "honda", "sold" : "2016-10-28", "condition": "okay"}

A primeira linha index, é sempre padrão: { “index”: {}}
Já a segunda linha é basicamente, chave : valor, chave : valor, e assim vai.

Isso é ideal para grandes carregamentos de arquivos, para os nossos exemplos, crie o índice com o script indicado.

Limitando os resultados (LIMIT)

Nessa parte vamos ver como criar sitaxes como limit (limita o numero de registros exibidos numa query) e ordenar os dados tipo ORDER BY e ORDER BY DESC, vamos começar com o LIMIT:

Vamos supor que assim como esse bulk do index vehicles que criamos nós tenhamos mais do que 10 registros, por padrão quando fazemos uma busca match_all ou outras, caso existam mais de 10 registros no Kibana ele exibe só 10, então podemos usar o parâmetro “size” para limitar o numero de registros e se necessário o “from” em conjunto com ele para limitar onde começa e termina os registros, veja os exemplos abaixo:

Exibindo 13 registros da busca

get /vehicles/cars/_search
{
	"size": 13,

	"query": {
	  "match_all": {}
	}
}

Exibindo somente 5 registros que vão do primeiro ao 5o.

get /vehicles/cars/_search
{
	"from": 0,
	"size": 5,

	"query": {
	  "match_all": {}
	}
}

Agora vamos ver como ordenar os dados extraídos assim como um order by no SQL, as ordens de ASC e DESC são as mesmas, portanto lembre que o padrão é ascendente, nesse exemplo estamos ordenando os preços dos carros do maior para o menor:

Realizando um COUNT:

Você já percebeu que sempre que fazemos uma busca, no argumento total, já vem o numero de registros que o ElasticSearch trás, porem nós usamos o _search na primeira linha, nesse exemplo, vamos fazer um count com o numero de veículos que são da marca Dodge:

get /vehicles/cars/_count
{
  "query": {
    "match":{"make" : "dodge"}
  }
}

--- Resultado:
{
  "count": 5,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  }
}

Realizando um MAX, MIN, AVG e um GROUP BY:

Nesse exemplo vamos trazer os seguintes dados:

  • Contagem veículos por marca
  • Valor médio desses veículos separados por marca
  • Preço máximo desses veículos separados por marca
  • Preço mínimo desses veículos separados por marca

Com essas consultas vamos ver como realizar MIN (Valor minimo), MAX (Valor máximo) e AVG (Média), lembrando que estamos fazendo uma analogia com SQL mas é muito parecido, veja a consulta abaixo:

get /vehicles/cars/_search
{
    "aggs":{
      "carros_populares": {
        "terms": {
          "field": "make.keyword"
        },
        "aggs": {
          "preco_medio": {
            "avg": {
              "field": "price"
            }
          },
          "preco_max": {
            "max": {
              "field": "price"
            }
          },
          "preco_min": {
            "min": {
              "field": "price"
            }
          }
          }
        }
      }
  }
}

Em resumo usamos o comando “aggs” o qual faz o agrupamento, onde o primeiro separou os tipos de veiculos por marca, dentro desse primeiro grupo, estamos criando outras 3 métricas, preco_medio (avg), preco_max(max) e preco_min(min), indo no resultado esses agrupamentos sempre ficam no final do resultado, no Kibana quando minimizamos o campo hits, o próximo é aggregations onde podemos ver nossos agrupamentos segue abaixo os exemplos:

"aggregations": {
    "carros_populares": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "dodge",
          "doc_count": 5,
          "preco_max": {
            "value": 35000
          },
          "preco_medio": {
            "value": 18900
          },
          "preco_min": {
            "value": 10000
          }
        },
        {
          "key": "chevrolet",
          "doc_count": 3,
          "preco_max": {
            "value": 28000
          },
          "preco_medio": {
            "value": 20333.333333333332
          },
          "preco_min": {
            "value": 13000
          }
        },
        {
          "key": "bmw",
          "doc_count": 2,
          "preco_max": {
            "value": 80000
          },
          "preco_medio": {
            "value": 55000
          },
          "preco_min": {
            "value": 30000
          }
        },
        {
          "key": "ford",
          "doc_count": 2,
          "preco_max": {
            "value": 30000
          },
          "preco_medio": {
            "value": 27500
          },
          "preco_min": {
            "value": 25000
          }
        },
        {
          "key": "honda",
          "doc_count": 2,
          "preco_max": {
            "value": 20000
          },
          "preco_medio": {
            "value": 15000
          },
          "preco_min": {
            "value": 10000
          }
        },
        {
          "key": "toyota",
          "doc_count": 2,
          "preco_max": {
            "value": 15000
          },
          "preco_medio": {
            "value": 13500
          },
          "preco_min": {
            "value": 12000
          }
        }
      ]
    }
  }
}

Agora como último exemplo, vamos fazer uma query e com base nelas criar esses agrupamentos, nesse nosso exemplo ele está pegando essas métricas de todos os registros, vamos limitar isso somente aos carros de cor vermelha, só para que não venham os dados e sim somente os cálculos vamos usar a clausula “size” igual a 0, sendo assim só teremos as médias e outros valores:

get /vehicles/cars/_search
{
  "size":0,
  "query":{
    "match":{"color": "red"}
  },
    "aggs":{
      "carros_populares": {
        "terms": {
          "field": "make.keyword"
        },
        "aggs": {
          "preco_medio": {
            "avg": {
              "field": "price"
            }
          },
          "preco_max": {
            "max": {
              "field": "price"
            }
          },
          "preco_min": {
            "min": {
              "field": "price"
            }
          }
          }
        }
      }
  }
}

Ao invés de 16 veículos temos somente 5, os quais são agrupados e calculados conforme a consulta:

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 5,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "carros_populares": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "dodge",
          "doc_count": 3,
          "preco_max": {
            "value": 35000
          },
          "preco_medio": {
            "value": 24000
          },
          "preco_min": {
            "value": 18000
          }
        },
        {
          "key": "bmw",
          "doc_count": 1,
          "preco_max": {
            "value": 80000
          },
          "preco_medio": {
            "value": 80000
          },
          "preco_min": {
            "value": 80000
          }
        },
        {
          "key": "chevrolet",
          "doc_count": 1,
          "preco_max": {
            "value": 20000
          },
          "preco_medio": {
            "value": 20000
          },
          "preco_min": {
            "value": 20000
          }
        }
      ]
    }
  }
}

Trazendo tudo isso de uma vez (STATS):

Sacaneando você que fez um por um, existe um comando no ElasticSearch que traz todas essas métricas de uma vez, esse comando é o stats, vamos eliminar todos os argumentos desde a média e vamos usar um único comando:

get /vehicles/cars/_search
{
  "size":0,
  "query":{
    "match":{"color": "red"}
  },
    "aggs":{
      "carros_populares": {
        "terms": {
          "field": "make.keyword"
        },
        "aggs": {
          "dados_dos_precos": {
            "stats": {
              "field": "price"
            }
          }
          }
          }
        }
      }
  }
}

Observe agora todos os dados no relatório final (MAX, MIN, AVG, SUM):

{
  "took": 77,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 5,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "carros_populares": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "dodge",
          "doc_count": 3,
          "dados_dos_precos": {
            "count": 3,
            "min": 18000,
            "max": 35000,
            "avg": 24000,
            "sum": 72000
          }
        },
        {
          "key": "bmw",
          "doc_count": 1,
          "dados_dos_precos": {
            "count": 1,
            "min": 80000,
            "max": 80000,
            "avg": 80000,
            "sum": 80000
          }
        },
        {
          "key": "chevrolet",
          "doc_count": 1,
          "dados_dos_precos": {
            "count": 1,
            "min": 20000,
            "max": 20000,
            "avg": 20000,
            "sum": 20000
          }
        }
      ]
    }
  }
}

Criando agrupamentos por Range:

Vimos nos artigos anteriores o comando range e vamos usa-lo também para a criação de argumentos, nesse exemplo vamos fazer uma separação do numero de vendas dentro de 2 períodos:

  • Periodo 1: 2016-01-01 até 2016-05-18
  • Periodo 2: 2016-05-18 até 2017-01-01

Vamos fazer esses ranges contabilizando pelo campo sold, sendo assim:

get /vehicles/cars/_search
{
  "size":0,

    "aggs":{
      "carros_populares": {
        "terms": {
          "field": "make.keyword"
        },
        "aggs": {
          "vendidos_por_periodo": {
            "range": {
              "field": "sold",
              "ranges": [
              	{
              	 "from": "2016-01-01", "to": "2016-05-18"
              	},
              	{
              	 "from": "2016-05-18", "to": "2017-01-01"
              	}
              ]
            }
          }
          }
          }
        }
      }
  }
}

De todos os veículos que temos cadastrados, seguem as métricas tiradas:

{
  "took": 4,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 16,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "carros_populares": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "dodge",
          "doc_count": 5,
          "vendidos_por_periodo": {
            "buckets": [
              {
                "key": "2016-01-01T00:00:00.000Z-2016-05-18T00:00:00.000Z",
                "from": 1451606400000,
                "from_as_string": "2016-01-01T00:00:00.000Z",
                "to": 1463529600000,
                "to_as_string": "2016-05-18T00:00:00.000Z",
                "doc_count": 4
              },
              {
                "key": "2016-05-18T00:00:00.000Z-2017-01-01T00:00:00.000Z",
                "from": 1463529600000,
                "from_as_string": "2016-05-18T00:00:00.000Z",
                "to": 1483228800000,
                "to_as_string": "2017-01-01T00:00:00.000Z",
                "doc_count": 1
              }
            ]
          }
        },
        {
          "key": "chevrolet",
          "doc_count": 3,
          "vendidos_por_periodo": {
            "buckets": [
              {
                "key": "2016-01-01T00:00:00.000Z-2016-05-18T00:00:00.000Z",
                "from": 1451606400000,
                "from_as_string": "2016-01-01T00:00:00.000Z",
                "to": 1463529600000,
                "to_as_string": "2016-05-18T00:00:00.000Z",
                "doc_count": 0
              },
              {
                "key": "2016-05-18T00:00:00.000Z-2017-01-01T00:00:00.000Z",
                "from": 1463529600000,
                "from_as_string": "2016-05-18T00:00:00.000Z",
                "to": 1483228800000,
                "to_as_string": "2017-01-01T00:00:00.000Z",
                "doc_count": 3
              }
            ]
          }
        },
        {
          "key": "bmw",
          "doc_count": 2,
          "vendidos_por_periodo": {
            "buckets": [
              {
                "key": "2016-01-01T00:00:00.000Z-2016-05-18T00:00:00.000Z",
                "from": 1451606400000,
                "from_as_string": "2016-01-01T00:00:00.000Z",
                "to": 1463529600000,
                "to_as_string": "2016-05-18T00:00:00.000Z",
                "doc_count": 1
              },
              {
                "key": "2016-05-18T00:00:00.000Z-2017-01-01T00:00:00.000Z",
                "from": 1463529600000,
                "from_as_string": "2016-05-18T00:00:00.000Z",
                "to": 1483228800000,
                "to_as_string": "2017-01-01T00:00:00.000Z",
                "doc_count": 1
              }
            ]
          }
        },
        {
          "key": "ford",
          "doc_count": 2,
          "vendidos_por_periodo": {
            "buckets": [
              {
                "key": "2016-01-01T00:00:00.000Z-2016-05-18T00:00:00.000Z",
                "from": 1451606400000,
                "from_as_string": "2016-01-01T00:00:00.000Z",
                "to": 1463529600000,
                "to_as_string": "2016-05-18T00:00:00.000Z",
                "doc_count": 0
              },
              {
                "key": "2016-05-18T00:00:00.000Z-2017-01-01T00:00:00.000Z",
                "from": 1463529600000,
                "from_as_string": "2016-05-18T00:00:00.000Z",
                "to": 1483228800000,
                "to_as_string": "2017-01-01T00:00:00.000Z",
                "doc_count": 2
              }
            ]
          }
        },
        {
          "key": "honda",
          "doc_count": 2,
          "vendidos_por_periodo": {
            "buckets": [
              {
                "key": "2016-01-01T00:00:00.000Z-2016-05-18T00:00:00.000Z",
                "from": 1451606400000,
                "from_as_string": "2016-01-01T00:00:00.000Z",
                "to": 1463529600000,
                "to_as_string": "2016-05-18T00:00:00.000Z",
                "doc_count": 0
              },
              {
                "key": "2016-05-18T00:00:00.000Z-2017-01-01T00:00:00.000Z",
                "from": 1463529600000,
                "from_as_string": "2016-05-18T00:00:00.000Z",
                "to": 1483228800000,
                "to_as_string": "2017-01-01T00:00:00.000Z",
                "doc_count": 2
              }
            ]
          }
        },
        {
          "key": "toyota",
          "doc_count": 2,
          "vendidos_por_periodo": {
            "buckets": [
              {
                "key": "2016-01-01T00:00:00.000Z-2016-05-18T00:00:00.000Z",
                "from": 1451606400000,
                "from_as_string": "2016-01-01T00:00:00.000Z",
                "to": 1463529600000,
                "to_as_string": "2016-05-18T00:00:00.000Z",
                "doc_count": 0
              },
              {
                "key": "2016-05-18T00:00:00.000Z-2017-01-01T00:00:00.000Z",
                "from": 1463529600000,
                "from_as_string": "2016-05-18T00:00:00.000Z",
                "to": 1483228800000,
                "to_as_string": "2017-01-01T00:00:00.000Z",
                "doc_count": 2
              }
            ]
          }
        }
      ]
    }
  }
}

Existe um doc_count geral da primeira busca de tipos de veículos e dentro de cada range existe outro doc_count que fala o numero de veículos vendidos por range.

Bom, acho que na parte de consultas e agrupamentos já vimos bastante, o restante fica por conta de treino e documentação da própria ElasticSearch que pode ser encontrada no link abaixo:

https://www.elastic.co/guide/index.html

No próximo e último artigo! (Graças a Deus), vamos por a mão na massa, usando o Logstash e criar alguns dashboard bonitos de mostrar pro chefe no Kibana.

Até o próximo!

Anselmo Borges

Brincando com ElasticSearch (Parte 5: Querying 2)

Postado em por Publicado em BigData, Dicas, Dicas Linux, ElasticSearch, Linux, NOSQL Deixe um comentário
Segunda rodada de consultas no ElasticSearch, agora focando em Filter

Terminando nossos posts sobre consulta, nesse só falaremos sobre Filter portanto você vai ver muita coisa do post anterior aqui, é bom que grava! rs

A principal diferença entre o Filter e o Query é que não temos o relevant score no mesmo. Outra grande diferença é que o parâmetro filter fica dentro do Query, ou seja, um sub-parâmetro. Ai você pergunta, mas porque foram separados os tópicos se vou usar o query aqui também? Apenas por fins didáticos, rs.

A ideia de separar o filter em outro tópico é realmente pelas possibilidades de realizarmos as querys sem o relevant score. As buscas atingem um padrão diferente das que as que estão usando só query. No final do artigo explico melhor.

Nesse exemplo abaixo, se eu usar o parametro “filter” sem a combinação do paramêtro “bool” o comando não funciona, pois estou dando mais de um parâmetros pro inicial que é o “query” sendo assim a consulta abaixo traz todos os cursos que possuem “accounting” no nome.

get courses/_search
{
  "query": {
    "bool": {
    "filter": {
      "match": {"name": "accounting"}
    }
    }
  }
}

Como dito anteriormente, a maior diferença entre uma query convencional e uma query com “filter” é que no campo max_score e _score, que se referem ao relevant score, vem zerados. Assim como uma base de dados convencional ele não organiza os dados por relevância, simplesmente trás o que é pedido na consulta. Outra diferença de usar o filter é que todas as consultas são cacheadas, ou seja, esses resultados foram dispostos na camada de cache para que novas consultas a respeito do mesmo caso ou parecido fossem mais rápidas. Outro fator das querys com filter serem mais rápidas é que elas não perdem tempo com o calculo do score.

Nesse caso se você precisa de consultas mais rápidas sem a necessidade de relevância, utilize sempre o filter nas consultas.

Vamos supor que além do curso, precisamos de mais um filtro, que além das classes que possuem accounting no nome, tenham um professor que chama-se “Bill”, adicionaremos mais um “bool” e um “must” na query e fazemos um match pelo nome do professor (lembrando que o must é um array e por isso jogamos chaves e novos colchetes no parâmetro match) conforme abaixo:

get courses/_search
{
  "query": {
    "bool": {
    "filter": {
      "bool": {
        "must": [
          {"match": {"professor.name": "Bill"}},
          {"match": {"name": "accounting"}}
          ]
      }
    }
    }
  }
}

OBS: Note que tiramos a busca match de baixo do bool inicial e jogamos dentro do array no “must”, isso se deve porque eu não posso ter uma busca especifica e depois uma nova busca, seria como ter 2 WHERE no SQL, então jogo o mesmo dentro do array do must e vira tipo um AND do SQL.

A busca me traz um total de 2 registros que são de cursos que possuem “accounting” no nome e são ministrados por um professor de nome Bill.

{
  "took": 10,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 2,
    "max_score": 0,
    "hits": [
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "8",
        "_score": 0,
        "_source": {
          "name": "Accounting Info Systems 350",
          "room": "E3",
          "professor": {
            "name": "Bill Cage",
            "department": "accounting",
            "facutly_type": "full-time",
            "email": "[email protected]"
          },
          "students_enrolled": 19,
          "course_publish_date": "2014-05-15",
          "course_description": "Act Sys 350 is an advanced course providing students a practical understanding of an accounting system in database technology. Students will use MS Access to build a transaction ledger system"
        }
      },
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "6",
        "_score": 0,
        "_source": {
          "name": "Cost Accounting 400",
          "room": "E7",
          "professor": {
            "name": "Bill Cage",
            "department": "accounting",
            "facutly_type": "full-time",
            "email": "[email protected]"
          },
          "students_enrolled": 31,
          "course_publish_date": "2014-12-31",
          "course_description": "Cst Act 400 is an advanced course from the business school taken by final year accounting majors that covers the subject of business incurred costs and how to record them in financial statements"
        }
      }
    ]
  }
}

No proximo exemplo, vou adicionar um “must_not” (equivalente um not in) eliminando a Sala “E7” (nessa mesma consulta temos 2 salas, E2 e E7), e ficaria como um novo array de must:

get courses/_search
{
  "query": {
    "bool": {
    "filter": {
      "bool": {
        "must": [
          {"match": {"professor.name": "Bill"}},
          {"match": {"name": "accounting"}}
          ],
        "must_not": [
          {"match": {"room": "e7"}}
        ]
      }
    }
    }
  }
}

Sendo assim essa consulta, toda baseada em filter, me traz somente os cursos que possuem “accounting” no nome que são ministrados por um professor de nome “Bill” que não dão aula na sala “E7”. Parece difícil mas tá bem fácil vai?? kkkkkk

Agora vamos ver algumas querys usando parcialmente o filter e parcialmente o query convencional que faz uso do relevant score. Nesse exemplo vamos retirar o filtro “must_not” da sala e7 e vamos jogar a busca pedindo um must, fazendo match com a “e3”.

get courses/_search
{
  "query": {
    "bool": {
    "filter": {
      "bool": {
        "must": [
          {"match": {"professor.name": "Bill"}},
          {"match": {"name": "accounting"}}
          ]
      }
    },
    "must": [
      {"match":{"room": "e3" }}
    ]
    }
  }
}

Explicando a query, o primeiro bool engloba as buscas via filter e via must sem filter, o segundo bool faz as buscas com filter ou seja, sem o relevant score, e o ultimo must onde filtramos as salas de nome “e3”, essa sim tem o relevant score ativado, pois a busca principal final passa a ser ela. Segue o retorno e observe o “max_score” e o “_score” do resultado:

{
  "took": 5,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 0.6931472,
    "hits": [
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "8",
        "_score": 0.6931472,
        "_source": {
          "name": "Accounting Info Systems 350",
          "room": "E3",
          "professor": {
            "name": "Bill Cage",
            "department": "accounting",
            "facutly_type": "full-time",
            "email": "[email protected]"
          },
          "students_enrolled": 19,
          "course_publish_date": "2014-05-15",
          "course_description": "Act Sys 350 is an advanced course providing students a practical understanding of an accounting system in database technology. Students will use MS Access to build a transaction ledger system"
        }
      }
    ]
  }
}

Note a situação inversa quando usamos um range de alunos maior que 12 e usamos fora do filter o “should” que é meio que um pode ser, esse no caso tem uma preferencia menor, então ele traz os resultados filtrados por ele (no caso sala e3) com _score e os demais não, porque todos os 10 registros que ele trouxe se enquadram na primeira pesquisa, os demais “podem ser”, achamos estranho pois não temos esse tipo de busca no SQL.

Segue abaixo o exemplo, rode essa consulta e veja por você mesmo o resultado.

GET courses/_search
{
  "query": {
    "bool": {
      "filter":{
        "bool":{
          "must":[
            {
              "range":{
                "students_enrolled":{
                  "gte": 12
              }
            }
          }]
        }
      },
      "should": [
        {"match":{"room": "e3"}}
      ]
    }
  }
}

Você deve achar estranho o sistema de relevância do ElasticSearch, esse é um dos motivos o qual as pessoas dizem que ele não é um banco de dados e sim um sistema de busca, por exemplo, quando você faz alguma pesquisa no Google ele não traz exatamente o que você pesquisou e sim assuntos relevantes de acordo com o seu string de busca, o ElasticSearch sem o filter faz isso, com o filter passa a fazer consultas como um banco normal, mas o mais legal é que podemos concatenar os 2 tipos de busca visando um resultado mais assertivo, isso que é o legal da ferramenta.

No próximo artigo vamos ver agrupamentos como Group BY, order by, Max, min, AVG e outras dicas.

Até o próximo!

Anselmo Borges

Brincando com ElasticSearch (Parte 4: Querying)

Postado em por Publicado em BigData, Devops, ElasticSearch, Mão na Massa, Minicursos, NOSQL Deixe um comentário
Fazendo buscas no ElasticSearch

Ainda não falei nos posts mas linguagem usada no ElasticSearch se chama DSL (Domain Specific Language), quando você faz qualquer busca no Elasticsearch, ele tem um sistema chamado relevant score, que faz uma avaliação de qual resultado da busca é mais próxima do que você precisa. Você vai perceber que eu tenho mais que uma maneira de busca no ElasticSearch, não seria como um select * from tabela where objeto=tal, você vai perceber no decorrer desse artigo.

Para esse material, roubei um index para fazermos os testes, rode as criações dos itens abaixo para que possamos fazer os exemplos:

wget https://github.com/AnselmoDBA/elasticsearch/blob/master/courses.dsl

Vocẽ pode usar no DSL 2 tipos de busca e cada uma delas tem seu algoritimo de relevant score:

  • Query
  • Filter

Trazendo tudo (match_all):

Vamos trazer só os dados onde no campo name tenham a string “computer”:

get courses/_search
{
  "query":{
    "match": {
      "name": "Computer"
    }
  }
}

A busca trouxe 2 registros e as 2 buscas cada registro tem um score:

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 2,
    "max_score": 0.9331132,
    "hits": [
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "4",
        "_score": 0.9331132,
        "_source": {
          "name": "Computer Science 101",
          "room": "C12",
          "professor": {
            "name": "Gregg Payne",
            "department": "engineering",
            "facutly_type": "full-time",
            "email": "[email protected]"
          },
          "students_enrolled": 33,
          "course_publish_date": "2013-08-27",
          "course_description": "CS 101 is a first year computer science introduction teaching fundamental data structures and alogirthms using python. "
        }
      },
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "7",
        "_score": 0.8781843,
        "_source": {
          "name": "Computer Internals 250",
          "room": "C8",
          "professor": {
            "name": "Gregg Payne",
            "department": "engineering",
            "facutly_type": "part-time",
            "email": "[email protected]"
          },
          "students_enrolled": 33,
          "course_publish_date": "2012-08-20",
          "course_description": "cpt Int 250 gives students an integrated and rigorous picture of applied computer science, as it comes to play in the construction of a simple yet powerful computer system. "
        }
      }
    ]
  }
}

Esse score é exatamente o relevant score, o calculo de quão relevante é o resultado de acordo com a sua busca, note que o primeiro dado tem um valor maior, isso se deve ao campo name ter um numero de caracteres melhor do que o segundo registro, quanto mais próximo da palavra “computer”, se tivesse um campo só com a palavra computer o valor seria maior ainda.

Checando registros se possuem uma chave:

Nesse exemplo estamos querendo trazer todos os registros do index course que possuem o sub item de professor de nome email.

get courses/_search
{
  "query":{
    "exists": {"field": "professor.email"}
  }
}

Sendo assim ele traz os 10 registros pois todos tem essa chave. Caso eu tirasse o campo email de um deles, ele traria só 9 registros.

Melhorando a busca:

Vamos supor que alem do nome do curso com o nome de computer eu queria saber qual deles é na sala c8, adiciono mais um match na mesma busca, porem se eu usar o parâmetro query eu tomarei um erro de chave duplicada, então altero o adicionando um parâmetro chamado bool de valores que não tem nada a ver com boolean, explico mais adiante e o must onde posso colocar os 2 parâmetros de busca.

get courses/_search
{
  "query":{
    "bool":{
     "must":[
      {"match": {"name": "computer"}},
      {"match": {"room": "c8"}}
      ]
    }  
  }
}

O resultado segue abaixo de um unico item que cumpre com os 2 parâmetros de busca. Como só tem um podemos perceber que o Score é igual o Max_score.

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 1.8590136,
    "hits": [
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "7",
        "_score": 1.8590136,
        "_source": {
          "name": "Computer Internals 250",
          "room": "C8",
          "professor": {
            "name": "Gregg Payne",
            "department": "engineering",
            "facutly_type": "part-time",
            "email": "[email protected]"
          },
          "students_enrolled": 33,
          "course_publish_date": "2012-08-20",
          "course_description": "cpt Int 250 gives students an integrated and rigorous picture of applied computer science, as it comes to play in the construction of a simple yet powerful computer system. "
        }
      }
    ]
  }
}

Fazendo uma validação negativa (NOT IN/IS NOT)

Quando usamos o must, podemos teóricamente fazer um where com end de 2 parâmetros, agora temos a possibilidade de rodar o must_not para eliminar uma hipótese. Nesse exemplo de busca, quero os cursos de accounting, na sala e3, mas que não tenham um professor de nome Bill.

get courses/_search
{
  "query":{
    "bool":{
     "must":[
      {"match": {"name": "accounting"}},
      {"match": {"room": "e3"}}
      ],
     "must_not": [
       {"match": {"professor.name": "Bill"}}
     ]
    }  
  }
}

O resultado vem abaixo:

{
  "took": 26,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 0.96917987,
    "hits": [
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "1",
        "_score": 0.96917987,
        "_source": {
          "name": "Accounting 101",
          "room": "E3",
          "professor": {
            "name": "Thomas Baszo",
            "department": "finance",
            "facutly_type": "part-time",
            "email": "[email protected]"
          },
          "students_enrolled": 27,
          "course_publish_date": "2015-01-19",
          "course_description": "Act 101 is a course from the business school on the introduction to accounting that teaches students how to read and compose basic financial statements"
        }
      }
    ]
  }
}

Eu tenho uma segunda possibilidade, que se no fim da minha busca eu tenho 2 registros da sala e7 por exemplo mas eu só quero exibir 1 deles, e ele exibe sempre o de melhor score, usamos a clausula shold com o parametro minimum_shold para 1. Veja o exemplo abaixo:

get courses/_search
{
  "query":{
    "bool":{
     "must":[
      {"match": {"name": "accounting"}}
      ],
     "must_not": [
       {"match": {"professor.name": "Bill"}}
     ],
     "should": [
       {"match": {"room": "e7"}}
     ],
     "minimum_should_match": 1
    }  
  }
}

Caso eu tenha mais registros por exemplo 5 e eu queira limitar o should para 2 eu posso simplesmente limitar pelo minimum_shold colocando 2.

Usando o mesmo critério para mais de uma chave (multi_match):

Nesse exemplo eu estou fazendo a busca pelo nome do curso e o departamento do professor pelo nome accounting, nesse caso eu posso ter um professor que da um curso de contabilidade e trabalha no departamento de contabilidade, segue o exemplo abaixo:

get courses/_search
{
  "query": {
    "multi_match": {
      "query": "accounting",
      "fields": ["name", "professor.department"]
    }
  }
}

Essa consulta me retorna 4 registros desse tipo, fizemos isso usando o multi_match, onde temos um critério de busca para mais de uma chave.

Buscando uma sentença e não uma string:

Diferente de uma busca usando like, por exemplo: like (‘hoje o ansel%’) que pegaria qualquer coisa com o que foi pedido mais o que vem depois de ansel, no ElasticSearch tenho a possibilidade de buscar uma frase inteira e não parte dela com o parâmetro match_phrase, se liga no exemplo:

get courses/_search
{
  "query": {
    "match_phrase": {
      "course_description": "from the business school taken by final year"
    }
  }
}

-- Resultado:
{
  "took": 85,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 4.738639,
    "hits": [
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "6",
        "_score": 4.738639,
        "_source": {
          "name": "Cost Accounting 400",
          "room": "E7",
          "professor": {
            "name": "Bill Cage",
            "department": "accounting",
            "facutly_type": "full-time",
            "email": "[email protected]"
          },
          "students_enrolled": 31,
          "course_publish_date": "2014-12-31",
          "course_description": "Cst Act 400 is an advanced course from the business school taken by final year accounting majors that covers the subject of business incurred costs and how to record them in financial statements"
        }
      }
    ]
  }
}

Porem se eu tirar um pedaço da buca por exemplo deixar o finalzinho do texto de “final year” para “fin”, ele já não busca o registro, se liga:

get courses/_search
{
  "query": {
    "match_phrase": {
      "course_description": "from the business school taken by fin"
    }
  }
}

-- Resultado:
{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": null,
    "hits": []
  }
}

Caso ao invés de “match_phrase” eu usar o “match_phrase_prefix” ai sim ele considera a frase quebrada tipo um % no like de SQL:

get courses/_search
{
  "query": {
    "match_phrase_prefix": {
      "course_description": "from the business school taken by fin"
    }
  }
}

-- Resultado:
{
  "took": 36,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 5.1960063,
    "hits": [
      {
        "_index": "courses",
        "_type": "classroom",
        "_id": "6",
        "_score": 5.1960063,
        "_source": {
          "name": "Cost Accounting 400",
          "room": "E7",
          "professor": {
            "name": "Bill Cage",
            "department": "accounting",
            "facutly_type": "full-time",
            "email": "[email protected]"
          },
          "students_enrolled": 31,
          "course_publish_date": "2014-12-31",
          "course_description": "Cst Act 400 is an advanced course from the business school taken by final year accounting majors that covers the subject of business incurred costs and how to record them in financial statements"
        }
      }
    ]
  }
}

Fazendo buscas numéricas e data com range:

Esse tipo de consulta parece muito o Beetween do Oracle, nesse exemplo vou buscar as turmas que tem um range de alunos entre 10 e 20, o parâmetro usado é bem sugestivo, chama range rs:

get courses/_search
{
  "query": {
    "range": {
      "students_enrolled": {
        "gte": 10,
        "lte": 20
      }
    }
  }
}

Nem vou colar o resultado nesse mas foram um total de 4 registros, porem usando o gte (grater then) e o lte (lighter then), eu incluo os números 10 e 20, caso eu NÃO queira incluí-los eu retiro o “e” da sintaxe, deixando gt e lt conforme exemplo abaixo:

get courses/_search
{
  "query": {
    "range": {
      "students_enrolled": {
        "gt": 10,
        "lt": 30
      }
    }
  }
}

Nesse exemplo o retorno foi de 6 registros, numa busca dos numeros 11 e 29. O mesmo range pode ser feito com datas e no exemplo abaixo vou pegar os que tem um “course_puplish_date” maior do que “2013-08-27”, ou seja, nem usei o LT, estou pegando só os maiores que esse atributo passado.

get courses/_search
{
  "query": {
    "range": {
      "course_publish_date": {
        "gt": "2013-08-27"
      }
    }
  }
}

Bom com todos esses modelos de busca, agora você pode juntar para uma busca mais avançada, concatenando os tipos como range, match, bool e tendo mais efetividade nas suas buscas, vou dar um exemplo abaixo:

get courses/_search
{
  "query": {
    "bool": {
      "must": [
        {"match": {
          "name": "accounting"}}
      ],
      "must_not": [
        {"match": {
          "room": "e7"}}
      ],
      "should": [
        {"range": {
          "students_enrolled": {
            "gte": 10,
            "lte": 20
          }
        }}
      ]
    }
  }
}

O legal de montar esses DSLs no Kibana, é que ele vai montando a consulta pra você assim como alguns IDEs de mercado.
Bom nesse artigo foi isso, vou encerrar por aqui pra não ficar muito extenso, no proximo artigo vamos ver as consultas usando FILTER.

Até o proximo,
Anselmo Borges.

Brincando com o ElasticSearch (Parte 3: Mapping)

Postado em por Publicado em BigData, Devops, Dicas, Dicas Linux, Linux, Minicursos, NOSQL Deixe um comentário
Mapeando datatypes, sharding, replicas e travando adições de chaves
Mapeando datatypes, sharding, replicas e travando adições de chaves

Se chegou até esse terceiro post é porque se interessou, então vamos a mais essa fase, nela vamos falar sobre o mapeamento de datatypes, pois nos tópicos anteriores vimos que ao criar um novo ID com seus registros, o index e o type são criados automaticamente e as chaves são criadas do jeito que o ElasticSearch acha mais conveniente, mas essa não é a melhor prática.

Para fazermos nosso exemplo, vamos criar mais um indice chamado clientes:

PUT /clientes/online/1
{
	"nome": "Anselmo Borges",
    "sexo": "Masculino",
    "idade": 38,
    "total_gasto": 300.00,
    "cliente_novo": false
}

Dando um GET como vimos no post anterior pegamos as informações dos datatypes de campos por exemplo e do numero de shardin e replicas, porém as mesmas podem ser setadas nos campos mappings e settings na criação do index, saiba para que serve cada uma:

  • Mappings: consigo setar os datatypes das chaves, como integer, float, text e outras, não deixando que o ElasticSearch sete automaticamente como bem entende.
  • Settings: consigo setar o numero de replicas e shardings o Index terá, caso não coloque nada o ElasticSearch seta um valor padrão.

Vamos deletar o Index criado e vamos criar outro usando essas instruções durante a criação:

DELETE /clientes

Vamos criar só o index e não inserir registros.

PUT /clientes
{
	"settings": {
	  "number_of_shards": 2,
	  "number_of_replicas": 1
	},
	"mappings": {}
}

Consultando:

GET clientes

-- Resultados:

{
  "clientes": {
    "aliases": {},
    "mappings": {},
    "settings": {
      "index": {
        "creation_date": "1533662973562",
        "number_of_shards": "2",
        "number_of_replicas": "1",
        "uuid": "C955NFVWR8yrSwM2W9rDfg",
        "version": {
          "created": "6030299"
        },
        "provided_name": "clientes"
      }
    }
  }
}

OBS: Note que o numero de shards e replicas foi configurado exatamente como solicitamos.

Configurando o Mappings:

Agora vamos criar o Type de nome “online” e colocar os campos que ele vai receber:

PUT /clientes/_mapping/online
{
	"properties": {
	   "nome": {
	      "type": "text",
	      "analyzer": "standard"
	   }
	}
}

Note que mesmo sem inserir nenhum registro eu já consigo falar o datatype do campo nome, é como se eu tivesse criado uma tabela zerada, onde não tenho nenhum registro mas já tenho a estrutura no caso o DDL.

{
  "clientes": {
    "aliases": {},
    "mappings": {
      "online": {
        "properties": {
          "nome": {
            "type": "text",
            "analyzer": "standard"
          }
        }
      }
    },
    "settings": {
      "index": {
        "creation_date": "1533662973562",
        "number_of_shards": "2",
        "number_of_replicas": "1",
        "uuid": "C955NFVWR8yrSwM2W9rDfg",
        "version": {
          "created": "6030299"
        },
        "provided_name": "clientes"
      }
    }
  }
}

Erro na inclusão de um novo TIPO:

Como disse no post anterior a partir da versão 6 do ElasticSearch eu não consigo criar mais que um tipo dentro do index, nas versões anteriores eu conseguia, vamos fazer um teste tentando criar o type de nome “offline”.

PUT /clientes/_mapping/offline
{
	"properties": {
	   "nome": {
	      "type": "text",
	      "analyzer": "standard"
	   }
	}
}

-- Resultado:
{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "Rejecting mapping update to [clientes] as the final mapping would have more than 1 type: [offline, online]"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "Rejecting mapping update to [clientes] as the final mapping would have more than 1 type: [offline, online]"
  },
  "status": 400
}

O erro aponta a não possibilidade da criação de mais de um tipo dentro do mesmo index, eu particularmente não gostei rs, por que diminui um pouco a organização dos dados dentro do index, por exemplo poderia criar uma segmentação como usei no exemplo do post anterior bebidas e segmentar os tipos por cervejas, vinhos, wiskys, vodkas e etc. Realmente uma pena, quando eu descobrir como o pessoal está se virando com isso posto aqui.

Possíveis Datatypes:

  • Campos de String: text, keyword
  • Campos numéricos: long, integer, short, byte, double, float
  • Campos de data: text, keyword
  • Valores de verdadeiro e falso: boolean
  • Campos binários: binary

Adicionando mais campos em um type já existente:

Vamos adicionar mais campos naquele type que criamos (online), adicionaremos os campos:

  • idade: integer
  • total_gasto: float
  • cliente_novo: boolean 
PUT /clientes/_mapping/online
{
	"properties": {
	   "nome": {
	      "type": "text",
	      "analyzer": "standard"
	   },
	   "idade": {
	      "type": "integer",
	   },
	   "total_gasto":{
	      "type": "float"
	   },
	   "cliente_novo:" {
	      "type": "boolean"
	}
}

Vamos ver o resultado agora:

{
  "clientes": {
    "aliases": {},
    "mappings": {
      "online": {
        "properties": {
          "cliente_novo": {
            "type": "boolean"
          },
          "idade": {
            "type": "integer"
          },
          "nome": {
            "type": "text",
            "analyzer": "standard"
          },
          "total_gasto": {
            "type": "float"
          }
        }
      }
    },
    "settings": {
      "index": {
        "creation_date": "1533662973562",
        "number_of_shards": "2",
        "number_of_replicas": "1",
        "uuid": "C955NFVWR8yrSwM2W9rDfg",
        "version": {
          "created": "6030299"
        },
        "provided_name": "clientes"
      }
    }
  }
}

OBS: Perceba a diferença comparando o type que criamos no post anterior e o de agora, as atribuições estão no campo mappings nesse.

Para fins didáticos os atributos de settings e mappings foram separados mas podemos já criar tudo com um comando só, lembrando que no primeiro comando que fizemos o sharding e as replicas criamos só o index, temos apenas que incluir o nome do TYPE no nosso caso o online.

Vou apagar tudo e criar denovo:

DELETE clientes

Recriando:

PUT /clientes
{
	"settings": {
	  "number_of_shards": 2,
	  "number_of_replicas": 1
	},
	"mappings": {
      "online": {
        "properties": {
          "cliente_novo": {
            "type": "boolean"
          },
          "idade": {
            "type": "integer"
          },
          "nome": {
            "type": "text",
            "analyzer": "standard"
          },
          "total_gasto": {
            "type": "float"
          }
        }
      }	
	}
}

OBS: Perceba que na 8a linha eu coloquei o nome do type, porque caso eu não coloque, ele vai criar campos pra quem? Pro index?

Resultado:

{
  "clientes": {
    "aliases": {},
    "mappings": {
      "online": {
        "properties": {
          "cliente_novo": {
            "type": "boolean"
          },
          "idade": {
            "type": "integer"
          },
          "nome": {
            "type": "text",
            "analyzer": "standard"
          },
          "total_gasto": {
            "type": "float"
          }
        }
      }
    },
    "settings": {
      "index": {
        "creation_date": "1533667313030",
        "number_of_shards": "2",
        "number_of_replicas": "1",
        "uuid": "N7knXjroSaaJpTwIjtvfIA",
        "version": {
          "created": "6030299"
        },
        "provided_name": "clientes"
      }
    }
  }
}

Travando a inserção de novas chaves:

A gente vê o tempo todo em bancos de chave valor que a cada inserção que eu faço, não necessariamente preciso adicionar novas chaves, mas caso eu adicione, ficariam os demais IDs no caso como uma coluna com vários campos nulos e um não. Mas suponhamos que queremos travar novos a entrada de novas chaves.

Vou fazer a inserção de um novo exemplo onde vou colocar meu endereço (lembrando que já definimos os datatypes do type “online”:

PUT /clientes/online/1
{
	"nome": "Anselmo Borges",
    "sexo": "Masculino",
    "idade": 38,
    "total_gasto": 300.00,
    "cliente_novo": false,
    "Endereço": "Rua Augusta, 237"
}

Note rodando um GET que o campo Endereço foi adicionado sem problemas automaticamente, veja:

{
  "clientes": {
    "aliases": {},
    "mappings": {
      "online": {
        "properties": {
          "Endereço": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "cliente_novo": {
            "type": "boolean"
          },
          "idade": {
            "type": "integer"
          },
          "nome": {
            "type": "text",
            "analyzer": "standard"
          },
          "sexo": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "total_gasto": {
            "type": "float"
          }
        }
      }
    },
    "settings": {
      "index": {
        "creation_date": "1533667313030",
        "number_of_shards": "2",
        "number_of_replicas": "1",
        "uuid": "N7knXjroSaaJpTwIjtvfIA",
        "version": {
          "created": "6030299"
        },
        "provided_name": "clientes"
      }
    }
  }
}

Alterando o tipo de Mapping:

Existem um parametro no mapping chamado dynamic, que basicamente serve para bloquear novos acesso de novas chaves. Ele pode estar em 2 status:

  • false – Ignora e manda criar o campo
  • strict – Gera um erro na criação vendo que o mesmo não está no mapping.

Vamos alterar nosso índice adicionando o parâmetro:

GET clientes/_mapping/online
{
	"dynamic": "strict"
}

Agora consultamos o Index e temos no início do arquivo, perto de online o campo dynamic:

{
  "clientes": {
    "aliases": {},
    "mappings": {
      "online": {
        "dynamic": "strict",
        "properties": {
          "Endereço": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "cliente_novo": {
            "type": "boolean"
          },
          "idade": {
            "type": "integer"
          },
          "nome": {
            "type": "text",
            "analyzer": "standard"
          },
          "sexo": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "total_gasto": {
            "type": "float"
          }
        }
      }
    },
    "settings": {
      "index": {
        "creation_date": "1533667313030",
        "number_of_shards": "2",
        "number_of_replicas": "1",
        "uuid": "N7knXjroSaaJpTwIjtvfIA",
        "version": {
          "created": "6030299"
        },
        "provided_name": "clientes"
      }
    }
  }
}

Agora vamos inserir um novo ID com um campo fora do ultimo padrão chamado “Cidade”.

PUT /clientes/online/2
{
	"nome": "Leonaldo José da Conceição",
    "sexo": "Masculino",
    "idade": 42,
    "total_gasto": 1000.00,
    "cliente_novo": true,
    "Endereço": "Rua da Pinga, 51",
    "Cidade": "Campina Grande"
}

-- Resultado:
{
  "error": {
    "root_cause": [
      {
        "type": "strict_dynamic_mapping_exception",
        "reason": "mapping set to strict, dynamic introduction of [Cidade] within [online] is not allowed"
      }
    ],
    "type": "strict_dynamic_mapping_exception",
    "reason": "mapping set to strict, dynamic introduction of [Cidade] within [online] is not allowed"
  },
  "status": 400
}

OBS: Perceba o erro do Reason: “mapping set to strict, dynamic introduction of [Cidade] within [online] is not allowed”

Bom, matamos mais uma parte do ElasticSearch, no próximo post começamos as consultas.

Até a próxima.
Anselmo Borges.

Brincando com o ElasticSearch (Parte 2: Indexando)

Postado em por Publicado em BigData, Dicas, Dicas Linux, Mão na Massa, Minicursos, NOSQL Deixe um comentário
Criando índices e rodando comandos básicos

Vamos lá, como eu tinha dito na segunda parte veríamos como executamos comandos, inserimos dados e consultamos no ElasticSearch, mas é importante saber que algumas coisas tem nomes diferentes aqui e metódos diferentes de bancos de dados convencionais. Alias o ElasticSearch não é um banco de dados apesar de parecer muito com um, se perguntarem pra 10 pessoas distintas da área de TI dificilmente você teria a mesma resposta. Eu lí em um post de alguém uma resposta parecida com essa:

O ElasticSearch é uma plataforma OpenSource que pode trabalhar Single ou em Cluster, com crescimento horizontal fácil, que permite buscas rápidas de informações usando o protocolo HTTP.

Algum lugar que eu lí.. rsVendo do meu lado de DBA, ele faz um serviço de base NOSQL, muito parecido com Redis que trabalha com dados de Chave + Valor.

Quando o DBA old-school ouve chave valor morre um panda! rs e porque? Eu venho de bases relacionais a vida toda, Postgres, Oracle, MySQL e qual a primeira coisa que esse cara pensa: “Tá como eu migro meu Oracle para uma base chave valor?”, “Como eu aponto minha aplicação pra fazer busca nele?”, “E os selects que estão no código da aplicação? O que faço com eles?”

Em resumo se sua aplicação já existe e roda em relacional, dificilmente você vai migrar seu banco pra chave valor, mas se a aplicação foi criada para essa tecnologia, dificilmente precisará de uma base relacional.

Vou usar o exemplo de aplicações como a que estamos usando aqui, temos um banco MYSQL, onde fazemos a busca de um determinado range de pessoas via CEP, via SQL ficou meio lento, não muito lento, mas lento. Então foi criada uma API que ao mesmo tempo que insere na base relacional, insere no ElasticSearch, então parte da funcionalidade está no relacional e essa busca por CEP está no Elastic, quando temos que alterar algo no banco relacional, rodamos um reindex no Elastic que atualiza esses dados alterado de forma rápida. Dava até pra rodar tudo no ElasticSearch, mas o desenvolvimento inicial foi com a base relacional (talvez na próxima, rs)

Sendo assim você já tem o overview básico do que é e pra que serve, então vamos aprender alguns conceitos básicos.

Não é inserting é indexing!

Esqueça a palavra insert, no ElasticSearch você esta indexando dados, e a primeira coisa que vamos aprender é criar um indice, mas de antemão já vou avisando uma coisa, na versão 6 o ElasticSearch não deixa criar mais de um type por index, você vai entender isso agora.

Qual a estrutura de um index (pelo menos como eu aprendi, rs)

PUT /index/tipo/ID
{
   "chave1": "valor1",
   "chave2": "valor2"
}

Na primeira linha do comando PUT temos o index que é a camada mãe dos dados, fazendo uma analogia com banco relacional, é o nome do database. Depois vem o Tipo que faço uma analogia com Oracle considero o schema. E por ultimo o ID que seria a Tabela no caso do ElasticSearch o documento.

Depois vem as chaves e os valores, chaves que considero colunas e o valor que considero o dado da coluna. Ai você pergunta, estão cada linha é um documento/tabela? Basicamente na minha forma de pensar é! rs

https://gph.is/1cjjl1n

Calma mano, vai ficar mais facil de entender, rs! Mas essa alteração do ElasticSearch acabou complicando um pouco minha analogia e Porque? Continuando na minha linha de raciocínio eu poderia criar vários schemas em um database, já nessa versão não posso criar varios types no mesmo index.

Iniciando a criação do index:

Vamos para um exemplo antes que você desista! Vamos criar um catalogo de bebidas básico, com:

  • Nome da bebida
  • Tipo da bebida
  • Importada
  • preço

Lembra do Kibana que instalamos no ultimo post? Vamos usar a aba Dev Tools nele que tem uma telinha para fazermos as querys no ElasticSearch, legal né? Acesse no navegador o link abaixo:

http://localhost:5601

Ao acessar você vai ver nessa tela o menu lateral esquedo clique em Dev Tools:

Você vai cair nessa tela abaixo:

Vamos chamar o index de adega e o type de bebidas, ao criar nosso primeiro registro já criamos o index e o type juntos, fazendo mais uma analogia, não precisamos rodar o create database e nem o create user.

Rode o comando abaixo e clique no play:

PUT /adega/bebidas/1
{
  "Bebida": "Velho Barreiro",
  "Tipo": "Pinga",
  "Importada": False,
  "Preço": 4.50
}

O retorno após a indexação/insert, é apresentado conforme abaixo:

{
  "_index": "adega",
  "_type": "bebidas",
  "_id": "1",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}

Beleza, nosso index adega foi criado e inserimos nosso primeiro registro de ID 1, vamos dar uma destrinchada nesse log, os 3 primeiros já foram explicados aqui, vamos explicar os demais:

  • _id: claramente o id do registro que colocamos no comando PUT “1”. Quando não colocamos o ID o Elasticsearch gera um automaticamente.
  • version: nunca houve uma atualização desse ID, portanto está na versão “1”.
  • result: “created” foi porque acabamos de cria-lo, mas se rodarmos o mesmo comando sem atualizar nada esse parâmetro muda para updated. Faça o teste.
  • Shards: Veremos mais adiante, mas é uma forma de distribuição de dados para facilitar a consulta, nesse caso do shard é 2.
  • Sucessful: Se o status é um é que deu tudo certinho, rs!

Sendo assim vamos inserir mais alguns registros, vou colocar os PUTs aqui mas insiram um por vez e de play, não sei se funciona tudo junto.

PUT /adega/bebidas/2
{
  "Bebida": "Skoll",
  "Tipo": "Cerveja",
  "Importada": false,
  "Preço": 1.99
}

PUT /adega/bebidas/3
{
  "Bebida": "Goes",
  "Tipo": "Vinho",
  "Importada": false,
  "Preço": 2.99
}

PUT /adega/bebidas/4
{
  "Bebida": "Dreher",
  "Tipo": "Conhaque",
  "Importada": false,
  "Preço": 4.99
}

PUT /adega/bebidas/5
{
  "Bebida": "Maccallan",
  "Tipo": "Wisky",
  "Importada": true,
  "Preço": 100.99
}

Realizando consultas:

Depois dessa bela indexação que deu água na boca, vamos fazer algumas buscas.

Consultando por ID: 

Suponhamos que já sabemos os ID de um registro vamos fazer essa busca com o comando GET:

GET /adega/bebidas/2

-- Resultado:
{
  "_index": "adega",
  "_type": "bebidas",
  "_id": "2",
  "_version": 1,
  "found": true,
  "_source": {
    "Bebida": "Skoll",
    "Tipo": "Cerveja",
    "Importada": false,
    "Preço": 1.99
  }
}

O comando GET trouxe as informações do ID 2 desse index, o resultado da busca também traz dados como version, found que as vezes não são interessantes, existe uma forma de busca que simplifica um pouco e só traz os dados que eu quero:

GET /adega/bebidas/2/_source

--Resultado:
{
  "Bebida": "Skoll",
  "Tipo": "Cerveja",
  "Importada": false,
  "Preço": 1.99
}

Usando o source na frente eu só trouxe os dados realmente, no caso poderia trazer found ou qualquer outra chave da identação inicial. Valide os demais itens alterando o ID.

Buscando um ID inexistente:

Caso eu faça uma busca de algum ID que não existe por exemplo, o campo found vem com o status false no retorno do log conforme abaixo em que busco o ID 6 que não existe:

GET /adega/bebidas/6

-- Resultado:
{
  "_index": "adega",
  "_type": "bebidas",
  "_id": "6",
  "found": false
}

Pra saber se um ID existe posso usar o comando HEAD, segue abaixo os resultados dos IDs 5 (que existe) e 6 (que não existe):

HEAD /adega/bebidas/5 -- Resultado: 200 - OK
HEAD /adega/bebidas/6 -- Resultado: 404 - Not Found

Atualizando valores:

No Elasticsearch os dados são imutáveis, ou seja, caso eu queira atualizar um registro, tenho que sobrescreve-lo se eu for usar o PUT ou usar o comando POST com o parâmetro _update caso queira atualizar um único registro, seguem os exemplos abaixo onde vou alterar o valor do vinho de 2.99 para 3.99:

PUT /adega/bebidas/3
{
  "Bebida": "Goes",
  "Tipo": "Vinho",
  "Importada": false,
  "Preço": 3.99
}

Vou após a alteração realizar um GET completo e ver a mudança da versão:

GET /adega/bebidas/3
{
  "_index": "adega",
  "_type": "bebidas",
  "_id": "3",
  "_version": 2,
  "found": true,
  "_source": {
    "Bebida": "Goes",
    "Tipo": "Vinho",
    "Importada": false,
    "Preço": 3.99
  }
}

Note que nunca fizemos uma alteração nesse ID antes disso e o version mudou pra 2, 1 da criação, 2 da atualização do preço.

Agora vamos fazer a alteração desse mesmo preço usando o comando POST aumentando para 4.20:

POST /adega/bebidas/3/_update
{
 "doc": {
  "Preço": 4.20
  }
}

O valor foi atualizado como podemos ver no log gerado.

{
  "_index": "adega",
  "_type": "bebidas",
  "_id": "3",
  "_version": 3,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 2,
  "_primary_term": 1
}

Observe os campos version e result e vemos que o dado foi atualizado com sucesso. Caso queira faça o GET e veja o valor atualizado.

Deletando um ID:

Esse já está meio evidente, basta colocar delete na frente do comando, vamos apagar o id 5:

DELETE /adega/bebidas/5

O resultado segue abaixo com o status de deleted.

{
  "_index": "adega",
  "_type": "bebidas",
  "_id": "5",
  "_version": 2,
  "result": "deleted",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 1,
  "_primary_term": 1
}

Pegando as informações do index:

Agora vamos pegar as informações do index, pegamos dados como:

  • Tipo de replicação do index
  • Tipo de sharding
  • Chaves e o tipo de valor do dado

Vamos pegar os dados do index adega:

GET adega

-- Resultado:
{
  "adega": {
    "aliases": {},
    "mappings": {
      "bebidas": {
        "properties": {
          "Bebida": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "Importada": {
            "type": "boolean"
          },
          "Preço": {
            "type": "float"
          },
          "Tipo": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          }
        }
      }
    },
    "settings": {
      "index": {
        "creation_date": "1533598051445",
        "number_of_shards": "5",
        "number_of_replicas": "1",
        "uuid": "dJcJM4MfS-mqaD1C2W8g7g",
        "version": {
          "created": "6030299"
        },
        "provided_name": "adega"
      }
    }
  }
}

Buscando todos os registros do index:

Fazendo aquela analogia com SQL vamos fazer um select * trazendo todos os dados do index adega para isso, usamos o mesmo comando do tópico anterior e colocamos um /_search na frente:

GET adega/_search

-- Resultado:
{
  "took": 61,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 4,
    "max_score": 1,
    "hits": [
      {
        "_index": "adega",
        "_type": "bebidas",
        "_id": "2",
        "_score": 1,
        "_source": {
          "Bebida": "Skoll",
          "Tipo": "Cerveja",
          "Importada": false,
          "Preço": 1.99
        }
      },
      {
        "_index": "adega",
        "_type": "bebidas",
        "_id": "4",
        "_score": 1,
        "_source": {
          "Bebida": "Dreher",
          "Tipo": "Conhaque",
          "Importada": false,
          "Preço": 4.99
        }
      },
      {
        "_index": "adega",
        "_type": "bebidas",
        "_id": "1",
        "_score": 1,
        "_source": {
          "Bebida": "Velho Barreiro",
          "Tipo": "Pinga",
          "Importada": false,
          "Preço": 4.5
        }
      },
      {
        "_index": "adega",
        "_type": "bebidas",
        "_id": "3",
        "_score": 1,
        "_source": {
          "Bebida": "Goes",
          "Tipo": "Vinho",
          "Importada": false,
          "Preço": 4.2
        }
      }
    ]
  }
}

Se você olhar no começo do log de saída vai ver um total de 5 e um e no hits um total de 4, o que isso quer dizer? Lembra daquele ID que deletamos, na busca inicial ele ainda existe, fica tipo numa lixeira, mas no 4 só mostra os dados ativos. Mais pra frente falamos da lixeira.

Busca especifica:

Agora chegou a cereja do bolo desse artigo, aquele “tá mais e se eu quiser filtrar minha busca por preço?” O parâmetro _search pode ser combinado com vários tipos de busca, nesse exemplo vamos usar o query.  Nessa busca lembre que alteramos o preço do vinho para 4.20?

GET adega/_search
{
	"query" : {
	   "term" : {"Preço" : 4.20}
	}
}

O resultado:

{
  "took": 0,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 1,
    "hits": [
      {
        "_index": "adega",
        "_type": "bebidas",
        "_id": "3",
        "_score": 1,
        "_source": {
          "Bebida": "Goes",
          "Tipo": "Vinho",
          "Importada": false,
          "Preço": 4.2
        }
      }
    ]
  }
}

Agora a ultima dica, lembra que disse que podíamos rodar esses comando usando o CURL no artigo anterior? Você viu que no Kibana temos um icone de uma ferramenta do lado do Play? Tem uma opção chamada “Copy as cURL” que já joga o comando CURL para a área de transferência.

Agora vamos rodar o mesmo comando pelo dash do Linux, caso você esteja no Windows ou outro instale o CURL. A imagem abaixo mostra a saida dessa execução no CURL

curl -XGET "http://localhost:9200/adega/_search" -H 'Content-Type: application/json' -d'
{
	"query" : {
	   "term" : {"Preço" : 4.20}
	}
}'

Todos os outros comandos que foram executados via Kibana podem ser executados pelo Bash, a grande vantagem que eu vejo é a não necessidade de instalação de nenhum agent e isso é muito legal, bem vindo ao mundo das APIs.

Bom sendo assim encerro essa segunda parte do tutorial de ElasticSearch mas já deu pra ter uma boa noção de como funciona e as facilidades que pode te trazer.

Se tiver alguma duvida estou a disposição.

Abraço!
Anselmo Borges;

Brincando com o ElasticSearch (Parte 1: Instalação)

Postado em por Publicado em BigData, Dicas, Dicas Linux, Linux, Mão na Massa, Minicursos, NOSQL Deixe um comentário
Realizando a instalação do ElasticSearch e do Kibana

Fala pessoal beleza? Vamos dar uma olhada nessa belezinha chamada ElasticSearch. Passando meu cenário, fizemos a configuração de um Amazon ElasticSearch aqui e eu não tinha muito conhecimento sobre uma serie de comandos e até mesmos a utilização em sí, sendo assim, paguei um cursinho o Udemy e perdi um tempinho estudando e vou logo adiantando, não é nenhum bicho de 7 cabeças, somos nós DBAs que viemos cheios de vícios de SQL, mas se fizermos uma analogia você acaba entendendo bem.

Sendo assim vamos separar esse primeiro material em 2 partes:

  • Instalação: No meu caso fiz a instalação no Ubuntu, mas você pode fazer no Mac ou no Windows sem problema, nesse exemplo vamos usar somente o ElasticSearch e o Kibana (Que é basicamente uma interface gráfica de acesso com uma série de funcionalidade de Dashboards e outras coisas que veremos mais pra frente.)
  • Utilização: Vamos fazer acesso via ao “developer” do Kibana e também pelo CURL (ferramenta que usa o protocolo HTTP para comunicação com algumas ferramentas)

Instalação ElasticSearch:

Como disse anteriormente, vamos fazer nesse exemplo a instalação no Ubuntu, mas no mesmo canal onde faço o download tem pra todos os S.O.s, simplesmente entre nesse link abaixo e escolha de acordo, no meu caso vou baixar o .tar.gz para uma instalação bem simples, descompactando e iniciando.

https://www.elastic.co/downloads/elasticsearch
Download do ElasticSearch
Baixei o TAR

No meu caso como estou usando Linux dei botão direito no tar e copiei o endereço, sendo assim você pode usar o comando abaixo também:

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.3.2.tar.gz

Após o download realizado, descompactamos e renomeamos o diretório descompactado com os comandos abaixo:

tar zfxv elasticsearch-6.3.2.tar.gz
mv elasticsearch-6.3.2 elasticsearch

Agora iniciamos o serviço do ElasticSeach com o comando abaixo (note que estamos deixando o mesmo em background usando o “&” no final.

./elasticsearch/bin/elasticsearch &

Alguns logs vão subir na tela, de alguns enters para voltar o bash e rode o comando abaixo para ver se o ElasticSearch subiu (sendo que localhost é porque estamos rodando na nossa maquina e 9200 é a porta padrão do ElasticSearch):

curl -XGET "http://localhost:9200"

Se ao rodar esse comando recebeu a mensagem abaixo, deu tudo certo:

{
  "name" : "tOAQ8Ad",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "HtkvKH2TS2mLY3t1sowxVQ",
  "version" : {
    "number" : "6.3.2",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "053779d",
    "build_date" : "2018-07-20T05:20:23.451332Z",
    "build_snapshot" : false,
    "lucene_version" : "7.3.1",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"


Pronto, com o ElasticSearch no ar já podemos fazer consultas, mas vamos instalar o Kibana agora.

Instalando o Kibana:

O procedimento vai ser basicamente o mesmo do ElasticSearch, vamos baixar o tar.gz descompactar e iniciar o serviço, só uma observação, o Kibana é feito em Java e consome um JMV (Java virtual machine) considerável, minha maquina tem 8GB de RAM e rodou de boa, fique ligado nesse ponto caso tenha uma maquina pequena, no arquivo de configuração é possível editar os parâmetros Java XMX e XMS, caso precise, procure por isso.

Para baixar o Kibana entre no link abaixo e escolha o de S.O. desejado, no meu caso baixarei o .tar.gz e farei via wget o download.

https://www.elastic.co/downloads/kibana
Download do Kibana
Dei botão direito no Linux 64-BIT e baixei via wget com o comando abaixo
wget https://artifacts.elastic.co/downloads/kibana/kibana-6.3.2-linux-x86_64.tar.gz

Da mesma forma que fizemos com o ElasticSearch vamos descompactar e renomear:

tar zfxv kibana-6.3.2-linux-x86_64.tar.gz
mv kibana-6.3.2-linux-x86_64 kibana

Agora iniciamos o serviço em segundo plano assim como feito com o ElasticSearch usando o “&” no fim do arquivo.

./kibana/bin/kibana &

O serviço do kibana será iniciado, acompanhe o log para ver se deu tudo certo, estando tudo OK, acesse pelo navegador o endereço:

http://localhost:5601

A seguinte pagina será aberta:

Sendo assim já estamos prontos para rodar alguns comandos, mas vamos fazer isso no próximo post.

Algumas observações:

  • Estamos executando os 2 serviços via serviço (systemctl) o que não é o recomendado para servidores, essa instalação só tem fins didáticos, na própria página de download tem materiais que auxiliam a instalação desse modo, de acordo com o sistema operacional desejado.
  • Não foi configurado nenhum tipo de autenticação por enquanto, até pra se fazerem testes como dito no nome do post “Brincando com ElasticSearch”, mais pra frente posso postar algo mais voltado para a segurança do ambiente.

Bom esperam que tenham gostado, fico a disposição no caso de dúvidas.

Até o proximo!
Anselmo Borges

%d blogueiros gostam disto: