Estudo Banco de Dados espaciais distribuído.
Transcrição
Estudo Banco de Dados espaciais distribuído.
Thiago Guedes Cunha de Moura Estudo Banco de Dados espaciais distribuído. 1 Introdução Devido a enorme geração de dados atualmente e o surgimento do termo Big Data para denir o processamento analítico, eciente e escalável dessas bases massivas e motivado pela perda de performance e baixa escalabilidade encontrada em banco de dados relacionais[4], surgiu nos últimos anos um novo modelo de armazenamento e recuperação: o NoSQL (Banco de dados não relacionais) que possuem como principais características a ausência ou alta exibilidade de esquemas(não possuem suporte ACID), código aberto, distribuídos, escaláveis horizontalmente, suporte à replicação e acesso via API.[3] Neste documento primeiramente é feito uma revisão geral sobre as principais classes de NoSQL (Orientado a Documentos; Orientado a Chave/Valor; Orientado a Colunas e Orientado a Grafo) e depois suas relações com dados espaciais. 2 NoSQL Uma comparação mais aprofundada pode ser vista em: http://db-engines. com/en/system/Neo4j 2.1 Orientado a Chave/Valor Funciona basicamente como uma grande tabela hash distribuída. Fácil implementação • Vantagens: • Desvantagens: mais complexas. • 2.2 Não permite a recuperação de objetos por meio de consultas Principais Nomes: DynamoDB, Redis, Riak Orientado a Documentos Os documentos de bancos de dados orientados a documentos são coleções de atributos e valores. Em geral, os bancos de dados orientados a documento não possuem esquema, ou seja, os documentos armazenados não precisam possuir estrutura em comum. Essa característica faz deles boas opções para o armazenamento de dados semi-estruturados. Suportam indices secundários, múltiplos tipos de documentos por banco e listas de documentos. • Vantagens: • Principais Nomes: MongoDB, CouchDB 1 2.3 Orientado a Grafo O modelo orientado a grafos possui três componentes básicos: os nós (são os vértices do grafo), os relacionamentos (são as arestas) e as propriedades (ou atributos) dos nós e relacionamentos. Neste caso, o banco de dados pode ser visto como um multigrafo rotulado e direcionado, onde cada par de nós pode ser conectado por mais de uma aresta. Alta eciência em consultas complexas • Vantagens: • Principais Nomes: 2.4 Neo4j Orientado a Colunas Neste modelo os dados são indexados por uma tripla (linha, coluna e timestamp), onde linhas e colunas são identicadas por chaves e o timestamp permite diferenciar múltiplas versões de um mesmo dado. Particionamento dos dados, além de oferecer forte consistência. • Vantagens: • Desvantagens: • Principais Nomes: 3 A escrita de um novo registro é bem mais custosa do que em um banco de dados tradicional BigTable, Cassandra, Hadoop/HBase Dados Espaciais Existem basicamente duas maneiras de representar dados espaciais, sao elas representação vetorial e representação matricial. Dados vetoriais são linhas, polígonos e pontos. Dados matriciais são geralmente imagens de satélites e possuem como característica o grande volume ocupado, geralmente na casa dos GigaBytes ou até PetaBytes. A principal maneira de representá-los e armazenálos é através do esquema piramidal, onde em cada nível a mesma imagem é "picotada"em pequenos pedaços que variam entre 1 e 32kb gerando milhões ou até bilhões de pequenos arquivos, indexados pelo próprio nome do arquivo que possui o nivel e as coordenadas x e y. Para a transformação do dado bruto no esquema piramidal existe a Biblioteca GDAL.[7] Dados espaciais também são gerados em larga escala todos os dias através de fotos de satélites, resultados de simulações de modelos espaciais, localização de pessoas em redes sociais, etc. 3.1 Armazenamento em SGBDs relacionais Duramente muitos anos banco de dados relacionais foram utilizados para armazenar dados espaciais. O mais provavelmente conhecido e difundido é o PostGIS, uma extensão ao PostgreSQL para tratar tais tipos de dados, além dele Oracle e MySQL também possuem produtos na mesma linha. O problema com essas soluções como dito anteriormente é em conseguir uma alta escalabilidade, outro motivo é a falta de suporte para visualização de dados matriciais.[6] Por outro lado possuem grande suporte para queries avançadas, vasta documentação e diversas otimizações para tratamento de dados vetoriais. 2 Existem diversos plugins para o GeoServer para prover os dados a partir de SGBDs relacionais e atrevés do próprio sistema de arquivos local de forma bastante eciente, porém como já explicado, quando essa base de dados cresce exponencialmente essas opções se tornam inviáveis. 3.2 Armazenamento em NoSQL Da mesma forma que nos SGBDs relacionais, em NoSQL existem extensões que dão um maior suporte para manipulação de dados vetoriais. As principais extensões são para o Neo4j (Neo4j Spatial), MongoDB(Geo Hash) e CouchDB(GeoCouch). Dentre elas, a que a oference um melhor suporte, maior crescimento, plugin para o geoserver e mais o amplamente estudado na literatura é o Neo4j Spatial.[1] O problema aqui também está no armazenamento e processamento de dados matriciais. Nenhuma das soluções citadas anteriormente possui tal suporte. Porém é encontrado na literatura diversas abordagens baseadas no Hadoop para tratar esse problema. É uma área de estudo "recem nascida"e ainda não existem aplicações em larga escala que utilizam esses métodos, com excessão é claro do Google, que mantém o seu NoSQL proprietário operando 24x7 mantendo os dados de seus principais serviços incluindo o Google Earth.[2] O principal foco das pesquisas é em como indexar os dados de forma eciente, uma vez que o Hadoop possui limitações para armazenamente de dados pequenos (≤ 16M B )[5] A principal fonte de informações encontrada que trata do assunto são artigos de pesquisadores Chineses da "Chinese Academy of Sciences", [9][10][11] 3.2.1 Plugins para GeoServer A principal forma de disponibilizar dados espaciais na internet é através de protocolos(WMS, WFS, WPS) denidos pela OGC(Open Geospatial Consortium). Para isso é necessário congurar uma fonte de dados para ser exportada, essa tarefa é feita a partir de plugins que fazem a integração entre o core do GeoServer e a fonte de dados desejável. O maior desao é em como desenvolver um plugin para o GeoServer acessar o HDFS e implementar uma indexação de dados vetoriais no mesmo, uma vez que não existe documentação alguma sobre o assunto. 3 Foi desenvolvido recentemente pela OSGeo um plugin opensource para o GeoServer acessar dados através do MongoDB[8], além desse existe também o plugin do Neo4j como citado anteriormente. Referências [1] BLP Baas. Nosql spatialneo4j versus postgis. 2012. [2] Fay Chang, Jerey Dean, Sanjay Ghemawat, Wilson C Hsieh, Deborah A Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E Gruber. Bigtable: A distributed storage system for structured data. ACM Transactions on Computer Systems (TOCS), 26(2):4, 2008. [3] Mauricio De Diana and Marco Aurélio Gerosa. Nosql na web 2.0: Um estudo comparativo de bancos não-relacionais para armazenamento de dados na web 2.0. [4] Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, and Werner Vogels. Dynamo: amazon's highly available key-value store. In IN PROC. SOSP, pages 205220, 2007. [5] Xuhui Liu, Jizhong Han, Yunqin Zhong, Chengde Han, and Xubin He. Implementing webgis on hadoop: A case study of improving small le i/o performance on hdfs. In Cluster Computing and Workshops, 2009. CLUSTER '09. IEEE International Conference on, pages 18, 2009. [6] OpenGeo. Documentação postgis. dataadmin/pgBasics/rasters.html. http://suite.opengeo.org/docs/ [7] OsGeo. Gdal - geospatial data abstraction library. http://www.gdal.org/. [8] OsGeo. Integration of geoserver with nosql databases. http://fosslc.org/ drupal/content/integration-geoserver-nosql-databases. [9] Guangqing Zhang, Chuanjie Xie, Lei Shi, and Yunyan Du. A tile-based scalable raster data management system based on hdfs. In Geoinformatics (GEOINFORMATICS), 2012 20th International Conference on, pages 14, 2012. [10] Yunqin Zhong, Jizhong Han, Tieying Zhang, and Jinyun Fang. A distributed geospatial data storage and processing framework for large-scale webgis. In Geoinformatics (GEOINFORMATICS), 2012 20th International Conference on, pages 17, 2012. [11] Yunqin Zhong, Shangchun Sun, Haojun Liao, Yanwei Zhao, and Jinyun Fang. A novel method to manage very large raster data on distributed key-value storage system. In Geoinformatics, 2011 19th International Conference on, pages 16, 2011. 4
Documentos relacionados
Bancos de Dados NoSQL x SGBDs Relacionais:Análise
Apesar de possuírem certas características em comum, tais como serem livres de esquema, promoverem alta disponibilidade e maior escalabilidade, os sistemas de bancos de dados NoSQL existentes possu...
Leia mais