4º Congresso Científico da Semana Tecnológica - IFSP 2013, copyright by IFSP de outubro de 2013, Bragança Paulista, SP, Brasil

Transcrição

1 UMA ABORDAGEM ORIENTADA A DOCUMENTOS PARA ARMAZENAR PUBLICACOES MEDICAS Gustavo Dos Santos Flório, gu.florio@hotmail.com Bianca Maria Pedrosa, bpedrosa@ifsp.edu.br Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Campus Capivari Resumo. Bancos de dados NoSQL armazenam um gigantesco volume de informações e suportam uma estrutura flexível dos dados. Dentre estes banco de dados, destaca-se o MongoDB, produzido pela 10Gen e distribuído como software livre. O modelo de dados do MongoDB é baseado no documento, um objeto que pode conter um conjunto de atributos. Uma coleção é um conjunto de objetos, que podem apresentar estruturas diferentes. MongoDB suporta as operações CRUD (create, read, update, delete), entretanto não suporta junções. Relacionamentos entre documentos são expressos através de referências, baseadas nos identificadores dos objetos, ou simplesmente os documentos são embutidos uns dentro dos outros. Este projeto analisa a viabilidade da utilização de banco de dados orientados a documentos para armazenar informações de publicações médicas. Para projetar e armazenar dados em MongoDB, foi necessário o estudo da notação BSON para especificação dos dados e práticas de modelagem baseadas na distribuição dos dados, além dos comandos do MongoDB. Os resultados preliminares mostram que o modelo de dados orientado a documentos é adequado para muitos casos de dados biotecnológicos em que uma estruturação rígida dos dados não é possível. Palavras Chaves: Banco de dados distribuídos. Banco de dados NoSQL. Banco de dados orientado a documentos. 1. INTRODUÇÃO Um dos desafios atuais para a área de Bancos de Dados é manipular grandes volumes de dados disponíveis em várias ciências, tais como astronomia, biologia e ciências da terra, entre outras (Gray, 2004). Com o advento da computação em nuvem, bancos de dados distribuídos emergiram como solução para muitas destas aplicações. Neste sentido, entidades como Apache 1 tem investido em plataformas para computação distribuída, provendo infraestrutura como o Hadoop 2, um ambiente de trabalho escalável para computação distribuída. Por muito tempo, para atender a demanda crescente por recursos computacionais, utilizou-se a abordagem de escalonamento vertical (scale-up), que estende o poder de processamento computacional através da adição de servidores. Entretanto, esta abordagem degrada o desempenho dos bancos de dados. Além disto, com a computação em nuvem passou-se a utilizar cada vez mais o escalonamento horizontal (scale-out), que estende os recursos computacionais através da adição de máquinas extremamente simples (POKORNY, 2011). As novas tecnologias computacionais tem promovido o compartilhamento de dados em diferentes modelos: estruturados, semiestruturados e não estruturados. Dados estruturados são dados que tem um formato bem definido, todas as informações são armazenadas com a mesma estrutura. Dados semiestruturados, possuem algum nível de organização interna, mas esta organização é extremamente flexível, por exemplo, uma planilha eletrônica é organizada em linhas e colunas, mas cada célula pode conter qualquer tipo de informação. Bancos de dados relacionais (BDR) lidam com dados estruturados em tabelas. Todas as operações submetidas a um BDR podem ser expressas em uma linguagem de consulta chamada SQL (Structured Query Language). Com o aumento do poder computacional e da complexidade da informação, o uso de banco de dados relacionais e linguagens de banco de dados, como SQL, nem sempre são eficientes. Para atender estas aplicações que não cabem no modelo de dados relacional, surgiu uma classe de banco de dados chamada NoSQL, que significa Not only SQL. Banco de dados NoSQL armazenam dados como documentos, objetos e grafos, entre outros modelos. Em geral, os dados são armazenados como uma coleção de pares (chave, valor), onde a chave identifica um valor, que pode ser uma informação estruturada ou não (Cattell, 2010). Este artigo descreve o uso do banco de dados MongoDB para armazenar dados de publicações médicas, desenvolvido a partir do PubMed (NCBI, 2013). Inicialmente, serão apresentadas as principais características do MongoDB. Depois, serão apresentadas a metodologia e materiais utilizados no projeto. Para finalizar, serão apresentados alguns resultados preliminares obtidos até o estágio de desenvolvimento atual do projeto de pesquisa. 2. DESENVOLVIMENTO 2.1 FUNDAMENTAÇÃO TEÓRICA Definir Banco de Dados NoSQL é uma tarefa um controversa, pois até mesmo o uso do termo banco de dados, neste caso, é questionável, já que o termo banco de dados aplica-se predominantemente a Banco de Dados Relacionais

