Visao comparativa de gravacao de arquivos em sistema

UNIVERSIDADE ESTATUDAL DE MARINGÁ
Programa de Pós-graduação em desenvolvimento de sistemas
para web
João Eduardo Rosa da Fonseca
Visão comparativa de gravação de arquivos em sistema de
arquivos e em banco de dados utilizando servidor web
Maringá
2013
UNIVERSIDADE ESTATUDAL DE MARINGÁ
Programa de Pós-graduação em desenvolvimento de sistemas
para web
João Eduardo Rosa da Fonseca
Visão comparativa de gravação de arquivos em sistema de
arquivos e em banco de dados utilizando servidor web
Trabalho de conclusão do programa de pósgraduação em desenvolvimento de sistemas
web da universidade estatual de Maringá para
obtenção do título de especialista em
desenvolvimento web
Orientador: Munif Gebara Junior
Maringá
2013
2
A minha família e amigos,
Pela ajuda e incentivo durante minha trajetória
3
AGRADECIMENTOS
A todos que contribuíram para a realização deste trabalho, fica expressa
aqui a minha gratidão especialmente:
Ao professor Munif Gebara Junior, pela orientação, aprendizado e apoio
durante todo os momento necessários.
Aos meus colegas de classe durante toda trajetória do curso e pelas
amizades que permaneceram após o termino da etapa presencial.
Aos meus amigos que me apoiaram e me ajudaram de alguma forma após o
meu acidente de carro que ocorreu durante a etapa de escrita do presente trabalho,
em especial aos senhores Alessandro Willian e Ulter Witte que me receberam em
Florianópolis e me ajudaram.
Ao mestre e grande amigo Alex Mattos que leu e revisou o presente trabalho
por algumas vezes.
Ao senhor Edilson Hipolito, o qual eu conheci durante o curso e tive a honra
de ser seu padrinho de casamento.
Ao metallica e aos discos death magnetic e S&M, pink floyd e aos discos
dark side of the moon e pulse, assim como tantas outras bandas que compuseram
obras primas que me animaram durante a escrita deste trabalho.
A minha família que me apoiou sempre que necessário.
A todos que de alguma forma apoiaram para esta construção.
4
Visão comparativa de gravação de arquivos em sistema de arquivos e em
banco de dados utilizando servidor web
João Eduardo Rosa da Fonseca1
Resumo
O presente trabalho apresenta uma estudo de análise de comparação da
gravação de arquivo enviados pela web e armazenado de duas formas diferente, em
sistema de arquivo e em banco de dados. Para isso foram escolhidos quatro
diferentes banco de dados sendo três no modelo relacional e um do modelo NoSQL,
no caso dos modelos relacionais, foram escolhidos banco de dados com licenças do
tipo freeware, GPL, Comercial, que são os bancos de dados Postgres, MySql e
oracle, já no modelo NoSql foi escolhido o MongoDB. Os resultado obtidos mostram
que ambos os métodos de gravação de arquivos possuem suas vantagens e
desvantagens. Entre as vantagens apresentadas no caso dos bancos de dados
existem a manipulação de partes específicas dos arquivos, sistema de bakcup
incremental nativo do próprio gerenciados do banco de dados, melhor performance
na inserção e buscas dos dados no caso dos bancos NoSql. Já as desvantagens
nos bancos de dados estão no aumento do espaço de armazenamento, perda de
performance após a inserção de vários registros na tabela dos bancos relacionais.
Já a vantagens na gravação de arquivos no sistema de arquivos são a fácil
implementação, o arquivo ser uma cópia fiel ao arquivo de origem sem aumentar o
tamanho ou adicionar bytes de controle e a não instalação de um software
gerenciador. Já as desvantagens estão presente na hora de realizar backups,
comprar diferença de versões de arquivo, gerenciamento e localização de arquivos.
Palavra chave: banco de dados NoSql, banco de dados relacional, gravação de
dados.
5
LISTA DE FIGURAS
LISTA DE TABELAS
6
LISTA DE SIGLAS
ASCII – American Standard Code for Information Interchange
BLOB – Binary large object
CD – Compact disk
CLOB – Caracter larg object
DVD – Digital Versatile Disc
IBOPE – Instituto brasileiro de opinião pública e estatísticas
LOB – Large object
HTTP – Hypertext Transfer Protocol
NCLOB - National Character Large Object
NoSQL – Not only SQL
ORDBMS – object-relational database management system
PHP – Hypertext Preprocessor
SQL – Structured Query Language
SSD – Solid state disk
UOL – Universo on-line
7
SUMÁRIO
1.INTRODUÇÃO................................................................................. 11
2.DESENVOLVIMENTO........................................................................ 11
2.1.SOBRE CLIENTE/SERVIDORES........................................................ 11
2.2.SERVIDORES DE ARQUIVO............................................................ 12
2.3.SERVIDORES DE BANCO DE DADOS............................................... 12
2.4.SERVIDORES WEB........................................................................ 12
2.5.SOBRE ARQUIVOS........................................................................ 13
2.6.SOBRE BANCO DE DADOS............................................................. 13
2.6.1.RELACIONAIS............................................................................ 13
2.6.2.NÃO RELACIONAIS.................................................................... 14
2.7.SOBRE GRAVAÇÃO DE ARQUIVOS.................................................. 14
2.7.1.GRAVAÇÃO EM FILE SYSTEM...................................................... 14
2.7.2.GRAVAÇÃO EM BANCO DE DADOS.............................................. 14
2.7.2.1.ORACLE................................................................................. 15
2.7.2.2.MYSQL.................................................................................. 17
2.7.2.3.POSTGRESQL......................................................................... 17
2.7.2.4.MONGODB............................................................................. 17
3.CONSIDERAÇÕES FINAIS................................................................. 19
3.1.MYSQL........................................................................................ 19
8
3.1.1.POSTGRES................................................................................ 21
3.1.2.ORACLE.................................................................................... 21
3.1.3.MONGODB................................................................................ 21
4.RESULTADOS.................................................................................. 22
5.CONCLUSÃO................................................................................... 25
6.REFERÊNCIAS................................................................................. 26
1.
Introdução
Segundo reportagem do portal de tecnologia do UOL(Universo on-line) em 1 o
de novembro de 2012 com o título de “Ibope: internet no Brasil chega a 70,9 milhões
de pessoas em casa e no trabalho”, exibe dados coletados por pesquisas do
IBOPE(Instituto brasileiro de opinião pública e estatísticas) sobre o crescimento de
pessoas no Brasil que acessam a internet em casa e no trabalho, no mês de
setembro de 2012
esse número atingiu 70,9 milhões de usuários, sendo que
crescimento do números de usuários ativos em setembro de 2012 foi 1,4% maior em
relação a agosto do mesmo ano e 11% maior que no mesmo período de 2011. (UOL
notícias, 2013)
Em outra reportagem publicada no portal exame da editora abril em 02 de
junho de 2011 com o título: “Você sabe o tamanho da internet?”, que toma como
base os estudo visual networking index realizado pela cisco que afirma que “A
estimativa é de que, hoje, o trafego da internet produz por hora informações
suficientes para ser contidas em 7 milhões de DVDs (Exame.com, 2013). O estudo
realizado pela cisco ainda prevê que em 2015 o trafego por hora produza 966
exabytes de informação, o que daria para preencher 28 milhões de DVDs.
9
Essas duas reportagens mostra que popularização da internet por meio de
banda larga, e a quantidade de conteúdo produzido na internet mostra que cada vez
mais o armazenamento de grande capacidade de dados será necessária. Para esse
armazenamento existem diversas técnicas de recebimento, processamento e
armazenamento dos dados produzidos. Essas técnicas variam desde a gravação do
arquivo em uma pasta do sistema operacional, até do armazenamento dos dados e
documentos como registros de banco de dados.
2.
Desenvolvimento
Inicialmente para entendimento da diferença entre a gravação dos
documentos em forma de arquivos, é necessário entender a diferença básica entre
as duas forma de armazenamento, a em arquivo de sistema e como registro em
banco de dados.
A gravação de arquivos em sistema de arquivos(file system) originados de
uma requisição web é realizada é chamada de upload. O arquivo é envidado para
um servidor web via protocolo http, onde o servidor recebe e armazena o arquivo
em uma pasta no seu disco, nesse caso o usual é que no banco de dados fique
armazenado o nome do arquivo com o seu caminho físico em disco.
(Searchnetworking, 2013)
Já no upload e gravação de arquivo em banco de dados, o arquivo é
convertido uma cadeia de byte, cada banco de dados tem seu tipo de dado(data
type) para armazenar cadeias de bytes, essa cadeia de bytes é enviada para uma
coluna no banco de dados(Searchnetworking, 2013), dependendo do tamanho do
arquivo é possível ser armazenado em um só registo, mas em alguns data types tem
limitações de tamanho dos dados, fazendo assim que se use uma estratégia onde
10
arquivo é quebrado em várias cadeias de bytes e essas cadeias são inseridas em
vários registros no banco de dados. Quando o usuário requisita o arquivo, é
necessário que o registro ou registros sejam recuperado e convertido novamente
para arquivo através de um algoritmo.
2.1. Sobre Cliente/servidores
Na arquitetura cliente/servidor, o servidor seria o responsável pelo controle e
centralização
de
informações
que
são
compartilhadas
e
acessadas
por
computadores em uma rede, os computadores que fazem o acesso ao servidor são
nomeados de clientes. segundo Júlio Battisti : “É uma arquitetura onde o
processamento da informação é dividido em módulos ou processos distintos. Um
processo é responsável pela manutenção da informação (Servidor), enquanto que
outro é responsável pela obtenção dos dados (Cliente)” (BATTISTI, 2001).
Assim sendo, a arquitetura de cliente servidor pode ser utilizado tanto na
forma de gravação de arquivos via file system, assim como na gravação de arquivos
em banco de dados. também é necessário entender que para que a arquitetura de
cliente/servidor funcione de forma eficiente, há um componente vital entrer o cliente
e o servidor, que é a infraestrutura de rede. Essa infraestrutura de rede influencia
diretamente na performance de subira(Upload) e descida(Download) dos arquivos
do servidor para o cliente, assim sendo, uma rede melhor estruturada, com
equipamentos de alta velocidade, ou mesmo a utilização de serviços de banda largar
no caso da internet fazem com que arquivos sejam enviado e recuperado no
servidor de forma mais ágil e rápida. Outra coisa que influencia na velocidade é o
poder de processamento do servidor, a quantidade de memória e quantos acessos o
servidor está recebendo no instante da recuperação de arquivos. Pois quanto maior
o número de acessos, maior é o consumo de memória do servidor e maior é o
11
consumo da banda da rede, tornado assim mais lento o acesso e recuperação do
arquivo armazenado no servidor . Segue a ilustração da arquitetura cliente/servidor.
Figura - Arquitetura cliente/servidor
Fonte :Cliente/Servidor, 2013
Nos próximos capítulos iremos explorar mais a fundo o funcionamento de
toda a estrutura da arquitetura cliente/servidor.
2.2. Servidores de arquivo
Segundo o site da microsoft sobre servidores de arquivo: “O servidor de
arquivos fornece um ponto centralizado na rede para armazenamento e
compartilhamento de arquivos entre os usuários. Quando desejarem usar um
arquivo importante, como um planejamento de projeto, os usuários podem acessá-lo
diretamente no servidor de arquivos, em vez de precisarem repassar o arquivo entre
cada computador. Se os usuários da rede precisarem acessar os mesmos arquivos
12
e aplicativos acessíveis pela rede, configure o computador como servidor de
arquivos.” (Microsoft, 2012)
Assim sendo, o servidor de arquivo tem um papel fundamental nas
empresas, centralizando o compartilhamento de arquivos e sendo uma tentativa de
evitar que esses arquivos seja compartilhado com todos a todo momento, assim
como evitar que o mesmo arquivo tenha cópias de diferentes versões.
Com a evolução das redes de dados, dispositivos de armazenamento e
serviços providos na internet, os servidores de arquivos passaram a ser uma
ferramenta que não precisa mais ficar alocado dentro da empresa e sim como um
serviços na internet. A disponibilização do servidor de arquivos como serviço
permitiu que a sua utilização deixa-se de ser apenas pelo meio coorporativo e
passou a estar disponível também para o uso particular. Existem alguns exemplos
de servidores de arquivos disponível como serviço e utilizado de forma particular
hoje em dia, como o google drive da google, Skydrive da microsoft, Dropbox da
Dropbox inc. entre outros. Mas não é possível saber se esse servidor de arquivos
armazena os documentos em file system ou em banco de dados.
Existem também servidores de arquivos para compartilhamento de arquivos
de forma pública, onde o usuário disponibilizam arquivos que podem ser baixados
por qualquer usuário com conexão de internet e um browser. Essa forma de
compartilhamento de arquivo gerou alguns problemas depois de um tempo por uma
grande quantidade de usuários disponibilizarem arquivos com conteúdo protegido
por direito autoral. alguns desses serviços públicos de servidor de arquivos
chegaram a ser fechados judicialmente como por exemplo o mega upload. já outros
mudaram sua política de publicação de conteúdo como por exemplo os serviços do
4shared, RapidShare, MediaFire etc.
13
Mas o objetivo do artigo não é falar sobre a parte legal do compartilhamento
de arquivos e sim a forma com que esses dados podem ser armazenados.
2.3. Servidores de banco de dados
Os servidores de banco de dados, tem como finalidade ser o ponto central
de armazenamento de informações em um sistema de tabelas, sendo ela relacional
ou não. segundo Júlio Battisti: “Sistema inovador surgido nos anos 90 e muito
utilizado
no
meio
corporativo,
baseado
em
três
componentes
principais:
gerenciamento de banco de dados, que funcionam como servidores; redes, que
funcionam como meio de transporte de dados e, finalmente, softwares para acesso
aos dados: Clientes”. (BATTISTI, 2001, pg 39).
Esse software para acesso apontado por Battisti, pode ser desde um simples
browser de internet fazendo uma requisição de informações para o servidor de
banco de dados. até uma aplicação específica criada para acessos mais específicos
de dados.
Um diferencial do servidor de banco de dados é que além de fornecer um
ponto central para o armazenamento de arquivos, é possível também armazenar
dados de outros tipo de informações pertencente a uns sistema implementado para
o cliente. Um outro ponto forte dos servidores de banco de dados seria que a
próprias ferramenta fornece mecanismos realização de backups, recuperação por
meio de um arquivo único de todas as informações assim como funções
desenvolvidas para que o banco realize esses backup’s de forma automatizada.
2.4. Servidores web
Como o presente trabalho tem como objetivo demostrar a gravação de
arquivos nos servidores de arquivos e de banco de dados por meio de um ambiente
web, não poderíamos deixar de falar do servidor web. O servidor web tem como
finalidade fornecer os serviços uma aplicação web, interagindo assim com os outros
14
servidores(arquivos e banco de dados) em um ambienta acessado por um navegar.
segundo o site da microsoft “Servidores web são computadores com software
específico que permitem a aceitação de solicitações de computadores de clientes e
retornam respostas à essas solicitações. Os servidores web permitem que você
compartilhe informações pela Internet ou por uma intranet ou extranet.”.(Microsoft,
servidor web, 2012)
No site da microsoft, ainda é apontado algumas finalidades de uso dos
servidores. Que no caso do site expõem algo mais voltado para o servidor
desenvolvido pela própria empresa, chamado de IIS(Internet Information Services).
Na tabela 1 segue os exemplos das aplicações em servidores web IIS 7
Tabela - Aplicações dos servidores web
Fornecer informações para usuários pela Internet.
Permitir que usuários façam download e upload de conteúdos com
FTP ou WebDAV (criação e versão distribuídas na Web).
Hospedar serviços da Web que contém lógica empresarial para
aplicativos de três camadas.
Distribuir aplicativos para usuários pela Internet ao invés de disquetes
ou CDs.
Os servidores Web podem ser úteis para clientes e necessidades
diferentes. Por exemplo:
Proprietários de pequenas empresas podem fornecer informações
sobre seus serviços usando um simples site.
Proprietários de empresas médias podem oferecer seus produtos e
serviços por meio de um sistema de pedidos online composto por vários
aplicativos em um site.
Empresas de negócios podem desenvolver e fornecer aplicativos de
negócios a funcionários por meio de intranets corporativas.
Empresas de hospedagem podem fornecer, a clientes individuais,
espaço e serviços de hospedagem de diferentes conteúdos online e
aplicativos.
Empresas podem fornecer aplicativos de negócios e informações
pertinentes para parceiros de negócios por meio de extranets.
Fonte: Microsoft
15
Mas assim como a escolha de qualquer tipo de servidor, o dimensionamento
dos recursos do servidor web passa por uma análise das necessidades da aplicação
desenvolvida e da quantidade de recurso que sua aplicação irá necessitar.
2.5. Sobre arquivos
Os arquivos de computadores são, um conjunto de bytes estruturado
armazenados em algum meio que pode ser recuperado depois.
Essas estruturas são armazenadas e contém uma extensão responsável por
indicar qual o programa responsável pela leitura, processamento e abertura desse
arquivo, assim, recuperando a informação contidas nele.
Existe
também
arquivos
denominados
executáveis,
esses
arquivos
conseguem a partir da sua própria estrutura serem abertos e lidos para executar
ações pré definidas.
2.6. Sobre banco de dados
Atualmente existe um grande número de banco de dados que podem ser
instalado e utilizados em servidores, a definição de qual o banco de dados será
utilizado em sua aplicação, varia muito do que será desenvolvido e o que esse
aplicativo irá necessitar armazenar de dados. É comum que a escolha do sistema de
banco de dados passe por uma avaliação criteriosa que vai desde a quantidade
prevista de acessos simultâneos, tipo de dados que serão armazenados, até quais
as licenças que esse sistema de banco de dados segue para a sua utilização.
Os banco de dados, tem como princípio básico seguir alguns atributos, como
tabelas, registros, colunas e chaves.
Uma tabela é uma simples estrutura de linhas e colunas. Em uma tabela,
cada linha contém um mesmo conjunto de colunas. Em um banco de dados podem
existir uma ou centenas de tabelas, sendo que o limite pode ser imposto tanto pela
16
ferramenta de software utilizada, quanto pelos recursos de hardware disponíveis no
equipamento.
As colunas de uma tabela são também chamadas de atributos. Ex.: O
campo Nome, ou endereço de uma tabela de um banco de dados relacional.
Os registros são linhas formadas por pelas colunas, mas não
necessariamente todas as colunas precisam estar completas, apenas as que estão
estabelecidas como não nulas(Not null).
As tabelas relacionam-se umas as outras através de chaves. Uma chave é
um conjunto de um ou mais atributos que determinam a unicidade de cada registro.
Existem diferentes tipos de bancos de dados, sendo diferenciados sempre
pela sua estrutura de armazenamento e recuperação de informações. Os banco de
dados são divididos em duas classes, os relacionais e os não relacionais, que
também são conhecidos como NoSql.
2.6.1.
Relacionais
Os banco de dados relacionais, são bancos de dados mais utilizados em
aplicações por seguirem as 13 regras do modelo relacional, essas regras foram
criadas e publicadas por Edgar Frank Codd em 1985, para que o banco de dados
seja considerado relacional, ele deve seguir as seguintes regras apresentadas na
tabela 2.
Tabela - As 12 regras de Codd
Regra
Regra 1
Descricação
Todas as informações em um banco de dados relacional são
representadas de forma explícita no nível lógico e exatamente em
Regra 2
17
apenas uma forma - por valores em tabelas.
Cada um e qualquer valor atômico (datum) em um banco de
dados relacionam possui a garantia de ser logicamente acessado
pela combinação do nome da tabela, do valor da chave primária e
Regra 3
do nome da coluna.
Valores nulos devem ser suportados de forma sistemática e
independente do tipo de dado para representar informações
Regra 4
inexistentes e informações inaplicáveis.
A descrição do banco de dados é representada no nível lógico da
mesma forma que os dados ordinários, permitindo que usuários
autorizados utilizem a mesma linguagem relacional aplicada aos
Regra 5
dados regulares.
Um sistema relacional pode suportar várias linguagens e várias
formas
de
recuperação
de
informações. Entretanto, deve haver pelo menos uma linguagem,
com uma sintaxe bem definida e expressa por conjuntos de
caracteres, que suporte de forma compreensiva todos os
seguintes itens: definição de dados, definição de "views",
manipulação de dados (interativa e embutida em programas),
restrições de integridade, autorizações e limites de transações
Regra 6
(begin, commit e rollback).
Todas as "views" que são teoricamente atualizáveis devem
Regra 7
também ser atualizáveis pelo sistema.
A capacidade de manipular um conjunto de dados (relação)
através de um simples comando deve-se estender às operações
Regra 8
de inclusão, alteração ou exclusão de dados.
Programas de aplicação permanecem logicamente inalterados
quando ocorrem mudanças no método de acesso ou na forma de
Regra 9
armazenamento físico.
Mudanças nas relações e nas views provocam pouco ou nenhum
impacto nas aplicações.
18
Regra 10
As aplicações não são afetadas quando ocorrem mudanças nas
Regra 11
regras de restrições de integridade.
As aplicações não são logicamente afetadas quando ocorrem
Regra 12
mudanças geográficas dos dados.
Se um sistema possui uma linguagem de baixo nível, essa
linguagem não pode ser usada para subverter as regras de
integridades e restrições definidas no nível mais alto.
Fonte: Serpro
2.6.2.
Não relacionais
Bancos não relacionais ou conhecido como NoSql, são bancos criados para
atender a necessidades de aplicações onde os bancos de dados relacionais são
ineficazes. O termo foi utilizado pela primeira vez em 1998 por seu criado, Carlo
Strozzi, onde ele dizia que o NoSql “é complemente distindo do modelo relacional e,
portanto, deveria ser mais apropriado chamado de “NoREL” ou algo que produzisse
o mesmo efeito”. (NoSql, 2012)
As principais características dos bancos de dados não relacionais são a sua
alta performance, replicação, escalabilidade, suporte a dados estruturados e sub
colunas
Os bancos de dados não relacionais, ou também conhecidos como NoSQL,
são bancos que não seguem os princípios das leis de Edgar Frank Codd, assim
sendo, ele armazena os dados de diferentes formar, normalmente esses dados são
armazenados com arrays associativos ou pares de chave e valor.
Os bancos NoSQL são normalmente utilizados para finalidades específicas,
conforme a tabela 3 demostra:
Tabela - Projetos NoSql
Tipo
Documento
Projeto
RavenDB, CouchDB, MongoDB,
MarkLogic, Server, BaseX, eXist
19
Orientado a Objetos
Db4o
Chave/Valor (Key/Value)
Memcachedb, Project
Voldemort, Redis, SimpleDB, Hbase
Tabular
Cassandra e Hypertable
Grafos
DEX e Neo4j
Fonte:NoSql
2.7. Sobre gravação de arquivos
A gravação de arquivos pode ser feita em vários meios, pois os blocos de
bytes, podem ser divididos e armazenados em diversos tipos dispositivos e de
diversas formas diferentes, seja ela diretamente no dispositivo de armazenamento,
banco de dados, além disso o arquivo pode ser compactado, criptografado, divididos
em blocos etc, antes de sua gravação.
2.7.1.
Gravação em file system
A gravação em file system, ou também conhecida como sistema de arquivos
é realizada em pequenos blocos pré-definidos no sistema operacional, esse blocos
são conjunto de bytes que o sistema operacional padroniza para gravar e recuperar
os arquivos direto de disco rígidos, SSD(Solid state disk), fita magnética,
CD(Compact disk) ou qualquer outro meio de gravação.
2.7.2.
Gravação em banco de dados
Para a gravação de arquivos em banco de dados, existem tipos específicos
de campos para registro e técnicas diferentes técnicas de inserção dos dados. Para
entender a gravação desses arquivos no banco, é necessário entender os tipo de
arquivo que será gravado e como essas informações são armazenadas.
Nos bancos de dados relacionais, cada banco tem o seu tipo específico de
registro de como armazenas esses arquivos. No caso dos bancos escolhidos para o
prensente trabalho, Foram escolhidos bancos de dados de diferentes tipo de
20
licenças, Sendo escolhido no modelo relacional o Postgres, MySql e oracle, já no
modelo NoSql foi escolhido o MongoDB.
Na tabela 4 é possível visualizar os tipos de dados e o tamaho máximo que
é possível armazenar nesses registros
Tabela - Tipos de dados
Nome
Oracle 11g
MySql
PostgreSQL
Tipo para
gravação de dados
BLOB, CLOB,
NCLOB, BFILE
TINYBLOB,
TINYTEXT
BLOB, TEXT
MEDIUMBLOB,
MEDIUMTEXT
LONGBLOB,
LONGTEXT
BYTEA(HEX,ES
CAPE)
Máximo por
registro
128 terabytes
256 bytes
64 Kilobytes
16 Megabytes
4 Gigabytes
1 Gigabytes
Fonte: Desenvolvida pelo autor.
2.7.2.1. Oracle
O Banco de dados oracle 11g possuí o diferentes tipos de dados para
armazenamento de arquivos, esses tipos de dados são chamado de LOB(Large
object) e são divididos em sub-tipo que são os BLOB(Binary large object),
CLOB(Caracter larg object), NCLOB e BFILE. segundo a documentação da oracle
subro os tipos LOB “permitem armazenar e manipular grandes blocos de dados não
estruturados (como texto, imagens, gráficos, vídeos, som e formas de onda) em
formato binário ou caracteres.” (Oracle, 2013, tradução nossa)
Ainda na documentação, a oracle descreve como os tipos LOBs trabalham
que é: “eles fornecem acesso aleatório, eficiente a pedaços inteligentes dos
dados.”(Oracle, 2013, tradução nossa)
Os dados do tipo LOB diferem em dois tipos, os RAW e LONG RAW. Mas
ele explica que ambos os tipos não são interpretados pelo banco de dados: “Os tipos
21
de dados RAW e LONG RAW são usados para dados que não deve ser interpretado
(não convertido ao mover dados entre diferentes sistemas) pelo banco de dados
Oracle. Esses tipos de dados são destinados para dados binários ou cadeias de
bytes.”(Oracle, 2013, tradução nossa). O que indica que por exemplo uma imagem
armazenada em banco, é convertida para dados binários ou cadeiras de bytes. Caso
uma consulta seja realizada por uma query no banco irá não irá mostrar a imagem,
mas sim os dados binários ou a cadeia de bytes. Para que a imagem seja exibida,
será necessário que um programa consulte o banco e converta os dados binário ou
a cadeia de bytes na imagem.
Na documentação do oracle 11g ainda explica que LONG RAW pode ser
usado para armazenar gráficos, som, documentos, ou matrizes de dados binários. A
interpretação depende do uso. RAW é um tipo de dados de comprimento variável
como o tipo de dados de caractere VARCHAR2,
A documentação indica que “LONG RAW dados não podem ser indexados,
mas RAW dados podem ser indexados.” (Oracle, 2013, tradução nossa)
A tabela 5 mostra outras características dos tipos de dados RAW e LONG
RAW indicadas na documentação do banco dados oracle 11g.
Tabela - Caracteristicas de RAW e LONG RAW
Uma tabela pode conter colunas LOB, mas apenas uma coluna
LONG.
Uma tabela contendo uma ou mais colunas LOB pode ser dividida,
mas uma tabela contendo uma coluna LONG não pode ser particionado.
O tamanho máximo de um LOB é de 128 terabytes, dependendo do
tamanho do bloco de dados, e o tamanho máximo de um LONG é de apenas
2 gigabytes.
LOBs apoiar o acesso aleatório a dados, mas LONG s suportam
22
apenas acesso seqüencial.
Tipos de dados LOB (exceto NCLOB ) pode ser atributos de um tipo
de objeto definido pelo usuário, mas tipos de dados LONG não pode.
LOBs temporários que atuam como variáveis locais podem ser
usados para realizar transformações em dados LOB. LOBs temporários
internos ( BLOBs, CLOBs e NCLOB s) são criados em um espaço de tabela
temporária e são independentes de tabelas. Para tipos de dados LONG, no
entanto, não há disponibilidade de estruturas temporárias.
Tabelas com colunas LOB pode ser replicadas, mas tabelas com
colunas LONG não pode
Fonte: Oracle
Depois de entendermos sobre o funcionamento dos dados RAW e LONG
RAW, podemos prosseguir com o entendimento dos tipo de dados que pertencem ao
LOB, que são os BLOB, CLOB, NCLOB e BFILE.
Na documentação do oracle 11g, afirma sobre o BLOB que: “O tipo de dado
BLOB armazena dados binários não estruturados no banco de dados. BLOBs pode
armazenar até 128 terabytes de dados binários.” (Oracle, 2013, tradução nossa)
Os tipo CLOB e NCLOB são diferenciados do BLOB por armazenarem os
dados em forma de caracteres: “Os tipos de dados CLOB e NCLOB armazenar até
128 terabytes de dados de caracteres do banco de dados.”(Oracle, 2013, Tradução
nossa).
Ainda sobre CLOB e NCLOB, a documentação fala mais especificamente
sobre o CLOB: “O tipo de dados CLOB armazena dados de caracteres de byte único
e multibyte. Ambos os conjuntos de caracteres de largura fixa e variável são
suportados, e ambos utilizam o conjunto de caracteres do banco de dados.
23
E sobre NCLOB: “O tipo de dados NCLOB armazena dados Unicode. Ambos
os conjuntos de caracteres de largura fixa e variável são suportados, e ambos
utilizam o conjunto de caracteres nacionalizados.”(Oracle.2013. Tradução nossa).
Já por fim o tipo BFILE armazena os dados arquivos do sistema operacional,
ou seja, fora do banco de dados: “O tipo de dado BFILE são dados binários não
estruturados de em arquivos do sistema operacional fora do banco de dados. A
coluna ou atributo BFILE armazena um arquivo localizador que aponta para um
arquivo externo que contém os dados. A quantidade de dados BFILE que podem ser
armazenados é limitado pelo sistema operativo.
BFILEs são somente leitura, você não pode modificá-los. Eles suportam
apenas leituras aleatórias (não sequencial), e não participar de transações. O
sistema operacional subjacente deve manter a integridade de arquivos, segurança e
durabilidade para BFILEs. O administrador de banco de dados deve garantir que o
arquivo existe e que os processos de banco de dados Oracle tem permissões de
leitura do arquivo no sistema operacional.”(Oracle, 2013, Tradução nossa)
Na documentação da oracle, as colunas do tipo LOB são sujeitas a algumas
regras, a tabela 6 lista algumas delas.
Tabela - Regras das colunas LOB
Você não pode especificar um LOB como uma coluna de chave
primária.
Clusters não pode conter LOBs, quer como chave ou colunas nãochave.
Você não pode especificar colunas LOB no ORDER BY cláusula de
uma consulta, ou no GROUP BY cláusula de uma consulta ou em uma
função agregada.
24
Você não pode especificar uma coluna LOB em uma SELECT ...
DISTINCT ou SELECT ... UNIQUE declaração ou em uma junção. No
entanto, você pode especificar um atributo LOB de uma coluna de tipo de
objeto em um SELECT ... DISTINCT ou em uma consulta que usa a UNION
ou operador MINUS de conjunto, se o tipo da coluna objeto tem um MAP ou
ORDER função definida sobre ele.
O (primeiro INITIAL extensão) de um segmento de LOB deve conter,
pelo menos, três blocos de dados.
Você não pode especificar uma coluna LOB, como parte de uma
chave de índice. No entanto, você pode especificar uma coluna LOB na
especificação indextype de um índice de domínio. Além disso, o Oracle Text
permite que você defina um índice em uma coluna CLOB.
Em uma operação INSERT ... AS SELECT, você pode ligar até 4000
bytes de dados para colunas LOB e atributos
Se a tabela tem tanto LONG e colunas LOB, você não pode ligar
mais de 4000 bytes de dados tanto para o LONG e colunas LOB na mesma
instrução SQL. No entanto, você pode ligar mais de 4000 bytes de dados
para tanto o LONG ou a coluna LOB.
Restrições de operação
No SQL Loader, Um campo de leitura de um LOB não pode ser
usado como um argumento para uma cláusula. Consulte "Utilitários de banco
de dados para carregar dados em LOBs" .
Sessão migração não é suportada para BFILE em servidor modo
compartilhado (servidor multithreaded). Isto implica que as operações em
aberto BFILE podem persistir para além do final de uma chamada para um
servidor compartilhado. Em sessões de servidor compartilhado, BFILE
operações são obrigados a um servidor compartilhado, que não podem
migrar de um servidor para outro.
Maiúsculas e minúsculas pesquisas sobre colums CLOB muitas
vezes não conseguem. Por exemplo, para fazer uma pesquisa de maiúsculas
e minúsculas em um colum CLOB.
25
A seleção não sem a LOWER função. Texto Oracle faz pesquisas
maiúsculas e minúsculas.
Fonte: Oracle
2.7.2.2. MySql
O banco de dados MySql, é um banco de dados que se tornou popular com
a expansão web e foi difundido principalmente por programadores php. Atualmente o
MySql pretence a Oracle Corporation.
O MySql, assim como os outros bancos de dados, possui um tipo de registro
especifico para arquivos, assim como já citado anteriormente, os tipos de registros
são o BLOB, e o TEXT. Segundo o site do MySql: “Um BLOB é um objeto binário
grande que pode guardar uma quantidade variável de dados. Os quatro tipos de
BLOB são TINYBLOB , BLOB , MEDIUMBLOB , e LONGBLOB. Estes diferem
apenas no comprimento máximo dos valores que eles podem armazenar. Os quatro
tipos TEXT são TINYTEXT , TEXT , MEDIUMTEXT , e LONGTEXT . Estes
correspondem aos quatro tipos BLOB e têm o mesmo tamanho máximo e os
requisitos de armazenamento.”(MySql, 2013, tradução nossa).
Ainda na documentação do MySql, a diferença entre o BLOB e o Text
são:”BLOB são valores tratados como strings binárias (cadeias de bytes). Eles não
têm nenhum conjunto de caracteres, e ordenação e comparação, são baseados nos
valores numéricos dos bytes de valores da coluna. TEXT são valores tratados como
strings não binários (sequências de caracteres). Eles têm um conjunto de
caracteres, e os valores são classificados e comparados com base no agrupamento
do conjunto de caracteres.”(MySql. 2013. Tradução nossa). Segue a tabela 7
demosntra os tamanhos máximos que podem ser armazenados os dados em bytes.
Tabela - Tamanho máximo dos dados no MySql
26
Tipo de dado
Tamanho
L + 1 bytes, where L <
28
TINYBLOB, TINYTEXT
L + 2 bytes, where L <
216
BLOB, TEXT
L + 3 bytes, where L <
MEDIUMBLOB, MEDIUMTEXT 224
L + 4 bytes, where L <
232
LONGBLOB, LONGTEXT
Fonte: MySql
2.7.2.3. PostgreSQL
Segundo o site do PostgreSQL,: “O PostgreSQL é um sistema de gestão de
banco de dados objeto-relacional (ORDBMS) com base no POSTGRES, Versão
4.2 , desenvolvido no Departamento de Informática da Universidade da Califórnia,
em Berkeley. O POSTGRES foi pioneiro muitos conceitos que só se tornaram
disponíveis em alguns sistemas de banco de dados comerciais muito mais tarde.
“(Postgres, 2013. Tradução nossa).
O
padrão SQL define
que
o
tipo
de
cadeia
binária
é
chamada
de BLOB(Binary Large Object). Mas no caso do PostgreSQL o tipo de
armazenamento de dados binários possuem um nome diferente que é o byteae foi
inserido no postgres a partir da versão 9.0. Mesmo com o nome diferente, as
funções e operadores fornecidos para a operação são praticamente os mesmos.
O
tipo
bytea
é
descrito
na
documentação
como:
“O
tipo
de
dado bytea permite o armazenamento de sequências binárias”.(Postgres, 2013,
tradução nossa )
Essas sequências binárias
de bytes são sequencias diferenciadas de
sequência de caracteres por exemplo, onde a sequência de caracteres são
codificados normalmente pela tabela ASCII com os caracteres imprimíveis(códigos
27
entre 32 e126), Assim sendo no tipo bytea são permitido codificações de tipos não
imprimíveis. O bytea também é um tipo que não sofre de problemas de codificação
de localidade como no caso de sequencia de caracteres. Em termos, o bytea serve
para armazenar bytes de dados brutos e as sequencias de caracteres servem para
armazenar textos.
O tipo bytea são diferenciados em dois formatos, o hex e o escape, sendo o
escape o tipo de dado mais tradicional do postgresql. No caso do escape ele segue
a linha de converter as sequências binárias em sequências de caracteres ASCII. Ao
converter os dados para sequencias não representadas pela tabela ASCII, o escape
utiliza caracteres especiais do próprio tipo escape. Essa conversão é iniciada
sempre com um ou duas barras invertidas (a barra invertida é um “escape” literal) e
faz com que cada byte seja convertido para um conjunto de três dígitos. O
mecanismo de caracteres especiais do tipo escape é um pouco pesado, assim
sendo, a utilização da conversão de bytes para o tipo escape deve ser evitada.
No caso do formato hex, cada registro é iniciado com \x e cada byte dos
dados são codificados para dois dígitos hexadecimais, é permitido espaço entre os
pares de valores hexadecimais, mas não é permitido espaço em branco entre o par
do bytes convertido para hexadecimal. O tipo hex é o tipo padrão do postgres e
tende a ser mais rápido que a conversão para o tipo escape, assim sendo, é
preferencialmente usando nas aplicações.
Ao inserir um registro do tipo bytea, é acrescido de 1 a 4 bytes como bytes
de controle e mais a sequencia de bytes convertidos. Assim sendo cabe avaliar o
quanto esses bytes de controle podem influir no tamanho do arquivo inserido em
bando e no desempenho para sua recuperação, principalmente no caso de um
arquivo que foi quebrado em diversos registro.
28
2.7.2.4. MongoDB
O mongodb é um banco de dados open source orientado a documento
desenvolvido para fácil uso de desenvolvimento e escalabilidade.
Para iniciar o entendimento de como funciona um banco de dados orientado
a documentos, na tabela 8 vamos comprar e entender os termos e conceitos entre
um banco de dados objeto relacional e um banco de dados NoSQL.
Tabela - Comparação dos termos e conceitos do Sql e NoSql
Termos e conceitos do SQL
Database
Table
Row
Index
Table joins
Termos e conceitos do MongoDB
Database
Collection
Documento ou documento BSON
Index
Documentos
embarcados
ou
linkados
Primary key(chave primária) uma única Primary key(Chave primária) No
coluna ou uma combinação de colunas
mongoDB, a chave primária é
setada
Agregação(Group by)
automaticamente
no
campo _id
Framework de agregação
Fonte: MongoDB
No caso citado na tabela anterior, o framework de agregação possui uma
tabela indicando um outro comparativo de como funciona em um banco de dados
SQL e o mongoDB. A tabela 9 mostra essa diferença.
Tabela - Comparativo de termos, funções e conceitos Sql e NoSql
Termos, funções e conceitos SQL
WHERE
GROUP BY
HAVING
SELECT
ORDER BY
LIMIT
SUM()
COUNT()
29
Operações
mongoDB
$MATCH
$GROUP
$MATCH
$PROJECT
$SORT
$LIMIT
$SUM
$SUM
de
agregação
do
JOIN
Não
existe
correspondente
um
ao
operador
JOIN
no
mongoDB, de toda forma, o operador
$UNWIND
tem
funcionalidades
semelhantes com as colunas e com
os documentos.
Fonte: MongoDB
No mongoDB a gravação de arquivo é feita atrás vez de um BinData é feita
por um registro do tipo BSON(Binary-encoded serialization), que é um registro
semelhante ao JSON só que para inserção de documentos. O BSON foi projetado
pra ser leve e eficiente, assim como JSON. O BSON suporta a incorporação de
objetos e arryas dentro de outros objetos e matrizes.
No entando para armazenamento de arquivos maiores de 16 megabytes a
documentação do mongodb fala para usar o GridFS como alteranativa, o GridFS tem
por padrão pegar os arquivos que excedam 16 megabytes e dividir em blocos
menores de 256k, nesta divisão ele utiliza duas coleções para realizado
armazenamento dos dados, sendo uma para armazenar os pedrações dos arquivos
e outra para armazenar o metadados. Uma das vantagens em usar o GridFS é que
ao caso o usuário necessite carregar um arquivo particionado, ele vai montando os
pedaços do arquivo conforme necessário, assim sendo, você pode realizar consultas
apenas em partes do arquivo, sem ter que carrega-lo todo.
Na documentação ainda existe uma seção chamada de “Como faço para
otimizar o uso de armazenamento para documentos pequenos? “(Mongodb, 2013) é
explicito que “Cada documento MongoDB contém uma certa quantidade recursos
30
ocupados. Esses recursos normalmente são insignificante, mas torna-se significativo
se todos os documentos inseridos são apenas alguns bytes, como poderia ser o
caso se os documentos em sua coleção só tem um ou dois campos.”(Mongodb,
2013)
Assim sendo, a documentação passa a seguinte sugestões como estratégia
para otimizar a utilização do armazenamento para coleções no mongodb:
Clientes MongoDB caso o usuário não insira um valor no campo _id o
mongobd adiciona automaticamente um campo _id a cada documento inserido, esse
campo _id gerar 12 byte únicos. Para documentos menores isto pode representar
uma quantidade significativa de espaço.
Para otimizar o uso de armazenamento, os usuários podem especificar um
valor para o campo _id explicitamente Ao inserir documentos na coleção. Esta
estratégia permite aplicações para armazenar um valor no campo _id Isso teria
espaço ocupado em outra parte do documento.
Você pode armazenar qualquer valor no campo _id, mas como este valor
serve como uma chave primária para documentos, caso esse valor do campo não
seja único, então ele não pode servir como uma chave primária havendo colisões de
chave primária duplicada, impedindo assim a identificação.
Na documentação ainda tem uma seção chamada de “Quando devo usar
GridFS?” está descrito que “Para documentos em uma coleção MongoDB, você
deve sempre usar GridFS para armazenar arquivos maiores que 16 MB.”(Mongodb,
2013). Em algumas situações, o armazenamento de arquivos grandes pode ser mais
eficiente no banco de dados MongoDB do que em um sistema de arquivos em nível
de sistema, a tabela 10 exibe essas situações.
Tabela - Situações onde o armazenamento de arquivos grandes pode ser mais
eficiente no sitema e arquivos
31
O sistema de arquivos limita o número de arquivos em um diretório, você
pode usar GridFS para armazenar arquivos como quanto necessário.
Quando você quer manter seus arquivos e metadados automaticamente
sincronizadas e implantado através de uma série de sistemas e
instalações. Ao utilizer uma definição de répicas distribuidas o mongodb pode
distribuir arquivos e seus metadados automaticamente para um número
de instâncias mongodb.
Quando você quiser acessar informações de partes de arquivos grandes sem
ter que carregar arquivos inteiros na memória, você pode usar GridFS
acessar seções de arquivos sem ler o arquivo inteiro na memória.
Fonte:MongoDB
Mas assim como existem situações onde ele não recomenda o uso do
GriFS, como por exemplo “Não use GridFS se você precisa atualizar o conteúdo de
todo o arquivo atomicamente.”(Mongosb, 2013) a alternative no caso de ter que
atualizar todo conteúdo é “Como alternativa, você pode armazenar várias versões de
cada arquivo e especificar a versão atual do arquivo de metadados. Você pode
atualizar o campo de metadados indica que "ultimo inserido" em uma atualização
atômica após carregar a nova versão do arquivo e, posteriormente, remover versões
anteriores, se necessário.”(Monogo, 2013)
A documentaçaõ ainda afirma que no caso de documentos menores que 16
megabytes que ”se seus arquivos são todos menores de 16 MB, tamanho limite do
documento BSON, considere armazenar o arquivo manualmente em um único
documento. Para isso poderá utilizar o tipo de dados BinData para armazenar os
dados binários.“(Mongodb, 2013)
3.
Considerações finais
Após a pesquisa, foi possível traçar e observar que cada banco de dados
armazena seus arquivos de forma peculiar, onde diferentes tipos de registro de
32
banco permitem inserir diferentes quantidades de registo, assim sendo, foi possível
criar uma projeção do armazenamento de dados nos bancos que acrescentam bytes
de controle na inserção de arquivos utilizando o tamanho máximo de cada tipo de
armazenamento de dados. A seguir iremos discorrer sobre como cada banco se
comporta.
3.1. MySql
No caso do MySql, a quantidade de dados adicionados aos registros
particionados e armazenados no tamanho máximo permitido no registro, faz com
que a adição dos dados chegue a 0,039% Já que existem quatro tipos de
armazenamento binários e quatro tipos de dados caracteres.
Tabela - Arquivo único
até 1
Megabyte
até 10
Megabytes
até 100
Megabytes
até 1
Gigabyte
até 10
Gigabytes
TINYBLOB(256
bytes)
BLOB(512 Kilobytes)
MEDIUMBLOB(16
Megabytes)
-
-
-
-
-
TA + 3 bytes
TA + 3 bytes
-
-
-
LONGBLOB(4
Gigabytes)
TA + 4 bytes
TA + 4 bytes
TA + 4 bytes
TA + 4 bytes
TA + 12 bytes
Fonte: Desenvolvida pelo autor
Tabela - Quantidade de partes do arquivo
Quantidade de partes do arquivo
até 10
até 100
até 1
Megabytes
Megabytes
Gigabyte
até 1
Megabyte
até 10
Gigabytes
TINYBLOB(255 bytes)
4113
41121
411207
4210753
42107523
BLOB(511 Kilobytes)
MEDIUMBLOB(15,99
Megabytes)
LONGBLOB(3,99
Gigabytes)
17
161
1601
16385
163843
1
1
7
65
641
1
1
1
3
1
Fonte: Desenvolvida pelo autor
Tabela - Quantidade de bytes adicionados aos registros
até 1
Megabyte
33
Quantidade de Bytes adicionados
até 10
até 100
até 1
Megabytes
Megabytes
Gigabyte
até 10
Gigabytes
Bytes
1048576
10485760
104857600
1073741824
10737418240
TINYBLOB(255 bytes)
1
4113
41121
411207
4210753
42107523
BLOB(511 Kilobytes)
2
34
322
3202
32770
327686
MEDIUMBLOB(15,99
Megabytes)
LONGBLOB(3,99
Gigabytes)
3
4
3
3
21
195
1923
4
4
4
4
12
Fonte: Desenvolvida pelo autor
Tabela - Tamanho final dos arquivos
até 1
Megabyte
Tamanho arquivo com bytes adicionados em bytes
até 10
até 100
até 1
Megabytes
Megabytes
Gigabyte
até 10
Gigabytes
Bytes
1048576
10485760
104857600
1073741824
10737418240
TINYBLOB(255 bytes)
1
1052689
10526881
105268807
1077952577
10779525763
BLOB(511 Kilobytes)
MEDIUMBLOB(15,99
Megabytes)
LONGBLOB(3,99
Gigabytes)
2
1048610
10486082
104860802
1073774594
10737745926
3
1048579
10485763
104857621
1073742019
10737420163
1048580
10485764
104857604
1073741828
10737418252
4
Fonte: Desenvolvida pelo autor
Tabela - Tamanho do arquivo com bytes adicionados
até 1
Megabyte
Tamanho arquivo com bytes adicionados
até 10
até 100
até 1
Megabytes
Megabytes
Gigabyte
TINYBLOB(255 bytes)
1048576
1,00
Megabytes
10485760
10,03
Megabytes
104857600
100,39
Megabytes
1073741824
1,00
Gigabaytes
BLOB(511 Kilobytes)
1,00
Megabytes
10,00
Megabytes
100,00
Megabytes
1,00
Gigabytes
MEDIUMBLOB(15,99
Megabytes)
1,00
Megabytes
10,00
Megabytes
100,00
Megabytes
1,00
Gigabytes
LONGBLOB(3,99
Gigabytes)
1,00
Megabytes
10,00
Megabytes
100,00
Megabytes
1,00
Gigabytes
até 10
Gigabytes
10737418240
10,03
Gigabytes
10,00
Gibaytes
10,00
Gibaytes
10,00
Gibaytes
Fonte: Desenvolvida pelo autor
3.1.1.
Postgres
No banco de dados posgtres não fica claro a forma com a quale le insere os
bytes de controle, especificando apenas que que são inseridos de 1 a 4 bytes de
controle. Assim sendo foi possível estabelecer o cenário de melhor e pior caso de
adição de bytes de controle onde mais uma vez os bytes de controle adicionados
chegam a menos de 1% do tamanho final do arquivo, a seguir será exibida uma
tabela com a projeção dos dados para um único arquivo inserido e para um arquivo
inserido em partes.
34
Tabela - Arquivo inteiro
Arquivo inteiro
Bytea melhor caso
Bytea pior caso
até 1 Megabyte
até 10
Megabytes
até 100
Megabytes
até 1 Gigabyte
até 10 Gigabytes
4 Bytes
1 byte
4bytes
1 byte
4bytes
1 byte
4bytes
1 byte
-
Fonte: Desenvolvida pelo autor
Tabela - Arquivo em partes
Arquivo em partes
Bytea melhor caso
Bytea pior caso
até 1 Megabyte
até 10
Megabytes
até 100
Megabytes
até 1 Gigabyte
até 10 Gigabytes
4 bytes
1 byte
4 bytes
1 byte
4 bytes
1 byte
4 bytes
1 byte
40 bytes
10 bytes
Fonte: Desenvolvida pelo autor
3.1.2.
Oracle
No caso do oracle 11g não a indicação de bytes que são adicionados nos
registro, assim como o tipo BLOB, CLOB, NCLOB que possuem um tamanho limite
de 128 terabytes podendo adicionar registros inteiros até o limite do tipo BLOB,
CLOB ou NCLOB.
3.1.3.
Mongodb
No mongodb os arquivos são inseridos por meio da biblioteca BSON no tipo
BinData no caso de arquivos menores de 16 megabytes, em arquivos superiores a
16 megabtyes é recomendável utilizar o GridFS para o armazenamento de dados
acima de 16 megabytes. O GridFS realiza a divisão do arquivo inserido em blocos
de 256 kilobytes, perminto que um documento seja acessado em seções
expecíficas, como por exempo minutos específicos de um vídeo ou mesmo de uma
música sem ter carregado o arquivo como um todo.
35
4. Resultados
Após a leitura da documentação foram elaborados pequenos testes de
gravação em sistema de arquivo e no banco de dados mongodb, esses teste
mostrou que a implementação da inserção de arquivo em base de dados pode ser
feita de forma simples e eficiente, assim como a utilização de banco de dados
NoSql. No caso do mongodb a inicialização do banco foi realizada de forma fácil
pelo console de comando, onde o usuário acessava a pasta bin dentro da pasta do
mongodb e digitando o comando mongod.exe –dbpath <caminho da pasta de
armazenamento>. Logo após inicializar o banco
O Exemplo desta facilidade de inserção de arquivos na base de dados pode
ser observada na figura 2 que mostra o algoritmo de inserção de arquivos no
mongodb utilizando o GridFS.
Figura - Código de inserção no mongodb
36
Antes de realizar a primeira inserção foi observado que a pasta do mongodb
onde era apontada na inicialização estava apenas com arquivos de controle, como
pode ser observado na figura 3.
Figura - Pasta inicial da base mongodb
Nos testes iniciais foram feitos uploads de um arquivo de 69 megabytes para
teste e foi possível observar na pasta do mongo que foram criados arquivos de
armazenamento e controle dos dados, o upload do mesmo arquivo foi feito onze
vezes para observar o comportamento do mongo com o mesmo aquivo e foi
observado que o mongodb alocou muito mais espaço que o conjunto de dados
enviados, como pode ser observado na figura 4.
Figura - Pasta da base mongodb após armazenar 11 arquivos de 69 megabytes
Após subir o mesmo arquivo 11 vezes foi realizada uma busca no banco de
dados mongodb para verificar como esses dados estavam armazenados e o
tamanho ocupado pelo banco de dados mongodb, essa consulta pode ser
observada na figura 5 e 6. Essa consulta foi feita no console do mongodb utilizando
37
o comando db.NomeDaColecao.find(), onde esse comando retorna todos os dados
armazenados na coleção estabelecida, já para observar o tamanho da base de
dados mongodb foi utilizado o comando show dbs.
Figura - Busca na base de dados mongodb
Figura - Tamanho do bado de dados após gravar 11 arquivos de 69 megabytes
Após observado o comportamento do mongodb no armazenamento de
arquivos, foi efetuado o teste de armazenamento de um arquivo de 192 kb, para
observar o tamanho que o arquivo de armazenamento aloca inicial para o sistema.
38
Essa nova coleção alocou um espaço inicial com dois arquivos, sendo um de 64
megabytes e outro de 128 megabytes, mostrando que armazenamento do mongodb
com GridFS aloca um espaço inicial de 192 megabytes. Esse comportamento pode
ser observado na figura 7.
Figura - Pasta da base mongodb após upload de arquivo de 192 kilobytes na
coleção ArquivoAteUmMega
Após as inserções no banco de dados mongodb foram realizados testes de
obtenção
do
arquivo
por
meio
do
GridFS
utilizando
o
comando
fs.findOne(NomeDoArquivo), onde o arquivo foi recuperado e gravado na pasta
temporária do sistema operacional, além de recuperar o arquivo o mongodb inseriu
um número randômico no nome do arquivo recuperado como pode ser obervado na
figura 8.
Figura - Pasta temporária onde foram gravados os arquivos recuperados do
mongodb
39
Os mesmo testes foram realizados gravando os dados em sistema de
arquivos, conforme a figura 9 e 10 mostra, os arquivos que foram feitos uploads
foram gravados em uma pasta especificada no código. Mas diferente do banco de
dados todas as versões que foram enviadas para o servidor foram sobrescritas pela
última versão, restando apenas um arquivo.
Figura - Pasta de gravação em sistema de aquios depois de 11 uploads de do
mesmo aquivo de 69 megabytes
Figura - Pasta de gravação em sistema de arquivos depois de 11 uploads do
mesmo aquivo de 69 megabytes e 1 upload de um arquivo de 192 Kilobytes
40
Conclui-se que no caso de gravações em sistema de arquivo deve ser feito
uma estratégia de gravação de arquivos em pastas diferentes ou com nomes
diferente sujeridos pelo sistema onde está sendo feito o upload, na figura 11 é
possível observar a comparação de como ficou a partas de arquivos gravados em
sistema de arquivos e no banco mongodb.
Figura - Arquivos gravados em sistema de arquivos e arquivos gravados no
mongodb
Além dos testes demostrados acima, foram realizados testes com outros
arquivos, na tabela 18 é possível observar os tempos de subida dos arquivos e
gravação em sistema de arquivos. Já na tabela 19 é possível observar os tempos do
armazenamento dos arquivos em banco de dados
Tabela - Gravação de dados em sistema de arquivos
41
O Arquivo ABNT_2011.pdf com tamanho 174145 bytes demorou 8 Milisegundos
O Arquivo ABNT_2011.pdf com tamanho 174145 bytes demorou 32 Milisegundos
O Arquivo ABNT_2011.pdf com tamanho 174145 bytes demorou 12 Milisegundos
O Arquivo Jmeter_Book.pdf com tamanho 5491754 bytes demorou 338 Milisegundos
O Arquivo Jmeter_Book.pdf com tamanho 5491754 bytes demorou 255 Milisegundos
O Arquivo Jmeter_Book.pdf com tamanho 5491754 bytes demorou 244 Milisegundos
O Arquivo apache-jmeter-2.8.zip com tamanho 26172552 bytes demorou 1715 Milisegundos
O Arquivo apache-jmeter-2.8.zip com tamanho 26172552 bytes demorou 1087 Milisegundos
O Arquivo apache-jmeter-2.8.zip com tamanho 26172552 bytes demorou 1049 Milisegundos
O Arquivo netbeans-7.3-macosx.dmg com tamanho 191977440 bytes demorou 14770 Milisegundos
O Arquivo netbeans-7.3-macosx.dmg com tamanho 191977440 bytes demorou 8015 Milisegundos
O Arquivo netbeans-7.3-macosx.dmg com tamanho 191977440 bytes demorou 7749 Milisegundos
O Arquivo dump.sql com tamanho 1075819688 bytes demorou 71142 Milisegundos
O Arquivo dump.sql com tamanho 1075819688 bytes demorou 117508 Milisegundos
O Arquivo dump.sql com tamanho 1075819688 bytes demorou 149303 Milisegundos
Fonte: Criado pelo autor.
Tabela - Gravação de dados em banco de dados
O Arquivo ABNT_2011.pdf com tamanho 174145 bytes demorou 1629 Milisegundos
O Arquivo ABNT_2011.pdf com tamanho 174145 bytes demorou 70 Milisegundos
O Arquivo ABNT_2011.pdf com tamanho 174145 bytes demorou 124 Milisegundos
O Arquivo Jmeter_Book.pdf com tamanho 5491754 bytes demorou 837 Milisegundos
O Arquivo Jmeter_Book.pdf com tamanho 5491754 bytes demorou 1047 Milisegundos
O Arquivo Jmeter_Book.pdf com tamanho 5491754 bytes demorou 813 Milisegundos
O Arquivo apache-jmeter-2.8.zip com tamanho 26172552 bytes demorou 4913 Milisegundos
O Arquivo apache-jmeter-2.8.zip com tamanho 26172552 bytes demorou 4268 Milisegundos
O Arquivo apache-jmeter-2.8.zip com tamanho 26172552 bytes demorou 3931 Milisegundos
O Arquivo netbeans-7.3-macosx.dmg com tamanho 191977440 bytes demorou 47690 Milisegundos
O Arquivo netbeans-7.3-macosx.dmg com tamanho 191977440 bytes demorou 92091 Milisegundos
O Arquivo netbeans-7.3-macosx.dmg com tamanho 191977440 bytes demorou 54252 Milisegundos
O Arquivo dump.sql com tamanho 1075819688 bytes demorou 637815 Milisegundos
O Arquivo dump.sql com tamanho 1075819688 bytes demorou 487902 Milisegundos
O Arquivo dump.sql com tamanho 1075819688 bytes demorou 626128 Milisegundos
Fonte: Criado pelo autor.
5. Conclusão
Ambos os métodos tem suas vantagens e desvantagens, assim sendo foi
elaborado a tabela 20 para indicar as vantagens e desvantagens do método de
gravação em arquivo de sistema e a tabela 21 para o método de gravação em banco
de dados.
Tabela - Vantagens e desvantagens da gravação em sistema de arquivos
Vantagens
Desvantagens
Arquivo gravado é do mesmo tamanho Dificuldade em realizar comparação das
do enviado.
Backup
configurado
operacional
Não necessita
42
instalar
no
um
versões de um arquivo
sistema Sem backup incremental dos aquivos
sistema Problemas em gerencias vários arquivos
gerenciador
em uma única pasta
Ao alterar um arquivo o mesmo deve ser
sobrescrito total em disco
Sistema de arquivo limita a quantidade
de aquivos em uma pasta
Fonte: Criado pelo autor.
Tabela - Vantagens e desvantagens de gravação em banco de dados
Backups
Vantagens
incrementais
feitos
Desvantagens
pelo Implementação
um
pouco
mais
gerenciado do banco
trabalhosa
Armazenar várias versões de um mesmo Adição de bytes de controle ou no
arquivo
arquivo
de
armazenamento,
necessitando de um espaço maior.
Não e necessário recuperar todo arquivo Performance reduzida, pois além de
para visualizar, sendo possível visualizar subir o arquivo, há a necessidade de
somente partes(Ex: streaming de video)
insert no banco de dados
Salvar apenas parte alterada do arquivo,
armazenando
assim
o
histórico
de
alterações
Altamente escalável
Fonte: Criado pelo autor.
Assim o presente trabalho conclui a sua visão de mostrar algumas das vangtagens
e desvantagens de cada médotod de arqmaenamento de arquivo enviado pela web,
sendo a escolha da forma de armazenamento de arquivos ser definida conforme a
necessidade e requisito do sistema implementado, fazendo com que quem irá
implementar avalie as vantagens e desvantagens de cada método, escolhendo quais
atenderá os requisitos e qual desvantagens não afetará todo sistema.
43
6. Referências
UOL notícias, Tecnologia. Ibope: internet no Brasil chega a 70,9 milhões
de pessoas em casa e no trabalho em setembro. Disponível em :
<http://tecnologia.uol.com.br/noticias/redacao/2012/11/01/ibope-internet-no-brasilchega-a-709-milhoes-de-pessoas-em-casa-e-no-trabalho-em-setembro.htm>,
acesso em 27 de fev. de 2013.
Cliente/Servidor. Arquitetura de Aplicações em 2, 3, 4 ou N camadas.
Disponível em: <http://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-34-ou-n-camadas/> , acesso em 14 de mar. 2013.
Exame.com, Tecnologia. Você sabe qual é o tamanho da internet?
Disponível em <http://exame.abril.com.br/tecnologia/noticias/voce-sabe-qual-e-otamanho-da-internet>, acesso 27 de fev. de 2013
BATTISTI, Júlio. SQL Server 2000: Administração e Desenvolvimento –
Curso Completo. 2. ed. Rio de Janeiro: Axcell Books, 2001.
CODD, Edgar F. Is your DBMS really relational? Computer World, 14 de
outubro de 1985.
Microsoft. Função do servidor de arquivos: Configurando um servidor de
arquivos. Disponível em: <http://technet.microsoft.com/ptbr/library/cc780253(v=ws.10).aspx> acesso em: 10 de novembro de 2012.
Microsoft. Visão geral da função de Servidor Web (IIS). Disponível em:
<http://technet.microsoft.com/pt-br/library/cc770634(v=ws.10).aspx >, acesso em 16
de nov. de 2012.
44
Oracle. Oracle® Database Concepts 11g Release 1 (11.1). Disponível em:
<http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm > Acesso em
19 Fev. 2013.
Oracle. Oracle® Database SQL Language Reference 11g Release 1
(11.1).
Disponível
em:
<http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm>
Acesso em 19 Fev. 2013.
Mongodb. FAQ: MongoDB for Application Developers. Disponível em:
<http://docs.mongodb.org/manual/faq/developers/> Acessado em 11 de fev. 2013.
MySql. The BLOB and TEXT Types. Disponível em:
<http://dev.mysql.com/doc/refman/5.0/en/blob.html> acessado 19 fev. 2013.
Postgres, PostgreSQL 9.2.3 Documentation. Disponível em
http://www.postgresql.org/docs/9.2/interactive/intro-whatis.html, Acessado em 25 de
fev. 2013
Postgres. 8.4. Binary Data Types. Disponível em :
<http://www.postgresql.org/docs/9.2/static/datatype-binary.html#DATATYPE-BINARYTABLE>, acessado 25 de fev. 2013
NoSql, Material para apresentação de seminário – 23/11/2012 NOSQL,
Vila
Velha
2012.
Disponível
em:
<http://123seminarsonly.com/Seminar-
Reports/2013-02/114144890-Material-Seminario-NoSQL.pdf>.
Serpro, A ESCOLHA DE UM BANCO DE DADOS RELACIONAL.
Disponível em <http://www1.serpro.gov.br/publicacoes/tematec/pubtem03.htm>,
Acesso em 14 de mar. 2013
45
Searchnetworking, Downloading, Disponível em :
<http://searchnetworking.techtarget.com/definition/downloading>, Acesso em 17 de
mar. 2013.
46