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

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