Uma pequena introdução ao Elasticsearch, para bibliotecários

Por que aprender Elasticsearch, se sou bibliotecário? Minha resposta simples para essa pergunta é que para se trabalhar em uma equipe multidisciplinar, é bastante importante entender ao menos os principais conceitos e melhores práticas de outras áreas. Além é claro de ser um diferencial competitivo na sua carreira.

Temos que começar rapidamente pela novidade essencial, que são os Banco de Dados não-relacionais (NoSQL) (Ops, não pode citar wikipédia, né?). Fiz uma pesquisa básica na BRAPCI e no RPPBCI e não encontrei nenhum resultado para os termos: elasticsearch, mongodb ou nosql, mas em compensação, uns 30 por XML. Então, cabe uma pequena explicação do que muda:

Primeiro, é necessário deixar claro que em tecnologia, não é porque você começa a adotar uma tecnologia que necessáriamente irá abandonar a anterior. Então, NoSQL não é necessariamente uma evolução do modelo SQL. Mas o que muda na prática?

Nos banco de dados relacionais, a informação é armazenada em tabelas, imagine a tabela LIVROS:

Titulo Autor Editora
Introdução à Biblioteconomia Edson Nery da Fonseca Briquet de Lemos Livros
Missão do bibliotecário José Ortega y Gasset Briquet de Lemos Livros

E as consultas, são por SQL:

SELECT * FROM LIVROS
Para retornar todos os títulos ou:
SELECT * FROM LIVROS
WHERE EDITORA = "Briquet de Lemos Livros"

Para recuperar todos os títulos de uma determinada editora.

Fiz um pequeno estudo de como os SIGBs livres armazenam os dados em banco de dados relacionais, para quem tiver interesse.

No modelo NoSQL, é um banco de dados que armazena o documento, mas um documento JSON. O JSON é um formato que tem algumas vantagens em relação ao XML. Vamos ver um exemplo dos dois:

< ?xml version="1.0" encoding="UTF-8"? >
< titulo >Introdução à Biblioteconomia< /titulo >
< autor >Edson Nery da Fonseca< /autor >
< editora >Briquet de Lemos Livros< /editora >
< /xml >

O XML, assim como o MARC, é um bom formato de intercâmbio de dados. Já o JSON ficaria assim:

{
"Titulo":"Introdução à Biblioteconomia",
"Autor": "Edson Nery da Fonseca"
"Editora": "Briquet de Lemos Livros"
}

A vantagem, neste caso, além de ser um formato mais enxuto, usar arrays, e pode ser usado diretamente nos bancos NoSQL, além é claro de ser o formato padrão do Javascript e por isso é usado amplamente na Internet por todas as APIs. Já é possível descrever documentos inteiros em JSON ou XML. Só como curiosidade, em 2007, eu juntei o que eu li sobre gerenciar documentos integrais em um pequeno slide, e vejo que hoje o modelo, precisa de adaptação, mas não perdeu totalmente o sentido:

Mas voltando ao Elasticsearch (dá para usar também o MongoBD, tendo cada um uma vantagem diferente sobre o outro). É um software livre, que faz parte de um conjunto chamado Elastic Stack.

A diferença que irei destacar em relação ao modelo relacional lá de cima é que a informação é armazenada no próprio documento e não tem mais uma estrutura fixa de dados. No modelo lá de cima, se quiser colocar a informação sobre a função do autor, tem que criar uma nova coluna na tabela. Para dois autores com duas funções diferentes, a coisa começa a complicar. Ou se criam 4 colunas, duas para o nome, duas para a função, ou se cria uma nova tabela, e faz o relacionamento entre elas. Mas é preciso uma modelagem prévia do modelo antes de entrar qualquer dado. No NoSQL, é bem mais simples, é só alterar o JSON. Como por exemplo no modelo abaixo:

{
"Titulo":"Introdução à Biblioteconomia",
"Autoria": {"nome":"Edson Nery da Fonseca",
"função":"Autor"
},
"Editora": "Briquet de Lemos Livros"
}

A desvantagem é que isso possibilita ter mais erros em relação a consistência dos dados.
Outro grande problema, é a esquematização da descrição. Há estudos em usar os nomes MARC e sua lógica de estrutura para os nomes dos campos. Eu particularmente não gosto desta abordagem. Eu optei por usar o formato schema.org. É um esquema bem completo para a descrição de qualquer tipo de objeto. Mas podemos utilizar qualquer esquema.

O Elasticsearch tem duas principais funcionalidades, pensando em recuperação da informação: A recuperação e a criação de facetas (ou agregações).

Ele não aceita consultas em SQL e tem um vocabulário próprio para consultas: Query DSL. E também um para construção de facetas: Aggregations.

Em relação a consulta, se destacam com alguns conceitos diferente em relação aos bancos de dados relacionais: atribuição de notas e criação de indices de palavras. Um campo título, por exemplo, ao ser indexado, é indexado por suas palavras separadas. Ele também cria um campo para o valor como um todo. Mas tem que buscar em um campo diferenciado com a palavra .keyword no final. Por exemplo, para uma busca no titulo acima, ele busca no índice de palavras “introdução” e “Biblioteconomia” e dá uma nota por maior proximidade de correspondência. Um chute: a busca acima daria uma nota de 80.333. Mas algum titulo como “Estudando a Biblioteconomia no Brasil”, daria uma nota de 30.455 para a mesma busca. Com isso, é possível definir a relevância, e inclusive, não exibir resultados com notas muito baixas.