2 Por isto, Cattell (2010) utiliza o termo armazenamento de dados (data storage) e prefere resumir as seguintes características comuns para descrever Banco de dados NoSQL: 1. Suporte para escalonamento horizontal (shared nothing) 2. Habilidade para distribuir dados entre vários servidores 3. Interface simplificada (não SQL ) 4. Controle de concorrência fraco 5. Uso eficiente da memória RAM e de índices 6. Habilidade para adicionar dinamicamente novos atributos aos registros de dados A tabela 1 apresenta uma comparação entre BDR e NoSQL. Note que estes bancos de dados diferem nos modelos de dados adotados, tipos de interface de consultas e operações predominantes. Banco de dados NoSQL suportam dados não estruturados, as consultas são expressas em linguagens de programação e as operações de leitura predominam, ao contrário de BDR, que foram concebidos para suportar várias operações de escrita e leitura. Tabela 1. NoSQL versus Relacional BDR NoSQL Modelo de dados Estruturado Não estruturado Interface SQL Linguagem de scripts Consultas Junção, ordenação, agregação Obter, atribuir Operações Escrita e leitura Escrita Controle de Concorrência ACID BASE Os banco de dados no NoSQL são projetados segundo três modelos de dados: o modelo chave-valor, orientado a documentos e orientado a coluna. O modelo chave-valor corresponde à abstração de tabelas hash, que é extremamente simples e eficiente computacionalmente. O modelo baseado em documentos pode ser considerado uma evolução do modelo chave-valor, na medida em que o valor é um documento pode ser qualquer tipo de informação como, por exemplo, um documento regular (arquivo texto) ou qualquer objeto complexo (lista de campos, atributos compostos, lista de valores). No modelo orientado a colunas, um banco de dados é composto de arquivos estruturados em coleções de pares (chave, valor) em que a chave é um atributo utilizado como índice para a recuperação do valor, que pode ser um dado estruturado ou não. As colunas podem ser agrupadas em super-colunas, armazenadas em vários servidores diferentes (escalonamento vertical). A abordagem chave-valor. A tabela 2 apresenta um resumo dos banco de dados NoSQL mais representativos e seus modelo de dados. Modelo de Dados Operações Tabela 2 Bancos de dados NoSQL mais representativos. Chave-valor Documento Coluna Chave-valor valor=escalar, list, map Get(chave) Put(chave,valor) Chave-valor valor=objeto Find Update Insert/delete Colunas Família de Colunas Super-colunas Insert/delete Get Consultas simples Vantagens Simplicidade Modelo de dados rico Escabillidade e performance Desvantagens Limitações para tipos de dados e consultas Ausência de controle de versões Ausência de compressão de dados Banco de Dados SimpleDB (S3) Dynamo (Amazon) Voldemort (LinkedIn) CouchDB(Apache) MongoDB(10gen) BigTable (Google) Hbase (Apache) Cassandra (facebook) Os banco de dados NoSQL com modelo de dados chave-valor são os que mais influenciam outros modelos de dados, como consequência, é o modelo que pode mais facilmente ser combinado com os demais. Nos modelos orientados a colunas e baseados em documentos, é possível identificar aspectos do modelo chave-valor. De fato, os bancos de dados NoSQL, mais recentes são influenciados pelos modelos mais antigos. Cassandra é um banco de dados NoSQL, com influências do Dynamo (chave-valor) e BigTable (baseado em coluna).

