Busca corporativa com Apache Solr - Motivação e conceitos

Este é o primeiro artigo da série que cobrirá os elementos, características, conceitos e implementação de um sistema de busca corporativa. O presente artigo abordará os conceitos, elementos e motivações para a adoção e uso de um sistema de busca corporativa.

[ Hits: 6.850 ]

Por: Edwi Oliveira Santos Feitoza em 03/10/2014 | Blog: http://edwifeitoza.wordpress.com


Histórico de banco de dados e suas tecnologias



Muito se fala hoje em dia sobre Big Data, Data Mining e outros conceitos relacionados aos dados, coisa que todos nós estamos expostos a todo o momento, seja no trabalho, em casa, no lazer ou nas ruas.

Ano passado, quando participei do TDC (The Delevopers Conference - 2013), ouvi uma boa definição sobre Big Data. Dizia a respeito de quando os dados com quais são necessários lidar passam a ser um problema para você ou sua organização.

Algumas pesquisas estimam que a quantidade de dados no mundo dobre a cada dois anos (EMC, 2014). Outras, estimam que 90% de todos os dados disponíveis hoje foram criados nos últimos dois anos (SIENCE DAILY, 2013). De qualquer forma, a previsão do crescimento exponencial de dados é assustadora.

O público do Viva o Linux é majoritariamente composto por sysadmins, developers, product managers, team leaders ou mesmo entusiastas da tecnologia.

O que os dados e um pouco de contexto que coloquei acima pode significar para você? É isso que a série de artigos, começando com este, propõe-se a fazer: situar o significado da era de Big Data que estamos vivendo e trabalhar em cima de uma das abordagens do tema, que é a busca de dados. Embora existam outras, como estratégias de armazenamento e modelagem de dados.

É importante lembrar que a preocupação com a busca de informações relevantes não é algo novo. O Babbo classificou o sistema de busca corporativa como "Mina de Ouro", em 2008.

Aqui no próprio Viva O Linux, Alessandro de Oliveira Faria (o Cabelo) fez um excelente artigo (só pra variar, né?!) sobre um sistema de busca corporativa chamada IBM OMNI Find Yahoo.

Conceito

Quando se fala de Big Data, existem muitas definições a respeito do tema. SEMANTIX (2014) publicou um post com definições fornecidas por referências na indústria de TI. Profissionais de renome que trabalham todos os dias com o desafio de lidar com Big Data.

A parte das definições fornecidas, quando se trata de Big Data estamos nos referindo às três características fundamentais deste novo desafio da gestão de dados, mais conhecidos como os "três Vs" de Big Data:
  • Volume :: trata-se da quantidade total de dados coletados e armazenados. Não faz muito tempo que o grande problema era lidar com grandes volumes de dados da ordem de gigabytes. Hoje, falamos da realidade de lidar com ordens de PetaBytes, números tão grandes que são inconcebíveis naturalmente para a mente humana. O tamanho dos dados é comumente visto como o primeiro grande desafio de Big Data;
  • Variedade :: trata-se da origem e tipos de dados coletados. Além do volume, precisamos lidar com dados de diversas fontes (banco de dados, arquivos de texto, planilhas, arquivos de mídia, redes sociais, ERPs, sensores, IoT, etc) e de diversos tipos (dados estruturados e não estruturados, sendo o último aquele que frequentemente demanda maior esforço). O objetivo é coletar dados com estas características e organiza-los de forma coesa e que façam sentido para aplicações e pessoas que as usem;
  • Velocidade :: trata-se do tempo de espera para ter acesso aos dados. Como os volumes de dados tendem a ser cada vez maiores, encontrar informações relevantes, precisas e rápidas torna-se um desafio sem precedentes. O objetivo é encontrar recursos, tecnologias e métodos para responder a este desafio.

Um caso real

No continente europeu existe uma empresa chamada GEFCO. Ela é subsidiária da Peugeot e é responsável pela logística de veículos e peças novas das fábricas para centros automotivos.

Segundo DEVMEDIA (2013), a GEFCO trabalha com aproximadamente 100.000 eventos diários, referentes a 600.000 veículos em 80 países. Na prática, isso significa 5 terabytes de informações, que são disponibilizadas para clientes via portal WEB, com disponibilidade 24x7 e com latência de atualização de dados da ordem de 15 minutos.

A situação é bem diferente da anterior, onde a disponibilidade do sistema mal superava sete horas por dia e a latência de atualização de dados era de 24 horas, além de os clientes terem que esperar inaceitáveis 30 segundos para ter acesso aos dados solicitados.

