Suspensão da Descrença

Quando migramos de Lucene para Elasticsearch, Liferay manteve o mesmo processo: ao salvar uma entidade, indexamos seus campos. Só que, agora, no Elasticsearch.

Contudo, Elasticsearch não é uma biblioteca: é um sistema servidor altamente distribuído, rodando em clusters. Isto nos forçou a tomar novas decisões, e nos presenteou com algumas lições valiosas. Para entendê-las, convém revisar como Elasticsearch pode ser usado.

O modelo de programação de Elasticsearch

No Elasticsearch, os dados são salvos como pares de chave-valor, agrupados em documentos. Os documentos representam as instâncias das entidades.

Um índice contem vários documentos. Para efeitos práticos, todos os documentos de um índice são mesmo tipo (ao contrário de SGBDs, que aceitam várias tabelas em um banco de dados). O tipo define que campos são encontrados nos documentos e é usualmente dinâmico, permitindo que campos novos sejam adicionados por mera inserção.

Vários índices para vários portais

É muito comum trabalhar, no Elasticsearch, com vários índices diferentes em um mesmo cluster, para o mesmo formato de dados. Como seriam os índices do Liferay. Para responder isso, é necessário ter em mente que Liferay é multi-tenant.

Sabe quando você entra, digamos, em wordpress.com ou blogspot.com e cria um blog? Seu blog é totalmente independente de qualquer outro no mesmo site. O mesmo se aplica ao Liferay Portal, que permite criar instâncias independentes em uma mesma instalação.

Os engenheiros decidiram então que cada instância teria seu próprio índice no Elasticsearch. Separar os dados desta maneira nos permitiu controlar melhor o acesso de uma instância, assim como nos deu flexibilidade para otimizar Elasticsearch.

Por outro lado, embora houvesse vários índices, todos teriam o mesmo formato. Como seria esse formato?

Tudo junto e misturado

Seguindo as recomendações da Elastic, cada índice teria um só tipo. Neste tipo, indexamos as mais diversas entidades.

Na hora em que uma entidade é salva no banco de dados, os valores de suas colunas são indexados em um só tipo de documento. Assim, o post de blog, o artigo do CMS, o comentário no fórum… todos serão representados pelo mesmo formato. O título do blog, do evento, da wiki etc. se tornarão o campo title de vários documentos. O mesmo se passa com campos como content, summary, description…

Estes campos representam características comuns a várias entidades. Quando todas elas são indexadas em um só índice, com um schema uniforme, a busca se torna mais simples: basca procurar pela string nestes documentos.

Os documentos Elasticsearch também contêm bastante metadados, sendo alguns dos mais importantes o campo entryClassName (o tipo da entidade que o documento representa, geralmente o nome de uma classe Java) e entryClassPK (identificador da entidade na tabela SQL). Desta forma, podemos encontrar o que o usuário procura e, a partir daí, recuperar a entidade correta do bando de dados.

Esta arquitetura é uma herança da busca com Lucene mas, nada surpreendentemente, funcionou perfeitamente com Elasticsearch. Esta foi uma de nossas primeiras lições:

Decidida a arquitetura dos dados, a próxima questão a resolver era: como indexar e buscar as entidades no índice da instância. Este será o tema da parte 3 desta série.