Abordagem Comparativa nos Processos de Armazenamento e

Abordagem Comparativa nos Processos de Armazenamento e
Recuperação de Dados Multimídia
Igor Modesto Alves1, Ary H. M. Oliveira1, Glenda Botelho1, Ivo S. M. Oliveira2
1
2
Universidade Federal do Tocantins (UFT), Palmas– TO – Brazil
Instituto Federal de Educação, Ciência e tecnologia (IFTO), Paraíso – TO – Brazil
{igorma, aryhenrique, glendabotelho}@uft.edu.br, [email protected]
Resumo. O tráfego de dados na rede mundial de computadores tem atingindo
proporções inéditas em termos de volume na atualidade. Essa demanda se dá
principalmente pelo compartilhamento de grandes volumes de dados multimídias
por pessoas que utilizam a internet. Grandes empresas tem buscado soluções para
otimizar os processos de armazenamento e recuperação de dados multimídia. Esse
trabalho tem o objetivo de analisar comparativamente os diversos tipos de bancos
de dados nos processos de armazenamento e recuperação de dados multimídias em
termos de tempo de resposta. O cenário proposto nessa analise se dá em ambiente
de maquinas virtuais no qual cada servidor de banco de dados é processado
isoladamente.
1. Introdução
O tráfego de dados na rede mundial de computadores tem atingindo proporções inéditas em
termos de volume no contexto atual. Este crescimento deve-se principalmente ao aumento do
número de sensores que consequentemente capturam um volume maior de diferentes tipos de
dados e informações, além de ferramentas de uso pessoal e compartilhado tais como as redes
sociais. Os dados produzidos têm como principal característica o grande tamanho em bytes e
muitas vezes não estão representados em uma estrutura padrão, ou seja, são dados não
estruturados. Dentre os dados que normalmente são compartilhados pela internet estão os
streamings de vídeo, as imagens e os arquivos de áudio, ou músicas, documentos de texto,
arquivos compactados, e outros. Esses por sua vez são conceituados como dados multimídia.
A inclusão digital em massa e a concepção de ferramentas como o Facebook 6,
Twitter , YouTube8, dentre outras unidas a grande quantidade de pessoas utilizando os
recursos na internet tem resultado em um aumento no tráfego de dados pela rede de
computadores, criando uma necessidade por meios de armazenamento eficazes e eficientes.
No que diz respeito ao armazenamento, basicamente existem duas formas de persistir os
dados nos sistemas de computadores, ou através de sistemas de arquivos ou por sistemas de
banco de dados. O armazenamento em sistemas de arquivos elimina a necessidade de Essa
análise é necessária pelo fato da técnica de armazenamento não apresentar os controles de
consistência na manipulação e acesso a informação.
7
Um Sistema de Gerencia de Banco de Dados (SGBD) é uma coleção de dados interrelacionados e um conjunto de programas para acessar esses dados (Silberschartz, 2006, p. 1).
Já os Bancos de dados propriamente ditos são as coleções de dados gerenciados pelos
6
https://www.facebook.com/
https://twitter.com/
8
https://www.youtube.com/
7
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
49
SGBD's. De fato, e conforme Silberschatz (2006) o principal objetivo de um SGBD é fornecer
uma maneira de recuperar informações de banco de dados que seja tanto conveniente (maior
usabilidade) quanto eficiente (maior desempenho). Atualmente, existem várias abordagens de
armazenamentos em bancos de dados, dentre as quais destacam-se a relacional (estruturado),
orientado a objetos, hierárquico, chave-valor, rede (ou grafos), coleção de documentos e
família de colunas.
O desempenho é um fator crucial para a adoção de soluções de bancos de dados, ainda
torna-se mais importante quando a demanda de utilização de recursos na internet é intensa e
na mesma proporção em que ocorrem as requisições nos bancos de dados. Assim, a prioridade
de tempo de resposta é bem requisitada na produção de tecnologias de armazenamentos de
dados. A comparação de tecnologias de sistemas de banco de dados, estratégias e modelagem
de registros existentes de acordo com fatores predefinidos contribui para o conhecimento e
decisão pela melhor utilização das tecnologias. Sabendo as vantagens e desvantagens de cada
uma em determinado fator pode-se optar por escolher a melhor forma que se encaixa em
determinada utilidade.
As opções do mercado tecnológico para o armazenamento de dados multimídia são
bem vastas. Assim, é possível analisar as diversas opções de banco de dados com o objetivo
de verificar qual solução poderia ser melhor adotada, baseado nas características e
peculiaridades do tipo de dado a ser armazenado. No caso deste trabalho, os dados são
heterogêneos e não-estruturados, trazendo a necessidade de se analisar formas de
armazenamento mais genéricas de forma a englobar o maior número de tipos de dados (áudio,
vídeo, imagens, documentos e etc.).
Análises comparativas de bancos de dados são vastas em projetos na literatura. E.
Bernuy et al (2009), compara bancos de dados comerciais em seus diversos tipos de
armamento em cenário de conjunto de dados multimídia dos tipos áudio, vídeo, imagem e
arquivos de documentos. Nesse projeto Bernuy et al (2009), relata as abordagens de
armazenamentos relacionais em termos de desempenho para os SGBDs, PostgreSQL e SQL
Server e discute os tipos de armazenamento utilizados em cada um desses bancos.
M. Diana et al (2010) analisam bancos de dados NoSQL [No-SQL, 2014] para
armazenamento de dados na Web 2.0. Esse estudo relata as necessidades de utilização de
otimização de processos em armazenamento e recuperação de grandes volumes de dados.
Essa necessidade é justificada pelo fato de a quantidade de dados gerados, armazenados e
processados ter atingidos escalas inéditas na Web 2.0. Nessa abordagem são analisados
bancos de dados chave-valor, famílias de colunas, documentos e orientados a grafos. I. India
(2013) propõe a utilização de armazenamentos não relacionais para o controle de grande
volume de dados. A solução proposta por esse projeto tem base na utilização de bancos de
dados orientados a documentos, e destaca suas vantagens e desvantagens nos diversos
quesitos de benchmark. Alguns dos SGBDs relatados nesse artigo são: CouchDB, MongoDB,
SimpleDB e OrientDB.
Os SGBDs Não relacionais, também denominados NO-SQL (Not Only SQL) são
usados em aplicações que não acomodam bem as propriedades ACID (Atomicidade,
Consistência, Isolamento e Durabilidade. Geralmente esses tipos de SGBDs são utilizados em
aplicações da web 2.0 que dispensam a rigidez da consistência para atender a outras
propriedades, tais com a distribuição geográfica dos bancos de dados e a alta disponibilidade
do sistema [Gilbert & Lynch, 2002]. Geralmente, essas bases de dados trabalham com
grandes volumes de dados em uma arquitetura massivamente distribuída, implementando
propriedades como a consistência eventual [Vogels, 2009].
50
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
Diante do cenário descrito nesta sessão, o objetivo deste trabalho e implantar um
conjunto de sistemas de banco de dados que implementam as mais variadas abordagens de
armazenamento, procedendo com o armazenamento de um conjunto de imagens de diferentes
tamanhos (em bytes), e posterior recuperação, de forma a analisar o desempenho de cada
abordagem. Ao final, serão gerados gráficos comparativos apresentando o desempenho de
cada uma das abordagens implantadas.
3. Metodologia
A abordagem proposta neste artigo analisa o desempenho de um conjunto de bancos de dados
nos processos de inserção e recuperação de dados multimídia, no contexto de armazenamento
de grandes volumes de dados. Para executar a análise foi necessário criar um cenário com
uma série de condições para possibilitar uma a analise viável e coerente. Desta forma,
inicialmente, foram selecionadas diferentes de combinações de amostras, parâmetros e
operações para subsidiar a execução e análise dos experimentos.
As abordagens de armazenamento e recuperação são representadas pelos diferentes
tipos de bancos de dados implantados para a análise neste trabalho, os quais se dividem em
SGBD's relacionais e não-relacionais. Os SGBDs relacionais selecionados foram o IBM DB2,
Firebird, Postgres SQL e Microsoft SQL Server. Já os NO-SQL são divididos segundo o
modelo de dados utilizado para a representação dos registros. Foram utilizados os SGBDs de
Armazenamento de Documentos, MongoDB e CouchDB, os de Famílias de Colunas
Hypertable e Cassadra, e os de armazenamento de XML EXist e BaseX. Todas as
características desses SGBDs, com os drivers utilizados, links de acesso e versão são
apresentados na tabela 1.
Para a execução dos ensaios foram selecionadas mídias com tamanhos e extensões
variadas, contendo imagens com extensões JPEG (Joint Photographic Experts Group), PNG
(Portable Network Graphics) e TIFF (Tagged Image File Format) com tamanhos
aproximados de 100 kilobytes, 1, 10 e 100 megabytes. Os dados selecionados possuem
variados tipos de finalidade, conforme mencionado alguns são arquivos de imagens, porém,
foi utilizada uma mídia de vídeo MP4 de 1 gigabyte.
Os Bancos de Dados Relacionais disponibilizam opções de armazenamento de dados
em um formato binário denominado tipo BLOB (Binary Large Object). Alguns bancos de
dados relacionais disponibilizam tipos de dados distintos para tratamento de dados
multimídia, por exemplo, o banco de dados PostgreSQL trabalha com o tipo OID, já o banco
de dados Microsoft SQL Server, utiliza um tipo de armazenamento por referencia externa
controlado pelo tipo FILESTREAM. As mídias citadas no parágrafo anterior foram inseridas
nos SGBDs relacionais utilizando esses três tipos de dados.
O Python foi a linguagem de programação escolhida para o desenvolvimento do
sistema que executa as operações de inserção e busca dos dados para a realização dos testes
necessários para analisar as abordagens de armazenamento multimídia. Foi necessária a
utilização de bibliotecas e drivers específicos para acessar e manipular cada banco de dados
experimentado, bem como, o framework web2py para acesso e controle em um cenário de
sistema web. As bibliotecas dos bancos de dados disponibilizaram os métodos para o
gerenciamento dos processos de bancos de dados, tais como conexão, inserção e recuperação
de dados, todos eles implementados e utilizados nos testes.
As técnicas de inserção e recuperação necessitam de métricas especificas para
execução dos processos do experimento, uma vez que os dados utilizados no experimento têm
tamanhos variados (na faixa de kilobytes, megabytes e gigabytes). Para que o experimento
tenha adequação tanto mídias de tamanho reduzido quanto aquelas com tamanho maior foi
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
51
necessário armazenar dados em fragmentos de tamanho reduzido, no caso deste trabalho 4
megabytes. Essa adaptação é necessária, pois há limitações de processamento em uma dada
imagem de uma só vez. Essas limitações são tanto no hardware do computador quanto nas
diversas arquiteturas de bancos de dados.
3.1. Arquitetura Implantada para a Execução do Experimento
O ambiente de testes foi construído para manter um servidor de aplicação aguardando
requisições dos clientes a partir de estações de trabalho, bem como um um servidor de banco
de dados que fornece o serviço de armazenamento dos diferentes SGBD’s utilizados nos
experimentos. Os SGBD’s foram montados sob um ambiente de virtualização sob o Monitor
de Máquina Virtual (Virtual Machine Monitor - VMM) Xen-hypervisor. Todas as VMs foram
definidas com as configurações tendo 2 núcleos de VCPUs, com memória 3.548 megabytes e
disco rígido virtual de 101.7 gigabytes, com o disco virtual no padrão VHD (Virtual Hard
Disk), reconhecido pelo Xenserver.
3.2. Procedimento Experimental
Os testes foram realizados com apoio da aplicação web desenvolvida para gerenciar as
operações de inserção e busca nos SGBDs. Para cada bateria de testes foram especificados o
SGBD utilizado, com o nome do banco de dados, o tipo de dado que representa o domínio da
informação (OID, FILESTREAM, BLOB), o tipo de operação (inserção/busca) e definição da
quantidade de ensaios que cada uma das operações será submetida. A lista dos bancos de
dados relacionais e não relacionais, juntamente com as versões utilizadas nos experimentos
são apresentados na tabela 2.
Como a aplicação foi desenvolvida na linguagem python, foram utilizados os módulos
(drivers) como meio de importação de bibliotecas adicionais ao código. Um módulo
representa um arquivo ou conjunto de arquivos contendo definições de declarações python.
Cada um dos SGBD possui um módulo específico para execução de operações em bancos de
dados. A tabela 2 apresenta a lista de módulos python utilizados para executar as operações de
banco de dados nos experimentos.
3.3. Execução do Experimento
O script da figura 2 ilustra o escopo do algoritmo de automatização do experimento. Esse
algoritmo foi adaptado para uma ilustração mais intuitiva de como o experimento são
executados por completo e como os tempos médios são capturados e calculados. A variável
list_datas na Figura 2 inicializa os requisitos de amostras de experimento, esse atributo possui
uma lista de nomes que representam as mídias coletadas. Deve-se observar que cada tabela
possui uma coluna com um tipo de dado específico.
Tabela 1: Módulos python para execução das operações nos bancos de dados.
Tipo de
Bancos de
Dados
Relacionais
SGBDs
(Referência)
Módulo
Python
Ver
são
IBM DB2 Express
http://www.ibm.com/us/en/
ibm_db2
10.1
Firebird
http://www.firebirdsql.org/
Kinterbasdb
2.5.2
PostgreSQL
http://www.postgresql.org/
psycopg2
9.1.6
Microsoft SQL
Server
http://www.microsoft.com/ptbr/server-cloud/products/sql-server/
Pyodbc
2008
http://couchdb.apache.org/
couchdb
1.2.1
Orientado a CouchDB
52
Link
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
Documento
Colunas de
Famílias
MongoDB
Hypertable
http://www.mongodb.org/
http://hypertable.org/
Pymongo
2.2.3
hypertable
0.9.7.
1
Cassandra
https://cassandra.apache.org/
pycassa
1.2.2
eXist
http://exist-db.org/
eulexistdb
2.0
BaseX
http://basex.org/
BaseXClient 7.6
XML
Para cada dado da lista de dados (list_data) serão executadas uma sequência de comandos.
Primeiramente o dado é lido parcialmente (executa-se a leitura dos 4Mbytes iniciais do dado
multimídia) para geração do valor md5. Em seguida, outro laço repetição é executado, para
executar as operações de inserção, consulta e deleção do dado. Nos experimentos, cada
operação foi repetida 11 vezes, sendo que o maior tempo gerado por uma operação foi
ignorado, e os outros 10 coletados foram usados para calcular o tempo médio.
Figura 7: Cálculo da média do tempo de execução de cada operação.
4. Resultados e Discussão
Os resultados das execuções dos testes foram organizados em duas classes, a dos testes
realizados com SGBDs relacionais, e dos testes com SGBDs NO-SQL. Foram gerados
gráficos de comportamento baseado em tempo de resposta para cada uma dessas classes, e as
analyses foram realizadas separadamente por operações, primeiramente em inserções, e em
seguida, através da recuperação dos dados multimedia.
4.1. Comparação em Bancos de Dados Relacionais
A figura 3 ilustra o tempo médio de execução, em milissegundos, do processo de
armazenamento em base de dados relacionais em milissegundos utilizando as amostras com
tamanhos variados de 100Kbytes à 1Gbyte aproximadamente. Já a figura 4 utiliza os mesmos
dados de amostra e apresenta o comportamento de execução para a operação de recuperação
dos mesmos dados multimídia nos bancos de dados relacionais.
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
53
Figura 8: Inserção de dados em Bancos de Dados relacionais.
O pior desempenho foi do armazenamento de tipo BLOB do PostgreSQL. O PostgreSQL
também armazena dados com tipo OID, que comparando com o tipo BLOB do mesmo banco
obteve quase a metade do tempo de execução em todos os tamanhos de dados testados. Dessa
forma é notável que o PostgreSQL precisou criar uma forma de armazenamento especifica
para tratar dados multimídia. Só que comparando o armazenamento OID com os tipos de
armazenamentos dos demais bancos de dados relacionais, observa-se que o desempenho foi
razoável.
De forma geral o IBM DB2 apresentou o melhor resultado na operação de inserção. Mas
apesar disso, esteve entre os piores desempenhos na operação de recuperação. Analisando a
figura 4 observa-se que a recuperação de um dado de 100 megabytes demandou por um maior
tempo de execução, ou seja, 23.099 milissegundos. Assim como na inserção, o
armazenamento do tipo BLOB do PostgreSQL obteve o pior desempenho na operação de
recuperação dos dados, registrando as maiores demandas de tempos para a recuperação de
dados de 1 Mbyte, 10 Mbytes e 1 Gbyte.
Os tipos diferenciados de armazenamento (OID e FILESTREAM) de forma geral
recuperaram dados em um espaço de tempo menor, tendo um melhor desempenho em relação
aos demais. Isso justifica a necessidade de utilizar esses tipos de armazenamento para o
processamento de dados multimídia. Visando o desempenho na operação de recuperação de
dados, na abordagem de bancos de dados relacionais, armazenar dados em forma de objeto,
ou em sistemas de arquivos são boas opções para o gerenciamento de grandes volumes de
dados não interpretados.
54
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
Figura 9: Recuperação de dados em Bancos de Dados relacionais.
4.2. Comparação em Bancos de Dados NoSQL
Os Bancos de Dados NoSQL são soluções de banco de dados que possuem características de
não implementarem o modelo relacional, distribuídos e horizontalmente escaláveis
(arquitetura distribuída – nothing sharing). Os bancos de dados NoSQL utilizam diferentes
abordagens para modelar e armazenar a informação utilizando estruturas hierárquicas nos
SGBDs XML, com o eXist e BaseX, estruturas de famílias de colunas, com o Hypertable e
Cassandra, e armazenamento de documentos, tendo como exemplos o MongoDB e CouchDB.
Cada um desses conjuntos de bancos de dados foram avaliados segundo a metodologia
proposta, e após a execução e análise, mostrados nas figuras 5 (inserção) e 6 (recuperação),
foi observado que o MongoDB obteve melhor desempenho na inserção de dados multimídia
de todos os tamanhos (100 Kbytes a 1 Gbytes) comparando com todos os bancos de dados
NoSQL testados neste trabalho. O CouchDB, apesar de ser orientado a documentos não
obteve um desempenho próximo ao obtido com o MongoDB. Isso individualiza o bom
desempenho em armazenamento de dados ao MongoDB e não somente a estratégia de
armazenamento e processamento de registros.
O pior desempenho observado nos SGBDs NoSQL na operação de inserção foi a do BaseX.
Foi observado nos testes que os Bancos de dados XML não obtiveram bom desempenho na
operação de inserção. Isso acontece porque houve a necessidade de converter os dados em
Base64, e isso gerou um custo de codificação de dado que foi adicionado ao tempo de
inserção dos dados, já que os documentos XML não interpretam dados binários diretamente.
Já os bancos de dados orientados a colunas obtiveram ótimos tempos na inserção. Tanto o
Hypertable quanto o Cassandra geraram resultados próximos ao melhor resultado (do
MongoDB). O bom desempenho é justificável pelo fato dos SGBDs orientados a colunas
serem projetados para armazenamento de grande volume de dados, esse fundamento se
adequa a armazenamento de dados multimídia.
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
55
Figura 10: Inserção de dados em Bancos de Dados NoSQL.
Apesar de alguns bancos de dados NoSQL processarem a inserção de dados muito
rápido, a abordagem de inserção de dados não sobrepõe a capacidade de recuperação desses
dados. Isso ocorre porque é melhor ter um banco de dados que recupere rapidamente os dados
e insira-os com desempenho razoável do que processar inserções mais rápidas e obter
desempenho mediano na recuperação de dados. Essa noção é bem compreensível se for
analisado que a solicitação de inserção em bancos de dados é menos requisitada do que a
operação de recuperação. Por exemplo, o dado de 1 Gbytes é inserido uma única vez no banco
de dados, já que não há necessidade de armazenar réplicas do mesmo dado. Mas a solicitação
de consulta desse dado pode ser requisitada diversas vezes, pois os processos de consulta de
forma geral são executados com maior frequência em uma solução que utiliza banco de dados.
A análise comparativa de recuperação de dados é prioritária na abordagem de bancos de
dados. O banco de dados NoSQL que obteve melhor desempenho na recuperação de dados
multimídia, em âmbito geral, foi o Hypertable (figura 6). O Hypetable processou a
recuperação de dados em menor tempo nos dados de tamanhos 1 Mbyte, 100 Mbytes e 1
Gbyte, respectivamente, com valores de 9.483 e 4.339 milissegundos. O MongoDB foi
melhor na recuperação de dados de tamanho 100 Kbytes e 10 Mbytes, mas em comparação
com o Hypertable esses valores são equivalentes.
Bancos de dados orientados a colunas tem proposito de armazenar grande volume de dados de
forma rápida. Segundo R. Cattel (2011) os grupos de colunas são atualizados em caches de
memória e posteriormente são liberados no disco rígido representados periodicamente de
forma compacta. Dessa forma, a recuperação de dados é processado muito rápido, pois os
dados são acessados diretamente na cache.
56
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
Figura 11: Recuperação de dados em Bancos de Dados NoSQL.
4.3. Análise Comparativa de todos os Bancos de Dados do experimento
Nas operações de inserção é curioso observar que os piores desempenho de armazenamento
de dados nos bancos de dados NoSQL testados gerou tempos de execução menores do que os
melhores desempenhos das inserções em bancos de dados relacionais. Observando as figuras
3 e 5, é possível notar que, os maiores valores de bancos de dados NoSQL a partir da
sequência, que indica os tamanhos de dados, são respectivamente: 62, 183, 1.260, 15.713 e
146.985. Os menores tempos gerados por bancos de dado relacionais são: 31, 184, 1.323,
15.282 e 153.059. Comparando sequencialmente é notável que os melhores tempos são dos
bancos de dados NoSQL.
Armazenamentos do tipo BLOB em banco de dados relacionais não obtiveram bons
desempenhos e alguns SGBDs necessitaram aplicar funcionalidades especificas para
tratamento dos dados multimídia. Assim como o PostgreSQL fornece o tipo OID, o Microsoft
SQL Server opta pelo FILESTREAM. Ambas as metodologias são diferenciadas e conseguem
recuperar dados com melhor desempenho do que os processamentos de BLOB em
armazenamentos relacionais.
Metodologias NoSQL são tendências na atualidade, e mostraram ser mais eficazes, em
termos de desempenho, na inserção e recuperação de dados multimídia. Bancos de dados
orientados a colunas, representados por Hypertable e Cassandra, são mais rápidos para
recuperar dados binários. O banco de dados MongoDB também demonstrou ótimo
desempenho para consulta de dados, mas o mesmo desempenho não foi aplicável ao
CouchDB que é do mesmo tipo.
5. Conclusão
Neste trabalho foram apresentadas e discutidas diversas abordagens para o armazenamento e
consulta de dados multimídia. Através dos resultados foi possível avaliar as diversas formas
de armazenamento, levando em consideração as diversas técnicas de banco de dados para
gerenciar a criação, atualização e exclusão dos dados. Foram analisadas estratégias que são
XVI Encoinfo – Encontro de Computação e Informática do Tocantins
57
apoiadas por técnicas de banco de dados com o objetivo de manter as informações
armazenadas de forma consistente, seguindo as propriedades ACID.
Com os resultados dos testes foi constatado que as abordagens de armazenamento
orientadas a colunas apresentaram-se como as mais promissoras neste cenário de
gerenciamento de dados multimídia, principalmente em termos de tempo de resposta. Esta
característica reforça o fato dos SGBDs NoSQL serem considerados como uma grande
tendência na atualidade, pois, todos testados neste trabalho mostraram-se ser bem eficientes
em termos de desempenho, tanto nas operações de inserção quanto nas de recuperação de
dados multimídia (dados complexos e não estruturados). Já os SGBDs Relacionais em termos
operacionais não obtiveram bons desempenhos utilizando armazenamento BLOB,
principalmente na recuperação de dados multimídias, mostrando-se ser uma boa solução para
dados simples e estruturados, porém, não sendo eficaz para dados complexos e nãoestruturados.
Referências
Bernuy, E.; Crispin, L. R.; Ribeiro, L. (2009). Análise de banco de dados com suporte a
multimídia. Universidades Anhembi Morumbi.
Cattell, Rick (2011). "Scalable Sql And Nosql Data Stores." Acm Sigmod Record, 39, pp.
412-27.
De Diana, Mauricio; Gerosa, Marco Aurélio (2010). Nosql na web 2.0: Um estudo
comparativo de bancos não-relacionais para armazenamento de dados na web 2.0.
Deitel, Harvey M. (2003). “Xml Como Programar”. Bookman.
Gilbert, S. and Lynch, N. (2002). Brewer's conjecture and the feasibility of consistent,
available, partition-tolerant web services. ACM SIGACT, 33, 2, pp. 51-59.
India, I. (2013). A Review On Document Oriented And Column Oriented Databases.
No-Sql (2014). “Not Only SQL”. Acesso 20/09/2014. Disponivel em: http://nosqldatabase.org/.
Silberschatz, Abraham, Henry F. Korth, and S. Sudarshan. (2006) Sistema de banco de dados.
Elsevier.
Tosatto, Daniele (2012). Citrix Xenserver 5.6 Administration Guide. Packt Pub Limited.
Vogels, W. (2009) “Eventually Consistent”. Communications of the ACM, January, 1, 52, pp.
40-44.
58
XVI Encoinfo – Encontro de Computação e Informática do Tocantins