O que a GEFCO fez, na verdade, foi substituir o sistema antigo de buscas, baseado em banco de dados Oracle, por outro baseado no paradigma de motor de busca corporativo (Enterprise Engine Search). Mas a Oracle é conhecida por ter um sistema de banco de dados muito robusto e altamente performático.

Todos estes atributos são verdadeiros para o sistema da Oracle, mesmo assim, o carro-chefe de Larry Ellison não aguentou o tranco! O que deu errado?

Histórico de banco de dados e suas tecnologias

Edgar Frank Codd (1923 - 2003) foi um cientista da computação nascido em Portland, Inglaterra. Ele trabalhou nos anos 60 e 70 na International Business Machines (IBM) e se tornou famoso e entrou para a história por ser o inventor do modelo relacional para banco de dados, conhecida como a teoria de base para banco de dados relacionais (WIKIPEDIA, 2014).

Edgar listou doze regras que definiam como um banco de dados relacional deveria funcionar (WIKIPEDIA, 2013).

Nos anos 80 já havia vários fabricantes de bancos de dados alegando se tratar de um SGDB (sistema gerenciador de banco de dados relacional). DEVMEDIA (2013) afirma que a IBM foi uma das primeiras empresas a pesquisar e desenvolver bancos de dados relacionais e a linguagem que seria chamada de SQL (Structured Query Language), mas o grande salto foi dado com a Oracle, com o lançamento do primeiro banco de dados que usava e implementava tal linguagem.

Nos anos 90 foi a vez da Microsoft em parceria com a SyBase, lançar seu banco de dados para o sistema OS2. A Oracle lançou seu primeiro SGDB em 1979, já a IBM em 1983.

Portanto, na melhor das hipóteses, se hoje você usa banco de dados relacional está lidando com um conceito e tecnologia que tem no mínimo 24 anos de idade. É até provável que esta tecnologia seja mais velha que a pessoa que está lendo este artigo agora! :)

Vinte e quatro anos é uma eternidade para a tecnologia da informação, sobretudo depois das transformações profundas que começaram a acontecer a partir das décadas de 1990 e 2000. Será que estas tecnologias ainda estão aptas para uma nova realidade de dados que se apresenta hoje para a humanidade? A resposta é parcialmente não!

A Microsoft (2009) publicou a migração de um grande banco privado do Brasil (Banco Itaú) do sistema Mainframe para o sistema Microsoft SQL Server 2008, para cálculo de PDD (Provisionamento para Devedores Duvidosos) e simulações nas mudanças de políticas de concessão de crédito. O tempo de processamento de informações despencou de 12 horas para apenas e estarrecedoras TRÊS HORAS!

Concordo com o texto da Devmedia. Esta mudança deve ser interpretada muito além de sucesso na migração, curto tempo de ROI e a imagem de modernização que o Itaú estava disposto a transmitir para o mercado. Repetindo ipsis-iteris, "hoje SQL Server é o que o Mainframe era vinte anos atrás".

Bancos de dados relacionais são muito bons para garantir controle transacional de operações, como garantir que o dinheiro transferido de uma conta "A" chegue corretamente na conta "B" ou que todo o processo seja desfeito (rollback). Entretanto, as aplicações e necessidades atuais exigem sistemas de banco de dados compatíveis com sistemas complexos e poderosos de busca (o foco deste artigo), sistema de recomendações (muito usado em redes sociais e e-commerce), negociações de alta frequência, catálogo de produtos e serviços, ACLs para usuários e grupos, análises de logs, repositórios de mídia, armazenamento de mensagens e e-mail, entre outras tarefas. E bancos de dados relacionais, bem como softwares baseados nestes, não conseguem entregar boas respostas para estes desafios.

O fato é que até pouco tempo (na verdade até hoje, nas mentes dos que ainda não entenderam a era em que vivemos), as aplicações deviam se vergar ao banco de dados. Precisa armazenar um novo conteúdo e mostrar na sua aplicação e precisa de uma nova coluna em uma entidade do banco? Ajoelhe-se perante o DBA e justifique que a entidade precisa receber um ALTER TABLE para atender este requerimento. O banco de dados era o foco das aplicações.

Hoje, o foco é atender as necessidades e desejos do USUÁRIO. Logo todos os sistemas devem empregar esforços para satisfazer as necessidades esperadas pelos usuários, inclusive o banco de dados.

Uma destas necessidades é encontrar informações relevantes, com a maior precisão possível e de forma rápida. Mas, como fazer isso?

Estratégia de pesquisa de dados