3 O modelo de dados do MongoDB é baseado em documentos, um objeto que contém um conjunto de atributos. Uma coleção é um conjunto de objetos, que podem apresentar estruturas diferentes. MongoDB suporta as operações CRUD (create, read, update, delete), entretanto não suporta junções. Relacionamentos entre documentos são expressos através de referências baseadas nos identificadores dos objetos, ou simplesmente os documentos são embutidos um dentro do outro de forma não relacional (não normalizada) (MongoDB, 2013). A tabela 2 resume as diferenças entre o modelo relacional e o MongoDB. O modelo de dados do MongoDB contempla as noções de coleção e documento, enquanto no modelo relacional os bancos de dados são estruturados em tabelas. Tabela 2. Diferença entre Bancos de dados Relacional e MongoDB. Relacional (SQL) MongoDB (NoSQL) Banco de dados Banco de dados Tabela Coleção Tupla/Linha/registro Documento Coluna/Campo Atributo Para exemplificar a modelagem de dados no MongoDB, considere o documento abaixo (figura 1), que descreve o conteúdo de livros. Neste documento, um livro é publicado por apenas uma editora, mas uma editora publica vários livros. livros= [ { _id: , titulo: MongoDB: The Definitive Guide, autor: Kristina Chodorow, editora: { nome: O Reilly Media, endereco: New York { _id: , titulo: Scaling MongoDB, autor: Kristina Chodorow, editora: { nome: O Reilly Media, endereco: New York ] Figura 1. Exemplo em JSON de um documento com relacionamento 1:N aninhado Note que no MongoDB relacionamento 1:N como, por exemplo, uma editora publica vários livros, pode ser modelado de forma aninhada (nesting), isto é, o livro contém a informação da editora. Outra forma de modelar relacionamento 1:N no MongoDB é através de referências (referring), que é feito através do identificadores dos objetos, como mostra a figura 2. livros=[ ] { _id: , autor: Kristina Chodorow, titulo: MongoDB: The Definitive Guide { _id: , autor: Kristina Chodorow, titulo: Scaling MongoDB editora={ nome: O Reilly Media, endereco: New York, livros_id:[ ,456789] Figura 2. Exemplo em Json de relacionamento 1:N com referência O modelo de dados do MongoDB suporta tanto a modelagem não normalizada, da Figura 1, quanto a normalizada, da Figura 2. A decisão da forma de modelagem a ser adotada depende de como o banco de dados irá crescer e do tipo de consultas a serem realizadas (MongoDB, 2013). 2.2 OBJETIVOS Fazer um levantamento de diferentes bancos de dados NoSQL com ênfase no modelo de dados orientado a documentos, Utilizar a notação BSON para especificação dos dados,

4 Estudar as melhores práticas de modelagem baseadas na distribuição dos dados, Utilizar ambientes de desenvolvimento e interfaces de consulta para mapear SQL para as operações/funções do MongoDB, Selecionar uma aplicação em computação científica (e-science) pelas características de volume e complexidade da estrutura dos dados envolvidos. 2.3 MATERIAIS Software MongoDB Versão Ferramentas MongoImport e MongoFiles Computador com sistema operacional Linux Ubuntu Versão PhpMoAdmin (ferramenta de administração MongoDB para PHP, interface WEB.) Banco de dados PubMed (NCBI, 2013) 2.4 METODOLOGIA Instalar, configurar e estudar o banco de dados MongoDB Selecionar um conjunto de dados para modelagem e armazenamento Projetar o banco de dados Preparar os dados selecionados (extração, transformação, limpeza) Armazenar os dados no MongoDB Processar os dados e produzir resultados Avaliar a qualidade dos resultados produzidos e o desempenho do sistema 2.5 RESULTADOS E DISCUSSÕES O banco de dados selecionado para este projeto é o PubMed, que é composto por mais de 23 milhões de citações para a literatura biomédica do MEDLINE, revistas de ciências da vida, e livros on-line (NCBI, 2013). A figura 3 apresenta o esquema XML para definir e validar a estrutura de dados de um artigo do PubMed. Figura 3. Esquema XML de um Artigo do PubMed No Esquema XML os nomes dos atributos foram mantidos em inglês para facilitar a importação dos dados. No PubMed um artigo é uma estrutura de dados complexa na medida em que possui vários atributos compostos por outras informações multivaloradas ou igualmente compostas. Todos os atributos compostos são seguidos do símbolo +. Por exemplo, um artigo (Article) é publicado em uma revista (Journal), que contém uma série de informações tais como:

5 Nome do Editor (PublisherName), Título da Revista (JournalTitle), ISSN, Volume, Data de Publicação (PubDate), entre outros, como mostra a Figura 4. Figura 4. Esquema XML de uma Revista Além das informações compostas como Journal e PubDate, um artigo pode conter atributos multivalorados, como AuthorList, que consiste na lista de autores que o escreveu, Figura 5. Figura 5. Esquema XML de um Autor No modelo relacional, uma estrutura de dados como esta do artigo, só poderia ser modelada através de muitas tabelas, que precisariam de muitas operações de junção para poder responder consultas satisfatórias. Além do mais, todos os artigos teriam que ter os mesmos atributos, por exemplo, todos teriam que ter uma lista de autores. Entretanto, com o modelo baseado em documentos, é possível armazenar cada artigo com suas características sem limitá-los uma estrutura rígida em que todos os artigos teriam que ter obrigatoriamente os mesmos atributos. Outra vantagem da estrutura de documentos é a disponibilidade de padrões interoperáveis como XML e JSon, que podem ser facilmente lidos por várias ferramentas de migração de dados. 3. CONCLUSÕES O estágio atual de desenvolvimento do projeto está na fase de preparação dos dados, que consiste na importação, limpeza e transformação dos dados. Para isto, tem sido utilizadas as ferramentas MongoImport, que importa arquivos json, csv ou tsv em banco de dados MongoDB. Como o MongoImport limita o tamanho do documento 16 Mb, pode-se utilizar a ferramenta MongoFiles para importar arquivos maiores que 16 MB. O MongoFiles armazena o documento no sistema de arquivos GridFS, que divide o arquivo em partes, que tem por padrão o tamanho de 256k. Os resultados preliminares da utilização do MongoDB mostram que o modelo de dados orientado a documentos é adequado para muitos casos de dados biotecnológicos em que uma estruturação rígida dos dados não é possível, nem desejada. Além disto, a forma de representação dos dados no modelo orientado a documentos é compatível com formatos amplamente utilizados tais como XML e JSon. Os dados biológicos utilizados neste projeto foram obtidos no National Center for Biotechnology Information, que oferece um volume tão grande de dados que possibilitará testar a escabilidade do MongoDB. Como trabalho futuro pretende-se testar o desempenho do MongoDB em um ambiente distribuído robusto, como o Amazon Web Services (AWS, 2013). 4. REFERÊNCIAS BIBLIOGRÁFICAS AWS. Amazon Web Services. Disponível em: < Acesso em: 27/05/2013.

6 CATTELL, R. Scalable SQL and NoSQL Data Stores. DBMS, New York, v. 39, n. 4, GRAY, J. The Next Database Revolution. SIGMOD, NCBI. National Center for Biotechnology Information. Disponível em: < Acesso em: 21/05/2013. MONGODB. The MongoDb 2.4 Manual. Disponível em: < > Acesso em: 17/02/2013. POKORNY, J. NoSQL Databases: a step to database scalability in Web environment. Proceedings of the 13th International Conference on Information Integration and Web-based Applications and Services. 2011