Para as facetas, é necessário usar o valor completo do campo, e não ele quebrado em palavras. Por isso é preciso usar o campo .keyword. Por exemplo, o campo editora.keyword permite saber quantas vezes cada ocorrência aparece no campo editora. É possível em bancos relacionais usar o “GROUP BY”, mas ele tem menos funcionalidades.

Teria muitos mais detalhes, mas como a idéia era escrever apenas uma pequena introdução, vou só mostrar como seria um exemplo de inclusão de documento, consulta e agregação (O Banco só aceita comandos REST):

INCLUSÃO:

PUT catalogo/livros/1
{
"Titulo":"Introdução à Biblioteconomia",
"Autoria": {"nome":"Edson Nery da Fonseca",
"função":"Autor"
},
"Editora": "Briquet de Lemos Livros"
}

CONSULTA SIMPLES (Retorna os registros com autor “Edson Nery da Fonseca” ):

GET catalogo/livros/_search
{
"query" : {
"term" : { "Autoria.nome" : "Edson Nery da Fonseca" }
}
}

FACETA SIMPLES (Retorna todos os valores de editoras e suas quantidades):

GET catalogo/livros/_search
{
"size": 0,
"aggregations": {
"my_agg": {
"terms": {
"field": "Editora"
}
}
}
}

Só para finalizar, o Elasticsearch aguenta milhões de registros e tem uma ferramenta poderosa de Business Inteligence que é o Kibana. Posso escrever um post depois só sobre ele.

Querem testar os resultados? O Repertório da Produção Periódica Brasileira de Ciência da Informação – RPPBCI é um exemplo de busca usando o Elasticsearch. Ah, a resposta no RPPBCI é um pouco mais lenta, por que na hora de gerar o resultado, nós consultamos o facebook e armazenamos a resposta no banco de dados. Mas vale para testar as funcionalidades.

7 pensamentos em “Uma pequena introdução ao Elasticsearch, para bibliotecários”

  1. Ola Thiago: mais uma bez, um ótimo post. Quero comentar o seguinte: o Elastic Search é uma plataforma bem interessante. Porém, na plataforma DSpace ela foi adotada há algum tempo, mas a partir da Versão 6.0 ela entra em status ‘Deprecated’, ou seja, será abandonada e removida em versões futuras. Restarão as tecnologias Apache SOLR e a recomendação para uso do mecanismo Google para busca e estatísticas. É um importante indicador de longevidade caso alguém insista na adoção dessa tecnologia.

    1. Oi Divino. O Elasticsearch foi abandonado no DSpace por que nunca foi implementado direito. Ele era usado para criar as estatísticas de servidor e nunca foi bem documentado. Entre o SOLR e o Elasticsearch, o Elasticsearch tem muito mais funcionalidades, mas ambos rodam em cima do Apache Lucene. Falta pouco, mas em breve irei adaptar a interface que fiz usando o Elasticsearch para o DSpace e ai testamos para testar as respostas nos dois ambientes.

      1. Ola Tiago: ‘por que nunca foi implementado direito’ é uma afirmação bem contundente, considerando a maturidade e o corpo de contribuidores da plataforma DSpace. Tens algum tipo de estudo técnico que demonstra isso? Aproveitando, gostaria de conhecer o referencial técnico que te convenceu a escolher o Elasticsearch; gostaria de saber quais as funcionalidades de que o Elasticsearch dispõe que o Solr não possui.

        1. A documentação diz claramente que era uma contribuição individual do Peter Dietz ( https://wiki.duraspace.org/display/DSDOC6x/Elasticsearch+Usage+Statistics ). Era para resolver um problema específico dele e não foi uma implementação de toda a comunidade. Esse é um dos erros do dspace, que manteve 3 relatórios de estatística, três interfaces… E em alguns momentos, eles abandonam uma. O Kibana foi o que mais me motivou a usar o Elasticsearch, mas existem bons comparativos na Internet caso precise ver detalhes mais específicos.

          1. Ola Tiago: grato pela reposta. Faltou uma coisa: podes compartilhar referencial técnico que te convenceu a escolher o Elasticsearch?

            1. A escolha do ElasticSearch veio na verdade por uma limitação do MongoBD. A idéia inicial foi a implementação de uma ferramenta usando NoSQL e o MongoBD é uma ótima opção. Mas ele não conseguiu responder bem a uma grande quantidade de registros, o que para a minha aplicação é essencial. Então fiz testes com o ElasticSearch, que trabalha com JSON da mesma maneira que o MongoDB. Mas que tem uma performance absurdamente melhor para uma grande quantidade de registros. Já o SOLR, é só um indice. Caso precisem, uma boa referencia é o site DB-Engines, que olha o mercado de soluções: https://db-engines.com/en/system/Elasticsearch%3BSolr . O Elasticsearch passou o SOLR em popularidade: https://db-engines.com/en/ranking_trend/system/Elasticsearch%3BSolr

Deixe uma resposta