Quando falamos em pesquisa de dados, existem hoje três estratégias disponíveis para serem usadas. É importante lembrar que elas não são mutuamente excludentes, ou seja, nada impede que uma estratégia complemente a outra.
  • Categorização :: esta estratégia é geralmente conduzida e liderada por especialistas diretamente ligados ao negócio, durante a inserção de dados. O objetivo é (pelo menos) tentar antecipar pesquisas feitas por usuários e definir encadeamentos ontológicos que terão como missão responder aos pedidos mais comuns. É uma estratégia muito útil quando o usuário não tem a menor noção do que ele quer pesquisar, logo as ontologias expostas ajuda a refinar a pesquisa. Por outro lado ela tem sérias desvantagens, porque as ontologias podem não corresponder aos critérios de pesquisa imaginados pelos especialistas de negócio ou mesmo não fazer nenhum sentido para os usuários. Por exemplo, se eu pedir para 10 usuários do VOL organizar 100 livros, garanto que cada um vai organizar seguindo seus preceitos e, ao pedir para os usuários mutuamente verem as organizações feitas, a organização feita por um usuário do VOL pode não fazer sentido para os outros nove;
  • Interface de pesquisa detalhada :: é uma estratégia muito útil quando o usuário sabe exatamente o que está procurando. Apresentam campos que permitem aos usuários ajustarem os parâmetros de pesquisa às suas necessidades de consulta. Mas exige que os usuários tenham conhecimento sobre como os dados estão organizados, além de ser uma solução pouco amigável para a maioria dos usuários;
  • Interface de pesquisa amigável :: frequentemente resume-se a uma interface simples, composta por apenas um campo onde usuários informam livremente linguagem humana sob a forma de texto como insumo para localizar as informações desejadas. É uma estratégia que entrega uma excelente experiência ao usuário, por exigir do mesmo poucos insumos para o sistema, de forma livre. Entretanto, esta estratégia coloca uma pressão brutal sobre o sistema de buscas, que a partir de agora precisa "entender" a linguagem do usuário e traduzir isso em informação relevante e de qualidade.

O essa série de artigos terá como objetivo demonstrar um sistema de busca baseado na terceira estratégia.

Conclusão

O objetivo deste artigo foi contextualizar o cenário atual de Big Data, reforçar por que devemos estar atentos a isso e apresentar insumos para a estratégia que será usada sobre a solução que será apresentada (baseada em Apache Solr).

O próximo artigo apresentará conceitos mais técnicos, apresentando características de dados, tecnologias (onde serão apresentadas algumas ferramentas, além do Apache Solr) modelagem de dados e conceitos matemáticos envolvidos.

A partir do terceiro artigo, o mesmo se tornará mais hands-on, mostrando o Apache Solr, como instalar o mesmo (Jetty, Tomcat, JBoss e GlassFish), prospectar dados, etc.

Até acho que para quem é técnico (como eu) e gosta de mão na massa, é frustrante passar por estas etapas até chegar a abrir a tela preta. Porém, são conceitos muito importantes para saber onde estamos enfiando o pé e, principalmente, justificar para lideranças por que esta abordagem, se bem conduzida, pode produzir resultados surpreendentes.

Só para dar água na boca, garanto que mesmo em ambientes modestos, o ambiente que produzirmos juntos poderá ser capaz de ter uma query que retorna um milhões de registros EM MENOS DE UM SEGUNDO! o_O

Até a próxima.

Referências

EMC. Digital Universe Invaded By Sensors. Acesso em: 23 setembro 2014.
Disponível em:
SIENCE DAILY. Big Data, for better or worse: 90% of world's data generated over last two years. Acesso em: 23 setembro 2014.
Disponível em:
SEMANTIX. O que é Big Data? Acesso em: 15 setembro 2014.
Disponível em:
DEVMEDIA. Introdução a sistemas de busca corporativa - SQL Magazine 80. Acesso em 20 setembro 2014.
Disponível em:
WIKIPEDIA. Edgar F. Codd. Acesso em: 28 setembro 2014.
Disponível em:
WIKIPEDIA. Codd's 12 rules. Acesso em: 28 setembro 2014.
Disponível em:
MICROSOFT. Economia em alta: Banco Itaú desenvolve sistema para cálculo de provisionamento para devedores duvidosos e alcança ROI em menos de um ano. Acesso em: 29 setembro 2014.
Disponível em:
   

Páginas do artigo
   1. Histórico de banco de dados e suas tecnologias
Outros artigos deste autor

Não confie em ninguém!

Banda Larga 3G da Claro no Slackware Linux

Leitura recomendada

Windowbuilder, o plugin do Google para trabalhar com interface gráfica no Eclipse

Testes unitários em Java com JUnit

Trabalhando com a interface gráfica em Java

Funções Completas - Comunicação entre aplicações Android e FTP

Java Native Interface

  
Comentários
[1] Comentário enviado por djcelsodub em 18/10/2014 - 12:34h

Boa tarde Ed_slacker,

Primeiramente gostaria de elogiar imensamente o artigo. Muito bom mesmo, mesmo não sendo nada técnico.

Estou curioso e ansioso para os próximos.

Trabalho em uma empresa de saúde com hospitais, laboratórios, farmácias e outros. Temos banco de dados Oracle para todas as aplicações.

Uma pergunta: em um ambiente com banco de dados oracle (para intranet temos sharepoint + m$sql) e diversas aplicações de terceiros, a busca corporativa pode acelerar mais as consultas? ou seria necessário migrar tudo para nosql?

Imaginei um cenário onde a busca corporativa indexe as informações do oracle e entregue mais rapidamente quando consultado. Estou correto no pensamento ou viajei? Neste cenário, com a capacidade da busca corporativa que citou, seria imensamente interessante.

Parabéns novamente.

abs.

Celso Faria
Americana/SP

[2] Comentário enviado por ed_slacker em 18/10/2014 - 23:14h

Olá, Celso Faria!

Primeiramente, muito obrigado pelo elogio ao meu artigo. Isso motiva pra caramba em continuar a publicar conteúdo aqui, coisa que não faço desde 2010.

Segundo, respondendo diretamente sua pergunta, respectivamente, COM CERTEZA e não é necessário!

Hoje em dia temos que construir e lidar com aplicações modernas e inteligentes, ou seja, aplicações cujo foco esteja em quem as usa e não mais nas tecnologias empregadas. Como preconizam frameworks e boas e melhores práticas de mercado (como o Cobit) a tecnologia deve habilitar negócios, não restringi-los.

É comum novas aplicações serem construídas com o seguinte conceito: problemas específicos devem ser resolvidos com soluções específicas. Um exemplo simples seria um site de e-commerce B2C (como um Submarino da vida) que precisa armazenar em banco de dados os produtos disponíveis para venda para exibi-los em um site, além de ter estratégias de recomendação de produtos de acordo com padrões de consumo e visitas no site.

Até daria para fazer isso com bancos relacionais mas nem de longe seriam a melhor solução! Só neste exemplo poderia se aplicar dois bancos com características distintas, como um banco de documentos para "prateleira" e um banco de grafos para linkar recomendações de compras.

No seu caso eu sugiro manter os bancos relacionais, até porque na sua pergunta você citou que todas as aplicações estão penduradas neles. Por outro lado você pode usar uma solução de busca (o próprio Apache Solr, Elastic Search, etc) para indexar o conteúdo deste banco e fornecer resultados que apontem para registros no Oracle.

Por exemplo, seu banco tem um conjunto de entidades que registram dados de ocupação de leitos. Supondo que estes dados estejam atrelados a um ID e outras características (tipo, tamanho, UTI ou não, etc) você teria que fazer algo similar a isto no Oracle:

SELECT ID, TAMANHO, TIPO, UTI, ALA, SETOR, DATA_OCUPACAO, DATA_LIBERACAO FROM LEITOS WHERE DATA BETWEEN '2014-01-01' AND '2014-07-30';

Por mais organizado que seja o banco de dados, a atomicidade e schemas fazem com que esta consulta seja um tanto lenta se comparado com documentos, supondo que a entidade pode ter milhares ou milhões de registros.

Agora com motores de busca você pode indexar o conteúdo das entidades do Oracle e fornecer uma interface de busca para o usuário buscar um dado leito. Quando o motor de busca retornar o documento basta pegar o ID e passa-lo como parâmetro para o Oracle, nos seguintes termos:

SELECT ID, TAMANHO, TIPO, UTI, ALA, SETOR, DATA_OCUPACAO, DATA_LIBERACAO FROM LEITOS WHERE ID = $retorno_motor_busca;

Veja como aliviou bastante o peso em cima do Oracle! A ideia é esta: problemas específicos devem ser resolvidos com soluções específicas.

Esta é a minha sugestão para uma aplicação não-intrusiva no seu modelo atual de aplicações. Nada impede que, a posteriori, você estude quais conjuntos de dados podem ser migrados para soluções NoSQL e quais devem ser mantidos na forma transacional, sempre observando riscos, impactos e vantagens.


Grande abraço.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts